リリース ノート
 |
 |
|
|
このドキュメントには、WebLogic Workshop 8.1 サービス パック 6 (SP6) リリースに関する事前情報が記載されています。このドキュメントは予告なしに変更される場合があります。
WebLogic Workshop 8.1 SP6 をインストールして使用する前に、以下の情報をお読みください。
最新のリリース ノートについては、次の URL にある BEA のマニュアル Web サイトにアクセスしてください。
http://edocs.beasys.co.jp/e-docs/
サポート対象のプラットフォームとハードウェアとソフトウェアの要件の詳細については、次の URL にある「WebLogic Platform サポート対象のコンフィグレーション」を参照してください。
http://edocs.beasys.co.jp/e-docs/platform/suppconfigs/index.html
WebLogic Workshop 8.1 SP4 のページ フローは、Apache Software Foundation™ の Jakarta™ プロジェクトの一部である Struts 1.1 に基づいています。これは Struts 1.1 の「Release Candidate」ソフトウェアではなく、リリース版の Struts 1.1 ソフトウェアです。WebLogic Workshop のページ フローが提供するプログラミング フレームワークによって、XML コンフィグレーション ファイルの自動生成や同期化を始めとする多数の拡張機能が追加されるほか、洗練されたグラフィカルな統合開発環境 (Integrated Development Environment : IDE) で Web アプリケーションを定義、ビルド、デプロイ、保守することができます。既存の Struts アプリケーションとページ フローを相互運用する場合は、Struts 1.1 を使用する必要があります。詳細については、WebLogic Workshop ヘルプの「Struts とページ フローとの相互運用を実現する」を参照してください。
WebLogic Workshop で提供される JSP ページは、デフォルトで UTF-8 (Unicode Transformation Format-8) でエンコードされます。UTF-8 は Unicode 文字の 8 ビット エンコード形式です。IDE で [ファイル｜新規作成｜JSP ファイル] を選択すると、生成されたファイルの最上部付近に以下の行が表示されます。
<!--Generated by WebLogic Workshop--> <%@ page language="java" contentType="text/html;charset=UTF-8"%>
WebLogic Portal および WebLogic Integration のリリース ノート
WebLogic Portal のリリース ノートについては、次のリンクを参照してください。
http://edocs.beasys.co.jp/e-docs/wlp/docs81/relnotes/index.html
WebLogic Integration のリリース ノートについては、次のリンクを参照してください。
http://edocs.beasys.co.jp/e-docs/wli/docs81/relnotes/index.html
サービス パック 4 には WebLogic Workshop 8.1 に対する以下の拡張機能が含まれています。
以前のバージョンの WebLogic Workshop からの移行
以下の手順は、Workshop 7.0 および 8.1 ベータ版からアプリケーションを移行するユーザに適用されます。Workshop 8.1 SP1 から 8.1 SP2 または 8.1 SP4 にアプリケーションを移行する必要はありません。
以前のバージョンの WebLogic Workshop で使われていた .work ファイルは、WebLogic Workshop 8.1 ではサポートされません。
以前のバージョンの WebLogic Workshop から WebLogic Workshop 8.1 にアプリケーションを移行するには、以下の手順に従います。
WebLogic Workshop を起動します。
[ファイル｜新規作成｜アプリケーション] を選択して新しいアプリケーションを作成します。
[空のアプリケーション] を選択し、新しいアプリケーションの名前を入力します。
既存の WebLogic Workshop アプリケーションから新しいアプリケーションにプロジェクトとファイルをインポートします。
また、SP4 以前で構築されたページ フローに最初にアクセスすると、WebLogic Workshop では自動的に更新していくつかの変更を行うか、またはユーザに変更の保留について尋ねます。
ソース管理と WebLogic Workshop アプリケーションの併用
WebLogic Workshop では、Perforce P4、Rational ClearCase、および CVS と統合されたソース管理を提供しています。ソース管理システムを WebLogic Workshop アプリケーションと併用している場合は、一部のファイルをチェックインしないようにする必要があります。これは、それらのファイルが動的に生成または更新されるためです。また、これらのファイルは編集しないでください。対象となるファイルは以下のとおりです。
<アプリケーション ルート>/META-INF/ ディレクトリのファイル
/.workshop ディレクトリのファイル
<プロジェクト ルート>/WEB-INF/classes ディレクトリのファイル
デフォルトのスキーマ プロジェクトを含めたコントロール プロジェクトおよび Java プロジェクトからビルドされた JAR ファイル
Struts コンフィグレーション ファイル (<プロジェクト ルート>/WEB-INF/.pageflow-struts-generated ディレクトリ内の jpf-struts-config.xml および jpf-struts-config--global.xml を含む)。これらのファイルは WebLogic Workshop によって自動的に生成および更新されます (/.pageflow-struts-generated サブディレクトリは SP2 から導入されました。「ページ フローの変更」を参照してください)。
Sybase データベースの 'DDL in Transaction' オプションを使用する
Web アプリケーションで次のようなコンポーネントの組み合わせを使用する場合、Sybase データベース オプションの 'DDL in Transaction' を true に設定する必要があります。この設定を使用すると、データベース テーブル作成コマンドが適切に機能します。
たとえば、SQL スクリプトでは次のようになります。
exec master.dbo.sp_dboption WEBLOGIC, 'ddl in tran' ,true go use WEBLOGIC go checkpoint go
Windows で名前にスペースを含むディレクトリに WebLogic Workshop をインストールすると、サーバ起動時に予期しない動作が発生する場合がある
名前にスペースが使用されているディレクトリに WebLogic Workshop をインストールすると、IDE から WebLogic Server を起動する際に予期しない結果を招く場合があります。場合によってはサーバが起動されず、進行状況ダイアログが表示されたままとなります。
回避策 : 名前にスペースが使用されていないディレクトリに WebLogic Workshop をインストールします。
Windows: 管理者特権を持つユーザとして WebLogic Workshop を使用する
Windows では、管理者特権を持つユーザとして WebLogic Workshop をインストールし、使用する必要があります。そうしないと、WebLogic Workshop アプリケーションを実行したときに次のエラーが発生する場合があります。
java.lang.SecurityException: Could not open windows registry node Software¥JavaSoft¥prefs at root 0x80000002: Access Denied
一部のロケールで Linux 上の WebLogic Workshop が起動に失敗する
Linux マシン上で、LANG 設定が ja_JP.eucjp (日本語)、ko_KR.euckr (韓国語)、および zh_CN.gbk (中国語) の場合に、WebLogic Workshop は起動に失敗します。次のエラーが送出されます。
Error occurred during initialization of VM
java.lang.Error: java.lang.IllegalStateException: recursive invocation
回避策 : JDK1.4.2_05 以降をダウンロードしてインストールします。[WEBLOGIC_HOME]¥workshop¥Workshop.sh を開いて、新しくインストールした JDK を指すようにパス "[BEA_HOME]¥jdk142_04/jre/bin/java" を編集します。WebLogic Workshop を再起動します。
ファイルを交互に表示するための〔Ctrl〕+〔Tab〕を Linux 環境で有効にする
〔Ctrl〕+〔Tab〕を押すと、WebLogic Workshop で開いているファイルが交互に表示されます。Linux システムでは、〔Ctrl〕+〔Tab〕が別の機能にすでに割り当てられている場合があります。WebLogic Workshop の Linux 版をインストールしている場合は、Workshop IDE で〔Ctrl〕+〔Tab〕を使用してウィンドウを交互に表示するために、〔Ctrl〕+〔Tab〕の既存のマッピングを無効にすることができます。
XML スキーマをコンパイルする際に大文字/小文字が区別されない
Windows にインストールした WebLogic Workshop では、スキーマ プロジェクトで XML スキーマをコンパイルする際に大文字/小文字が区別されません。このため、スキーマ ファイルに名前の大文字/小文字のみが違っている要素が含まれていると、ネームスペースの衝突が発生するおそれがあります。
無効な EJB リンク値によって 503 エラーが発生する場合がある
EJB コントロールに無効な EJB リンク値が含まれていると、デプロイメント エラーが発生してユーザに 503 が返されるおそれがあります。
会話を実装する複数の WSDL に対してビルド エラーが発生する
会話を実装する複数の WSDL が同じスキーマ プロジェクトに配置されていると、ビルドが失敗して重複グローバル タイプ エラー メッセージが表示されます。この問題は、会話を実装する各 WSDL に別々のスキーマ プロジェクトを作成することで解決できます。
テスト ブラウザの [テスト XML] タブが SOAP 1.2 をサポートしない
テスト ブラウザの [テスト XML] タブでは、SOAP 1.2 Web サービスをテストすることができません。SOAP 1.2 Web サービスをテストするには、[テスト フォーム] タブまたは別のテスト クライアントを使用する必要があります。
サーバがアプリケーションへのリクエストを処理しているとき、IDE ではそのアプリケーションのソース ファイルを編集できない
WebLogic Server がアプリケーションへのリクエストを処理している場合、IDE ではそのアプリケーションのソース ファイルを編集できません。編集すると、アプリケーションのサーバへのデプロイが失敗する可能性があります。
回避策 : WebLogic Server を停止して再起動します。
Workshop アプリケーションと同じサーバにデプロイされたアプリケーションでの log4j の使用
Workshop アプリケーションが log4j を使用する他のアプリケーション (必ずしも Workshop アプリケーションとは限らない) と共に WebLogic Server にデプロイされているときは、サーバ上のすべてのアプリケーションが log4j バージョン 1.2.8 を使用する必要があります。log4j の別のバージョンを使用すると、WebLogic Workshop で使用する log4j と衝突する場合があります。
アプリケーションが大きすぎる場合にビルドが失敗するおそれがある
きわめて大きなアプリケーションをビルドすると、コンパイル プロセスがメモリ不足で失敗する場合があります。この問題が発生した場合は、1 つの大きなアプリケーションではなく、より小さな複数のアプリケーションを作成してみてください。
WebLogic Workshop デバッガのコンソール ウィンドウを開いておく必要がある
WebLogic Workshop でアプリケーションをテストすると、WebLogic Workshop デバッガに対してコンソール ウィンドウが開きます。このコンソールは、WebLogic Server を起動するとロードされ、このサーバを停止すると終了します。このウィンドウは手動で閉じないでください。閉じてしまうと、予期しない結果を招くおそれがあります。
大きなアプリケーションで追加のメモリ割り当てが必要となる場合がある
大きなアプリケーションをビルドしてテストしているときに、WebLogic Workshop がメモリを使い果たして実行速度が低下したりシャットダウンしたりする場合があります。
回避策 : Workshop.cfg ファイルを変更してメモリ割り当てを増やすことができます。このファイルは、BEA_HOME¥weblogic81¥workshop¥ ディレクトリにあります。コマンドライン引数に次のフラグを追加します。
VM flag -Xmx512m
大きなスキーマ プロジェクトで追加のメモリ割り当てが必要となる場合がある
大きなスキーマ プロジェクトをコンパイルする場合、メモリ不足エラーが発生することがあります。この場合は、ビルド プロセスを手動で編集して、スキーマのビルドにより大きなメモリを割り当てることができます。
回避策 : スキーマ プロジェクトの build.xml ファイルをエクスポートします (build.xml ファイルをエクスポートするには、スキーマ プロジェクトを右クリックして [プロパティ] を選択し、[ビルド] をクリックしてから [ANT ファイルにエクスポート] をクリックします)。エクスポートされた ANT ファイルで次の要素を検索します。
<xmlbean
classgendir="${classes.dir}"
schema="${src.path}"
classpath="${class.path}"
memoryInitialSize="8m"
memoryMaximumSize="256m"
fork="true"
failonerror="true" />
memoryMaximumSize 属性を編集して、スキーマ プロジェクトのコンパイルにより大きなメモリを割り当てます。build.xml ファイルを保存してから、プロジェクトを再コンパイルします。
クラス ファイルに対応するソース ファイルが削除または名称変更されると、そのクラス ファイルがファイル システムから削除されなくなる
クラス ファイルに対応するソース ファイルが削除されると、WebLogic Workshop はそのクラス ファイルをファイル システムから削除できなくなります。このため、コードでこれらのクラスが削除されたと想定している場合に、予期しない動作が発生するおそれがあります。
回避策 : 古いクラスを、WEB-INF/classes ディレクトリおよび .workshop ディレクトリから削除するか、上記の cleanApp コマンドを実行します。
WebLogic Workshop ヘルプ トピック : トピックの URL
WebLogic Workshop ヘルプのトピックの URL はブラウザのアドレス バーに表示されません。各トピックのヘルプ内でユニークな URL は、トピックの下の方に表示されます。これらの URL は表示の際にスクリプトによって生成されます。したがって、全文検索エンジンのインデックスが付いていないため、検索することはできません。
EJB コントロール ウィザードで、誤ってリモート インタフェースではなくローカル インタフェースを参照する EJB コントロールが作成される
EJB コントロール ウィザードで EJB を生成すると、ウィザードで EJB のリモート JNDI 名を選択した場合でも、生成された EJB コントロール ファイルは常にリモート インタフェースではなくローカル インタフェースを拡張します。
回避策 : EJB コントロール ファイルが作成された後に、ローカル インタフェースではなくリモートのホーム インタフェースと Bean インタフェースを拡張するようにこのファイルを編集します。
[XQuery マッパー] ダイアログから行った変更が、Web サービス ソース ファイルに対してコミットされない
[XQuery マッパー] ダイアログから XQuery マップを編集したときに、変更内容が JWS ソース ファイル内の XQuery マップに保存されない場合があります。編集内容が JWS ファイルに保存されるようにするには、[XQuery マッパー] ダイアログの [テスト] タブをクリックしてからダイアログを終了します。
SP2 リリースでは、WebLogic Server を起動するためのスクリプト (<BEA_HOME>¥weblogic81¥samples¥domains¥workshop¥startWebLogic.sh など) で -memmax フラグをサポートしなくなりました。代わりに環境変数 JAVA_OPTIONS および MEM_ARGS を使用してください。
weblogic.jws.control.DatabaseFilter から com.bea.control.DatabaseFilter へのパッケージの変更
WebLogic Workshop 8.1 リリースでは、パッケージ weblogic.jws.control.DatabaseFilter は com.bea.control.DatabaseFilter に変更されました。
WebLogic Workshop の外部で変更された JAR ファイルの変更内容はアプリケーション ウィンドウに自動的に反映されない
WebLogic Workshop アプリケーションの内部で使用される JAR ファイルを IDE の外部で変更した場合、JAR ファイルに加えられた変更を表示するには、アプリケーションを閉じてから再び開く必要があります。
weblogic.xml の JSP コンフィグレーション セクションにある keepgenerated フラグで予期される動作が起きない
<jsp-descriptor> 要素内の keepgenerated フラグを true に設定しても、予期される動作 (各 JSP ファイルの対応する .java ファイルがディスク上に保持される) が起きない場合があります。
生成されたファイルを取得するために、WebLogic Workshop JSP コンパイラではなく WebLogic JSP コンパイラを使用するように WebLogic Server をコンフィグレーションできます。WebLogic Server で WebLogic JSP コンパイラを使用するには、jsp-servlet パラメータの定義をコメントアウトします。<jsp-param> 要素の前でコメントを開始します。
コンパイラがローカル マシン上に大量の CLASS ファイルを残す場合がある
Windows マシン上で、WebLogic Workshop は CLASS ファイルと JAR ファイルのキャッシュを C:¥Documents and Settings¥[user_name]¥Local Settings¥Temp¥ フォルダに格納します。この CLASS ファイルと JAR ファイルは、javelin-path-cache-xx という形式の名前が付いたフォルダに格納されます。Temp フォルダからこれらのフォルダを定期的に削除してください。
複数のネームスペースに分散するスキーマ コンポーネントへの参照のためにアプリケーションのビルドが失敗する
Workshop ランタイムでは、デフォルト ネームスペースが xmlns="http://schemas.xmlsoap.org/wsdl/"; に設定されています。wsdl の types セクションの非修飾スキーマでタイプ解決の問題を起こしています。
影響を受けるプラットフォーム : 8.1 SP2、SP3、SP4、SP5
回避策 : wsdl に wsdl プレフィックス ネームスペース定義を追加します。wsdl プレフィックスをすべての wsdl 要素に追加します。デフォルト ネームスペースを空のネームスペースに再定義します。
WebLogic Server による受信 SOAP メッセージの処理方法のために、ハンドラにおける SOAP メッセージの扱いに関していくつかの制限事項があります。
- ハンドラは対象のオペレーションを変更できません。サーバはハンドラが呼び出される前に対象のオペレーションを決定します。
- ハンドラでは、サーバがオペレーション名を判別できなくなるような方法で SOAP 本文の値を暗号化することはできません。
- ハンドラは会話 ID を変更できません。会話 ID は、呼び出しと対象のインスタンスを相関させるためにサーバで必要になります。
自動生成された WSDL ファイルをプロダクション環境で使用できない
JWS ファイルから自動生成される WSDL ファイルは、開発目的には適していますが、プロダクション環境には適していません。生成された開発 WSDL には、「localhost」のエンドポイントが含まれています。
WSDL がプロダクション アプリケーションでエクスポーズされる前に、正しい対象サービスを使用するように ServiceControl 要素をコンフィグレーションする必要があります。その方法は環境によって異なります。次のいずれかの方法を選択できます。
1. 収容元のコンポーネントから setEndpoint URL_endpoint を呼び出してエンドポイントをルックアップする (外部コンフィグレーション ストアから)。
2. 環境の DNS (www.some.public.service://servicePath など) を使って正しく解決された値で、WSDL の <location> タグをコンフィグレーションする。
デフォルトでは、新しい WebLogic Workshop ドメインのコンフィグレーションで、JMS および JWS/JPD 対話状態が保持されるデータベースに対して非 XA ドライバが使用されます。新しい接続プールを追加し、対話 JWS/JPD からその接続プールを参照する場合は、XA ドライバを使ってその接続プールを手動でコンフィグレーションする必要があります。
MS SQL を使用する場合、会話形式の Web サービスでは BEA ドライバを使用する必要がある
対話状態を保存するために MS SQL データベースを使用する会話形式の Web サービスをデプロイしている場合は、BEA MS SQL Server ドライバを使用する必要があります。会話形式の Web サービスの場合、DataDirect MS SQL ドライバはサポートされません。
現在、WebLogic Workshop では、添付ファイルの配列を Java プロキシから WebLogic Workshop Web サービスへ送信することはできません。また、添付ファイルの配列を WebLogic Workshop サービス コントロールから WebLogic Server Web サービスに送信することもできません。
JSP ページでは、{pageFlow.myStaticVariable} などのデータバインディング表現で静的変数を参照することができません。静的変数を参照すると、IllegalExpressionException が発生します。データバインディング表現を使用する場合は、参照される変数が静的でないことを確認する必要があります。
ポータル アプリケーションでスタンドアロンのページ フローが securePort トークンを使用する際の問題
ポータル アプリケーションにスタンドアロンでデプロイされているページ フローは url-template-config.xml で定義される {url:securePort} トークンを使用できません。ここでの「スタンドアロン」のページ フローとは、ポータル プロジェクトにデプロイされていて直接アクセスされるがポータル ページには集約されないものを指します。{url:securePort} トークンは、ページ フローがポータル ページに集約される場合にのみ機能します。ポータル内のスタンドアロンのページ フローは以下を使用できません。
https://{url:domain}:{url:securePort}/{url:path}?{url:queryString} url:securePort
ポータル内のスタンドアロンのページ フローの場合は、{url:securePort} トークンを使用する代わりに、url-template-config.xml でポートをハードコード化します。
非パブリック実装クラスを持つインタフェースへのデータバインディングがサポートされない
非パブリック実装クラスを持つインタフェースにデータバインドしようとすると、IllegalAccessException 例外が発生します。パブリック実装クラスを持つインタフェースにのみデータバインドするようにしてください。
ページ フローで JMS コントロールを使用する場合に例外が発生する
ページ フローで JMS メッセージ タイプの JMS コントロールを使用すると、次の例外が発生します。
weblogic.jms.common.IllegalStateException
Web サービスでこのタイプの JMS コントロールを使用する場合はエラーは発生しません。また、ページフロー内で、次のように、TextMessage を受け付ける JMS コントロールに TextMessage を送信するときはエラーは発生しません。
testjms.sendTextMessage("Welcome");
回避策としては、getSession()、createTextMessage()、および sendJMSMessage() の呼び出しを 1 つにまとめるラッパー コントロールを作成します。すべてのメソッドが同じコントロール インスタンスによって実行されます。詳細については、「ページフローからコントロールを呼び出す場合にコントロールの有効期間に関して考慮すべき事がら」を参照してください。
RowSet および Oracle 9.20 TIMESTAMP を使用する場合の変換例外
ORACLE 9.20 SQL 型の TIMESTAMP は WebLogic Server RowSet で現在サポートされていません。Oracle TIMESTAMP データは 11 バイトのデータとして保持され、このオブジェクトを対応する java.sql 型に正しく変換する変換コードはありません。この問題を解決するには、getObject() から返される 11 バイトの表現を java.sql.Timestamp オブジェクトに変換する Rowset フォーム マッピングを作成します。
バイト 表すもの 0 世紀 (1990 の場合は 119) 1 10 年間 (1990 の場合は 190) 2 月 3 日 4 時 5 分 6 秒 7 ナノ秒 8 ナノ秒 9 ナノ秒 10 ナノ秒
oracle.sql.TIMESTAMP クラスの詳細については、Oracle サイトの Javadoc を参照してください。
ページフローがオーバーロードされたアクションを使用している場合、予期しない結果を避けるために、実行時の動作に注意する必要があります。詳細については、@jpf:forward 注釈のヘルプ トピックで備考を参照してください。
WebLogic Workshop IDE で、ページ フローにアクションと同じ名前のサブディレクトリがある場合、フロー ビューは JSP ページによって生成されたアクションを表示しません。このフロー ビューの表示の問題を回避するには、JSP で発生するアクションの名前を変更するか、競合しているサブディレクトリを変更します。
他のエンティティと同じ名前を持つページ フローを作成する際に警告が表示されない
[ページ フロー] ウィザードは、ユーザが既存の Java ベース ファイルと同じ名前で新しいディレクトリを作成しようとしても警告を表示しません。同一の名前を使用すると、パッケージ化の衝突が発生し、それによって .jws、.jcs、.jcx、.java の各ファイルでエラーが解析されます。
回避策 : ディレクトリとそれに対応する Java ベース ファイルには、同じ名前を付けないようにします。誤って同じ名前を付けてしまった場合は、一方のエンティティの名前を変更してください。
ページ フロー コントローラ クラスの begin() メソッドとその他のメソッド
URL に JPF ファイルを指定してページ フローにアクセスすると、そのページ フローの begin() メソッドが実行されます。このメソッドによって、現在のページ フローに対して最初にロードされる JSP ページが決まります。たとえば、サーバ実行中に次の URL にアクセスするとします。
http://localhost:7001/WebApp/Controller.jpf
ページ フローが初期化され、begin() によってページ フローの最初のページである /SamplesApp/WebApp プロジェクトの index.jsp が表示されます。
URI で <メソッド名>.do を使用すると、メソッドに直接アクセスすることができます。次に例を示します。
http://localhost:7001/WebApp/specialFlow/ThisWeeksSpecial.do
メソッドに直接アクセスした場合は、ページ フローの begin() メソッドが無視されて実行されません。このことは、直接指定したメソッドの実行に必要なデータや条件がすでに揃っていれば問題ではありません。ただし、ページ フローの begin() メソッドの役割とページ フロー内の他のメソッドの役割について考えたとき、この点は重要な違いになります。
また、ページ フローのインスタンスが作成されるときに、必ずその onCreate() メソッドが実行されます。onCreate は、URI に <ページ フロー名>Controller.jpf または <メソッド名>.do のどちらが指定されている場合でも実行されます。
ページ フロー内の適切な Struts アクションに対して、緑色の波線による警告が表示されることがあります。この警告は [フロー ビュー] および [アクション ビュー] に表示されますが、[ソース ビュー] には表示されません。こうした警告は該当する Struts アクションが存在しないことを示すものですが、このような場合は誤って表示されているので無視してください。
この誤った警告の例を参照するには、SamplesApp サンプル アプリケーションの strutsInterop サンプルを [フロー ビュー] または [アクション ビュー] で表示します。このサンプルは次の場所にあります。
BEA_HOME/weblogic81/samples/workshop/SamplesApp/WebApp/struts/strutsInterop/strutsInteropController.jpf
メソッドまたはコールバックで XQuery マップを編集するとエラーが発生する場合がある
メソッドまたはコールバックで xquery 属性を変更して XQuery マップを編集しようとすると、スキーマ要素が見つからないことを通知するエラーが表示される場合があります。
回避策 : [アプリケーション] ペインでスキーマ プロジェクトを右クリックし、[Schemas をビルド] を選択することで、スキーマ プロジェクトを再構築します。
コンソールを使った EAR の再デプロイが失敗する場合がある
新しい EJB が EAR ファイルに追加されている場合に、WebLogic Server コンソールからその EAR ファイルを再デプロイしようとすると失敗するおそれがあります。このときに、weblogic.management.ApplicationException 例外が発生する場合があります。
このような場合は、Weblogic Server コンソールではなく、コマンドライン ツール weblogic.Deployer を使って EAR ファイルを再デプロイしてください。コマンドライン ツールでは、次のように -redeploy フラグを使用します。
java -cp ... weblogic.Deployer -source foo.ear -targets myServer -redeploy
WebLogic Workshop の 8.1 リリースでは、WebLogic Server の HTTP フロントエンド機能がサポートされません。
回避策 : プロダクション アプリケーションに対してランタイム ホスト名と HTTP/HTTPS ポートを設定するには、アプリケーションの wlw-runtime-config.xml ファイルを使用します。
現時点では、コントロールにそれ自身のタイプへの参照を組み込むことができません。これを行うと、そのコントロールが属しているプロジェクトをビルドする際に、次のエラーが発生します。
ERROR DispCache [ExecuteThread: '11' for queue: 'weblogic.kernel.Default'][]: Exception processing controls.ReflexiveImpl
Throwable: java.lang.reflect.InvocationTargetException
Stack Trace:
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedConstructorAccessor153.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
...
アプリケーションを新しいドメインに移動すると EJB デプロイメント エラーが発生する場合がある
WebLogic Workshop アプリケーションをあるドメインから別のドメインに移動すると、多数の EJB デプロイメント エラーが発生する場合があります。
workshop ドメインと integration ドメインの場合の回避策 : WebLogic Workshop 付属の workshop ドメインまたは integration ドメインにアプリケーションを移動した場合は、cleanApp コマンドを実行することでこのようなデプロイメントの問題を解決できます。cleanApp コマンドは、Windows (cleanApp.cmd) または Linux (cleanApp.sh) で使用することができます。コマンド プロンプトから、BEA_HOME¥weblogic81¥samples 内のドメイン ディレクトリに移動し、cleanApp を実行します。
プラットフォーム ドメインまたはユーザ作成ドメインの場合の回避策 : アプリケーションをプラットフォーム ドメインまたは各自で作成したドメインに移動した場合は、以下の手順に従って cleanApp コマンドを実行します。
BEA_HOME¥weblogic81¥samples¥workshop に移動します。
次のファイルをプラットフォーム ディレクトリまたは各自のドメイン ディレクトリにコピーします。
cleanApp.cmd (Windows の場合) または cleanApp.sh (Linux の場合)
cleanAppUsage.txt
cleanApp.xml
テキスト エディタで cleanApp.cmd を開き、各自のマシンの適切な場所をポイントするように必要なパスをすべて修正します。
コマンド プロンプトから、ドメイン ディレクトリに移動し、cleanApp を実行します。
Oracle: 対話状態テーブルで USERS 以外のテーブルスペースに BLOB データを格納する必要がある
プロダクション環境にデプロイされた Workshop Web サービスに対話状態テーブルを作成する場合、Oracle ユーザは USERS テーブルスペースに BLOB データを格納することができません。
USERS テーブルスペースに BLOB データを格納すると、テーブルスペースの容量を使い果たすおそれがあります。
回避策 :BLOB データを格納する新しいテーブルスペースを作成します。次のテーブル作成スクリプトをテンプレートとして使用できます。
CREATE TABLE <*tableName*>(
CG_ID varchar(768) not null,
LAST_ACCESS_TIME number(19,0),
CG_DATA BLOB,
PRIMARY KEY (CG_ID)
)
LOB("CG_DATA") STORE AS ( TABLESPACE <*blobTablespace*> )
すべてのデフォルト アプリケーションにタイマー コントロール、JMS コントロール、およびイベント コントロールがある
Workshop アプリケーションからコンパイルされたすべての EAR には、そのリソースがアプリケーションから明示的に参照されていない場合でも、次のリソースが含まれています。
com¥bea¥control¥TimerControl.jcx
com¥bea¥wlw¥runtime¥core¥control¥jmscontrol¥MDBListener.jcx
com¥bea¥wlw¥runtime¥core¥control¥EventControl.jcx
これは EAR コンパイラの予期された動作です。
EJB プロジェクトでの java.lang.AssertionError
EJB プロジェクトは、一時 .java ファイルをいくつか作成した後に、それらを削除します。ファイル システム リスナは、このように生成されたファイルが存在し続けると想定して、「java.lang.AssertionError: added file does not exist」というエラーを返す場合があります。このエラーが発生した場合は、次の手順に従い、ファイルが削除されないようにします。
1. [アプリケーション] ビューで EJB プロジェクトの build.xml をダブルクリックします。
2. ソース エディタを使って、パラメータ「keepgenerated」を true に設定します。
クライアント証明書が取得されなかったときに警告/例外が発生しない
転送セキュリティ メソッド useClientKeySSL()、setClientCert()、および setKeystore() は、キーが存在しない、間違ったパスワードが使用された、あるいはキーストアが壊れていたなどの理由でクライアント証明書が取得されなかった場合に、警告の生成や例外の送出を行いません。
@common:security runAs 注釈がコントロール ファイル (JCX または JCS ファイル) 上でサポートされるのは、コントロールが Web サービス (JWS) またはビジネス プロセス (JPD) からではなくページ フロー ファイル (JPF) から呼び出された場合に限られます。
回避策 :@common:security runAs 注釈は、Web サービスまたはビジネス プロセス ファイルで直接使用し、これらのファイルから呼び出されるコントロールでは使用しないようにします。
データ ダイレクト MSSQL XA ドライバを使用する場合は、JDBC 接続プールのコンフィグレーションで TestConnectionsOnReserve="true" および TestTableName="dbo.sysusers" を指定する必要があります。
これをコンソールから行うには、コンソール左側のナビゲーション ツリーで [<ドメイン名>｜サービス｜JDBC｜接続プール｜<プール名>] の順に移動し、[接続] タブで [表示] をクリックして詳細オプションを表示します。TestConnectionsOnReserve 用のチェック ボックスと、TestTableName 用のチェック ボックスがあります。
MS SQL とデータ ダイレクト ドライバを使用している場合、WebLogic Server が起動時にハングする
WebLogic Server は、(1) MS SQL への接続にデータ ダイレクト ドライバが使用されていて、(2) トランザクションが有効になっている場合、起動時にハングする可能性があります。
回避策 :MS SQL のパッチをすべてインストールしていることを確認してから、MS SQL Server と WebLogic Server を再起動してください。
以下に示すのは、信頼性のあるメッセージングに関連して確認されている制限事項です。
Web サービス コントロールがロード バランサから起動されたときに SERVICE FAULT が発生する場合がある
ロード バランサからクラスタへの通信が可能で、クラスタからロード バランサへの通信が不可能となるようにロード バランサとクラスタがコンフィグレーションされている場合は、同じクラスタ上にデプロイされた Web サービスを呼び出す Web サービス コントロールから成るアプリケーションで問題が生じるおそれがあります。このようなアプリケーションをロード バランサから起動しようとすると、SERVICE FAULT 例外が送出されます。
回避策 : ロード バランサとクラスタが双方向に通信できるようにネットワークをコンフィグレーションします。
Tuxedo コントロールの SP04 リリースでは、XATMI バッファのサポート、パック 10 進数のサポート、およびバグの修正が提供されています。
XATMI バッファのサポート
WTC は XATMI バッファ型の X_COMMON、X_C_TYPE、および X_OCTET をサポートしています。Tuxedo コントロールは、入力引数およびコントロール拡張メソッドからの戻り値として、TypedXOctet のインスタンスを受け付けます。TypedXOctet バッファは TypedCArray バッファと同様に扱われます。Tuxedo コントロールは、入力引数およびコントロール拡張メソッドからの戻り値として、TypedXCommon と TypedXCType のインスタンスも受け付けます。
VIEW バッファの FLD_DECIMAL 型は WTC と Tuxedo コントロールの両方でサポートされます。
インターナショナライズされた Tuxedo コントロール メッセージ
コントロールのすべてのメッセージと表示名がインターナショナライズされているため、コントロールのローカライゼーションを行えます。
日本語にローカライズされたメッセージ プロパティ ファイルが TuxedoControl.jar ファイルのインストールの一部として提供されています。
WebLogic Workshop 8.1 SP04 をインストールするときに、Tuxedo コントロールはデフォルトではインストールされません。Tuxedo コントロールは、アプリケーションにコントロールを初めて挿入するときにインストールされます。Tuxedo コントロールをアプリケーションに挿入するには、[挿入｜コントロール｜Tuxedo] を選択します。インストールすると、<BEA_HOME>/<WEBLOGIC_HOME>/samples/partners/Tuxedo ディレクトリの Tuxedo コントロール サンプルにアクセスできます。
注意 : WebLogic Workshop 8.1 から移行する場合で、アプリケーションで Tuxedo コントロールを使用していなかった場合は、必ず <BEAHOME>/ext_components ディレクトリから Tuxedo ディレクトリとその内容をすべて削除します。こうしておくと、アプリケーションで 8.1 のバージョンが使用されなくなります。ただし、その同じディレクトリに格納されている TuxedoControl.zip ファイルは削除しないでください。この zip は SP04 の Tuxedo コントロールです。
現在 Tuxedo コントロールを使用しているアプリケーションがない場合は、新しい空のアプリケーションで Web サービス プロジェクトを作成します。[アプリケーション] ペインでアプリケーションの名前を右クリックし、[インストール｜コントロール｜Tuxedo] を選択して、Tuxedo コントロールをインストールします。アプリケーションに TuxedoControl.jar ファイルがインストールされて、サンプル ファイルが解凍されます。サンプルは <BEA_HOME>/<WEBLOGIC_HOME>/samples/partners/Tuxedo ディレクトリにあります。
SP02 以降では、WebLogic Workshop のヘルプ コンテンツに Tuxedo コントロール ヘルプ ファイルが用意されています。
Tuxedo コントロール 8.1 を使用するアプリケーションの SP04 への移行
WebLogic Workshop 8.1 SP04 には Tuxedo コントロールの新しいバージョンが含まれています。システムに WebLogic Workshop 8.1、8.1 SP02 または 8.1 SP03 をインストール済みで、WebLogic Workshop 8.1 SP04 にアップグレードする場合は、次の手順に従って Tuxedo コントロールをアップグレードします。
1. <BEAHOME>¥ext_components ディレクトリから、Tuxedo コントロールのディレクトリとその内容をすべて削除します。ext_components ディレクトリに格納されている TuxedoControl.zip ファイルは削除しないでください。
2. Tuxedo コントロールを使用する既存のアプリケーションがある場合は、各アプリケーションを開いて次の手順を実行します。
a. [アプリケーション] ペインで [ライブラリ] フォルダから TuxedoControl.jar ファイルを削除します。
b. [アプリケーション] ペインでアプリケーションの名前を右クリックし、[挿入｜コントロール｜Tuxedo] を選択します。
FML または FML32 応答バッファを使用する際に、[コントロールの挿入 - Tuxedo] ダイアログでフィールド テーブルを設定する
呼び出されたサービスからの応答バッファが FML または FML32 バッファである場合は、必ず非 FML バッファにもフィールド テーブル定義を設定します。フィールド テーブルは、FML または FML32 バッファが送受信される際、および Resource セクションでフィールド テーブルを利用できない場合に必要となります。送受信される FML または FML32 バッファに使用されるフィールド テーブルを提供する WTC リソースをコンフィグレーションすることもできます。
Tuxedo コントロール インポート ウィザードは Tuxedo 7.1 からサービスをインポートできない
Tuxedo コントロールでインポート ウィザードを使用して Tuxedo サービスをインポートすると、WTC から Tuxedo 7.1 への接続が失敗し、エラー メッセージ「Unable to read WSL packet」が表示されます。
回避策 : WebLogic Server Administration Console を使用して、Tuxedo 7.1 から必要な Tuxedo サービスをインポートするように WTC をコンフィグレーションすることで、それらのサービスを WebLogic Workshop および Tuxedo コントロールで利用できるようにします。
Tuxedo アプリケーションで圧縮が有効になっている場合、Tuxedo コントロール ウィザードは動作しない
Tuxedo アプリケーションで、-c オプションを使用して圧縮が有効になるようにワークステーション リスナ (WSL) をコンフィグレーションしている場合、Tuxedo コントロール ウィザードでは WTC のコンフィグレーションやサービスのインポートが機能しません。
回避策 : WebLogic Server Administration Console を使用して WTC をコンフィグレーションします。
Tuxedo コントロールのコンフィグレーション ウィザードは、Tuxedo 7.1 で動作する Tuxedo アプリケーションからローカルおよびリモートのドメイン情報をインポートできない
Tuxedo コントロールのコンフィグレーション ウィザードを使用して WTC をコンフィグレーションする場合、Tuxedo 7.1 で動作する Tuxedo アプリケーションからローカルおよびリモートのドメイン情報をインポートできません。Tuxedo 7.1 への接続は失敗し、コンフィグレーション ウィザードはデフォルトのローカルおよびリモート WTC ドメインのコンフィグレーションを続行します。
回避策 : WebLogic Server Administration Console を使用して WTC をコンフィグレーションします。
Tuxedo コントロールのコンフィグレーション ウィザードは、SECURITY=USER_AUTH の場合、Tuxedo 6.5 アプリケーションからドメイン情報をインポートするときに失敗する
Tuxedo 6.5 アプリケーションからコンフィグレーション情報をインポートするときに、Tuxedo アプリケーションでセキュリティ レベルが USER_AUTH に設定されている場合、Tuxedo コントロールのコンフィグレーション ウィザードは TPEPERM - permission エラーにより失敗します。
回避策 : WebLogic Server Administration Console を使用して WTC をコンフィグレーションします。
Tuxedo コントロールはシリアライズ/デシリアライズ循環クラスを受け付けない
Tuxedo コントロールでは現在、循環定義のある Java クラスを受け付けません。つまり、クラスの中に自身への参照、またはそのクラスを参照している別のクラスへの参照が含まれている場合です。
WSL アドレス パネルの [前へ] ボタンをクリックすると、デフォルト コンフィグレーション設定ダイアログ ボックスが表示される
Web サービスに Tuxedo コントロールを挿入して WTC サービスをコンフィグレーションする場合、WSL アドレス パネルが表示されます。[前へ] ボタンをクリックすると、デフォルト コンフィグレーション設定ダイアログ ボックスが表示されます。操作を取り消すには [前へ] ボタンを 2 回クリックする必要があります。[前へ] ボタンをクリックしても、使用可能なサービスのパネルには戻りません。
回避策 : なし。
リモート ドメインのない Tuxedo アプリケーションの場合、[リモート Tuxedo ドメインのネットワーク アドレス] パネルが 2 回表示される
ドメインのない Tuxedo アプリケーションを開始して、Tuxedo サービスをコンフィグレーションする場合、Tuxedo コントロールは、使用可能なドメインがないことを示すメッセージを表示してから、[Tuxedo Application Network Address] パネルを表示します。マシン名とポート番号を入力して [次へ] をクリックすると、デフォルトのドメインがコンフィグレーションされるというメッセージが表示されます。[Remote Tuxedo Application Network Address] パネルが表示されます。操作を取り消すと、デフォルト コンフィグレーションが試行され、他の有効な Tuxedo アプリケーションへの接続が失敗することにより、Tuxedo コントロールは不安定な状態になります。
回避策 : なし。
[ワークステーション アドレス] パネルで、先頭または末尾にスペースがあると接続が失敗する
[ワークステーション アドレス] パネルで WSL アドレスの先頭または末尾にスペースがある場合、Tuxedo コントロール ウィザードは Tuxedo アプリケーションへの接続に失敗します。
回避策 : WSL アドレスのスペースを削除します。
CR122600 Tuxedo コントロールは継承されたフィールドをシリアライズ/デシリアライズしません。
CR125169 Tuxedo コントロールは、コントロール拡張メソッドへの入力またはコントロール拡張メソッドからの戻り値として、WTC TypedBuffer クラスを直接受け付けません。
CR128102 Tuxedo コントロール コンフィグレーション ウィザードは、完全修飾ドメイン名の WLS ドメイン (machine.beasys.com など) を認識しません。
CR131562 Tuxedo コントロールは、コンフィグレーションで古い形式のネットワーク アドレスを使用すると、例外エラーを表示します。
CR136225 Tuxedo コントロールは動的フィールド テーブルを処理しません。
CR176837 Tuxedo コントロール - エイリアス名を使用する Tuxedo サービスは失敗します。
CR176963 Tuxedo コントロール - デフォルト WTC コンフィグレーションとコンフィグレーション ウィザードを使用してサービスを呼び出すと失敗します。
CR106017: ラップされたプリミティブの代わりに Java プリミティブをサポートする必要があります。
CR106299: JavaBean スタイルのセッターおよびゲッターに対するサポートを追加します。
CR110291: Tuxedo 6.5 からサービスをインポートできません。
CR110383: mapping-strictness が STRICT の場合、short データ型の組み合わせから例外が送出されます。
CR111779: Tuxedo コントロール サンプルのヘルプ コンテンツには、不適切なリンクが 2 箇所あります。
CR121044: Tuxedo コントロール サンプルが壊れています。
CR122518: さまざまなデータ型で、エラーまたは警告メッセージに一貫性がありません。
CR124525: 埋め込まれていないオブジェクトの配列をシリアライズするときの問題。
CR125147: WLW の Tux コントロールをシリアライズできません。ステートフル プロセスでエラーが発生します。