マイグレーションに関するその他の制約
WebSphere Application Server 4.0 は、EJB 1.0 仕様で開発された Enterprise bean をサポートします。しかし GlassFish アプリケーションサーバーは EJB 1.0 bean をサポートしません。マイグレーションツールは、この Enterprise bean を EJB 1.1 仕様に準拠するよう、最小限の面倒を見ますが、この実装には完全な信頼性が無く、移行したアプリケーションの配備時に明るみに出るような食い違いを引き起こす場合があります。
この制限を回避するには、CMP entity bean がこの機能を使わないように書き換えてください。Floyd Marinescu の EJB Design Paterns に役に立つ情報が書かれています。
WebLogic 6.0 がリリースされたときにはまだこの制約が無かったため、現在禁止されているこの機能を使ったアプリケーションは、手作業で EJB 2.0 仕様に従うよう修正する必要があります。
この制限を回避するには、マイグレーション後の GlassFish アプリケーションサーバーにアプリケーションを配備する前に、手作業で WLQL を同等の EJB-QL に置き換えてください。
マイグレーションツールは、移行されるアプリケーションがサーバーローカルにあることを仮定しています。すなわち、アプリケーションのすべてのメソッドコールやオブジェクトコールは、サーバーのローカルにあるメソッド/オブジェクトを参照するよう移行されます。この点を説明するため、接続情報を持ったコードがマイグレーションツールで修正されたところを以下にに示します。 Properties h = new Properties(); h.put(Context.INITIAL_CONTEXT_FACTORY, m_INITIAL_CONTEXT_FACTORY); h.put(Context.PROVIDER_URL, m_PROVIDER_URL); h.put(Context.SECURITY_PRINCIPAL, user); h.put(Context.SECURITY_CREDENTIALS, password); ..... InitialContext ctx = new InitialContext(h); このコードの断片は、次に示すように空の IntialContext コンストラクタに置き換えられます。 InitialContext ctx = new InitialContext(); ..... 従って、サーバーローカルではないアプリケーションの移行を行うときには、ツールはリモートオブジェクトコールが存在していないと仮定しているという、この問題を心に留めておいてください。
GlassFish アプリケーションサーバーは JSP 1.2 と JSP 2.0 仕様をサポートしています。JSP 1.2 仕様の実装では、カスタムタグの中にあるアトリビュートの getter や setter メソッドを返し、同じデータ型を受け付けなければなりません。マイグレーションツールは、次の例で説明するように、このシナリオを扱うことができません。 public class Listtag extends TagSupport{
int numIterms; public int getNumItems() {
return numItems;
}
public void setNumItems(String numItemsStr)
numItems = Integer.parseInt(numItemsStr);
}
}
GlassFish アプリケーションサーバーが要求するタグハンドラークラスは次のようになります。 public class Listtag extends TagSupport{
int numIterms; public int getNumItems() {
return numItems;
}
public void setNumItems(int numItemsStr)
numItems = Integer.parseInt(numItemsStr);
}
}
この制限を回避するには、移行したアプリケーションが GlassFish アプリケーションサーバーが期待する動作をするようタグハンドラークラスの中を手作業で修正してください。
GlassFish アプリケーションサーバーは、System.setOut() のような、いくつかのシステムコールの使用に制限があり、使った場合には実行時アクセスコントロール例外を引き起こします。典型的な例としては、System.out ストリームが server.log ファイルに送られ、この送り先を変えると、サーバーのロギング機能に問題を起こします。実行時例外を回避するために、マイグレーションツールは、移行するコードでそのような呼び出しがある場合に次の例のようにコメントアウトします。 public void init(ServletConfig config) throws ServletException{
super.init(config);
Logger.initialize("astp.query.log", "Console");
Logger.log(Logger.LOGTYPEISMESSAGE, "SrvQueryControlloer", "init", "got here!");
try{
System.setOut(new PrintStream(new ServletOutputStreamAdapter
(new FileOutputStream("sys.out"))));
}catch(IOException eio){throw new ServletException(eio);}
}
こちらが、コメントアウトされた移行コードです。 public void init(ServletConfig config) throws ServletException{
super.init(config);
Logger.initialize("astp.query.log", "Console");
Logger.log(Logger.LOGTYPEISMESSAGE, "SrvQueryControlloer", "init", "got here!");
try{
/*Removed call to System.setOut()*/
}catch(IOException eio){throw new ServletException(eio);}
}
しかしながら、この例で注意して欲しいのは、try/catch ブロック内にそのメソッドコールしかなくて、これがコメントアウトされると、IOException は try/catch ブロックからスローされないため、コンパイル時にエラーとなる点です。マイグレーションツールは次のような問題を検出できないため、制限があります。
この制限を回避するには、この状況を知らせるマイグレーションレポートを見て、必要に応じて例外を引き起こす部分をコメントアウトするなどの対応をしてください。
マイグレーションツールは JAR ファイルが EAR ファイルの直下にあることを想定しています。ツールでは入れ子になった JAR ファイルの移行をサポートしていません。移行を成功させるために、すべての JAR ファイルが EAR ファイルの直下に配置してください。 EAR | | |---Lib/lib.jar | | |---EJBs | |---EJB1.jar | |---EJB2.jar | |---WEB | |---WEB1.war | |---WEB2.war EAR ファイル構成を、次の例に示すように、移行が成功する形式に修正する必要があります。 EAR | | |---lib.jar | |---EJB1.jar | |---EJB2.jar | |---WEB1.war | |---WEB2.war
"Cp1252 エンコーディングタイプを配備記述子に使うことは Solaris ではサポートされません。この制限を回避するには、移行を Windows 2000/NT/XP といった Windows プラットフォームだけで行うか、エンコーディングタイプを Windows プラットフォームでも Solaris でもサポートできる "UTF-8" に変更します。 日本語翻訳: shioda 英文 (翻訳したバージョン: 5) |
