表 1 BEA Workshop バージョン 10.2 に関する確認済みの制限事項
|
|
|
|
|
プロジェクトのインポート後に初めて [プロジェクト|クリーン] を実行した際には、.apt_src ディレクトリにあるファイルが完全にはクリーニングされないことがある
build ディレクトリ (.apt_src など) を含んだプロジェクトをユーザがインポートした後で、最初にクリーニングを実行した際には、そのディレクトリにある一部のファイルが削除されずに残ることがある。この問題は初回にのみ発生する。次回以降のクリーニング操作では、生成されたディレクトリも正しく処理される。
回避策 : インポート後に初めてクリーニングを実行した際、.apt_src ディレクトリ内のファイルを手作業で削除する。削除した後、このディレクトリ内に格納される新しいファイルはクリーニング操作で正しく処理される。
|
|
|
Web サービスや他のアーティファクトが、複数の EAR の一部である Web プロジェクト内にある場合、[サーバで実行] によって誤った URL が生成される可能性がある
ワークスペースで、複数の EAR に関連付けられている Web プロジェクト内のアーティファクトに対して [サーバで実行] アクションを使用すると、ブラウザが誤った URL を指して起動される可能性がある。つまり、関連付けられている最後の EAR の URL が使用される。
この問題を回避するには、次のいずれかを行う。 a) 起動に使用されない EAR を閉じる。 b) 起動に使用されない EAR から Web プロジェクトを削除する。 c) 正しい EAR を指すように、ブラウザで URL を手動で更新する。
|
|
|
JRockit を使用してデバッグする場合に JVMTI イベント (特にブレークポイント) がなくなる
JRockit JVM を使用してデバッグする場合、パフォーマンスに関する問題が発生してブレークポイントがなくなる可能性がある。
回避策 : JRockit 5.0 R27.1 以上に更新する。
|
|
|
複数の JMS サーバを持つサーバに (IDE から) デプロイされている場合、バッファ付きコントロール メソッドの呼び出しが実行時に失敗する
IDE はアプリケーションをデプロイするときに、必須の Workshop ライブラリを自動デプロイする。コントロール メソッドで @MessageBuffer を使用すると、weblogic-controls ライブラリ内のアプリケーション スコープの JMS リソースに対して依存関係が生じる。weblogic-controls ライブラリが、複数の JMS サーバを持つサーバに (IDE から) デプロイされた場合、ライブラリはデプロイされるが、アプリケーション スコープの JMS リソースは使用可能にならない。これは、IDE がデフォルトのサブモジュールの対象指定に依存していて、デフォルトのサブモジュールの対象指定は、厳密に 1 つの JMS サーバを含む対象に依存しているためである。デプロイメントに問題があることを警告する以下のようなメッセージが表示される。
警告メッセージが表示されても、ライブラリはサーバにデプロイされる。つまり、ライブラリに依存しているアプリケーションも正常にデプロイされる。ただし、バッファ付きコントロール メソッドの呼び出しは実行時に失敗し、以下のようなメッセージが表示される。
この状況は、Workshop for Weblogic Platform をサポートしないで作成されたドメインを使用している場合に起きる可能性が高い。
weblogic.Deployer コマンドを使用してライブラリを手動でデプロイする。コマンドの形式は以下のとおり。
-adminurl t3://localhost:7001
-name weblogic-controls-10.0
-source %WL_HOME%/common/deployable-libraries/weblogic-controls-10.0.ear
-submoduletargets cgJMSServer@WlwRuntimeAppScopedJMS@WseeJmsServer
-library -libspecver 10.0
- WseeJmsServer はアプリケーション スコープの送り先をホストする
このコマンドは config.xml 内のライブラリ定義を更新する。そのため、1 回だけ実行する必要がある。
|
|
|
JMS プロトコルの場合、ServiceControl でのバッファ付きメソッドが失敗する場合がある
ServiceControl でのバッファ付きオペレーションは無効にする必要がある。ただし、基底の WSDL のメッセージ交換パターン (MEP) は、要求/応答 (空の応答付き) または一方向 (応答なしの要求) のいずれかに設定できる。
JMS に対して要求/応答の MEP にした場合、@MessageBuffer の存在によって、要求がデッドロックし、最終的にタイムアウトする。一般的に、次のような警告メッセージが生成される。
生成されるエラー メッセージには、次のような文が含まれる。
注意 : これは、要求用の転送プロトコルが JMS である場合にのみ発生する。
回避策 : ターゲット JWS のデザインに影響を及ぼすことができる場合、JWS オペレーションに @Oneway アノテーションを付けると、基底の MEP が一方向になり、この状況が回避される。ターゲット JWS のデザインに影響を及ぼすことができない場合の回避策としては、TransactionAttribute アノテーションを ServiceControl オペレーションに追加する。
@TransactionAttribute が存在しても、呼び出し側アプリケーション内で行われるアクションのトランザクション動作は変わらない。
|
|
|
WebLogic Server 10.0 の Servlet 2.5 実装では 9.2 の Beehive アプリケーションが使用できない場合がある
説明 : 9.2 の Beehive アプリケーションが WebLogic Server 10.0 にデプロイされると、問題が発生する可能性がある。このシナリオの症状では java.lang.IllegalStateException が送出される。根本的な問題は、Servlet 2.4 の javax.servlet.ServletException が Servlet 2.5 で変更された点にある。
プラットフォーム : WebLogic Server 10.0 以上
回避策 : アプリケーションをアップグレードして Beehive 10.0 ライブラリ (Servlet 2.4 または Servlet 2.5 のいずれかを処理できる) を使用する。9.2 アプリケーションが 10.0 でコンパイルできない場合は、9.2 アプリケーション EAR のデプロイメント記述子を手動で更新して 10.0 Beehive ライブラリを使用することでこの問題は解決する。以下に例を示す。
9.2 の .ear に含まれる各 .war で、web-inf/weblogic.xml の次のセクション
<wls:library-ref> <wls:library-name>beehive-netui-1.0</wls:library-name> <wls:specification-version>1.0</wls:specification-version> <wls:implementation-version>1.0</wls:implementation-version> </wls:library-ref>
<wls:library-ref> <wls:library-name>beehive-netui-1.0.1-10.0</wls:library-name> <wls:specification-version>1.0</wls:specification-version> <wls:implementation-version>1.0.1.1</wls:implementation-version> </wls:library-ref>
|
|
|
8.x アプリケーションを 9.x/10.x アプリケーションにアップグレードする場合、1 つのページ フロー メソッドから JDBC コントロールへ複数のメソッドを呼び出すと、問題が発生することがある。
ページ フローからのトランザクション スコープにおける変更が原因。詳細については、以下で説明されている。
「コントロールはトランザクションのスコープ内で自動的に実行されない」の節を参照。
8.x アプリケーションを 9.x/10.x アプリケーションにアップグレードする場合、1 つのページ フロー メソッドから JDBC コントロールへ複数のメソッドを呼び出すと、問題が発生することがある。問題の要点は次のようになる。JDBC コントロールに対して最初の呼び出しが行われると、トランザクション インターセプタによって新しいトランザクションが作成される。その呼び出しに応答があると、トランザクションはコミットまたはロールバックされる。
JDBC コントロールに次の呼び出しが行われると、新しいトランザクションが作成されるが、コントロールで使用されている JDBC 接続は新しいトランザクションでは使用できない (接続は最初のトランザクションのリソースとして関連付けられている)。
8.x ページ フローの動作では、JDBC コントロールは各メソッド呼び出し後に JDBC 接続を解放していた。ページ フローから呼び出されるコントロール メソッドのトランザクション スコープは、コントロール メソッドの呼び出しの最初にトランザクションを開始し、メソッドが戻るときにトランザクションを終了するというものだった。コントロールがトランザクションをロールバックすると、そのトランザクション内で実行されているすべての処理もロールバックされていた。
1) トランザクション (8.x では暗黙的) を使用しない場合は、
トランザクション インターセプタのアノテーション (アップグレード ツールによって挿入される) をコントロール メソッドから削除してよい。
2) トランザクションを使用する場合は、ページ フロー メソッドで JTA トランザクションを作成して、JDBC コントロールへの呼び出しが完了した後でコミットまたはロールバックする。
|
|
|
コールバックを持つ Web サービス コントロールでは、単純なクラス名の重複がサポートされない
コールバックを持つ複数の Web サービス コントロールに、同じクラス名 (パッケージ名は考慮しない) が付けられていると、jwsc でエラーが発生する。このエラーは、IDE でパブリッシュを行うとき、エクスポートされた Ant スクリプトで利用可能するとき、または IDE から EAR ファイルをエクスポートするときに発生する。以前のバージョンの Workshop では、この状況が起きた場合でも、エクスポートされた Ant スクリプトによって、アセンブル手順が成功したと誤って報告されていた。Ant スクリプトが生成された Java ファイルに対して jwsc を実行しようとしなかったためである。
回避策 : コールバックを持つ Web サービス コントロール (SerivceControl) を使用する場合は、各コントロール ファイルにユニークな非修飾クラス名が付いていることを確認する。パッケージ名が異なるだけでは十分ではない。
|
|
|
サービス コントロールの生成時に、誤ったコールバック メソッド名が生成される場合がある
名前にアンダースコアや数字を含む WSDL コールバックに基づいてサービス コントロールを生成すると、誤ったコールバック メソッド名が生成される場合がある。この状況は、アンダースコアまたは数字の後に小文字が続いている場合に起きる。
たとえば、次のような WSDL コールバック名の場合、
数字またはアンダースコアに続く最初の文字が大文字になっている。
このメソッドを呼び出すと、次のようなエラーが発生する。
回避策 : アンダースコアまたは数字の後に小文字が続くコールバック メソッド名を避ける。
|
|
|
追加システム プロパティを定義するまで Linux 上にヘッドレス モードで Workshop startup.jar を実行できない。
以下のシステム プロパティを true に設定するまで Linux 上にヘッドレス モードで Workshop startup.jar を実行できない。
回避策 : システム プロパティ m7.disable.swt.init を true に設定してヘッドレス モードで Workshop を起動します。この回避策のために DISPLAY システム プロパティを設定しないよう注意してください。
|
|
|
Weblogic Server 10.0 における Hibernate JPA デプロイメントの問題
Workshop 10.1 で作成されたか、Workshop Studio 3.x からインポートされた Hibernate JPA プロジェクトが Weblogic Server 10.0 へのデプロイに失敗する。以下の回避策で、Hibernate JPA プロジェクトがデプロイされる。ただし、再デプロイメントする場合にはサーバを再起動する必要がある。
プラットフォーム : Workshop 10.1 以上
回避策 : EAR プロジェクトの場合、weblogic-application.xml を変更して以下を追加する。
Web アプリケーションの場合、Web プロジェクトを EAR に追加して上記に示すように weblogic-application.xml を修正する。
注意 : プロジェクトを再デプロイメントする場合、サーバを再起動する必要がある。
|
|
|
プロジェクト名を変更した後、古いプロジェクトはサーバからアンデプロイされない。
EAR に属するプロジェクト名を変更すると、WebLogic Server から前のプロジェクト名がアンデプロイされない。
回避策 : サーバからプロジェクトを削除するには WebLogic Server からアプリケーションをアンデプロイして再デプロイする。
|
|
|
コマンドライン アップグレード ツールを使用してアップグレードした EJB プロジェクトをデプロイするときに問題が発生。
コマンドライン アップグレード ツール upgradeStarter を使用してアップグレードした EJB プロジェクトをデプロイする時、問題が発生することがある。
回避策 : コマンドライン ツールの代わりに IDE を使用してプロジェクトをアップグレードする。Workshop IDE を使用してアップグレードするには、次の手順に従います。
|
|
|
アップグレード後、不完全な AppXRay データベースが生成されることがある。
Workshop version 8.1.x から 10.2 へのアップグレード、または 9.2 から 10.0 を通じて 10.2 への移行後、アップグレードしたアプリケーションの初期のビルドは、AppXRay 機能を有効にした Web プロジェクトに対して不完全な AppXRay データベースを生成する場合がある。この場合、App Xaminer ビューに、すべての依存関係が正しく表示されない。
プラットフォーム : Workshop 8.1 以上
回避策 : この問題を修正するには、([ プロジェクト|削除] を選択して) workspace を削除して再ビルドする。
|
|
|
WebLogic Server 9.2 で Web サービスをデプロイする時に、ExceptionInInitializerError が発生する。
WebLogic Server 9.2 の pre-MP1 バージョンで Web サービスをデプロイする時に ExceptionInitializerError を発生する可能性がある。
プラットフォーム : Workshop 10.2 および WebLogic Server 9.2
(1) WebLogic Server 9.2 インストールを 9.2 MP1 以上にアップグレードする。
(2) または、VM の workSpaceStudio.ini ファイルおよび WebLogic Server の起動スクリプトの両方に次のフラグを追加する。
|
|
|
Web アプリケーション デプロイメント記述子のグラフィカル エディタでは、<resource-ref> 要素がサポートされない。
Workshop のデプロイメント記述子用グラフィカル エディタでは、<resource-ref> 要素がサポートされない。[ デプロイメント記述子要素] ツリー ビュー (ソース エディタ上にある) および [ 概要] ビューでは、<resource-ref> 要素の追加または編集がサポートされない。
回避策 : <resource-ref> 要素を追加および編集するためにソース ビューを使用する。
|
|
|
フィルタ ディスパッチャーが、JSF webapp デプロイから警告を出す。
Workshop とバンドルされている MyFaces のバージョンでは、MyFaces web.xml parser のバグのため WebLogic Server コンソールで警告を出す。バグは次にトラックしている。
http://issues.apache.org/jira/browse/MYFACES-1415
|
|
|
一部の Workshop テキスト フィールドでは、〔Ctrl〕+〔V〕(貼り付け機能) がサポートされない。
WebLogic Portal Eclipse プラグインが存在する場合、一部の Workshop テキスト フィールドでは、 〔Ctrl〕+〔V〕(貼り付け機能) がサポートされない。
回避策 : これらのテキスト フィールドに手動でテキストを入力する。
|
|
|
Linux : Workshop JSP デザイン ビューでは、ドラッグ アンド ドロップがサポートされない。
Linux の場合、Workshop JSP デザイン ビューでは、デザイン パレットからドラッグ アンド ドロップがサポートされない。
回避策 : ソース ビューのデザイン パレットからドラッグ アンド ドロップする。
|
|
|
Workshop JSP デザイナーでは、JSP の XML 構文がサポートされなく、XML JSP を解析する時に警告が出される。たとえば、文字「&」に対してエンティティ参照「&」を使用すると、問題ビューには、デプロイメントが防止されたという警告が出される。
回避策 : これらの警告を無視する。JSP XML 構文によってアプリケーションのデプロイメントが妨害されない。
|
|
|
Workshop Studio 3.3 からアップグレードされたプロジェクトでは、Kodo ライセンスの手動アップグレードを行う必要がある場合がある。
Workshop Studio 3.3 のリリースにバンドルされた Kodo ライセンスが期限切れのため、<Project_Home>/src/license.bea にライセンスファイルのある旧アプリケーションを手動でアップグレードする必要がある。
プラットフォーム : Workshop Studio 3.3 から Workshop 10.1 以降にアップグレードされた JPA/Kodo アプリケーションに適用する。
JPA/Kodo をサポートする新しいプロジェクトを作成する。詳細については、http://edocs.beasys.co.jp/e-dcos/wlw/docs101/guide/ormworkbench/conAddingEJB3Support.html を参照。
license.bea ファイルを新しいプロジェクトから元のプロジェクトの src フォルダにコピーする。
|
|
|
Workshop Studio 10.2 および Workshop for WebLogic 10.2 は、同じ BEA ホームにインストールされた場合、ライセンスが必要。
Workshop for WebLogic 10.2 および Workshop Studio 10.2 の両方が同じ BEA_HOME でインストールされ、Workshop Studio のトライアルまたは完全なライセンスが期限切れの場合、Workshop の機能 (Workshop Studio および Workshop for WebLogic の機能) がすべて使用できなくなる。
プラットフォーム : Workshop for Weblogic 10.2 および Workshop Studio 10.2。
回避策 : 以下の手順に従って、Workshop Studio 10.2 をアンインストールする。
アンインストール ウィザードで Workshop Studio 以外のすべてのコンポーネントを選択解除してアンインストールを実行する。製品を再び起動する。Workshop for WebLogic のライセンスを使用すると、Workshop for WebLogic の機能が使用可能になる。
|
|
|
サーバの起動に失敗した場合、Workshop のコンソールがクローズされる。
WebLogic Server は Workshop で起動しない場合、[ コンソール] ビューがクローズされ、起動時の失敗に関連するエラーをモニタできない。
1. [サーバ] ビューで、[サーバの概要] を開くためにサーバ インスタンスをダブルクリックする。
2. [起動およびデプロイメント] のセクションで、[Eclipse コンソールで WebLogic server の起動] のチェックを外す。
3. <domain_home>\bin\startWebLogic.cmd|.sh にある起動スクリプトを使用して WebLogic Server を起動する。
4. 起動失敗に関連するエラーを表示するには、コマンド シェル コンソール出力を参照。
|
|
|
WorkSpace Studio About Box は、BEA Product が BEA ホーム ディレクトリから削除された後プラグインおよびコンフィグレーションの詳細情報を表示しない。
他の製品をインストールしている BEA ホーム ディレクトリから BEA Product をアンインストールした後、WorkSpace Studio IDE about box ( Help|About BEA WorkSpace Studio) のプラグインの詳細およびコンフィグレーションの詳細のボタンが操作できなくなる。これは、ある状況下で、プラグインを削除しても空のプラグイン ディレクトリが存在する可能性があり、IDE がこれらのディレクトリにプラグインの詳細を見つけられないために発生する。
プラットフォーム : WorkSpace Studio 1.1
回避策 : -clean を使用して WorkSpace Studio を起動する。
|