表 1 BEA Workshop for WebLogic Platform バージョン 9.2.3 に関する確認済みの制限事項
|
|
|
|
|
アップグレードが正常に完了しなかった場合に、ファイルが元の状態に戻されない
アップグレードが正常に完了しなかった場合、ファイルが元に戻されず、アップグレードが不完全な状態のままになる。たとえば、ファイル拡張子は .java に変更されたのに、アノテーションは Workshop for WebLogic 9.2.1 形式に変換されていないといった状態が発生する。ただし、元のソース ファイルは変更されない。
回避策 : バージョン 8.1 のファイルをワークスペースにドラッグ アンド ドロップしてから、該当するファイルに対するアップグレードを実行し直すか、プロジェクト全体をインポートし直す。
|
|
|
Web サービスのパラメータ名が変更されている場合、アップグレード後に @WebParam アノテーションが必要となる
WSDL 開始 (start-from-WSDL) モードの Web サービスで、パラメータ名 (Java シグネチャ内) と WSDL 名が一致していない場合、アップグレード後に @WebParam アノテーションを手作業で追加する必要がある。パラメータ名の変更は、使用されている WSDL 名が Java の識別子として有効でない場合に行われることが最も多い。
回避策 : 該当する Web サービス オペレーションの各パラメータに、対応する WSDL 名を指定した @WebParam アノテーションを追加する。
|
|
|
クイック フィックス機能を使用して serialVersionUID を生成すると Eclipse がハングする
serialVersionUID の欠落を示す警告に対処するためにクイック フィックス機能 ( [Ctrl]+[1] を押すと有効になる) を使用すると、Eclipse がハングすることがある。これは Eclipse 3.1 に関する確認済みの制限事項であり、Workshop for WebLogic の今後のバージョンで修正される。
回避策 : 手作業で serialVersionUID をクラスに追加するか、警告を無視する。
|
|
|
タイトル : [Beehive] タグのアップグレード後、tagid 属性は Pageflow ポートレット間でユニークではない
説明 : [netui] タグ上の tagid 属性は、[scriptContainer] タグを追加しない限り、[Beehive タグ] に移動した後、pageflow ポートレット間でユニークではない。[scriptContainer] タグを追加すると、ユニークな tagId が強制的に生成される。
回避策 :以下に示すように、[scriptContainer] タグを使用して、ユニークな値で書き換えた ID 属性を取得することができる。
<%@ taglib uri="http://beehive.apache.org/netui/tags-html-1.0" prefix="netui" %> <netui:scriptContainer> <netui:anchor action="myAction" tagId="myId">some text</netui:anchor> </netui:scriptContainer>
|
|
|
[新規サーバー] ウィザードで、8.1 ドメインが正常にアップグレードされた場合でもエラーが表示される
ユーザが [新規サーバー] ウィザードでバージョン 8.1 ドメインを選択すると、Domain Upgrader を起動するためのハイパーリンクが表示される。ドメインのアップグレードが正常に完了しても、状況によってはウィザードのステートが更新されないことがある。その場合、ウィザード上部の古いエラー メッセージとアップグレード用のハイパーリンクが表示されたままになり、[次へ] ボタンが有効にならない。
回避策 : [ ドメイン ホーム] コンボ ボックス内のテキストを選択し直すことで問題を回避できる。
|
|
|
インタフェース内にブレークポイントを設定すると Eclipse がハングする
Eclipse デバッガではインタフェース宣言の中にもブレークポイントを設定できるが、そのようなブレークポイントが発動すると Eclipse がハングすることがある。これは、Workshop for WebLogic バージョン 9.2.1 のベースとなっている Eclipse 3.1 に関する確認済みの制限事項である。
回避策 : ブレークポイントは必ず実際のメソッド実装に対して設定し、インタフェース ファイル内にあるメソッド宣言に対しては設定しないようにする。
|
|
|
Workshop for WebLogic のインストール場所が <BEA-HOME> のデフォルト ディレクトリと異なる場合、Workshop for WebLogic ライブラリの Javadoc 添付ファイルが破損することがある
Workshop for WebLogic 9.2.1 のインストール時には必要に応じてインストール先ディレクトリを指定できるが、デフォルト (「workshop92」) 以外の場所を指定した場合、Workshop for WebLogic コード (サービス コントロールやタイマー コントロールなど) の Javadoc を IDE から発見できず、そのため、たとえば〔Shift〕+〔F2〕を押してクラスのドキュメントを表示する操作などが機能しないことがある。
回避策 : 該当するライブラリに含まれる JAR に対して、Javadoc 添付ファイルを手作業で追加する。たとえば、Workshop 基本コントロールの JAR に Javadoc 添付ファイルを追加するには、[ ウィンドウ｜設定｜WebLogic｜J2EE ライブラリ] を選択する。[ weblogic-controls-1.0] を選択して [ 編集] をクリックする。[クラスパス コントリビューション :] ツリーに属する各 JAR を展開し、[Javadoc location] ノードを右クリックして [ 編集] を選択する。次に、[Javadoc ロケーション・パス] に <BEA-HOME>/<your-workshop-dir>/workshop4WP/docs/api を設定する (<your-workshop-dir> は、インストール時に指定した、デフォルトと異なる Workshop ディレクトリ名)。
|
|
|
JDK クラスのデバッグ時に「ソースが見つかりません」エラーが発生する
アプリケーションのデバッグ時、場合によって JDK クラスのソースを発見できず、クラスに対して「ソースが見つかりません」というエラーのページが表示されることがある。
回避策 : ソース添付ファイルを手作業で追加する。この作業は、ワークスペースの設定レベルで行うことも、デバッグ セッションの実行中にその場で行うこともできる。
デバッグ セッションがまだ開始されていない場合、[ ウィンドウ｜設定｜Java｜インストール済み JRE] の設定ページを表示する。jdk150_04 JRE を選択し、[ 編集] をクリックする。[JRE を編集] ダイアログ ボックスで、[デフォルト・システム・ライブラリーの使用] を選択解除する。rt.jar のノードを展開し、[ソース添付] ノードを選択する。[ 編集] ボタンをクリックして [ 外部ファイル...] を選択し、<BEA-HOME>/jrockit90_150_04/ を参照して src.zip を選択する。
デバッグ セッションがすでに開始されており、JDK クラスに対して「ソースが見つかりません」というエラーを示すエディタ ページが表示された場合は、[ソース・ルックアップ・パスの編集...] ボタンをクリックする。[ 追加] ボタンをクリックし、[外部アーカイブ] を選択する。ファイル ダイアログ ボックスで、<BEA-HOME>/jrockit90_150_04/ を参照して src.zip を選択する。
|
|
|
デバッガ上で、スレッドに「(may be out of sync)」と表示される
サーバ上のアプリケーションをデバッグ中に、コードに対する変更内容を保存すると、1 つまたは複数のスレッドに対してデバッガ ウィンドウ上に「(may be out of sync)」と表示されることがある。これが発生した場合は、コードの変更をサーバに反映するためにアプリケーションをパブリッシュし直す必要がある。これは Eclipse 3.1 に関する確認済みの制限事項である。
回避策 : アプリケーションをサーバにパブリッシュし直す。
|
|
|
予期しないサーバ エラーが発生し、IDE の再起動が必要になることがある
制御不能なサーバ エラーまたはサーバの異常終了が発生すると、場合によってパブリッシュのステータスおよびパブリッシュ操作がエラーになることがある。たとえば、サーバ プロセスでメモリ不足エラーが発生すると、Workshop for WebLogic および該当サーバの両方について再起動が必要になる場合がある。
回避策 : Workshop for WebLogic を再起動し、サーバを再起動する。
|
CR272082 CR273414 CR272245
|
JSP タグの変数を JSP エディタ上で解決できない
Eclipse の問題が原因で、一部の JSP タグ (<auth:login> や <portlet:actionURL> など)、および JSP タグで宣言された変数が、実際には正常であるにもかかわらずエラーを含んでいると見なされることがある。その場合、実際にエラーがなくても Eclipse でアプリケーションをパブリッシュ (デプロイ) できない。
回避策 : この問題が発生した場合は、パブリッシュを実行する前に JSP 検証を無効にする必要がある。これらのタグで発生するすべてのエラーを修正し終えるまでは、必ず JSP 検証を有効にしておくこと。デプロイを実行する前に、[ ウィンドウ｜設定] を選択して、ツリーから [ 検証] を選択し、[ JSP 構文バリデータ] チェック ボックスを選択解除する。
|
|
|
Linux で、サーバの起動に使用されるコンソールにマルチバイト文字が正しく表示されないことがある
IDE ではサーバの起動に xterm が使用されるため、コンソールにマルチバイト文字が正しく表示されないことがある。
プラットフォーム : 英語版以外の Linux オペレーティング システム
回避策 : IDE の外部で、使用する言語を表示できるよう適切にコンフィグレーションされたコンソールから、コマンドラインでサーバを起動する。IDE でサーバの定義を作成した後は、すでに動作しているサーバに IDE を接続することも可能になる。
|
|
|
Workshop for WebLogic バージョン 9.2.1 では Tuxedo コントロールを使用できなくなった
Tuxedo コントロールは、Workshop for WebLogic 9.2 以降では使用できない。
回避策 : 『 Tuxedo Control Migration』ホワイトペーパー (PDF 形式) を参照。この PDF では、Tuxedo コントロールから代わりの機能への移行方法を示している。
|
|
|
プロジェクトのインポート後に初めて [プロジェクト｜クリーン] を実行した際には、.apt_src ディレクトリにあるファイルが完全にはクリーニングされないことがある
build ディレクトリ ( .apt_src など) を含んだプロジェクトをユーザがインポートした後で、最初にクリーニングを実行した際には、そのディレクトリにある一部のファイルが削除されずに残ることがある。この問題は初回にのみ発生する。次回以降のクリーニング操作では、生成されたディレクトリも正しく処理される。
回避策 : インポート後に初めてクリーニングを実行した際、.apt_src ディレクトリ内のファイルを手作業で削除する。削除した後、このディレクトリ内に格納される新しいファイルはクリーニング操作で正しく処理される。
|
|
|
ServiceControl 用に生成される Xbean ラッパー クラスは本来、ターゲット JWS に対して可視であってはならないが、可視になってしまう場合がある
発生する状況は限られているが、サービス コントロール用の Xbean 型が生成される際に、WSDL からのラッパー型がサービス コントロール内の型として公開されてしまうことがある (たとえば、1 つのオペレーション シグネチャ内に同じ Document 型が複数回出現する場合など)。生成される型の JAR がターゲット JWS のクラスローダに対して可視になっていると、デプロイ時に型の重複エラーが送出される。
回避策 : ラッパー型を使用するサービス コントロールと、それを呼び出すサービスとを、別のプロジェクトに分離する。SerivceControl クラスがユーティリティ プロジェクトからロードされる場合、そのサービス コントロールとターゲットのサービスはそれぞれ別のアプリケーション内に存在する必要がある。
|
|
|
document/literal/bare スタイルのオペレーションについて、パラメータまたは戻り値として XBean がサポートされていない
オペレーションまたはコールバックについて、document/literal/bare バインディングのパラメータまたは戻り値として XBean を使用する機能はサポートされておらず、使用するとデプロイ時にエラーが発生する。
回避策 : パラメータまたは戻り値として XBean を使用するサービスには、document/literal/wrapped スタイルを使用する。
|
|
|
Workshop for WebLogic に付属の Beehive API には正式版でない部分がある
Workshop for WebLogic に付属の Apache Beehive は、SVN スナップショット (post v1.0.1) である。一部の API は Apache Beehive の post v1.0.1 段階で新設されたものであり、まだ Apache による正式リリースには含まれていない。
以下の API の仕様は、まだ正式に決定したものではない。
Session mutex, HttpSessionMutexListener... NetUI で特定ユーザ全体のロックを実行する方法について、設計上の新たな変更が行われている。オプションの HttpSessionListener (セッション内での変更をシリアライズする際に使用できる、セッション全体に対するミューテックス オブジェクトを作成するインタフェース) が実装されている。 NetUI...で Tree および DivPanel の AJAX リクエスト(.xhr)を処理する低レベル機能へのプラグ ポイント。
Beehive 1.0 リリースで、NetUI の Tree および DivPanel は両方とも AJAX 対応となった。より高度なリクエスト処理およびルーティングを実現できるようにするために、新しいプラグ ポイントがいくつか設けられている。API には以下の変更が加えられている。
URLRewriter getAjaxUrl() メソッド。AJAX リクエストの情報を提供するための URL 書き換えに使用できる。 AJAX リクエストに対してのサービス提供に関する、Chain of Responsibility (CoR) / コマンド パターン。これは、クライアント向けにマークアップやデータをレンダリングするリクエストの処理に使用できる、新しいコマンド処理インフラストラクチャである。高レベルの観点では、Chain of Responsibility (CoR) パターンに基づいて組み合わせられたコマンド ハンドラ クラス群を実装したことと、そのコマンドを NetUI コンフィグレーションに含めたことにより実現されている。 |
|
|
XSD/WSDL ファイルが大きいと、XMLBeans ビルダで極端に長い処理時間がかかる
Workshop for WebLogic で、XMLBeans ビルダを使用してサイズの大きいスキーマファイル (1MB まで) を処理すると、ビルドに要する時間が極端に長くなる。これは、XMLBean コンパイラおよび Eclipse Java ビルダの両方のパフォーマンスに起因する問題である。
回避策 : XMLBean コンパイラのパフォーマンス : XMLBean コードのアサーションを無効にすると XMLBean コンパイラのパフォーマンスを向上できる。アサーションを無効にするには、workshop92/workshop4WP/workshop4WP.ini ファイルに「-da:org.apache.xmlbeans...」という行を追加する。Java および XMLBean ファイルの生成に XMLBeans ビルダを使用していない場合は特に、この変更によって劇的な効果が得られる (たとえば、単純な ALSB XQuery マッパー プロジェクトの場合など)。
Java ビルダのパフォーマンス : XMLBeans ビルダと Java ビルダでは増分ビルドが実行されるため、ビルド サイクルが反復されると、スキーマ (および生成される Java) のうち変更された要素だけが処理の対象となり、初回よりはるかに短い時間でビルドが完了する。ただし、プロジェクトがクリーン ビルドし直される際には完全なビルドが実行され、長い時間がかかる。したがって、XMLBean のソースが必要となり XMLBeans ビルダによる増分ビルドのパフォーマンスが問題になってきた場合は、Workshop for WebLogic の外部で、コマンドラインを使用して XMLBeans Jar ファイルを生成しておき、アプリケーションからはその生成した Jar を参照するという方法が考えられる。
|
|
|
WebLogic EJB プロジェクト プロパティが、生成された Ant ビルド スクリプトから表示されていない
説明 : WebLogic EJB プロジェクト上 [Project｜Properties｜WebLogic EJB] を使用して設定できる [Jar の設定] プロパティおよび EJBC フラグは、IDE ビルドを実行する時のみ使用する。この設定は、エクスポートされた Workshop Ant ビルド スクリプトを実行する時には表示されない。
回避策 : エクスポートされた Ant スクリプトを使用してプロジェクトを構築する前に、EJB Java ソース ファイルの [weblogic.ejbgen.JarSettings] アノテーションを使用してすべての必要な [Jar の設定] プロパティを指定し、必要な EJBC フラグを「weblogic.ejbc」が実行されるビルド スクリプトで直接追加する。
|
|
|
9.2.1 アップグレードのインストール中にインターネット接続が切断された場合は、IDE を再起動する必要がある
9.2.1 アップグレードのインストール中にインターネット接続が切断された場合、JAR ファイルが完全にダウンロードされなかったことを表す以下のようなエラーが表示される可能性がある。
| 注意 : |
Unable to complete action for feature "BEA Workshop for WebLogic Platform" due to errors. Unable to retrieve remote reference ... [Unexpected end of file from server] Unable to retrieve remote reference |
回避策 : アップグレード処理を繰り返す前に、インターネット接続を確認してから IDE を再起動する。
|
|
|
order.xsd から XML タイプを生成できない
.xsd ファイルが通常の相対パス (ファイル プロトコル) を介して別の .xsd ファイルを参照している場合、.xsd ファイルに対して XML タイプを生成するとエラーが発生する
| 注意 : |
この問題は WebLogic Platform 10.0 で解決されている。 |
|
|
|
JMS プロトコルの場合、ServiceControl でのバッファ付きメソッドが失敗する場合がある
ServiceControl でのバッファ付きオペレーションは無効にする必要がある。ただし、基底の WSDL のメッセージ交換パターン (MEP) は、要求/応答 (空の応答付き) または一方向 (応答なしの要求) のいずれかに設定できる。
JMS に対して要求/応答の MEP にした場合、@MessageBuffer の存在によって、要求がデッドロックし、最終的にタイムアウトする。一般的に、次のような警告メッセージが生成される。
生成されるエラー メッセージには、次のような文が含まれる。
注意 : これは、要求用の転送プロトコルが JMS である場合にのみ発生する。
回避策 : ターゲット JWS のデザインに影響を及ぼすことができる場合、JWS オペレーションに @Oneway アノテーションを付けると、基底の MEP が一方向になり、この状況が回避される。ターゲット JWS のデザインに影響を及ぼすことができない場合の回避策としては、TransactionAttribute アノテーションを ServiceControl オペレーションに追加する。
@TransactionAttribute が存在しても、呼び出し側アプリケーション内で行われるアクションのトランザクション動作は変わらない。
|
|
|
Web サービスまたは Web サービスにアクセスするコントロールのパブリッシュに失敗する
Platform アップグレード インストーラを使用して WebLogic Platform 9.2.0 から 9.2.1 以降へアップグレードすると、Web サービスまたは Web サービスにアクセスするコントロールのパブリッシュに失敗する。
回避策: アップグレード後、 -clean オプションを使用して Workshop を起動する。 -clean オプションを使用しないと、以下のようなエラーが返される可能性がある。
java.lang.LinkageError: Class com/bea/wlw/util/virtualfs/VirtualFileSystem violates loader constraints.
|
