Migrating J2EE application from from Weblogic to JBOSS application server

1 Objective

Objective of this document provide insights, consideration and configuration changes that needs to be done for migrating the j2ee application from BEA Weblogic application server to JBOSS application server.


2 Assumptions

· Third party libraries used with Weblogic application servers are compatible with the JBoss application server
· If migration requires any JDK version upgrades, those changes are not covered in the scope of the requirement
· Migrations of third party adapters needed to communicate to third party component are not covered.
· Target Jboss version considered is 4.2


3 Migration Process

3.1 Potential issues with migrations

Java enterprise application servers are standard driven and adheres to JEE specifications. Even in that case when we want to migrate j2ee enterprise application from one application server to another application server, there are potential issues like

1. Completeness of Specifications:

Though JEE specification is very comprehensive some of the behaviors are not defined in specification like Class loading , clustering etc. which are critical for application migration

2. JDK compatibility :

Every vendor has implemented JDK like sun Microsystems , Bea Jrocket JDK. There could be subtle different behavior and bugs can be found between different java virtual machine

Following link provides the OS and JDK compatibility for JBOSS Application server 4.2 and 4.3

http://www.jboss.com/products/platforms/application/testedconfigurations/

1. Class loading mechanism


Web-logic class loader policy :

Following diagram depicts the class loader hierarchy for

Weblogic application server

JBOSS Server class loader

For the details about JBOSS class loader hierarchy you can find at
JBOSS Classloader hierarchy



As shown in the above figure the class loading mechanism is different between two application server. While migrating the application, review of class lading hierarchy requirements and isolation level of class loader across various modules ( wars, jars, rars) in the applications are necessary.


4. Different Specification versions

Weblogic (current version) and JBOSS (target version) may be supporting different JEE specification and underling JDK version . IT management needs to take decision about which specification needs to be targeted


5. Use of application server specifics

There could be some weblogic specific components that the applications is using , Typical candidates are
· Security Realms , context lookup, datasource , JMS configuration
· WEbservices developed using weblogic framework
· Proprietary components
· Clustering and caching mechanism , session replications
· Connection to third party systems for e.g integration adapters to systems like SAP, Siebel , People soft


3.2 Migration process Steps

Following diagram represent migration processes

Setting Up Default Isolation level on WAS 6.1

Setting a right Isolation level for database operation is critical for performance of the database operation performed in online or batch application.

Following are different isolation levels

1. READ Uncommited
2. READ_COMMITED
3. REPEATABLE_READ
4. Serializable

Read Uncommited provides highest level of concurrancy and best performance, while Serialization provides lowest level of concurrecy , highest level of transaction isolation and lowest performance.

The need of iolstaion level is an application specific requirement and can differ from transaction to transaction.

In J2EE application, isolation level can be set at application server (data source setting level ) as well as application level using declarative configuration. ( In EJB application, it can be defiend in server specific deployment discriptor or in Spring based applciation , it can be defined in the transaction manager configuration using element )

If this is not defined application server defaults it to default transaction level depending upon driver and application server setting

For most drivers, WebSphere Application Server uses an isolation level default of TRANSACTION_REPEATABLE_READ. For Oracle drivers, however, WebSphere Application Server uses an isolation level of TRANSACTION_READ_COMMITTED.

Use the following table for quick reference:
1. Sybase : RR
2. Oracle : RC
3. DB2: RR
4. Informix : RR
5. Cloudscape : RR
6. DB2 : RR
7. SQL Server : RR


• Note: These same default isolation levels are used in cases of direct JNDI lookups of a data source.
• RR = JDBC Repeatable read (TRANSACTION_REPEATABLE_READ)
• RC = JDBC Read committed (TRANSACTION_READ_COMMITTED)

WebSphere 6.1 allows us to specify the default Isolation level as a customproperty on the data source definition.
To Set this Data Source custom property webSphereDefaultIsolationLevel can be used

Data Source custom property : webSphereDefaultIsolationLevel

Possible values : 1, 2, 4, 8

Value JDBC ISOLATION Level DB2 Isolation Level

8 TRANSACTION_SERIALIZABLE Repeatable Read (RR)

4 TRANSACTION_REPEATABLE_READ Read Stability (RS)

2 TRANSACTION_READ_COMMITTED Cursor Stability (CS)

1 TRANSACTION_READ_UNCOMMITTED Uncommitted Read (UR)

Following are the instructions to add custom property for a data source using Administrative console:
1. Configure the JDBC provider using Creating and configuring a JDBC provider using the administrative console and the Data Source using Creating and configuring a data source using the administrative console
2. Expand Resources > JDBC provider >
3. Select the Configured_JDBC_Provider
4. Select DataSource
5. Click on the name of the Data Source for which you want to customize the default Isolation level
6. Under additional properties, click Custom properties
7. Click New to add a new custom property, specifying the name webSphereDefaultIsolationLevel and type the desired value (possible values: 1, 2, 4, 8)
8. Click OK, and save the configuration; resync the node if you are using the Network Deployment Environment.
9. Restart the Application Server to make the custom property active
You can find the details about isolation level to specific to DB2 at following link
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/db2/rbafzmstisol.htm

Useful Shortcut for eclipse IDE

Following are useful shortcuts that a developer can leverage on eclipse IDE.

Ctrl + Shift + O : Organize imports

Ctrl + Shift + R : Search resources

Ctrl + T : Type hierarchy

Ctrl + / : Line Comment

Ctrl + Shift + T : Open Type

Ctrl + O : Open declarations

Ctrl + E : Open Editor

Ctrl + Shift + F4 : Close all Opened Editors

Alt + Shift + R : Rename

Alt + Shift + L : Extract to Local Variable

Alt + Shift + M : Extract to Method

F3 : Open Declaration

Alt + Shift + X : Run As…

Alt + Shift + D : Debug As…

Alt + Shift + W : show the class in the package view.

Ctrl+Q : Last edit

Alt + Left or Alt + Right : Navigate Left and Right

Ctrl + 1 : Quick Fix

Ctrl + Space : Content Assist

Ctrl + Shift + F : Format code

Alt + Shift + S + R : Generate getter and setter methods

Maven Build Process

Maven Introduction

Above diagram provides high level overview of Maven 2

JBI and Apache Service Mix

Excellent Video at

http://parleys.com/display/PARLEYS/Home#slide=1;title=ServiceMix;talk=14123079

WAS 6.1 issue with log4J

Apache Commons Logging has a problem with WAS 6.1. Its Log4JLogger either can't be loaded or be reported not compatible with LogFactory.The root cause is WebSphere uses commons-logging and so it's in the root classloader. In addition, WebSphere ships a commons-logging.properties with the following properties set:

org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImplorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger

Therefore by default the application will use JDK logging and not log4j.

The solution is to ensure that the right classloader mode is set and the application has an appropriate commons-logging.properties:

1. Set application classloader mode as PARENT_LAST.
2. Also, add a commons-logging.properties to the application classpath with the following entries:

priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

The priority flag was introduced in Commons Logging 1.1 to allow an ordering based on priority.

To ensure that an application's commons-logging.properties will take precedence over WebSphere's file, a priority of greater that 0.0 must be set.