|
|
|
|
|
Web サービス コントロールを使用する WLI アプリケーションのデプロイが失敗する
Web サービス コントロールを使用する WLI アプリケーション 8.1.x から 9.2 MP2 へのアップグレード後に、WLI アプリケーションのデプロイが失敗します。
解決策 : アップグレードしたアプリケーションを正常にデプロイするには、9.2 MP2 に移行した Web サービス コントロールを再作成し、アップグレードされたプロセスで、新しく作成された 9.2 MP2 コントロールを参照します。
|
|
|
アップグレード インストーラを使用して 9.2GA プラットフォームから 9.2 MP1 にアップグレードし、その後に 9.2GA に戻すと、WebLogic Integration および WebLogic Portal のサンプル ドメインが使用できなくなる
9.2 MP1 にアップグレードする際は、よく確認してから実行してください。アップグレードした後に古いバージョンに戻すと、サンプル ドメインが使用できなくなります。
|
|
|
JWS から JPD を呼び出すために使用するプロセス コントロールのコールバック処理では、com.bea.control.annotations.MessageBuffer を使用しないでください。クラスタ環境で com.bea.control.annotations.MessageBuffer アノテーションを使用した場合、信頼性の高い動作にはなりません。
|
|
|
解決策 : 8.1 アプリケーションをアップグレードすると、タイマー コントロールはクラスタ内で使用できない WebLogic Workshop タイマー コントロールにアップグレードされます。アプリケーションをクラスタ環境で使用する場合は、アプリケーションを手動でクラスタ バージョンにアップグレードする必要があります。
|
|
|
アプリケーション ソースをアップグレードした後、MFL のトランスフォーメーションが XQuery の例外 (XQRLUserException) で失敗する
9.2 では、MFL から派生する XMLBean はネームスペースに属しています。8.x では、出力タイプとして MFL 派生の XMLBean を使用する XQuery トランスフォーメーションは、適切なネームスペースの要素を持つ XML を生成するように手動で更新する必要があります。使用されるネームスペースは、スキーマのソース ディレクトリを基準とする MFL ファイルのパスによって決まります。
たとえば、MFL ファイルが project/schemas/dir/purchase.mfl にある場合、生成される XMLBean は XML ネームスペース dir/purchase に属します。
|
|
|
アップグレードしたワークリスト アプリケーションがアップグレードした Integration ドメインで ControlException を送出する
解決策 : デフォルト認証プロバイダを使用している場合、アップグレードしてもセキュリティ ポリシーは設定されません。デフォルトの LDAP プロバイダ以外の認可プロバイダを使用している場合は、このセキュリティ ポリシーを確認または設定する必要があります。
8.1 ドメインをアップグレードした後で、Compatibility 8.1.x タスク プランについてセキュリティ ポリシーを設定し、作成ポリシーで Anonymous ロールを有効にしたことを確認する必要があります。Worklist Administration Console (デフォルトの認可プロバイダ) を使用して、Compatibility 8.1.x タスク プランの作成ポリシーを設定します。サードパーティの認可処理プログラムを使用している場合は、対応するサードパーティ クライアント ツールを使用してポリシーを設定します。
|
|
|
8.1 SP5 から 9.2 にアップグレードしたプラットフォーム アプリケーションでスキーマ (XML Beans) を構築中にエラーが発生する
|
|
|
COFACE アプリケーションでインライン XQ をアップグレードしても、Prolog の外部 XQ は変換されない
解決策 : [ ソース] ビューで、Prolog に存在しない XQuery の xf: を検索し、fn: に置換します。
|
|
|
複数の Web プロジェクトが存在する 8.x アプリケーションをアップグレードすると、ビルド パスに jpdpublic.jar などのプロセス ライブラリが追加されない
解決策 : 依存関係があるアーティファクトは WLI 関連のクラスを持たないため、プロジェクトに追加されません。そのため、ライブラリは手動で追加する必要があります。
|
|
|
プロセス アノテーション内に出現するインライン XQuery 式は、[XQ2002 を XQ2004 にアップグレードします] オプションを選択しても更新されない
アップグレード ウィザードで [XQ2002 を XQ2004 にアップグレードします] オプションを選択した場合でも、プロセス アノテーション内に出現する一部のインライン XQuery 式は更新されません。たとえば、xf: 関数プレフィックスは、本来であれば fn: 関数プレフィックスに置き換えられなければなりません。次に例を示します。
<case name=\"Case\" value=\"xf:string($x)\"/>
<case name=\"Case\" value=\"fn:string($x)\"/>
解決策 : ソース ビューで関数プレフィックスを手動で変更してください。
|
|
|
アップグレード プロセスで同期受信メソッドの非 void 戻り値型が許可される
アップグレード プロセスは非 void 戻り値型をチェックしないため、コンパイル エラーになります。
解決策 : このエラーを検出するには、プロセス XML を解析してメッセージの戻り値型をチェックします。WebLogic Integration では、8.x のソースが無効であることを示す警告またはエラー メッセージが発生します。
|
|
|
アップグレード プレビュー ステージでアップグレード プロセスが異常終了する
アップグレード ウィザードの [アップグレードのプレビュー] タブで [取り消し] をクリックすると、エラーが発生します。発生するエラーはアプリケーションによって異なる可能性があります。アプリケーション固有の問題ではないので、無視してかまいません。
|
|
|
Workshop for Eclipse および MessageBuffer を含む JWS を使用して反復的開発を行った後の例外
JWS と MessageBuffer アノテーションを使用してプロセス アプリケーションを作成します。アプリケーションを Workshop からパブリッシュしてテストします。Workshop から再パブリッシュしないで、Web アプリケーションを変更します。テスト コンソールから JWS または JPD を呼び出すと、「EJB をデプロイできない」というエラーが発生します。
解決策 : サーバを再起動します。サーバの再起動後にアプリケーションをパブリッシュして続行します。
|
|
|
大きい Web アプリケーションをアーカイブするときのメモリ不足
Workshop で生成されたビルド スクリプトを使用して非常に大きい Web アプリケーションをアーカイブすると、java.lang.OutOfMemoryException が発生します。
解決策 : Web アプリケーションの build.xml ファイルで、<apt> タスクに memoryMaximumSize="1024m" プロパティを追加します。
|
|
|
rpc/encoded の複合型配列の型に Java を選択して 8.1 SP4 で生成した Workshop Web サービス コントロールは、複合型配列を具象型配列ではなく anyType[ ] にマップします。以下に例を示します。
<schema targetNamespace="urn:serviciosAdminNE" xmlns="http://www.w3.org/2001/XMLSchema";;> <import namespace="http://schemas.xmlsoap.org/soap/encoding/";;/> <complexType name="Aplicacion"> <sequence> <element name="certificado" type="xsd:base64Binary"/> <element name="descripcion" nillable="true" type="xsd:string"/> <element name="idAplicacion" nillable="true" type="xsd:string"/> <element name="nombre" nillable="true" type="xsd:string"/> <element name="organismo" nillable="true" type="xsd:string"/> </sequence> </complexType> <complexType name="AplicacionArray"> <sequence> <element name="abonadoArray" nillable="true" type="impl:ArrayOf_tns1_Aplicacion"/> <element name="aplicacionArray" nillable="true" type="impl:ArrayOf_tns1_Aplicacion"/> </sequence> </complexType> </schema> <schema targetNamespace="http://notanot/jboss-net/services/ServicioWEBAdminNE";; xmlns="http://www.w3.org/2001/XMLSchema";;> <import namespace="http://schemas.xmlsoap.org/soap/encoding/";;/> <complexType name="ArrayOf_tns1_Aplicacion"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="tns1:Aplicacion[]"/> </restriction>
|
|
|
</complexContent> </complexType> </schema> 生成される Workshop Web サービス コントロールでは、次のようになっています。
public static class AplicacionArray implements java.io.Serializable { public anyType[] abonadoArray; public anyType[] aplicacionArray; } public static class anyType implements java.io.Serializable { private static final long serialVersionUID = 1L; public XmlObject[] t; }
anyType[] は、9.2 の Workshop Web サービス コントロールではサポートされません。したがって、アップグレード後に、上記のようなサービス コントロールでは、デプロイメント時またはアプリケーションのアーカイブ時にエラーが発生します。
解決策 : アップグレード後に、サービス コントロール内の型を、具象型をポイントするように変更します。以下に例を示します。
public static class Aplicacion implements java.io.Serializable { public byte[] certificado; public java.lang.String descripcion; public java.lang.String idAplica ion; public java.lang.String nombre; public java.lang.String organismo; } public static class AplicacionArray implements java.io.Serializable { public Aplicacion[] abonadoArray; public Aplicacion[] aplicacionArray; }
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
WebLogic Integration のメッセージ ブローカ チャネルをサブスクライブする JPD を含むアプリケーションをアップグレードすると、未完了のコンパイル ステージがエラー通知なしで終了するようになります。その後でアプリケーションを実行すると、チャネルに対する JPD のサブスクリプションで失敗します。
この問題は、テスト アプリケーション「e2ecm」に対してのみ報告されています。この問題に対する解決策としては、足りないライブラリ (この場合は p13n_app.jar) を、アプリケーションのクラスパスに追加します。
|
|
|
|
JWS のアップグレードで、アノテーション common:message-buffer および jws:message-buffer の属性 retryDelay および retryCount に対して、デフォルト値 (default=0) が使用されない
解決策 : アプリケーションをアップグレードした後、手動で weblogic.jws.MessageBuffer アノテーションに retryCount=0 および retryDelay=0 を設定します。
|
|
|
|
ControlHandle.sendEvent が未使用の場合、Java カスタム コントロール内で ebXMLControl を使用している ebXML アプリケーションに null ポインタ例外が発生する
解決策 : 『WebLogic Integration 9.2 へのアップグレード』の「JPD およびコントロール コールバック」の注意と例を参照してください。 この情報は、 http://edocs.beasys.co.jp/e-docs/wli/docs92/upgrade/component.html にあります。
|
|
|
XMLObject を返すトランスフォーム関数に相当するアップグレード後の XQuery ファイルは、実行時にエラーになる場合がある
解決策 : 複数の戻り値を指定するように XQuery 関数のシグネチャを変更します。
|
|
|
インタフェース WSDL は、Workshop for WebLogic Platform 9.2 Web サービス コントロールではサポートされない
BPEL インポートによってインタフェース WSDL に対する Workshop Web サービス コントロールが生成されると、アプリケーションのデプロイメントでエラーが発生します。
解決策 : BPEL インポートの後で、WSDL にダミーの実装要素 <service> と <binding> を追加します。
|
|
|
|
|
スキーマを含む 8.x アプリケーションのアップグレードと、Workshop for Weblogic Platform アップグレード ウィザードでのプレフィックスの追加
アップグレード ウィザードでスキーマを含む 8.x アプリケーションにプレフィックスを追加すると、エラーになります。これは、アップグレード ユーティリティが、8.x のアプリケーション ディレクトリで指定されたプレフィックスを持つ Schemas.jar ファイルを探すためです。8.x のアプリケーション ディレクトリには Schemas.jar ファイルしか存在せず、このようなファイルはありません。
解決策 : アップグレード ウィザードでプレフィックスを追加しないようにするか、または <EarProject>\EarContent\APP-INF\lib\Schemas.jar ファイルを手動で削除します。
|
|
|
|
|
JPD およびコントロール ファイルで互換性のないパッケージが参照されているため、B2B アプリケーションのアップグレードがエラーになる
JPD とコントロール ファイルで異なる 2 つのパッケージの EnvelopeDocument が参照されている場合、B2B アプリケーションのアップグレードは失敗します。JPD は EnvelopeDocument を org.xmlsoap.schemas.soap.envelope で参照し、コントロール ファイルは weblogic.wsee.jws.wlw.schemas.soap11 パッケージを参照しています。
解決策 : ebXML コントロール ファイルで、EnvelopeDocument のパッケージを weblogic.wsee.jws.wlw.schemas.soap11 から org.xmlsoap.schemas.soap.envelope に変更します。
|
|
|
|
|
BPEL インポートは、パートナ リンクとして指定されている外部サービスに対して Workshop Web サービス コントロールを生成します。Workshop Web サービス コントロールは、相対 URI を使用して WSDL (サービス コントロールと関連付けられている) にインポートされた外部スキーマを解決できません。
解決策 : 外部スキーマをユーティリティ プロジェクトから Web プロジェクトにコピーします。その後、Web プロジェクト内で WSDL を基準とする場所に外部スキーマを配置します。
|
|
|
"elementFormDefault=unqualified" を指定してスキーマ内で定義されているスキーマ要素に対する SOAP が正しくない
elementFormDefault="unqualified" を指定したスキーマの要素が、XML Bean バインディングで生成される Workshop Web サービス コントロールのパラメータまたは戻り値の型として使用された場合、Workshop Web サービス コントロールによって生成される SOAP メッセージは正しくありません。
解決策 : スキーマで elementFormDefault="qualified" を使用します。Workshop で新しいスキーマを作成するときに、スキーマに elementFormDefault="qualified" を追加します (elementFormDefault="unqualified" に対するデフォルト値)。
|
|
|
|
|
サスペンドしている外部イベント ジェネレータが、ドメインのアップグレード時にアップグレードされない
WebLogic Integration のドメイン アップグレード ツールは、実行中のイベント ジェネレータだけをアップグレードします。 つまり、サスペンド状態のイベント ジェネレータがある場合、そのジェネレータはアップグレードされません。
解決策 : アプリケーションをアップグレードする前に、サスペンドしているイベント ジェネレータがないことを確認します。
|
|
|
|
|
アップグレード後の 8.1 アプリケーションで、JPD およびトランスフォーメーション クラスのコンパイル エラーが表示される
log4j クラスを使用するアプリケーション (特に EJB プロジェクト) をビルドするには、log4j.jar ファイルが必要です。log4j.jar ファイルの場所が 8.x から 9.2 リリースになるときに変更されているため、手動で指定する必要があります。
解決策 : プロジェクトをアップグレードした後、プロジェクト ビルド パスに log4j.jar ファイルを手動で追加します。
|
|
|
|
|
アップグレード時にソース ファイル内の MBCS (マルチバイト文字セット) 文字はサポートされず、アップグレード後は正しく表示されない
|
|
|
WebLogic Integration と他の WebLogic 製品の相互運用性の問題
次のパッチを WebLogic Integration 9.2 以外のインストール環境にインストールしてください。
パッチ ID S35L パッチ ID XE28 パッチ ID 9Z62
WebLogic Integration 9.2 とのシームレスな相互運用性を保証するには、WebLogic Server または Workshop for WebLogic Platform のインストールにこれらのパッチをインストールする必要があります。
|
|
|
|
|
|
|
|
XmlObject[ ] は、JWS コールバック処理のパラメータとしてサポートされていない
|
|
|
9.2 では、JWS の weblogic.jws.Types アノテーションで配列型がサポートされない
8.x JWS/Workshop Web サービス コントロールの jws:parameter-xml/jws:return-xml アノテーションで、include-java-types の値として配列型が定義されている場合、9.2 に正しくアップグレードされません。
解決策 : アップグレードを開始する前に、JWS/Workshop Web サービス コントロールを設計し直してください。
|
|
|
|
|
JAX-RPC (Tylar) バインディングが、xsd:schema 要素を参照するスキーマをサポートしない
次のコード サンプルで示すように、このサポートがないことで、xsd:schema 要素に対する参照を含む WSDL からの Workshop Web サービス コントロール/JWS (JAX-RPC バインディングを使用する) の生成に影響があります。
<xsd:element ref="xsd:schema"/>
解決策 : 次の例で示すように、要素に名前を割り当てて、xsd:anyType を使用してください。
<xsd:element name="schema" type="xsd:anyType"/>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
zip でアーカイブされた Workshop for WebLogic Platform プロジェクトのインポートに関する問題
zip アーカイブ ファイルになっている Workshop for WebLogic Platform プロジェクトをインポートしようとすると、例外が発生します。
解決策 : アーカイブされたファイルの内容を解凍してから、プロジェクトをインポートしてください。
|
|
|
|
|
アプリケーションのアップグレード時、ログ ファイルに ArrayIndexofBoundException が記録される
8.x アプリケーションを 9.2 にアップグレードする際に、ArrayIndexofBoundException が WORKSPACE_ROOT/.metadata/.log ファイルに記録される場合があります。このエラーは致命的なものではなく、アップグレードされるアプリケーションのビルド パスに BEA_HOME/weblogic92/server/lib/webserviceclient.jar がある場合に発生する可能性があります。
|
|
|
JMS と HTTP の転送 URI が同じコールバックを持つ JWS で、アップグレードの後にコンパイル エラーが発生する
解決策 : アップグレードした JWS をコンパイルする前に、URI が異なることを確認します。
|
|
|
weblogic.jws.Types アノテーションが、JWS のコールバック処理でサポートされていない
解決策 : weblogic.jws.Types アノテーションを使用しないようにサービスを変更します。
|
|
|
|
|
パラメータまたは戻り値の型として w3c.dom.* (Document、Element、および DocumentFragment) を使用する JWS がサポートされていない
解決策 : w3c.dom 型を使用する JWS の操作シグネチャおよび戻り値の型は、SAAJ 型を使用するように変更する必要があります。操作の内部実装を、SAAJ および w3c.dom 型に、またはこれらの型から変換するよう更新する必要があります。
|
|
|
XMLBean 型を返す JWS をアップグレードすると、コンパイルできなくなる
XMLBean 型を返す JWS をアップグレードすると、アップグレード後にはその JWS に関するすべての操作でコンパイル エラーが発生します。メッセージでは、戻り値の型が、XMLBean のスキーマで定義されている要素名と一致しないことが示されています。
解決策 : @WebResult アノテーションを削除します。または、スキーマの型と一致するように名前を変更します。
|
|
|
wftracking/M2_ArchHelloAsync.java ファイルおよび Process_Tracking_Binary.java について 2 つの問題が確認されている。削除で helloDelay_onTimeout メソッドから例外が返される
問題を解決した後、[問題] ウィンドウに以下のエラーが表示されます。
このプロジェクトのビルド パスは未完したので、これは構築されませんでした。weblogic.xml.xmlnode.XMLNode のためクラス ファイルを検索できません。ビルド パスを修正して、このプロジェクトの構築を再試行してください。(wfTrackingWeb) weblogic.xml.xmlnode.XMLNode タイプは解決できません。必要な .class ファイルから間接的に参照しました。
解決策 : 上記の問題を解決するには、ビルド パスの外部 jar リストに weblogic.jar を追加します。
|
|
|
|
|
|
|
WebLogic Integration で 8.x アプリケーションを実行中に、テスト ブラウザ コンソールにコメント文字列が表示される
解決策 : これは仕様どおりの動作です。アップグレードされた JPD にコメントが存在するため、そのコメントがテスト ブラウザに表示されます。アップグレード後にコメントを削除してください。
|
|
|
Workshop for WebLogic Platform 9.2 Web サービス コントロールの生成が、コールバックを含む 8.x WSDL からはサポートされていない
解決策 : 8.x WSDL が 8.x JWS を表している場合は、以下を実行します。
8.x JWS を 9.2 にアップグレードします。 9.2 JWS から WSDL を生成します。 9.2 Workshop Web サービス コントロールを生成します。
8.x WSDL が 8.x JPD を表している場合は、以下の手順を実行します。
8.x JPD を 9.2 にアップグレードします。 9.2 JWS を JPD のフロントエンドにします (9.2 JPD からプロセス コントロールを生成した後、プロセス コントロールからフロントにする JWS を生成します)。 9.2 JWS から WSDL を生成します。 前の手順で生成した WSDL から、9.2 Workshop Web サービス コントロールを作成します。 |
|
|
|
|
|
|
|
|
|
|
SOAP 1.2 メッセージング形式を使用するクライアントのアップグレードが要求される
解決策 : WebLogic Integration 9.2 へのアップグレード時に Web サービスの WSDL が変更されます。新しい仕様に準拠するには、SOAP 1.2 メッセージング形式を使用する Web サービスのクライアントを生成し直す必要があります。
|
|
|
Workshop for WebLogic Platform 9.2 Web サービス コントロールが、8.x スタイルのエンド ポイント サービスからの 8.x スタイルのコールバック メッセージの受信をサポートしない
8.x のアプリケーションに、Workshop Web サービス コントロール (呼び出し元) を使用して別の JPD (呼び出し先) を呼び出し、その JPD からのコールバックを受信する JWS (呼び出し元) の使用例が含まれている場合、アップグレード後は正しく機能しません。
解決策 : 呼び出し先 (JPD) と呼び出し元 (JWS および Workshop Web サービス) の両方をアップグレードし、以下の手順を実行します。
9.2 JWS を呼び出し先 JPD のフロントエンドにします。 9.2 JWS 用に、WSDL から 9.2 Workshop Web サービス コントロールを再生成します。 ステップ (2) で生成した 9.2 Workshop Web サービス コントロールを、呼び出し元の JWS から使用します。 |
|
|
|
|
|
|
|
Workshop for WebLogic Platform 9.2 Web サービス コントロールが、8.x スタイルのエンド ポイント サービスからの 8.x スタイルのコールバック メッセージの受信をサポートしない
8.x のアプリケーションに、Workshop Web サービス コントロール (呼び出し元) を使用して別の JPD (呼び出し先) を呼び出し、その JPD からのコールバックを受信する JPD (呼び出し元) の使用例が含まれている場合、アップグレード後は正しく機能しません。
解決策 : 呼び出し先 (JPD) と呼び出し元 (JPD および Workshop Web サービス) の両方をアップグレードし、以下の手順を実行することをお勧めします。
9.2 JWS を呼び出し先 JPD のフロントエンドにします。 9.2 JWS 用に、WSDL から 9.2 Workshop Web サービス コントロールを再生成します。 ステップ (2) で生成した 9.2 Workshop Web サービス コントロールを、呼び出し元の JPD から使用します。
呼び出し元の JPD および Workshop Web サービス コントロールだけをアップグレードした場合は、以下の手順を実行します。
呼び出し先の JPD 用に、WSDL から 9.2 サービス ブローカ コントロールを生成します。 アップグレードした Workshop Web サービス コントロールの代わりに 9.2 サービス ブローカ コントロールを、呼び出し元の JPD から使用します。 |
|
|
|
|
|
|
|
|
|
|
9.2 で、JMS コントロールが受信メッセージを非同期に処理しない
8.x では、JPD は JMS コントロールを使用して、受信メッセージを非同期に処理できました。9.2 ではこの機能はサポートされておらず、JPD の処理は失敗します。
解決策 : 受信メッセージを非同期に処理するには、JMS コントロールを WebLogic Integration JMS コントロールに置き換えます。
|
|
|
|
|
HTTP プロトコルまたは JMS プロトコルでの非 SOAP XML メッセージ形式の使用がサポートされていない
8.x リリースでは、JWS に対して、非 SOAP XML メッセージ形式が HTTP プロトコルまたは JMS プロトコルを介してサポートされていました。Workshop for WebLogic Platform 9.2 では、SOAP プロトコルのみがサポートされています。したがって、JPD のフロントエンドの JWS をアップグレードすると、機能しなくなります。
解決策 : JPD のフロントエンドの JWS を削除し、HTTP または JMS のイベント ジェネレータを作成して、非 SOAP XML メッセージを受信します。その後、JPD にメッセージ ブローカ サブスクリプションを作成し、先に作成した HTTP または JMS イベント ジェネレータから非 SOAP XML メッセージを受信します。
|
|
|
