Do not use WebLogic-specific JNDI property values or the t3 protocol

You must remove or replace WebLogic-specific naming properties used when getting the IntialContext in your application. The migration tool scans Java, XML, and properties files for the property values: weblogic.jndi.WLInitialContextFactory, t3://.* and t3s://*. For example, if an application specifies the following properties, the tool would flag the red text:

Liberty

Java files

When moving your application to Liberty, do not specify an initial context factory or a provider URL in the properties passed to the InitialContext constructor. Use the empty constructor unless other naming properties are being set.

The following example illustrates application code that this rule will mark when migrating to Liberty:


import java.util.Hashtable;
import javax.naming.InitialContext;
...
void main( String[] args ) {
Hashtable ht = new Hashtable();

ht.put("java.naming.factory.initial", "weblogic.jndi.WLInitialContextFactory");
ht.put("java.naming.provider.url", "t3://localhost:7001");

InitialContext ctx = new InitialContext(ht);
}

Manually remove the unnecessary properties:


import javax.naming.InitialContext;
...
void main( String[] args ) {
InitialContext ctx = new InitialContext();
}

XML files

In addition to flagging java files, the tool will flag xml files containing WebLogic property values. For Liberty, the properties should be removed in order to use the default InitialContext initialization values.

Property files

In addition to flagging java and xml files, the tool will flag property files containing WebLogic property values. For Liberty, the properties should be removed.

WebSphere Application Server traditional

Java files

When migrating to WebSphere Application Server traditional, the same WebLogic properties mentioned earlier will be flagged. An automated fix will be provided for Java files that changes the WebLogic naming property values to ones that work in WebSphere Application Server traditional:

The following example illustrates application code that this rule will flag when migrating to WebSphere Application Server traditional:


import java.util.Hashtable;
import javax.naming.InitialContext;
...
void main( String[] args ) {
Hashtable ht = new Hashtable();

ht.put("java.naming.factory.initial", "weblogic.jndi.WLInitialContextFactory");
ht.put("java.naming.provider.url", "t3s://localhost:7001");

InitialContext ctx = new InitialContext(ht);
}

Using the same example shown earlier, after running the automated fix for WebSphere Application Server traditional, the code will be migrated as shown:


import java.util.Hashtable;;
import javax.naming.InitialContext;;

...

void main( String[] args ) {
Hashtable ht = new Hashtable();

ht.put("java.naming.factory.initial", "com.ibm.websphere.naming.WsnInitialContextFactory");
ht.put("java.naming.provider.url", "corbaloc:iiop:localhost:2809");

InitialContext ctx = new InitialContext(ht);
}

Note: The automated fix will use the default bootstrap port, 2809, for all t3 URLs, including the SSL 't3s://' URLs. Check your server settings to make sure that the correct port is used for each URL. For additional information, refer to the Port Number Settings for WebSphere Application Server traditional article.

Another option when moving to WebSphere Application Server traditional is removing the properties and using the empty InitialContext() constructor.

Warning: The automated fix will only adjusts literals. If a URL is being built using variables, it will have to be manually migrated.

Variable example before:

void main( String[] args ) {
Hashtable ht = new Hashtable();

...

String port = "7001";
ht.put("java.naming.provider.url", "t3://localhost:" + port);

InitialContext ctx = new InitialContext(ht);
}

Variable example after:

void main( String[] args ) {
Hashtable ht = new Hashtable();

...

String port = "7001";
ht.put("java.naming.provider.url", "corbaloc:iiop:localhost:" + port);

InitialContext ctx = new InitialContext(ht);
}

Notice that the string variable port was not changed. Be sure that all such variables are migrated.

The following example illustrates similar changes applied to XML code.

XML code before :

<property name="java.naming.factory.initial" value="weblogic.jndi.WLInitialContextFactory"/>

<property name="java.naming.provider.url" value="t3://localhost:7001/"/>

XML code after:

<property name="java.naming.factory.initial" value="com.ibm.websphere.naming.WsnInitialContextFactory"/>

<property name="java.naming.provider.url" value="corbaloc:iiop:localhost:2809/"/>

Property files

While the migration tool checks properties files, naming factory and provider properties are not migrated by an automated fix. For WebSphere Application Server traditional, either remove the properties or change them to the WebSphere naming property values.

See also the Use portable JNDI property values rule.