Side by Side deployment/Versioning

Production redeployment of application/ versioning/ side by side deployment

We need versioning for updating the application in production on runtime. The sessions which are already logged in will be using the previous version of the application and the new sessions created will use the new version of application.

1) In the application, Version-1 in MANIFEST.MF we need to add the following:

Manifest-Version: 1.0

Created-By: 1.5.0_04 (Sun Microsystems Inc.)

Weblogic-Application-Version: Version-1

Version-2 MENIFEST-MF

Manifest-Version: 1.0

Created-By: 1.5.0_04 (Sun Microsystems Inc.)

Weblogic-Application-Version: Version-1

2. Open a command window and browse to your domain bin directory.

3. start Admin server using Startweblogic.cmd.

4. Type setdomainenv.cmd to set your weblogic Domain.

5.Now to deploy the first version run the following command (please change as per your specifications):

C:\bea9.1\user_projects\domains\base_domain>java weblogic.Deployer -appversion 1 -adminurl http://127.0.0.1:7001 -username weblogic -password weblogic -deploy -name deployment_name -source c:/.../ -targets AdminServer

6. Now to Redeploy use the following command:

C:\bea9.1\user_projects\domains\base_domain>java weblogic.Deployer -appversion 2 -adminurl http://127.0.0.1:7001 -username weblogic -password weblogic -redeploy -name deployment_name -source c:/.../ -retiretimeout 120

7. We will get the version -1 application in retiring state in the console. The requests which were handled previously by this application will be handled by this version.

8. Version-2 application will have ACTIVE status and will be accepting new requests coming in to the application.

Reference:

http://download.oracle.com/otn_hosted_doc/wls/redeployment/wls-side-by-side-non-annotation_viewlet_swf.html

Configuration: WLDF Mail Notification for Runtime Mbean

Weblogic Diagnostics Framework can be used to analyze, collect, archive and access diagnostic data generated by a running server and the applications deployed within its containers.

Here I have provided configuration for sending mail notification on the harversted data for the runtime Mbean which you want to monitor.

1. From -> Diagnostics -> Diagnostics Module Create a diagnostic module and target it to server for which WLDF module has to be used.

2.

For the Diagnostics module created in step 1, create a Collection metrics for mbean you want to monitor:

a) Click on 'New’ to create a Collection Metrics

b) Select the Mbean Server location for which we want to collect data. It can be DomainRuntime or ServerRuntime Mbean.

c) Select the Mbean which has to be monitored

d) Select the Attributes which you want to collect for the Runtime Mbean selected in Step 2(c)

3) Create a mail session from Services -> Mail Session

a) Specify and JNDI name for mail session and the following as mail session properties:

mail.smtp.host=xxxxxxxx

mail.smtp.user=xxxxxxxxxxxxxx

b) Target the mail session to a server

4) Creating a Notification:

a) From Diagnostics -> Diagnostics Module -> Watches and Notification, Create a New Notification. Specify Notification Type as SMTP (email). Here Keep ‘Enable Notification’ as Checked and click ‘Next’

b) Here select the Mail session which we configured in Step 3 along with the Email Recipients who will be receiving the mail notification for Runtime mbean. Here we can edit the format of Email notification. Click Finish.

5) Create a Watch for Runtime mbean which was mentioned in Collection Metrics configured in Step 2 (Can be Server Log as well):

a) Select the Mbean location

b) Select Mbean to be monitored

c) Select instance for which the Mbean has to be monitored. (Only one instance can be selected at a time. Note: If we want to monitor Runtime Mbean for more than one instance then we can add expression selecting the same mbean for other servers. Refer Step 5-f)

d) Select the attribute for which watch has to be configured and apply desired operation to it. Attribute should be same as what we have configured in Collection Metrics.

f) Verify the Watch Rule Expression created from the previous steps followed. If you want the same mbean to be monitored for more than one server then click on ‘Add Expression’ tab follow steps 5-a through 5-e for other server instance. We can use ‘AND’/’OR’ operations to create Watch Rule as per requirement.

g) Select Alarm on the watch

h) Select the notification which we created in step 4 and Click Finish

After all the above setting we will get an email update if the condition mentioned in the watch rule is met.

Registering Custom MBeans with Weblogic Server

Registering Custom Mbeans with Weblogic Server.

Example.java

package jmxMbeans;

public class Example implements ExampleMBean {

      public void sayHello(String str) {

            System.out.println("Hello " + str + "'!");

      }

}

ExampleMbean.java

package jmxMbeans;

public interface ExampleMBean {

      void sayHello(String name);

}

Index.jsp

<%@ page import="javax.management.MBeanServer"%>

<%@ page import="javax.management.ObjectName"%>

<%@ page import="javax.naming.Context"%>

<%@ page import="javax.naming.InitialContext"%>

<%@ page import="java.util.Hashtable"%>

<%@ page import="jmxMbeans.ExampleMBean"%>

<%@ page import="jmxMbeans.Example"%>

<html>

<body>

<p>Registering Mbeans.</p>

<% 

    Example ex = new Example();

      MBeanServer mbeanServer = null;

      Hashtable<String, String> env = new Hashtable<String, String>();

    env.put(Context.SECURITY_PRINCIPAL, "weblogic");

      env.put(Context.SECURITY_CREDENTIALS, "weblogic");

      InitialContext ic = new InitialContext(env);

      mbeanServer = (MBeanServer) ic.lookup("java:comp/env/jmx/runtime");

      String MBEAN_OBJECT_NAME = "jmxMbeans:Name=Example,Type=ExampleMBean";

      registerMBean(mbeanServer,MBEAN_OBJECT_NAME,ex);

      unregisterMBean(mbeanServer,MBEAN_OBJECT_NAME);

   

%>

<%!

   void registerMBean(MBeanServer server,String mbeanObjectName,Object obj) {

   ObjectName objectName = null;

            try {

                  objectName = new ObjectName(mbeanObjectName);

                  server.registerMBean(obj, objectName);

                  System.out.println("MBean registered:" + objectName);

            } catch (Exception e) {

                  //log.log(Level.SEVERE, "Error registering MBean " + objectName, e);

            }

      }

%>

<%!

 void unregisterMBean(MBeanServer server,String mbeanObjectName) {

            ObjectName objectName = null;

            try {

                  objectName = new ObjectName(mbeanObjectName);

                  server.unregisterMBean(objectName);

                  System.out.println("MBean unregistered: " + objectName);

            } catch (Exception e) {

              System.out.println("Error unregistering MBean " + objectName);

              e.printStackTrace();

            }

      }

%>

</body>

</html>

Invoking the Custom MBean

test.jsp

Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "weblogic");
InitialContext ctx = new InitialContext(env);

try{

String MBEAN_OBJECT_NAME = "jmxMbeans:Name=Example,Type=ExampleMBean";
MBeanServer server = (MBeanServer) ctx.lookup("java:comp/env/jmx/runtime");
ObjectName objName = new ObjectName(MBEAN_OBJECT_NAME);
Object[] params = new Object[] {"Faisal"};
String[] sigs = new String[] {"java.lang.String"};
server.invoke(objName, "sayHello", (Object[])params, sigs);
}
catch(Exception e){
e.printStackTrace();
}
ctx.close();

Plan.xml usage for Message Driven Bean

This post is an illustration of usage of plan.xml for overriding features of Message Driven Bean application dynamically.

Administrators use deployment plans to easily change an application’s WebLogic Server configuration for a specific environment without modifying existing Java EE or WebLogic-specific deployment descriptors. Multiple deployment plans can be used to reconfigure a single application for deployment to multiple, differing WebLogic Server environments.

In the plan.xml we will override the  specified in the 

 element tag of the weblogic-ejb-jar.xml file.

Steps to be followed:-

 1:- Create a MDB listening to the Queue with the  

specified in the weblogic-ejb-jar.xml file.

2:- Generate the plan.xml file using the weblogic.PlanGenerator.

Ex:- java weblogic.PlanGenerator D:\ TestApp\TestMDB.jar –configurables

Once the plan.xml file is generated we can override the value for the provider-url as below.

   MessageDrivenDescriptor_ProviderUrlname>

   t3://localhost:7001value>

The corresponding mapping is done as below.

  MessageDrivenDescriptor_ProviderUrlname> /weblogic-ejb-jar/weblogic-enterprise-bean

/[ejb-name="TestMDB"]/message-driven-descriptor/provider-url

After overriding the  value from the plan.xml, run the weblogic.Deployer command to deploy 

the application specifying the deployment plan as below.

java weblogic.Deployer -adminurl t3://localhost:7001 -user weblogic 

-password weblogic -deploy -name TestAPP 

-source D:\TestAPP.ear -targets AdminServer -stage -plan D:\plan.xml

This would override the  dynamically, not requiring to manually edit the weblogic-ejb-jar.xml.

Hope the post is helpful for those who would like to use 

the same archive files for different environments overcoming 

the tedious job of manually editing the deployment descriptors.

I have uploaded the sample application as well for further references.

http://www.4shared.com/file/161924469/59a49461/Planxml-Usage.html

Any feedback or queries would be highly appreciated.

Please refer the below blog for some great stuff related to WebLogic Security.

http://secure-zone.blogspot.com/

References:-

http://download.oracle.com/docs/cd/E13222_01/wls/docs90/deployment/wlplangenerator.html