How to migrate Weblogic applications to JBoss

In this article we will learn how to migrate an Enterprise application from Oracle Weblogic into JBoss EAP / WildFly. To do that, we will be using Red Hat Migration Toolkit for Applications (MTA).

Red Hat Migration Toolkit in a nutshell

The Migration Toolkit for Applications (MTA) is an extensible tool which you can use to ease the migration of several Java applications. This tool is available in several formats. The most common ones are:

  • The Web application Toolkit: which you can deploy on the top of a Container and use its UI to complete the migration
  • The Command Line Interface: which you can use to perform the migrations from the OS Shell

When you start the MTA tool, it will go through the application artifacts and archives producing as result an HTML report which highlights all the needing changes.

The most common migration patterns are:

  • Oracle Weblogic / IBM WebSphere to JBoss Enterprise Application server
  • JBoss EAP upgrade to the latest release
  • Making your application container-ready
  • Oracle JDK to OpenJDK
  • Spring Boot to Quarkus

We will show as an example how to migrate an Oracle Weblogic application so that you can deploy in on JBoss EAP or WildFly application server. For this purpose, we will be using the MTA Command Line Interface. You can perform the same steps with another flavor of MTA.

Installing MTA

First things first. Head to the Download page and choose which type of toolkit you want to download. In our case, we will go for the CLI. Next, unzip the Toolkit in a folder of your likes:

$ unzip migrationtoolkit-mta-cli-6.2.1-offline.zip -d /path

Then, move to the bin folder where the MTA is available:

mta-cli
mta-cli.bat

A typical MTA execution includes the following arguments:

$ ./mta-cli --input /path/to/jee-example-app-1.0.0.ear \
    --output /path/to/output --source weblogic --target eap:7 \
    --packages com.acme org.apache

Here is a short description of the arguments:

  • input is the application that you want to migrate.
  • output is the folder where MTA will create its reports
  • source is the product/framework that you are migrating from
  • target is the destination which you want to migrate to
  • packages you can optionally use it to indicate which packages will be checked. Highly recommended to improve performance.

The MTA has an –help command to print the list of available commands. Besides that, you can enable bash auto-completion by running the mta-cli script available in the bash-completion folder:

$ source <MTA_HOME>/bash-completion/mta-cli

In order to migrate our Spring Boot application, we will check the list of source technologies available by running the CLI with the –listSourcetecnologies:

./mta-cli --listSourceTechnologies

agroal
amazon
apicurio
artemis
avro
. . . .
springboot
thorntail
weblogic
websphere

Therefore, the correct source technology for a SpringBoot application is “weblogic“.

Here is the command to migrate the application “jee-example-app-1.0.0.jar” into the folder output choosing as target JBoss EAP 7:

./mta-cli --input jee-example-app-1.0.0.ear --output report --source weblogic --target eap:7

The execution will take a while, depending on how many classes and jar files are in your application. At the end of it, you will have in the output folder an index.html page with a set of sub folders:

$ ls
index.html  reports  stats

Checking the Migration Report

By opening the index.html page you will see the list of applications which MTA has inspected:

weblogic to jboss migration

Click on the application link (jee-example-app-1.0.0.jar) to access the MTA DashBoard:

There you can see a recap of all Incidents grouped by Category, Type and the migration complexity. Within the Issues Tab, you can see the list of changes that you need to apply to migrate your application:

Common Migration Points

When porting applications from Weblogic to Jboss EAP 7 there are some common migration points which the MTA cover with its Rules. Let’s see the most common ones.

Proprietary logger

The WebLogic NonCatalogLogger is not supported on JBoss EAP, and should be migrated to a supported logging framework, such as the JDK Logger or JBoss Logging:

import java.util.logging.Logger;
Logger LOG = Logger.getLogger("MyLogger");

Call of JNDI lookup

WebLogic JMS provides two default connection factories that are included as part of the configuration. They can be looked up using the weblogic.jms.ConnectionFactory JNDI name and the weblogic.jms.XAConnectionFactory, which is configured to enable JTA transactions.

(ConnectionFactory)initialContext.lookup("weblogic.jms.ConnectionFactory");

should become:

(ConnectionFactory)initialContext.lookup("/ConnectionFactory");

T3 JNDI binding

RMI communications in WebLogic Server use the T3 protocol to transport data between WebLogic Server and other Java programs, including clients and other WebLogic Server instances.

The equivalent functionality needs to be configured in JBoss EAP 7. This could be done either by using standard Java EE JNDI names or by using a WebLogic proprietary library if the connectivity to WebLogic server is still required.

WebLogic T3ServicesDef usage

T3ServicesDef provides access to core services of the container, such as Timers and Logging facilities.

T3ServicesDef t3services;
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "t3://localhost:7003");
// Above line u can pass any Managed Server URL as well to take their Thread Dumps//
env.put(Context.INITIAL_CONTEXT_FACTORY,weblogic.jndi.WLInitialContextFactory.class.getName());
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "weblogic");
 
Context ctx = new InitialContext(env);
t3services = (T3ServicesDef)ctx.lookup("weblogic.common.T3Services");
System.out.println("nt For the T3ServicesDef : "+t3services);

Replace the services provided by this with a Singleton EJB (using the @Singleton annotation) that provides access to the equivalent services from JBoss EAP.

WebLogic EJB XML (weblogic-ejb-jar.xml)

Within the file weblogic-ejb-jar.xml you can configure custom elements such as the maximum duration for an EJB’s container-initiated transactions, in seconds, after which the transaction is rolled back.

In JBoss EAP 7, you can achieve the same behavior by using the TransactionTimeout annotation.

TransactionManager extensions

Oracle Weblogic provides several extensions to the JTA specification in the weblogic.transaction package.

import javax.transaction.Transaction;
import java.sql.Connection
import weblogic.transaction.TxHelper:
import weblogic.transaction.Transaction;
import weblogic.transaction.TxConstants;
User Transaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
//Begin user transaction
    tx.begin();
//Set transaction isolation level to TransactionReadCommitted
Transaction tx = TxHelper.getTransaction();
    tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
    (Connection.TransactionReadCommitted));
//perform transaction work 
    tx.commit();

Replace with the Java EE standard javax.transaction.TransactionManager

InitialContextFactory

weblogic.jndi.WLInitialContextFactory is an implementation of InitialContextFactory used to get object instances from JNDI.

The equivalent functionality needs to be configured on JBoss EAP 7 using org.jboss.naming.remote.client.InitialContextFactory. Then the context could be instantiated as follows:

InitialContext ctx = new InitialContext();.

Proprietary InitialContext initialization

In JBoss EAP, the InitialContext should be instantiated with no arguments. Once an instance is constructed, look up the service using portable JNDI lookup syntax. Ensure also that in case system properties for InitialContext are provided, they do not need to be changed for the JBoss EAP.

InitialContext context = new InitialContext();
Service service = (Service) context.lookup( "java:app/service/" + ServiceImpl.class.getSimpleName() );

WebLogic EJB XML (weblogic-ejb-jar.xml)

The elements of proprietary weblogic-ejb-jar.xml descriptor need to be mapped to the jboss-ejb3.xml

Proprietary EJB classes

In Weblogic you can implement a generic bean template in a class of your own by importing the generic class into the class you are writing.

import weblogic.ejb.GenericSessionBean;
     ...     
public class HelloWorldEJB extends GenericSessionBean { 

Replace classes in weblogic.ejb package with standard Jakarta EE EJB3 packages.

ApplicationLifecycleEvent and ApplicationLifecycleListener

WebLogic ApplicationLifecycleEvent must be replaced with standard Java EE ServletContextEvent. Otherwise, a custom solution using CDI’s ApplicationScoped beans or EJB’s @Startup beans is required in order to propagate a custom event object because ServletContextEvent types are not extendible in the standard Java EE programming model.

Use a javax.servlet.ServletContextListener with @javax.annotation.servlet.WebListener, or an EJB 3.1 @javax.ejb.Startup @javax.ejb.Singleton service bean.

WebLogic ApplicationLifecycleListener must be replaced with standard Java EE ServletContextListener types. Otherwise, a solution using CDI’s ApplicationScoped beans or EJB’s @Startup beans is required.

Use a javax.servlet.ServletContextListener with @javax.annotation.servlet.WebListener, or an EJB 3.1 @javax.ejb.Startup @javax.ejb.Singleton service bean.

Proprietary ServletAuthentication annotation

Oracle WebLogic Server provides a proprietary ServletAuthentication class to perform programmatic login.

In Red Hat JBoss EAP 7, you can use the standard Java EE servlet security 3.1 HttpServletRequest.login() method or you can define a element in the web.xml file. You must also replace code that uses the Oracle WebLogic Server proprietary ServletAuthentication class.

WebLogic JMS descriptor

<weblogic-jms xmlns="http://www.bea.com/ns/weblogic/90">

 	  <queue name="LogEventQueue">

 	  <jndi-name>LogEventQueue</jndi-name>

 	  </queue>

 	 </weblogic-jms>

This file is a proprietary WebLogic JMS configuration and needs to be migrated. While there is no direct mapping of these descriptor elements, many of these features may be configured in the application deployment or JBoss server configuration files.

For information on how to configure JBoss EAP JMS, please refer to the JBoss Enterprise Application Platform 7 messaging configuration documentation.

web application descriptor (weblogic.xml)

The Oracle WebLogic Server deployment descriptor file (weblogic.xml) provides functionality that is not included in the standard Java EE specification. While there is no direct mapping of these descriptor elements, many of these features may be configured in the application deployment or JBoss server configuration files.

EAR application descriptor (weblogic-application.xml)

The weblogic-application.xml deployment descriptor file is used to describe Oracle WebLogic Server EAR archives. Oracle WebLogic Server EAR configures some application settings through the application-param element. These settings could be replaced with context-param elements in Java EE Servlet web.xml descriptor.