Nie używaj wartości właściwości JNDI specyficznych dla serwera WebLogic ani protokołu t3

Należy usunąć lub zastąpić właściwości nazewnictwa specyficzne dla serwera WebLogic, które są używane na potrzeby pobierania obiektu InitialContext w aplikacji. Narzędzie do migrowania przegląda pliki Java, pliki XML i pliki właściwości pod kątem występowania następujących wartości właściwości: weblogic.jndi.WLInitialContextFactory, t3://.* i t3s://*. Jeśli na przykład aplikacja określa następujące właściwości, narzędzie będzie oznaczać tekst wyróżniony kolorem czerwonym:

Liberty

Pliki Java

Podczas przenoszenia aplikacji do produktu Liberty nie należy podawać fabryki kontekstu początkowego ani adresu URL dostawcy w właściwościach przekazywanych do konstruktora InitialContext. Należy użyć pustego konstruktora, chyba że zostały ustawione inne właściwości nazewnictwa.

Poniższy przykład przedstawia kod aplikacji oznaczany przez tę regułę podczas migrowania do serwera 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);
}

Należy ręcznie usunąć niepotrzebne właściwości:


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

Pliki XML

Oprócz plików Java narzędzie oznaczy także pliki XML zawierające wartości właściwości serwera WebLogic. W przypadku serwera Liberty należy usunąć właściwości w celu użycia wartości domyślnych inicjowania klasy InitialContext.

Pliki właściwości

Oprócz plików Java i XML narzędzie oznaczy również pliki właściwości zawierające wartości właściwości serwera WebLogic. W przypadku serwera Liberty należy usunąć właściwości.

WebSphere Application Server traditional

Pliki Java

Podczas migracji do tradycyjnego serwera WebSphere Application Server oznaczane są te same właściwości serwera WebLogic, które wymieniono wcześniej. Automatyczna poprawka zostanie dostarczona dla plików Java która zmienia wartości właściwości nazewnictwa WebLogic na takie, które działają w tradycyjnym WebSphere Application Server :

Poniższy przykład przedstawia kod aplikacji oznaczany przez tę regułę podczas migrowania do serwera 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);
}

Używając tego samego przykładu pokazanego wcześniej, po uruchomieniu automatycznej poprawki dla WebSphere Application Server traditional, kod zostanie zmigrowany jak pokazano:


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);
}

Uwaga: Automatyczna poprawka użyje domyślnego portu startowego, 2809, dla wszystkich adresów URL t3, w tym adresów URL SSL " t3s:// ". Należy sprawdzić ustawienia serwera, aby upewnić się, że dla każdego adresu URL jest używany poprawny port. Więcej informacji na ten temat zawiera artykuł Ustawienia numerów portów dla serwera WebSphere Application Server traditional.

Kolejną opcją, która jest dostępna przy przenoszeniu na serwer WebSphere Application Server traditional, jest usunięcie właściwości i użycie pustego konstruktora InitialContext().

Ostrzeżenie : Automatyczna poprawka dostosuje tylko literały. Jeśli adres URL jest tworzony przy użyciu zmiennych, należy go zmigrować ręcznie.

Wcześniejszy przykład zmiennej:

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);
}

Przykład zmiennej po:

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);
}

Należy zwrócić uwagę na to, że zmienna łańcuchowa port nie została zmieniona. Należy zadbać o to, aby wszystkie takie zmienne zostały zmigrowane.

W poniższym przykładzie przedstawiono podobne zmiany zastosowane do kodu XML.

Kod XML przed :

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

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

Kod XML po:

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

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

Pliki właściwości

Podczas gdy narzędzie do migracji sprawdza pliki właściwości, właściwości fabryki nazw i dostawcy nie są migrowane przez automatyczną poprawkę. W przypadku serwera WebSphere Application Server traditional należy usunąć właściwości lub zmienić je na wartości właściwości nazewnictwa produktu WebSphere.

Patrz także: reguła Używaj przenośnych wartości właściwości JNDI.