表 1 BEA Workshop バージョン 10.0 に関する確認済みの制限事項
|
|
|
|
|
アップグレードが正常に完了しなかった場合に、ファイルが元の状態に戻されない
アップグレードが正常に完了しなかった場合、ファイルが元に戻されず、アップグレードが不完全な状態のままになる。たとえば、ファイル拡張子は .java に変更されたのに、アノテーションは Workshop for WebLogic 9.2.1 形式に変換されていないといった状態が発生する。ただし、元のソース ファイルは変更されない。
回避策 : バージョン 8.1 のファイルをワークスペースにドラッグ アンド ドロップしてから、該当するファイルに対するアップグレードを実行し直すか、プロジェクト全体をインポートし直す。
|
|
|
Web サービスのパラメータ名が変更されている場合、アップグレード後に @WebParam アノテーションが必要となる
WSDL 開始 (start-from-WSDL) モードの Web サービスで、パラメータ名 (Java シグネチャ内) と WSDL 名が一致していない場合、アップグレード後に @WebParam アノテーションを手作業で追加する必要がある。パラメータ名の変更は、使用されている WSDL 名が Java の識別子として有効でない場合に行われることが最も多い。
回避策 : 該当する Web サービス オペレーションの各パラメータに、対応する WSDL 名を指定した @WebParam アノテーションを追加する。
|
|
|
[新規サーバー] ウィザードで、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 for WebLogic 基本コントロールの 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/3.2 に関する確認済みの制限事項である。
回避策 : アプリケーションをサーバにパブリッシュし直す。
|
|
|
予期しないサーバ エラーが発生し、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.2) である。一部の API は Apache Beehive の post v1.0.2 段階で新設されたものであり、まだ Apache による正式リリースには含まれていない。
以下の API の仕様は、まだ正式に決定したものではない。
netui データ グリッドの一部のデータ セットのサポート
SVN 431515 実装により、一部のデータ セットがサポートされ、configurePager タグに「partialDataSet」フラグが追加される。この機能は Apache Beehive リリース v1.0.2 には含まれていなかったが、Workshop for WebLogic の Beehive post v1.0.2 スナップショット リリースに含まれていた。 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 コンフィグレーションに含めたことにより実現されている。 |
|
|
アップグレードの際に .jcx ファイルで一部の MBCS 文字がコピーされない
.jcx ファイルをアップグレードするときに、アップグレード プロセスが一部の MBCS 文字をアップグレード後のファイルにコピーできない場合がある。この状況は、UTF-8 エンコーディングの WSDL が他の種類の MBCS エンコーディング (MS932 (Japanese) など) のファイルに含まれていて、MBCS 文字がそのファイルで WSDL 定義の外側にある場合に発生する。
この場合、生成されるファイルには元の文字の代わりに「????」が含まれて、コンパイルされなくなる。
1. wsdl 定義と VM のエンコーディングが異なる場合は、wsdl 定義を UTF-8 などの代わりに VM のエンコーディングに変更する。
3. サービス コントロール ソースのコメントと生成後の wsdl ファイルの両方で、wsdl 定義を元の設定 (UTF-8 など) に変更する。
|
|
|
WebLogic EJB プロジェクトのプロパティは、生成された Ant ビルド スクリプトからは見えない。
説明 : WebLogic EJB プロジェクト ([プロジェクト｜プロパティ｜WebLogic EJB]) で設定できる [Jar の設定] プロパティと EJBC フラグは、IDE のビルドの実行時にのみ使用できる。これらの設定は、エクスポートした Workshop Ant ビルド スクリプトの実行時には見えない。
回避策 : エクスポートした Ant スクリプトでプロジェクトをビルドする前に、EJB Java ソース ファイルの weblogic.ejbgen.JarSettings アノテーションを使用して必要な [Jar の設定] プロパティをすべて指定し、必要な EJBC フラグを「weblogic.ejbc」が実行されるビルド スクリプトに直接追加する。
|
|
|
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 回だけ実行する必要がある。
|
|
|
8.1 アップグレード中に [取り消し] をクリックすると、例外が発生する場合がある
8.1 アプリケーションのアップグレード中に、アップグレードのプレビュー ウィンドウで [取り消し] をクリックすると、例外が発生する場合がある。
|
|
|
クラスタ内のコントロール メッセージのバッファリングにはサブモジュールの対象指定が必要になる
アプリケーションで、アノテーション com.bea.control.annotations.MessageBuffer を使用して、コントロールのメッセージのバッファリングを有効にしている場合、クラスタをデプロイしようとすると、「While attempting to create destination MSG_BUFFER_QUEUE in module <name_of_your_ear>!WlwRuntimeAppScopedJMS the JMSServer of name <name_of_your_cluster> could not be found」というエラーが発生する場合がある。
回避策 : この場合は、weblogic.Deployer コマンドに次のような submoduletargets オプションを指定して、MSG_BUFFER_QUEUE を特定の JMS サーバに対象指定する必要がある。
|
|
|
XDoclet ファセットを有効にした Web プロジェクトの移行でエラーが発生する
XDoclet ファセットが有効になっている Workshop for WebLogic 9.2 アプリケーションをバージョン 10.0 に移行すると、次のエラー メッセージが発生する。
回避策 : 回避策はない。XDoclet はバージョン 10.0 ではサポートされていない。
|
|
|
コマンドラインでのアップグレードで、誤った致命的ではないエラーが生成されることがある
8.1 アプリケーションのアップグレードをコマンドラインで実行したときに、致命的ではない org.xml.sax.SAXParseException が生成される場合がある。
回避策 : これは誤ったエラーであるため、無視しても問題ない。IDE からアップグレードする場合はこの問題は起きない。
|
|
|
Perforce Eclipse プラグイン (P4WSAD) では、アプリケーションをバージョン 9.2 からバージョン 10.0 にアップグレードした後の新しい .prefs ファイルは追加されない
説明 : Workshop for WebLogic バージョン 9.2 アプリケーションから 10.0 にアップグレードする場合、[Perforce Pending Changelists] ビューには、アップグレード プロセスで作成されたファイルがすべて表示されるとは限らない。たとえば、com.bea.wlw.libmodules.core.prefs ファイルに取って代わる com.bea.workshop.wls.core.prefs はビューに追加されない。
説明 : プロジェクト レベルで [ チーム｜Open for Add] を選択してファイルを手動で追加する。プロジェクトに追加される新しい .prefs ファイルと他のすべての新しいファイルは、ビューに追加される。
|
|
|
プロジェクトの移行時、ファイル weblogic.xml と weblogic-application.xml の「exact-match」要素値は無視される
説明 : Workshop for WebLogic バージョン 9.2 アプリケーションをバージョン 10.0 にアップグレードする場合、ライブラリ モジュールに関して <exact-match> 要素は無視される。<exact-match> が true に設定されていても、アップグレード プロセスでライブラリ モジュールは 10.0 で利用できる最新のバージョンにアップグレードされる。
説明 : Workshop 10.1 を使用して 9.2 アプリケーションをアップグレードする。Workshop 10.1 では古いライブラリ バージョンがサポートされる。
|
|
|
JMS プロトコルの場合、ServiceControl でのバッファ付きメソッドが失敗する場合がある
ServiceControl でのバッファ付きオペレーションは無効にする必要がある。ただし、基底の WSDL のメッセージ交換パターン (MEP) は、要求/応答 (空の応答付き) または一方向 (応答なしの要求) のいずれかに設定できる。
JMS に対して要求/応答の MEP にした場合、@MessageBuffer の存在によって、要求がデッドロックし、最終的にタイムアウトする。一般的に、次のような警告メッセージが生成される。
生成されるエラー メッセージには、次のような文が含まれる。
注意 : これは、要求用の転送プロトコルが JMS である場合にのみ発生する。
回避策 : ターゲット JWS のデザインに影響を及ぼすことができる場合、JWS オペレーションに @Oneway アノテーションを付けると、基底の MEP が一方向になり、この状況が回避される。ターゲット JWS のデザインに影響を及ぼすことができない場合の回避策としては、TransactionAttribute アノテーションを ServiceControl オペレーションに追加する。
@TransactionAttribute が存在しても、呼び出し側アプリケーション内で行われるアクションのトランザクション動作は変わらない。
|
|
|
Web アプリケーションをバージョン 10.0 にアップグレードすると、[ページ フロー コントローラ] ソース フォルダが、デフォルトの場所に戻る場合がある
Beehive NetUI ファセットを持つ一部の 9.2 Web プロジェクトでは、[関連ファイルモデル] の設定値が保持されない場合がある。特に、こうしたプロジェクトに複数のソース フォルダが含まれ、[ページ フロー コントローラ] プロパティ パネルでデフォルト以外のソース フォルダに設定されている場合、この値は、このプロジェクトを 10.0 にアップグレードするとデフォルトに戻る。
Beehive NetUI ファセットと JSF ファセットの両方が含まれているプロジェクトでは、同じ状況が [ プロジェクト｜プロパティー｜関連ファイル モデル｜JSF バッキング ファイル] プロパティで発生する場合がある。
回避策 : 10.0 でこの値を変更するには、[ プロジェクト｜プロパティー｜関連ファイル モデル｜ページ フロー コントローラ] を選択し、目的のソース フォルダを選択する。
|
|
|
「プロジェクトのアップグレード」ウィザードを長時間開いたままにした後で取り消しまたは終了すると、Workshop IDE の状態が不安定になる
「プロジェクトのアップグレード」ウィザードを長時間開いたままにした後で取り消しまたは終了すると、Workshop IDE でエラーが発生する場合がある。Workshop の状態が不安定になり、それ以降に問題がさらに発生する可能性がある。
回避策 : 「プロジェクトのアップグレード」ウィザード ダイアログを長時間開いたままにしておかない。エラーが発生した場合は、IDE を再起動する。
|
|
|
Perforce プラグインを使用して Workshop 9.2 プロジェクトを Workshop 10.0 にインポートする場合にエラーが発生する可能性がある
Perforce プラグイン (P4WSAD) を使用して Workshop 9.2 プロジェクトを Workshop 10.0 にインポートする場合、エラーが発生したり、IDE を閉じるように要求されたりする場合がある。これらのエラーやプロンプトは、自動ビルド サイクルで 10.0 へのアップグレード中に生じるデータの不整合が原因で表示される。
回避策 : p4win などの外部クライアントを使用して、Perforce からプロジェクトを同期させる。[ファイル｜インポート｜全般｜既存プロジェクトをワークスペースへ ] を選択して、プロジェクトをワークスペースにインポートする。
|
|
|
Workshop for WebLogic 9.2 から移行されたアプリケーションをクリーニングすると、ワークスペースのビルドが何度も実行される場合がある
特定の状況において、Workshop for WebLogic 9.2 から移行されたアプリケーションが繰り返しビルドされる。
回避策 : ワークスペースのビルドが完了するまで、一時的に自動ビルドを無効にする ([プロジェクト｜自動的にビルド])。その後で自動ビルドを再度有効にする。
|
|
|
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>
|
|
|
スタンドアロン モードでヘルプを実行するためのドキュメントが正しくない
説明 : Workshop for WebLogic Platform バージョン 10.0 ドキュメントのスタンドアロン モードでヘルプを起動するためのコマンドが正しくない。
プラットフォーム : Workshop for WebLogic Platform 10.0
回避策 : スタンドアロン モードでヘルプを起動するには、次のコマンドを実行する。
%BEA_HOME%/jdk150_06/bin/java -classpath %BEA_HOME%/tools/eclipse32/eclipse/plugins/org.eclipse.help.base_3.2.1.R321_v20060822.jar org.eclipse.help.standalone.Infocenter -command start -eclipsehome %BEA_HOME%/tools/eclipse32/eclipse -port 7034 -noexec -product com.bea.workshop.product.wl.workshop
|
|
|
8.x アプリケーションを 9.x/10 アプリケーションにアップグレードする場合、1 つのページ フロー メソッドから JDBC コントロールへ複数のメソッド呼び出しを行うと、問題が発生することがある
ページ フローからのトランザクション スコープにおける変更が原因。詳細については、以下で説明されている。
「コントロールはトランザクションのスコープ内で自動的に実行されない」の節を参照。
8.x アプリケーションを 9.x/10 アプリケーションにアップグレードする場合、1 つのページ フロー メソッドから JDBC コントロールへ複数のメソッド呼び出しを行うと、問題が発生することがある。問題の要点は次のようになる。JDBC コントロールに対して最初の呼び出しが行われると、トランザクション インターセプタによって新しいトランザクションが作成される。その呼び出しに応答があると、トランザクションはコミットまたはロールバックされる。
JDBC コントロールに次の呼び出しが行われると、新しいトランザクションが作成されるが、コントロールで使用されている JDBC 接続は新しいトランザクションでは使用できない (接続は最初のトランザクションのリソースとして関連付けられている)。
8.x ページ フローの動作では、JDBC コントロールは各メソッド呼び出し後に JDBC 接続を解放していた。ページ フローから呼び出されるコントロール メソッドのトランザクション スコープは、コントロール メソッドの呼び出しの最初にトランザクションを開始し、メソッドが戻るときにトランザクションを終了するというものだった。コントロールがトランザクションをロールバックすると、そのトランザクション内で実行されているすべての処理もロールバックされていた。
1) トランザクション (8.x では暗黙的) を使用しない場合は、
トランザクション インターセプタのアノテーション (アップグレード ツールによって挿入される) をコントロール メソッドから削除してよい。
2) トランザクションを使用する場合は、ページ フロー メソッドで JTA トランザクションを作成して、JDBC コントロールへの呼び出しが完了した後でコミットまたはロールバックする。
|
|
|
9.2 ドメインをアップグレードする前にアプリケーションをアンデプロイする必要がある
移行したアプリケーションを正常に再デプロイするためには、9.2 ドメインをアップグレードする前に、すべてのアプリケーションをアンデプロイする必要がある。WebLogic コンソールを使用すると、既存のアプリケーションの一覧を表示したり、各アプリケーションを削除したりできる。
|
|
|
Workshop for WebLogic と Workshop Studio を同じ Eclipse インストール環境にインストールしてはならない
Workshop for WebLogic と Workshop Studio の両方を同じ Eclipse インストール環境にプラグインとしてインストールしてはならない。複数のエラーや障害が発生する。
回避策 : Workshop for WebLogic と Workshop Studio を別々の Eclipse インストール環境にインストールする。
|
|
|
Web アプリケーションの一部ではあるが EAR の一部ではないプロジェクトの参照があると NoClassDefFound エラーが発生する
EAR 内の Web プロジェクトが Java プロジェクトを参照していて ([J2EE モジュール依存関係｜Web ライブラリー] 設定)、さらに、その Java プロジェクトが EAR の一部ではない場合、クラスがロードされず NoClassDefFound エラーが発生する。これは、反復的な開発中の場合にのみ発生する。EAR をエクスポートすると、EAR 内の Web アプリケーションの web-inf/lib ディレクトリに jar が正しくコピーされる。
回避策 : ユーティリティ プロジェクトを使用し、そのプロジェクトを EAR に追加する。Web アプリケーションのプロパティで、[J2EE モジュール依存関係｜Web ライブラリー] 設定を使用して Java プロジェクトを参照させる。反復的な開発中も、エクスポートされた EAR でも、クラスが見つかるようになる。
|
|
|
サービス コントロールを RPC/Enc WSDL から生成する場合、生成されないタイプがある
サービス コントロールを複合型を持つ RPC/Enc WSDL から生成する場合、[サービス コントロール生成ウィザード] でタイプ JAR は生成されない。
プラットフォーム : BEA Workshop for WebLogic Platform 10.0
回避策 : タイプ生成ウィザードでタイプ JAR を生成する。WSDL を右クリックして、[Web サービス｜タイプ JAR ファイルの生成] を選択する。
|
|
|
9.2 ワークスペースのアップグレード後に [問題] タブが正しく表示されない
9.2 ワークスペースを Workshop 10.0 で開くと、[問題] ビューのカラムが正しく表示されない。
回避策 : [問題] ビューを閉じて再び開く。再び開くには、[ウィンドウ｜ビューの表示｜問題 ] を選択する。
|
|
|
Java Web サービス (JWS) でネストされた型を使用できない
WebLogic Server 9.x/10.0 の Web サービス スタックでは、パラメータまたは戻り値としてネストされた型をサポートしていない。ただし、Beehive コントロールでは、データ値のパターンとして内部クラスがよく使用される (たとえば、JDBC コントロールでは、データベース クエリからの戻り値を保持する内部クラスの例がコメントアウトされている)。したがって、Beehive コントロールのネストされた値を JWS で使用することはできない。
回避策 : JWS で使用される内部クラスを含む Beehive コントロールでは、内部クラスをスタンドアロン クラスに変換する必要がある。
|
|
|
コールバックを持つ Web サービス コントロールでは、単純なクラス名の重複がサポートされない
コールバックを持つ複数の Web サービス コントロールに、同じクラス名 (パッケージ名は考慮しない) が付けられていると、jwsc でエラーが発生する。このエラーは、IDE でパブリッシュを行うとき、エクスポートされた Ant スクリプトでアセンブルを行うとき、または IDE から EAR ファイルをエクスポートするときに発生する。以前のバージョンの Workshop では、この状況が起きた場合でも、エクスポートされた Ant スクリプトによって、アセンブル手順が成功したと誤って報告されていた。Ant スクリプトが生成された Java ファイルに対して jwsc を実行しようとしなかったためである。
回避策 : コールバックを持つ Web サービス コントロール (SerivceControl) を使用する場合は、各コントロール ファイルにユニークな非修飾クラス名が付いていることを確認する。パッケージ名が異なるだけでは十分ではない。
|
|
|
8.x ポータル アプリケーションをアップグレードした後で Workshop for WebLogic がハングする
8.x ポータル アプリケーションをアップグレードした後で Workshop for WebLogic がハングする場合がある。
回避策 : HTML 構文バリデータを無効にして、アップグレードを再試行する。バリデータの選択を無効にするには、[ウィンドウ｜設定｜検証 ] を選択する。[HTML 構文バリデーター ] のボックスを選択解除する。
|
|
|
未使用のコールバックを持つサービス コントロールを 8.1 から 10.0 にアップグレードすると、コンパイル エラーが生成される場合がある
Workshop 8.1 アプリケーションで、Web サービス ファイルで使用されないコールバックが WSDL ファイルで指定されている場合、アップグレードすると、そのコールバックがアップグレード後の 10.0 Web サービス ファイル内に生成される。コールバックが外部タイプを使用している場合、コンパイル エラーが生成される可能性がある。
回避策 : サービス コントロールのコールバック インタフェース内のコードをコメントアウトするか、コールバックを完全に削除する。
|
|
|
サービス コントロールの生成時に、誤ったコールバック メソッド名が生成される場合がある
名前にアンダースコアや数字を含む WSDL コールバックに基づいてサービス コントロールを生成すると、誤ったコールバック メソッド名が生成される場合がある。この状況は、アンダースコアまたは数字の後に小文字が続いている場合に起きる。
たとえば、次のような WSDL コールバック名の場合、
数字またはアンダースコアに続く最初の文字が大文字になっている。
このメソッドを呼び出すと、次のようなエラーが発生する。
回避策 : アンダースコアまたは数字の後に小文字が続くコールバック メソッド名は避ける。
|
|
|
ドキュメントのスタンドアロン モードでヘルプを実行するためのコマンドが正しくない
Workshop for WebLogic Platform 10.0 のドキュメントのスタンドアロン モードで実行するためのコマンドが正しくない。
プラットフォーム : Workshop for WebLogic Platform 10.0
回避策 : スタンドアロン モードでヘルプを実行するには、次のコマンドを使用する。
%BEA_HOME%/jdk150_06/bin/java -classpath %BEA_HOME%/tools/eclipse32/eclipse/plugins/org.eclipse.help.base_3.2.1.R321_v20060822.jar org.eclipse.help.standalone.Infocenter -command start -eclipsehome %BEA_HOME%/tools/eclipse32/eclipse -port 7034 -noexec -product com.bea.workshop.product.wl.workshop
|
|
|
10.0 ドメインに対する新しいライブラリ モジュールの自動デプロイメントで、プロダクション デプロイメント時にクラスが見つからない場合がある
Workshop 10.1 で、Workshop for WebLogic 10.0 インストールを指す新しいターゲット ランタイムを作成し、そのインストールのドメインに対してアプリケーションを開発する場合、Workshop 10.1 では、アプリケーションのすべてのファセットに対してより新しいバージョンのライブラリ JAR (より新しいバージョンがある場合) が自動的にパブリッシュされる。
しかし、アプリケーションを 10.0 ドメインにデプロイする場合、ドメインがより新しいライブラリにアクセスしない場合がある。
プラットフォーム : Workshop for WebLogic Platform 10.1
回避策 : 10.0 ドメインを 10.1 ドメインに手動で更新する。ドメインを更新するには、リリース ノートの CR325421 (下記) の指示に従う。
|
|
|
Workshop for WebLogic 10.0 を 10.1 にアップグレードする場合にドメインの手動アップグレードが必要になる場合がある
Workshop for WebLogic 10.0 以前のドメインを Workshop バージョン 10.1 に移行する場合、IDE を使用してドメイン アップグレードを開始する必要がある。これによりドメインがアップグレードされ、Workshop バージョン 10.1 の最新のランタイム バイナリが設定される。
IDE が使用できない環境のドメインを管理している場合 (IDE がサポートされていないプラットフォーム、またはデプロイされたサーバなど)、手動のアップグレードが必要になる場合がある。
プラットフォーム : Workshop for WebLogic Platform 10.1
回避策 : 次の手順で 10.1 バージョンのライブラリをドメインに追加する。
1. 10.1 バイナリを指すように setDomainEnv スクリプトを手動で変更する。
2. サーバを起動して次の新しいライブラリをドメインにデプロイする。
beehive-controls-1.0.2.1.ear
beehive-controls-1.0.2.1.war
beehive-netui-1.0.2.1.war -- new
beehive-netui-resources-1.0.2.1.war
jsf-myfaces-1.1.3.war -- new
weblogic-controls-10.1.ear -- new
weblogic-controls-10.1.war -- new
次のトピックは、Weblogic デプロイヤおよび Weblogic コンソールを使用してライブラリをデプロイするときに役立つ。
WebLogic デプロイヤを使用したライブラリのデプロイについては、http://edocs.beasys.co.jp/e-docs/wls/docs100/deployment/deploy.html#wp1020594 を参照。
WebLogic Server コンソールを使用したライブラリのデプロイについては、http://edocs.beasys.co.jp/e-docs/wls/docs100/ConsoleHelp/taskhelp/deployment/InstallApplicationsAndModules.html を参照。
|
|
|
WebLogic Server 10.0 MP1 でサーバ コントロールを使用して 10.0 アプリケーションを起動するときにランタイム例外が発生する
WebLogic Server 10.0 MP1 でアプリケーションをデプロイした後にサービス コントロールを使用して 10.0 アプリケーションを起動すると、ServiceClassCacheException が発生する。この例外は、JDK 150_06 と 150_11 の javax.xml.namespace.QName クラスのシリアル バージョン UID が不一致のために発生する。
回避策 : 次の JVM 引数を startWeblogic スクリプトの WebLogic Server 起動コマンドに渡す。
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0
|
|
|
Web サービス アプリケーションのパブリッシュに失敗する
アップグレード インストーラを使用して Workshop for WebLogic Platform 10.0 を 10.0.1 にアップグレードすると、Web サービス アプリケーションのパブリッシュに失敗する。これは、アップグレード プロセスがプラグインを上書きしてキャッシュが古くなってしまうため。
回避策 : アップグレード後に - clean と - initialize オプションを指定して workshop4WP.exe を実行し、キャッシュを更新する。
|
|
|
9.2 MP2 から 10.0 にアップグレードした後にインストール済みのランタイムを編集できない
9.2 MP2 から 10.0 へのアプリケーション アップグレードを実行した後にインストール済みのランタイムを編集しようとすると、Workshop からエラーが返される。
回避策 : 9.2 のインストール済みのランタイムを削除してから 10.0 のインストール済みのランタイムを編集する。
| 注意 : |
Workshop 10.0 で 9.2 のワークスペースを開いている場合は、2 つのインストール済みのランタイムが作成される。1 つはワークスペースを開いている 10.0 用に作成され、もう 1 つはワークスペースの本来の作成元である 9.2 用に作成される。 |
|
|
|
10.0 MP1 から 10.0 にダウングレードすると予期しない EOF エラーが発生する
製品のアンインストーラをコンソール モードで実行すると、無害の EOF エラーが返され、ダウングレードが正常に完了したことを示す確認メッセージは返されない。
|
|
|
Workshop 10.0 のアンインストールが適切に完了しない
Workshop 10.0 MP1 から 10.0 にダウングレードした後で 10.0 をアンインストールした場合、BEA_HOME ディレクトリ内の一部のファイルが自動的には削除さない。
回避策 : ディレクトリ内の不要なファイルを手動で削除する。
|
|
|
Smart Update を使用して 10.0 から 10.0 MP1 に製品アップグレードすると失敗する
HPUX 64 ビット マシンの場合、Smart Update を使用して Workshop 10.0 から 10.0 MP1 にアップグレードすると致命的なエラーでアップグレードが失敗する。
回避策 : パッケージ アップグレード インストーラを使用して 10.0 インストールを 10.0 MP1 にアップグレードする。
|
