リリース ノート

     前  次    新しいウィンドウで目次を開く     
ここから内容

BEA Workshop バージョン 10.2 リリース ノート

このドキュメントの内容は以下のとおりです。

 


Workshop バージョン 10.2 の新機能

信頼性とパフォーマンスの向上

BEA Workshop のこのリリースでは、多数の問題点が修正され、パフォーマンスが改善され、開発効率が向上しています。

Tuxedo コントロール

Workshop は Tuxedo コントロールをサポートするようになりました。これにより、Tuxedo サービスにアプリケーションを接続できます。

WorkSpace Studio ランチャー

Workshop は現在 BEA_HOME/workSpaceStudio_1.1/workSpaceStudio/workSpaceStudio.exe においてWorkSpace Studio ランチャーと統合されています。

Adobe Flex Builder 2 と Flex Charting

Workshop Studio ではサード パーティ アドオン (Windows 対応のみ) として Adobe Flex Builder 2 と Flex Charting がバンドルされています。

Adobe Flex Builder 2 の機能は以下のとおりです。

Workshop Studio に Adobe Flex Builder 2 をインストールするには、「Adobe Flex 2 のインストール」を参照してください。

Adobe Flex Builder 2 と Flex Charting は、Windows でのみサポートされます。

 


サポート対象プラットフォーム情報の参照先

ハードウェアおよびソフトウェア要件とともにサポート対象のプラットフォームに関する詳細については、「サポート対象のプラットフォーム」web サイトを参照してください。

 


Workshop ソース コードの参照先

Eclipse Public License に準拠するために、派生作業用のソース コードを用意しました。このソース コードは、次のリンクからダウンロードが可能です。

https://submit-codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=S372

 


Workshop 10.2 インストーラによって自動的にインストールされた WebLogic Server パッチ

Workshop 10.2 は以下のパッチを自動的に WebLogic Server 10 にインストールします。

パッチ ID : LBTB

Passcode : 8CJVM75F

このパッチは次の問題を解決します。CR346060、CR346061、CR346063、CR346064、CR348244、CR341039。

 


Workshop 10.2 に関する確認済みの制限事項

表 1 に、Workshop for WebLogic に関する確認済みの制限事項を示します。

表 1 BEA Workshop バージョン 10.2 に関する確認済みの制限事項
問題 ID
説明
CR282777
プロジェクトのインポート後に初めて [プロジェクト|クリーン] を実行した際には、.apt_src ディレクトリにあるファイルが完全にはクリーニングされないことがある
build ディレクトリ (.apt_src など) を含んだプロジェクトをユーザがインポートした後で、最初にクリーニングを実行した際には、そのディレクトリにある一部のファイルが削除されずに残ることがある。この問題は初回にのみ発生する。次回以降のクリーニング操作では、生成されたディレクトリも正しく処理される。
プラットフォーム : すべて
回避策 : インポート後に初めてクリーニングを実行した際、.apt_src ディレクトリ内のファイルを手作業で削除する。削除した後、このディレクトリ内に格納される新しいファイルはクリーニング操作で正しく処理される。
CR287585
Web サービスや他のアーティファクトが、複数の EAR の一部である Web プロジェクト内にある場合、[サーバで実行] によって誤った URL が生成される可能性がある
ワークスペースで、複数の EAR に関連付けられている Web プロジェクト内のアーティファクトに対して [サーバで実行] アクションを使用すると、ブラウザが誤った URL を指して起動される可能性がある。つまり、関連付けられている最後の EAR の URL が使用される。
プラットフォーム : すべて
回避策 :
この問題を回避するには、次のいずれかを行う。
a) 起動に使用されない EAR を閉じる。
b) 起動に使用されない EAR から Web プロジェクトを削除する。
c) 正しい EAR を指すように、ブラウザで URL を手動で更新する。
CR293197
JRockit を使用してデバッグする場合に JVMTI イベント (特にブレークポイント) がなくなる
JRockit JVM を使用してデバッグする場合、パフォーマンスに関する問題が発生してブレークポイントがなくなる可能性がある。
プラットフォーム : すべて
回避策 : JRockit 5.0 R27.1 以上に更新する。
CR294199
複数の JMS サーバを持つサーバに (IDE から) デプロイされている場合、バッファ付きコントロール メソッドの呼び出しが実行時に失敗する
IDE はアプリケーションをデプロイするときに、必須の Workshop ライブラリを自動デプロイする。コントロール メソッドで @MessageBuffer を使用すると、weblogic-controls ライブラリ内のアプリケーション スコープの JMS リソースに対して依存関係が生じる。weblogic-controls ライブラリが、複数の JMS サーバを持つサーバに (IDE から) デプロイされた場合、ライブラリはデプロイされるが、アプリケーション スコープの JMS リソースは使用可能にならない。これは、IDE がデフォルトのサブモジュールの対象指定に依存していて、デフォルトのサブモジュールの対象指定は、厳密に 1 つの JMS サーバを含む対象に依存しているためである。デプロイメントに問題があることを警告する以下のようなメッセージが表示される。
<The JMS module named "WlwRuntimeAppScopedJMS" inside 
application "testLibWebApp" does not have a sub-deployment stanza
named "WlwRuntimeAppScopedJMS".Without such a stanza no entities
inside the module will be deployed, since the sub deployments
inside of the sub-deployment stanza named
"WlwRuntimeAppScopedJMS" control where JMS entities inside this
module are targeted.>
警告メッセージが表示されても、ライブラリはサーバにデプロイされる。つまり、ライブラリに依存しているアプリケーションも正常にデプロイされる。ただし、バッファ付きコントロール メソッドの呼び出しは実行時に失敗し、以下のようなメッセージが表示される。
"Failed to invoke end componentFailed to invoke methodMessage
buffering is not available - either the buffering MDB did not
deploy or we are in a standalone WAR"
この状況は、Workshop for Weblogic Platform をサポートしないで作成されたドメインを使用している場合に起きる可能性が高い。
プラットフォーム : すべて
回避策 :
weblogic.Deployer コマンドを使用してライブラリを手動でデプロイする。コマンドの形式は以下のとおり。
java weblogic.Deployer
-username weblogic
-password weblogic
-adminurl t3://localhost:7001
-deploy
-name weblogic-controls-10.0
-source %WL_HOME%/common/deployable-libraries/weblogic-controls-10.0.ear
-targets cgServer
-submoduletargets cgJMSServer@WlwRuntimeAppScopedJMS@WseeJmsServer
-library -libspecver 10.0
-libimplver 10.0
ここで、
- WseeJmsServer はアプリケーション スコープの送り先をホストする
- targets はデプロイメント サーバ
このコマンドは config.xml 内のライブラリ定義を更新する。そのため、1 回だけ実行する必要がある。
CR301661
JMS プロトコルの場合、ServiceControl でのバッファ付きメソッドが失敗する場合がある
ServiceControl でのバッファ付きオペレーションは無効にする必要がある。ただし、基底の WSDL のメッセージ交換パターン (MEP) は、要求/応答 (空の応答付き) または一方向 (応答なしの要求) のいずれかに設定できる。
JMS に対して要求/応答の MEP にした場合、@MessageBuffer の存在によって、要求がデッドロックし、最終的にタイムアウトする。一般的に、次のような警告メッセージが生成される。
Potential blocking operation
{http://someNamespace}someOperation: a synchronous
request/response invocation within a transaction using the JMS
transport can cause deadlocks.Please refer to WebLogic
documentation for details.
生成されるエラー メッセージには、次のような文が含まれる。
javax.xml.rpc.soap.SOAPFaultException: Failed to receive message java.io.IOException: Request timed out
注意 : これは、要求用の転送プロトコルが JMS である場合にのみ発生する。
プラットフォーム : すべて
回避策 : ターゲット JWS のデザインに影響を及ぼすことができる場合、JWS オペレーションに @Oneway アノテーションを付けると、基底の MEP が一方向になり、この状況が回避される。ターゲット JWS のデザインに影響を及ぼすことができない場合の回避策としては、TransactionAttribute アノテーションを ServiceControl オペレーションに追加する。
@MessageBuffer
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void voidMethod();
@TransactionAttribute が存在しても、呼び出し側アプリケーション内で行われるアクションのトランザクション動作は変わらない。
CR304008
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>
CR304502
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 コントロールへの呼び出しが完了した後でコミットまたはロールバックする。
CR308749
コールバックを持つ Web サービス コントロールでは、単純なクラス名の重複がサポートされない
コールバックを持つ複数の Web サービス コントロールに、同じクラス名 (パッケージ名は考慮しない) が付けられていると、jwsc でエラーが発生する。このエラーは、IDE でパブリッシュを行うとき、エクスポートされた Ant スクリプトで利用可能するとき、または IDE から EAR ファイルをエクスポートするときに発生する。以前のバージョンの Workshop では、この状況が起きた場合でも、エクスポートされた Ant スクリプトによって、アセンブル手順が成功したと誤って報告されていた。Ant スクリプトが生成された Java ファイルに対して jwsc を実行しようとしなかったためである。
プラットフォーム : すべて
回避策 : コールバックを持つ Web サービス コントロール (SerivceControl) を使用する場合は、各コントロール ファイルにユニークな非修飾クラス名が付いていることを確認する。パッケージ名が異なるだけでは十分ではない。
CR313306
サービス コントロールの生成時に、誤ったコールバック メソッド名が生成される場合がある
名前にアンダースコアや数字を含む WSDL コールバックに基づいてサービス コントロールを生成すると、誤ったコールバック メソッド名が生成される場合がある。この状況は、アンダースコアまたは数字の後に小文字が続いている場合に起きる。
たとえば、次のような WSDL コールバック名の場合、
a_b
a4b
次のようなコールバック メソッド名が生成される。
a_B
a4B
数字またはアンダースコアに続く最初の文字が大文字になっている。
このメソッドを呼び出すと、次のようなエラーが発生する。
javax.xml.rpc.JAXRPCException: SOAPFaultException - FaultCode
[{http://schemas.xmlsoap.org/soap/envelope/}Client] FaultString
[Failed to get operation name from the incoming request]
プラットフォーム : 10.x
回避策 : アンダースコアまたは数字の後に小文字が続くコールバック メソッド名を避ける。
CR326326
追加システム プロパティを定義するまで Linux 上にヘッドレス モードで Workshop startup.jar を実行できない。
以下のシステム プロパティを true に設定するまで Linux 上にヘッドレス モードで Workshop startup.jar を実行できない。
    m7.disable.swt.init
プラットフォーム : Workshop 10.1
回避策 : システム プロパティ m7.disable.swt.init を true に設定してヘッドレス モードで Workshop を起動します。この回避策のために DISPLAY システム プロパティを設定しないよう注意してください。
CR326466
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 を変更して以下を追加する。
<prefer-application-packages>
   <package-name>antlr.*</package-name>
   <package-name>org.apache.commons.*</package-name>
   <package-name>org.apache.oro.*</package-name>
   <package-name>oracle.*</package-name>
</prefer-application-packages>
Web アプリケーションの場合、Web プロジェクトを EAR に追加して上記に示すように weblogic-application.xml を修正する。
注意 : プロジェクトを再デプロイメントする場合、サーバを再起動する必要がある。
CR327602
プロジェクト名を変更した後、古いプロジェクトはサーバからアンデプロイされない。
EAR に属するプロジェクト名を変更すると、WebLogic Server から前のプロジェクト名がアンデプロイされない。
プラットフォーム : Workshop 10.1
回避策 : サーバからプロジェクトを削除するには WebLogic Server からアプリケーションをアンデプロイして再デプロイする。
CR327849
コマンドライン アップグレード ツールを使用してアップグレードした EJB プロジェクトをデプロイするときに問題が発生。
コマンドライン アップグレード ツール upgradeStarter を使用してアップグレードした EJB プロジェクトをデプロイする時、問題が発生することがある。
プラットフォーム : Workshop 10.1
回避策 : コマンドライン ツールの代わりに IDE を使用してプロジェクトをアップグレードする。Workshop IDE を使用してアップグレードするには、次の手順に従います。
CR328406
アップグレード後、不完全な AppXRay データベースが生成されることがある。
Workshop version 8.1.x から 10.2 へのアップグレード、または 9.2 から 10.0 を通じて 10.2 への移行後、アップグレードしたアプリケーションの初期のビルドは、AppXRay 機能を有効にした Web プロジェクトに対して不完全な AppXRay データベースを生成する場合がある。この場合、App Xaminer ビューに、すべての依存関係が正しく表示されない。
プラットフォーム : Workshop 8.1 以上
回避策 : この問題を修正するには、([プロジェクト|削除] を選択して) workspace を削除して再ビルドする。
CR334542
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 の起動スクリプトの両方に次のフラグを追加する。
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0
CR336597
Web アプリケーション デプロイメント記述子のグラフィカル エディタでは、<resource-ref> 要素がサポートされない。
Workshop のデプロイメント記述子用グラフィカル エディタでは、<resource-ref> 要素がサポートされない。[デプロイメント記述子要素] ツリー ビュー (ソース エディタ上にある) および [概要] ビューでは、<resource-ref> 要素の追加または編集がサポートされない。
プラットフォーム : すべて
回避策 : <resource-ref> 要素を追加および編集するためにソース ビューを使用する。
CR340273
フィルタ ディスパッチャーが、JSF webapp デプロイから警告を出す。
Workshop とバンドルされている MyFaces のバージョンでは、MyFaces web.xml parser のバグのため WebLogic Server コンソールで警告を出す。バグは次にトラックしている。
http://issues.apache.org/jira/browse/MYFACES-1415
警告は無害であり、機能性が失われることはない。
プラットフォーム : すべて
回避策 : これらの警告を無視する。
CR342837
一部の Workshop テキスト フィールドでは、〔Ctrl〕+〔V〕(貼り付け機能) がサポートされない。
WebLogic Portal Eclipse プラグインが存在する場合、一部の Workshop テキスト フィールドでは、〔Ctrl〕+〔V〕(貼り付け機能) がサポートされない。
プラットフォーム : すべて
回避策 : これらのテキスト フィールドに手動でテキストを入力する。
CR342995
Linux : Workshop JSP デザイン ビューでは、ドラッグ アンド ドロップがサポートされない。
Linux の場合、Workshop JSP デザイン ビューでは、デザイン パレットからドラッグ アンド ドロップがサポートされない。
プラットフォーム : Linux
回避策 : ソース ビューのデザイン パレットからドラッグ アンド ドロップする。
CR344306
JSP XML 構文の最小限のサポート
Workshop JSP デザイナーでは、JSP の XML 構文がサポートされなく、XML JSP を解析する時に警告が出される。たとえば、文字「&」に対してエンティティ参照「&amp;」を使用すると、問題ビューには、デプロイメントが防止されたという警告が出される。
プラットフォーム : すべて
回避策 : これらの警告を無視する。JSP XML 構文によってアプリケーションのデプロイメントが妨害されない。
CR350342
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 フォルダにコピーする。
CR355189
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 の機能が使用可能になる。
CR356110
サーバの起動に失敗した場合、Workshop のコンソールがクローズされる。
WebLogic Server は Workshop で起動しない場合、[コンソール] ビューがクローズされ、起動時の失敗に関連するエラーをモニタできない。
プラットフォーム : Workshop 10.2
回避策 : 以下のプロシージャに従う。

1. [サーバ] ビューで、[サーバの概要] を開くためにサーバ インスタンスをダブルクリックする。

2. [起動およびデプロイメント] のセクションで、[Eclipse コンソールで WebLogic server の起動] のチェックを外す。

3. <domain_home>\bin\startWebLogic.cmd|.sh にある起動スクリプトを使用して WebLogic Server を起動する。

4. 起動失敗に関連するエラーを表示するには、コマンド シェル コンソール出力を参照。

CR362046
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 を起動する。


  ページの先頭       前  次