Thursday, April 17, 2014

WLST script to update Graceful Shutdown parameters in weblogic server

WLST script to update Graceful Shutdown parameters in weblogic server


A graceful shutdown gives WebLogic Server subsystems time to complete certain application processing currently in progress.

Graceful Shutdown


The Graceful Shutdown command transitions a server instance from the RUNNING state to the SHUTDOWN state, allowing work in process to be handled gracefully, with this sequence of state transitions:

RUNNING > SUSPENDING > ADMIN > SHUTTING_DOWN > SHUTDOWN

Controlling Graceful Shutdown


Ignore Sessions During Shutdown — If you enable this option WebLogic Server will drop all HTTP sessions immediately, rather than waiting for them to complete or timeout. Waiting for abandoned sessions to timeout can significantly lengthen the graceful shutdown process, because the default session timeout is one hour.

Graceful Shutdown Timeout — Specifies a time limit for a server instance to complete a graceful shutdown. If you supply a timeout value, and the server instance does not complete a graceful shutdown within that period, WebLogic Server performs a forced shutdown on the server instance.

This tutorial explains the approach to update graceful update parameters through WLST script in weblogic

WLST Script


The script will help us to update the Graceful Shutdown parameter for the servers in the weblogic domain.

UpdateGracefulShutdownParameters.py


Script

https://github.com/techforum-repo/youttubedata/blob/master/scripts/wlst/UpdateGracefulShutdownParameters.py

Before executing the script, change the configurations as required.

Execute the script — <<Oracle_Home>>\oracle_common\common\bin\wlst.cmd UpdateGracefulShutdownParameters.py

Now the Graceful Shutdown Parameters updated for all the servers in the domain




Thursday, April 3, 2014

Getting the Messaging Bridge Runtime Details through Java - Weblogic

Getting the Messaging Bridge Runtime Details through Java - Weblogic

The below java jmx code will help us to get the run time details of the messaging bridge in weblogic server.

import java.util.Hashtable;
import javax.management.MBeanServerConnection;
import javax.management.ObjectName;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import javax.naming.Context;

public class GetMessageBridgeStatus {
    private static MBeanServerConnection connection;
    private static JMXConnector connector;
    public static void  getMessageBridgeStatus() {
        try
        {
                getRuntimeMBeanServerConnection();
                String son = "com.bea:ServerRuntime=AdminServer,Name=Bridge-0,Location=AdminServer,Type=MessagingBridgeRuntime";
                ObjectName service = new ObjectName(son);
                String status = connection.getAttribute(service,"State").toString();
                System.out.println("Status: "+status);
         
                String description = connection.getAttribute(service,"Description").toString();
                System.out.println("Descrption: "+description);
       
        }catch(Exception e) {
           e.printStackTrace();
        }
         
    }
    public static void getRuntimeMBeanServerConnection()  throws Exception{
          String jndiroot = "/jndi/";
          String mserver = "weblogic.management.mbeanservers.domainruntime";
          JMXServiceURL serviceURL = new JMXServiceURL("t3", "localhost", 8000,jndiroot + mserver);
          Hashtable h = new Hashtable();
          h.put(Context.SECURITY_PRINCIPAL, "weblogic");
          h.put(Context.SECURITY_CREDENTIALS, "welcome1");
          h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,"weblogic.management.remote");
          connector = JMXConnectorFactory.connect(serviceURL, h);
          connection = connector.getMBeanServerConnection();
    }
 
    public static void main(String[] args) {
        getMessageBridgeStatus();
    }
 
}


Include the wlfullclient.jar file in the class path(Refer the following post https://www.albinsblog.com/2012/07/creating-wlfullclientjar-weblogic.html to generate the wlfullclient.jar )


Wednesday, March 12, 2014

weblogic.management.ManagementException: [Deployer:149014]Target 'wlsbJMSServer' is not defined.

weblogic.management.ManagementException: [Deployer:149014]Target 'wlsbJMSServer' is not defined.

Sometimes we may receive the following exception when trying to deploy a web application from JDeveloper to weblogic server.

[02:44:09 PM] ----  Deployment started.  ----
[02:44:09 PM] Target platform is  (Weblogic 10.3).
[02:44:12 PM] Retrieving existing application information
[02:44:12 PM] Running dependency analysis...
[02:44:12 PM] Building...
[02:44:17 PM] ****  One or more compilation errors prevented deployment from continuing.
[02:44:17 PM] ****  Please correct all compilation errors before deploying.
[02:44:17 PM] ####  Deployment incomplete.  ####
[02:44:17 PM] ****  One or more compilation errors prevented deployment from continuing. (oracle.adfdt.common.deploy.impl.AdfLibraryBuildDeployer)
[02:45:08 PM] ----  Deployment started.  ----
[02:45:08 PM] Target platform is  (Weblogic 10.3).
[02:45:09 PM] Retrieving existing application information
[02:45:09 PM] Running dependency analysis...
[02:45:09 PM] Building...
[02:45:10 PM] Deploying profile...
[02:45:11 PM] Wrote Web Application Module to C:\JDeveloper\mywork\GettingPayload\GetPayloadWeb\deploy\GetPayloadWeb.war
[02:45:11 PM] Deploying Application...
[02:45:24 PM] Weblogic Server Exception: weblogic.management.ManagementException: [Deployer:149014]Target 'wlsbJMSServer' is not defined.
[02:45:24 PM]   See server logs or server console for more details.
[02:45:24 PM] weblogic.management.ManagementException: [Deployer:149014]Target 'wlsbJMSServer' is not defined.
[02:45:24 PM] ####  Deployment incomplete.  ####
[02:45:24 PM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)

The issue is due to wlsbJMSServer target is not defined in weblogic server.

We can avoid this error and continue with the deployment by selecting the option as Deploy to selected instances in the domain and selecting the particular server or cluster instead of selecting the option as Deploy to all instances in the domain from the JDeveloper deployment wizard.




This is a temporary solution to continue with the deployment but we have to correct the Target issue.


Wednesday, March 5, 2014

Wildcard SSL HostnameVerifier in Weblogic Server

Wildcard SSL HostnameVerifier in Weblogic Server

Before WLS release 10.3.5, weblogic  servers's hostname verification code did not supports the wildcard certificate by default we have to create a custom hostname verification code to handle this scenario but from WLS release 10.3.5, weblogic servers  hostname verification code  by default supports the wildcard certificates.

Wildcard SSL Certificates work the same way as a regular SSL Certificate, allowing you to secure the connection between the client and server(www.abc.com) but a single Wildcard SSL Certificate covers any and all of the sub-domains of the main domain(*.abc.com)

Configuring Wildcard SSL HostnameVerifier:

  • Launch WLS console
  • Click on Environment -> Servers and click on the server
  • Then go to SSL tab
  • Lock & Edit
  • Scroll down and expand advanced section
  • Change Hostname verification entry to Custom Hostname Verifier
  • Enter Below in Custom Hostname verifier "weblogic.security.utils.SSLWLSWildcardHostnameVerifier"

  • Make sure the option Use JSSE SSL is selected.


  • Restart the weblogic server.


Wednesday, October 30, 2013

Weblogic Managed server status struck in STARTING

Weblogic Managed server status struck in STARTING

We faced the issue while starting the weblogic managed server, the status of the server struck in STARTING.

W could not able to find a valid error messages in the log files

Managed Server Log File:

<30-Oct-2013 11:13:29 o'clock GMT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING> 

No logs are getting printed after this.

Node Manager Log File:


<30-Oct-2013 11:09:44> <INFO> <SOACoreDomain> <MS1> <Server failed during startup so will not be restarted>
<30-Oct-2013 11:09:44> <WARNING> <Exception while starting server 'MS1'>
java.io.IOException: Server failed to start up. See server output log for more details.
      at weblogic.nodemanager.server.AbstractServerManager.start(AbstractServerManager.java:200)
      at weblogic.nodemanager.server.ServerManager.start(ServerManager.java:23)
      at weblogic.nodemanager.server.Handler.handleStart(Handler.java:604)
      at weblogic.nodemanager.server.Handler.handleCommand(Handler.java:121)
      at weblogic.nodemanager.server.Handler.run(Handler.java:71)

      at java.lang.Thread.run(Thread.java:662)

The root cause of this issue is somehow the ldap directory of the server got corrupted.

To resolve this issue:

  •  Kill the managed server 
  •  Remove the ldap folder from the following location  <<DOMAIN_HOME>>/servers/<<Managed Server>>, this file will be auto generated while restarting the server.
  • Restart the server


Tuesday, March 12, 2013

Creating Foreign JMS Server configurations through WLST script in Weblogic server

Creating Foreign JMS Server configurations through WLST script in Weblogic server


WebLogic JMS enables you to reference foreign (that is, external) JMS providers within a local WebLogic JNDI tree. Using the Foreign JMS Server node, you can quickly map a foreign JMS provider so that its connection factories and destinations appear in the WebLogic JNDI tree as a local JMS objects.

A Foreign JMS Server configuration can also be used to reference remote instances of WebLogic Server in another cluster or domain in the local WebLogic JNDI tree

Once the Foreign Provider is configured within Weblogic, for all practical purposes within the code — it can be called as if it was on local JNDI lookup. Weblogic will make the remote calls transparent to your code. This allows you to change your destination via configuration on the Weblogic console.

This tutorial explains the approach to configure Foreign JMS server through WLST script
WLST Script

The below WLST script help us to create a Foreign JMS server in a local server for a JMS resources running in a remote weblogic server(in different domain) but the same can be used to configure Foreign Server with external providers .

The JMS Server running on t3://localhost:7002 is configured as a Foreign JMS Server for t3://localhost:7002

The JMS clients can use the local JNDI configured in the local server to send the messages to the remote JMS server.

The same script can be modified to create a Foreign JNDI Server for other JMS providers, some of the important remote server properties to be modified is remoteDestinationJNDI, remoteConnectionFactoryJNDI, remoteConnectionURL, initialJNDIContextFactory, remoteUserName and remotePassword

ConfigureForeignJMSServer.properties

adminUserName=weblogic
adminUserPassword=weblogic1
adminServerHost=localhost
adminServerPort=7001foreignJMSModuleName=BAMForeginJMSResource
foreignJMSServerName=BAMForeignJMSServer
localConnectionFactoryJNDI=jms/BAMMonitoringConnectionfactory1
remoteConnectionFactoryJNDI=jms/BAMMonitoringConnectionfactory1
localDestinationJNDI=jms/BAMMonitoringQueue1
remoteDestinationJNDI=jms/BAMMonitoringQueue1remoteConnectionURL=t3://localhost:7002
initialJNDIContextFactory= weblogic.jndi.WLInitialContextFactory
remoteUserName=weblogic
remotePassword=welcome1

ConfigureForeignJMSServer.py

from java.io import FileInputStreampropInputStream = FileInputStream("ConfigureForeignJMSServer.properties")
configProps = Properties()
configProps.load(propInputStream)connect(configProps.get("adminUserName"),configProps.get("adminUserPassword"), 't3://'+configProps.get("adminServerHost")+':'+configProps.get("adminServerPort"))foreignJMSModuleName=configProps.get("foreignJMSModuleName")
foreignJMSServerName=configProps.get("foreignJMSServerName")
localConnectionFactoryJNDI=configProps.get("localConnectionFactoryJNDI")
localDestinationJNDI=configProps.get("localDestinationJNDI")remoteDestinationJNDI=configProps.get("remoteDestinationJNDI")
remoteConnectionFactoryJNDI=configProps.get("remoteConnectionFactoryJNDI")remoteConnectionURL=configProps.get("remoteConnectionURL")
initialJNDIContextFactory=configProps.get("initialJNDIContextFactory")
remoteUserName=configProps.get("remoteUserName")
remotePassword=configProps.get("remotePassword")edit()
startEdit()cd('/')
cmo.createJMSSystemResource(foreignJMSModuleName)cd('/SystemResources/'+foreignJMSModuleName)
set('Targets',jarray.array([ObjectName('com.bea:Name=AdminServer,Type=Server')], ObjectName))cd('/JMSSystemResources/'+foreignJMSModuleName+'/JMSResource/'+foreignJMSModuleName)
cmo.createForeignServer(foreignJMSServerName)cd('/JMSSystemResources/'+foreignJMSModuleName+'/JMSResource/'+foreignJMSModuleName+'/ForeignServers/'+foreignJMSServerName)
cmo.setDefaultTargetingEnabled(true)cmo.setJNDIPropertiesCredential(remotePassword)cmo.setInitialContextFactory(initialJNDIContextFactory)
cmo.setConnectionURL(remoteConnectionURL)
cmo.createJNDIProperty('java.naming.security.principal')cd('/JMSSystemResources/'+foreignJMSModuleName+'/JMSResource/'+foreignJMSModuleName+'/ForeignServers/'+foreignJMSServerName+'/JNDIProperties/java.naming.security.principal')
cmo.setValue(remoteUserName)cd('/JMSSystemResources/'+foreignJMSModuleName+'/JMSResource/'+foreignJMSModuleName+'/ForeignServers/'+foreignJMSServerName)cmo.createForeignConnectionFactory('ForeignJMSConnectionFactory')cd('/JMSSystemResources/'+foreignJMSModuleName+'/JMSResource/'+foreignJMSModuleName+'/ForeignServers/'+foreignJMSServerName+'/ForeignConnectionFactories/ForeignJMSConnectionFactory')
cmo.setLocalJNDIName(localConnectionFactoryJNDI)
cmo.setRemoteJNDIName(remoteConnectionFactoryJNDI)cd('/JMSSystemResources/'+foreignJMSModuleName+'/JMSResource/'+foreignJMSModuleName+'/ForeignServers/'+foreignJMSServerName)
cmo.createForeignDestination('ForeignJMSDestination')cd('/JMSSystemResources/'+foreignJMSModuleName+'/JMSResource/'+foreignJMSModuleName+'/ForeignServers/'+foreignJMSServerName+'/ForeignDestinations/ForeignJMSDestination')
cmo.setLocalJNDIName(localDestinationJNDI)
cmo.setRemoteJNDIName(remoteDestinationJNDI)activate()

Script

https://github.com/techforum-repo/youttubedata/tree/master/scripts/wlst/ConfigureForeignJMSServer

Before executing the script, change the configurations as required.

Execute the script — <<Oracle_Home>>\oracle_common\common\bin\wlst.cmd ConfigureForeignJMSServer.py







Now the foreign JMS server is configured and ready for use — the messages can be send/receive through local JNDI’s , Weblogic server internally communicate to the remote server. The foreign JMS server configuration helps as to abstract the remote server details from clients, the remote server implementations can be changed any time without impacting the clients


Monday, March 11, 2013

Creating JMS Adapter connection factory through WLST script in weblogic server

Creating JMS Adapter connection factory through WLST script in weblogic server:

The below WLST script will help us to create the JMS adapter connection factories. Before Executing the script change the details accordingly.

configureJMSAdapterConnection.py

TargetServerName='AdminServer'

soaHome='oracle/Middleware/Oracle_SOA1'

appPathJms=soaHome+'/soa/connectors/JmsAdapter.rar'
appNameJms='JmsAdapter'
moduleOverrideNameJms=appNameJms+'.rar'
JMSJNDIName = 'eis/wls/BAMQueueConnection'
JMSConnectionfactory='jms/BAMMonitoringConnectionfactory'
#Sever Details

moduleDescriptorName='META-INF/weblogic-ra.xml'
planPathJms=soaHome+'/soa/connectors/Plan_JMS.xml'

def createJMSConnectionFactory():

        edit()
        startEdit()
        startApplication(appNameJms)
        myPlanJms=loadApplication(appPathJms, planPathJms)
        makeDeploymentPlanVariable(myPlanJms,'ConnectionInstance_eis/Jms_JNDIName_13102979357209', JMSJNDIName , '/weblogic-connector/outbound-resource-adapter/connection-definition-group/[connection-factory-interface="oracle.tip.adapter.jms.IJmsConnectionFactory"]/connection-instance/[jndi-name="'+JMSJNDIName+'"]/jndi-name',moduleOverrideNameJms)
        makeDeploymentPlanVariable(myPlanJms, 'ConfigProperty_eis/JMS_JNDIName_ConnectionFactory_Name_13102979357210', JMSConnectionfactory,'/weblogic-connector/outbound-resource-adapter/connection-definition-group/[connection-factory-interface="oracle.tip.adapter.jms.IJmsConnectionFactory"]/connection-instance/[jndi-name="'+JMSJNDIName+'"]/connection-properties/properties/property/[name="ConnectionFactoryLocation"]/value',moduleOverrideNameJms)

        myPlanJms.save();
        save();
        cd('/AppDeployments/JmsAdapter/Targets');
        updateApplication(appNameJms, planPathJms);
        activate(block='true');
     
  
def makeDeploymentPlanVariable(wlstPlan, name, value, xpath,overrideName, origin='planbased'):
    wlstPlan.destroyVariable(name)
    wlstPlan.destroyVariableAssignment(name, overrideName, moduleDescriptorName)
    variableAssignment = wlstPlan.createVariableAssignment(name, overrideName, moduleDescriptorName)
    variableAssignment.setXpath(xpath)
    variableAssignment.setOrigin(origin)
    wlstPlan.createVariable(name, value)
    print 'moduleDescriptorName=',moduleDescriptorName


def main():
       adminURL='t3://localhost:9001'
       adminUserName='weblogic'
       adminPassword='welcome1'
       connect(adminUserName, adminPassword, adminURL)
       createJMSConnectionFactory()
       disconnect()
main()

Login to the server, cd to the folder where the script is available and execute the script as shown below.

%MIDDLEWARE_HOME%\wlserver_10.3\common\bin\wlst.cmd configureJMSAdapterConnection.py


Monday, March 4, 2013

WLST script to configure JMS resources in weblogic server

WLST script to configure JMS resources in weblogic server

A JMS queue/Topic in Weblogic Server is associated with a number of additional resources:

JMS Server


A JMS server acts as a management container for resources within JMS modules. Some of its responsibilities include the maintenance of persistence and state of messages and subscribers. A JMS server is required in order to create a JMS module.

JMS Module


A JMS module is a definition which contains JMS resources such as queues and topics. A JMS module is required in order to create a JMS queue.

Subdeployment


JMS modules are targeted to one or more WLS instances or a cluster. Resources within a JMS module, such as queues and topics are also targeted to a JMS server or WLS server instances. A subdeployment is a grouping of targets. It is also known as advanced targeting.

Connection Factory


A connection factory is a resource that enables JMS clients to create connections to JMS destinations.

Persistent Store


It can be a UserDefined Persistent Store or a Default Persistent store. It is used for storing the Data (Messages).

JMS Queue/JMS Topic


JMS queue is a point-to-point destination type. A message is written to a specific queue or received from a specific queue.

JMS Topic follows Publish/Subscribe(Pub/Sub) model. Pub/sub messaging applications send and receive messages by subscribing to a topic

In this tutorial, we are going to configure JMS Queue with required additional resources through WLST script

WLST Script


The below script will help us to define the required JMS resources to enable the messaging queue

JMSConfiguration.properties
adminUserName=weblogic
adminUserPassword=weblogic1
adminServerHost=localhost
adminServerPort=7001
JMSConfiguration.py
from java.io import FileInputStream


Script

https://github.com/techforum-repo/youttubedata/tree/master/scripts/wlst/JMSConfiguration

Before executing the script, change the configurations as required.

Execute the script — <<Oracle_Home>>\oracle_common\common\bin\wlst.cmd JMSConfiguration.py



Now the required JMS resources are created and the queue is ready for messaging

The queue can be accessed using the below JNDI names

jms/BAMMonitoringConnectionfactory
jms/BAMMonitoringQueue







Wednesday, December 12, 2012

Creating the reports based on the data from weblogic JMS queue – Oracle BAM

Creating the reports based on the data from weblogic JMS queue – Oracle BAM


Oracle BAM supports the reporting based on the data from External Messaging Sources.
This post explains the steps to create a report based on the data from the weblogic Queue.

Create the data object:

Create a data object with required fields to populate the data from the JMS Queue (Refer the previous post for the steps to create the Data Object).Here I am creating the Employee data object with three fields.

Configure the External Messaging Source:

These steps configure the JMS queue and map the JMS data to the data object (Employee) created in the previous step.
  • Click on Architect button from the Start up page.
  • Select External Message Source from the drop down list.
  • Enter the name for the message source and also the JNDI Service provider URL, Queue connection factory name and Queue name.
  • Select the JMS Message Type as TextMessage.
  • Select the Data object name as Employee created in the previous step and also select the operation as Insert.


Wednesday, October 24, 2012

ResourceLimitException : No resources currently available in pool to allocate to applications – Oracle SOA 11g

ResourceLimitException : No resources currently available in pool to allocate to applications – Oracle SOA 11g

You could have observed the below exception frequently in the weblogic server log file, weblogic server throws the below exception when there is not enough database connections in the pool to serve the incoming requests reporting increasing the connection pool count. This will affect the overall system  performance

java.sql.SQLException: Internal error: Cannot obtain XAConnection weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool SOADataSource to allocate to applications, please increase the size of the pool and retry..
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResourceInternal(ResourcePoolImpl.java:577)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:342)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:329)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:417)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:324)


The above exception is due to there is not enough connections available in the pool to service the requests.

To identify which datasource / connection pool requires more connection do the following.

  • Go to Weblogic Admin console
  • Go to Environment -> Servers
  • Select the server on which the connection pool needs to be monitored
  • Go to Monitoring -> JDBC
  • Customize the table to add the below two properties
This page will list all the datasources/ connection pools targeted to that particular server and how many connections are waiting to get the connection. If more number of connections are waiting, that is not a good which will cause performance impact and also cause stuck threads on the server if the wait time is going to be beyond the thread stuck time (By default it's 10 mins).

(This screen shot taken by reducing the max capacity to 5 for blogging purpose, unfortunately I did not captured the actual screen shot)


Saturday, October 6, 2012

Changing the weblogic server admin console timeouts.

Changing the weblogic server admin console timeouts.

This post will explain how to change the weblogic server admin console timeouts.

The console application can be find at the below location
$WEBLOGIC_HOME\server\lib\consoleapp

Change the directory location to $WEBLOGIC_HOME/server/lib/consoleapp/webapp/WEB-INF and open the weblogic.xml in a text editor.

Look for a session param tag with the name as "invalidation-interval-secs" and "timeout-secs"

Default Values

<session-descriptor>
    <timeout-secs>3600</timeout-secs>
    <invalidation-interval-secs>60</invalidation-interval-secs>

    <cookie-name>ADMINCONSOLESESSION</cookie-name>
    <cookie-max-age-secs>-1</cookie-max-age-secs>
    <url-rewriting-enabled>false</url-rewriting-enabled>
 </session-descriptor>

Change the value for "invalidation-interval-secs" and "timeout-secs" as per your requirement and restart the Weblogic Admin Server.

Login to weblogic admin console and verify the same.


If the EM console is deployed to weblogic server(EM console will be part of domain if any of the middleware component is installed) then the session timeout can be increased as follows.

Login to EM console and open the MBean Browser(Right click soa-infra-->Administartion-->System MBean Browser)

Enter the following value into the Mbean Browser filter and click on ok.


Change the session timeout value accordingly and click on Apply.




Tuesday, September 25, 2012

Weblogic Monitoring Dashboard to monitor the resources

Weblogic Monitoring Dashboard to monitor the resources


Monitoring dashboard is the new feature of latest weblogic server to view diagnostic data without doing additional setup.

This is the extension of the WLDF framework. The Monitoring Dashboard provides views and tools for graphically presenting diagnostic data about servers and applications running on them. The underlying functionality for generating, retrieving, and persisting diagnostic data is provided by the WebLogic Diagnostics Framework. The Monitoring Dashboard provides additional tools for presenting that data in charts and graphs.

The Monitoring dashboard can be launched from the home page of the Web logic administration console or pointing to the direct URL.


Direct URL to access the Monitoring Dashboard - http://<Server Host>:<Server Port>/console/dashboard


Monday, September 24, 2012

Weblogic Server Deployment Staging Configuration

Weblogic Server Deployment Staging Configuration:


We can deploy, redeploy, undeploy, and distribute applications using Weblogic server Administration Console, ANT script or through WLST script.

We can deploy an application as a single archive EAR file or as an exploded archive directory.
Before deploying the application the following server level configuration should be done based on our requirement.

Staging Mode:

The mode that specifies whether an application's files are copied from a source on the Administration Server to the Managed Server's staging area during application preparation.

Nostage mode: 

The Administration Server does not copy the deployment unit files to the target servers. The deployment units are deployed directly from the source. This mode is useful when deploying very large deployments to multiple targets. This is the default staging mode for the Administration Server.

Stage mode: 

The Administration Server copies the deployment unit files to the staging directories of target servers and they are deployed using the local copy. This mode is useful when deploying small size applications. This is the default staging mode for Managed Servers.

External mode:

In this mode you manually copy the deployment units  to the staging directories and then deploy.

Staging Directory Name:

The directory path on the Managed Server where all staged (prepared) applications are placed.

Upload Directory Name:

The directory path on the Administration Server where all uploaded applications are placed.

Configure Deployment Staging:

  • Log in to Weblogic server Admin console and click on Servers
  • Click on particular Server then Click on Deployment
  • Configure the deployment staging accordingly.


Changing Default JPA Provider in WebLogic Server

Changing Default JPA Provider in WebLogic Server :


WebLogic Server has been providing both Kodo and TopLink as JPA providers since WLS 10.3.1.
Unless an explicit <provider>...</provider> is specified in the persistence.xml file of a deployed application, WLS will use Kodo by default.

With the release of WLS 10.3.3, we have now provided a way to change the default JPA provider at the domain level, allowing you to switch between Kodo or TopLink as the default persistent provider that weblogic server will use.

The default JPA provider setting is exposed via a new MBean: JPAMBean on the DomainMBean, and persists the configuration into the config.xml file.

Steps to Change the Default provider:

  • Login to weblogic server console
  • Click on the Domain and click on JPA
  • Change the Default JPA Provider to TopLink and click on Save



Oracle TopLink is the default persistence provider in WebLogic Server 12c and later but you can change to Kodo if required.