4. 解決された問題

4 つの JBoss Rules 関連の修正が JBoss Enterprise BRMS Platform から移植されました。これらの問題は次のとおりです。

これらの問題はすべて修正されました。

修正済み: マルチスレッド環境で JBoss Rules セッション挿入が予期しない例外 (ConcurrentModificationException) を出力していました。

RuleFlow は、BusinessRulesProcessor ESB アクション内で正しく実行されない場合がありました。これは、通常予想されるステートフルセッションではなく、ステートレスセッションで実行されていたためです。ステートレスセッション処理コードが更新され、このタイプのシナリオをより適切に処理できるようになりました。

ユーザーが CXF を有効にして security_saml クイックスタートをデプロイすると、java.lang.ClassCastException が発生しました。これは、ビルドファイルのエラーが原因で、デプロイメント時にクラスが検出されたが、その後の実行テストでは検出されなかったことが原因でした。この問題を修正するために、クイックスタートで picketlink-sts.war ファイルが更新されました。その結果、例外は発生しなくなりました。

このリリースでは、JBossESB 名前空間の XSD URL が変更されました。JBossESB 製品クイックスタートの jboss-esb.xml ファイルが更新され、現在のネームスペース定義を参照するようになりました。JBoss Developer Studio を使用する場合、またはオートコンプリートが機能しない場合は、正しい名前空間が必要です。

正しい XSD URL は次のとおりです: http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.1.0.xsd

非 ESB Web サービス関連のクイックスタートは、CXF では機能しません。それらはデプロイメント時に失敗します。コードは実行対象のプロファイルをチェックし、jbossws-native が存在しない場合は代わりに有益なエラーメッセージを生成します。

wsmq_router QS readme ファイルの指示には、現在使用されていないデータソースを作成するための不要な手順が含まれていました。このステップはファイルから削除されました。その結果、指示はよりシンプルで関連性が高くなります。

JBossTS トランザクションリーパーがトランザクションを中止すると、JCA レイヤーでデッドロックが発生することがありました。これは、マルチスレッドアクセスの問題が原因でした。コードが修正された結果、このデッドロックは発生しなくなりました。

jboss-esb.xml ファイルが適切なスキーマに対して検証されていませんでした。この問題は、ModelParser 内の静的初期化子の順序が原因でした。正しく検証されるように修正されました。jbossesb-properties.xml ファイルの org.jboss.soa.esb.deployment.schema.validation プロパティーを使用して設定を上書きできることに注意してください。

サーバーの起動時にレジストリー例外が発生しました。これは、JUDDI の同時実行バグが原因でした。コード修正が適用されました。その結果、この例外は発生しなくなりました。

Bean 設定プロパティー名が変更され、JavaBeans 規則に準拠するようになりました。たとえば、次の形式のプロパティー名:

isTransactionEnabled

は次のように命名されました:

transactionEnabled

それらは依然として下位互換性があるため、以前の形式の名前を引き続き使用できます。

JBoss Developer Studio では、BPEL プロジェクトを SOA ランタイムに関連付けることができず、使用可能であっても無効に見えました。その後、ユーザーは、現在のプロジェクトファセットの 1 つをアンインストールするように誤って求められました。この問題は、BPEL ファセット ID を JBoss Developer Studio に追加することで解決され、ユーザーは対象のランタイムとして SOA を選択できるようになりました。

JBoss Rules のバージョンやコンテンツに暗号化されたペイロードが含まれているかどうかによってシリアライズされた形式が変わる可能性があるため、生成されたパッケージは削除されました。自動的に作成されるようになりました。その結果、互換性の問題は発生しなくなりました。

ESB Administration Guide の Database Configuration セクションには、ESB Management Console への参照が含まれていましたが、これは SOA 5 製品ラインには含まれていません。このセクションは更新され、より明確で適切なものになりました。

opensso ESB クイックスタートの opensso-1.0.ear がデプロイされませんでした。これはいくつかの理由で発生しました。まず、application.xml ファイルに、デプロイヤが解析できないバイトオーダーマーカー (BOM) が含まれていたためです。次に、jboss-aop.xml に不適切な名前空間定義が含まれていたためです。これらのエラーは設定ファイルから削除されました。さらに、jsr173_api.jar が WAR ファイルに含まれなくなり、クイックスタートがエラーなしでデプロイされるようになりました。

JBoss SOA Platform はヘッドレスモードが有効な状態で出荷されます。ただし、一部のクイックスタートでは、実行するためにこのモードを無効にする必要があります。これらのクイックスタートを実行するためにヘッドレスモードを無効にする手順については、SOA Getting Started Guide の Configuration セクションを参照してください。

ヘッドレスモードを無効にした本番環境で JBoss SOA Platform を実行することは推奨されません。

JBDS を使用して ModeShape に公開する場合、ユーザーが workspacepath を指定できるオプションが追加されました。このパスは、何をシーケンスするかを決定するときにサーバーによって使用されます。

JCA レイヤーがメッセージングインフローデプロイメントを閉じようとしたときに、JBoss Messaging コードの競合がトリガーされました。これにより、トランザクション境界でのコミット中に IllegalStateException タイプの例外が発生しました。この問題を修正するために、いくつかの JBoss Messaging パッチがバックポートされました。

SOAPProxyWsdlLoader は、HTTP クライアント設定の抽出中に TARGET_HOST_URL を初期化しました。これにより、後続の URL で指定された値に関係なく、後続のすべての WSDL クエリーでホスト/ポート情報が保持されていました。SOAPProxyWsdlLoader ファイルのコードが変更され、この問題が修正されました。その結果、後続の URL の値が認識されるようになりました。

ユーザーがアクティビティーを onAlarm スコープに追加したときに、null ポインター例外が発生しました。これは、ReconciliationHelper.java のバグが原因でした。コードが修正された結果、ユーザーは例外に遭遇することなく、そのスコープにアクティビティーを追加できるようになりました。

見つからない WSDL インポートは、バリデーターによって警告としてマークされました。プロセスファイルが存在しない WSLD へのインポートを宣言している場合、プロセスはデプロイされないため、これは正確ではありません。バリデーターは、欠落している WSDL インポートをより正確にエラーとしてマークするようになりました。

ユーザーが新しいデプロイメント記述子を作成して変更し、プロジェクトからファイルを削除した場合、ODE デプロイメント記述子エディターが開いたままになりました。その後、新しいデプロイメント記述子が作成された場合でも、エディターは更新されず、その内容が表示されませんでした。ProcessPage.java ファイルが変更され、デプロイメント記述子が削除されるとエディターが閉じるようになりました。

Administration Console がデフォルトのデプロイメントで実行された場合、stdout にエラーが表示されました。メッセージには、jndi:/localhost/admin-console/plugins/rhq-platform-plugin.jar のプラグイン Platyform をロードできなかったため、デプロイされませんと記載されていました。 これは、JAR ファイルに署名情報が含まれていなかったために発生しました。JAR ファイルが適切に変更され、エラーがログに表示されなくなりました。

管理コンソールで ESB サービスエンティティーを表示すると、サービスデプロイメント内のすべての ESB サービスに対して同じ説明が表示されました。正しい説明が表示されるように、説明を収集したコードが修正されました。

Camel HTTP コンポーネントのポーリング頻度を設定する方法がありませんでした。デフォルトのポーリング頻度が高すぎて、大量のメッセージが生成されました。スケジューリングのサポートが Camel Gateway に追加されました。

MessageSucker は、クラスターの異なるメンバー間でメッセージを移行します。リモートキューから消費し、そこからローカルクラスターメンバーのキュー宛てのメッセージを受信します。停止した場合、失敗したメッセージは再配信されず、データベースに残ります。JBoss Messaging は、ストールがメッセージの再配信をトリガーするように変更されました。

例外処理が改善されました。rollback() メソッドは、トランザクションのロールバック中に出力された例外をキャッチして返し、ログに記録するようになりました。以前は、commit() メソッドが DbPersistenceService.endTransaction() で例外を出力した場合、rollback () が呼び出され、次に rollback() も例外を出力した場合、クライアントアプリケーションはそれを受け取りましたが、これは最適な動作ではありませんでした。

CXF がマシンにインストールされている場合、Web サービスのクイックスタートのサブセットがコンパイルに失敗しました。これは、soap.esb ファイル内に jaxws-rt/tools JAR が含まれていることが原因でした。CXF 統合をサポートするために、不足しているファイルが追加されました。その結果、クイックスタートが正しくコンパイルされるようになりました。

jUDDI スキーマは、juddiv3.war の uddi_v3replication.xsl ファイル内の WSDL に対して無効なタイプを指定しました。WSDL タイプが修正されました。

DB2 スキーマツールは、db2jcc.jar の lib ディレクトリーをチェックしました。ただし、この場所にある jar の正しい名前は db2jcc4.jar です。チェックが更新されました。

サーバーの起動時に、esbwarfiles ディレクトリーを作成しようとすると、いくつかのディレクトリーを作成できませんでしたというエラーがログに記録されました。ディレクトリーがすでに存在していたため、ログに記録されたエラーは不正確でした。すでに作成された esbwarfiles ディレクトリーを処理するためのチェックが追加されたため、このエラーはディレクトリーが存在せず、作成できない場合にのみログに記録されます。

jUDDI クライアントは、JAXWSTransport でサービスを取得できませんでした。どんな試行でも、タイプ TransportException の例外が発生しました。これは、WSDL で指定されたサービス名が JAXWSTransport のものと一致しなかったために発生しました。WSDL は、JAXWSTransport と一致するように更新されました。

HttpClientFactory のトラストストア設定が正しく機能しませんでした。2 つの問題がありました。まず、定義されたプロトコルは使用されませんでした。つまり、ソケットファクトリーは常にデフォルトの Protocol インスタンスに関連付けられたファクトリーを使用していました。第 2 に、プロトコルソケットファクトリービルダーは、暗号化されたパスワードをファイルから取得できませんでした。これらの問題は両方とも解決され、Truststore 設定は HttpClientfactory で正しく機能します。

SOAPProxy の認証情報が保存されている場合、clientCredentialsRequired プロパティーが false に設定されていても、認証情報を持たないクライアントはサービスを呼び出すことができませんでした。このプロパティーが false の場合、認証情報が保存されていても認証は必要ありません。

EJB から JBoss Rules ESB サービス (jbrules.esb) を使用すると、最初の EJB の後にデプロイされた EJB では機能しません。これは、コンテキストクラ出力ダーの代わりに jbrules.esb クラ出力ダーを使用してクラスがロードされたためです。クラスはデプロイメント間でキャッシュされるため、後続のデプロイメントによる呼び出しは間違ったクラ出力ダーを使用することになります。これは、すべてのデプロイメントで最初にコンテキストクラスローダーの使用が試行されるようにすることで解決されました。

jbpm.cfg.xml に mail from ヘッダーが設定されている場合、jbpm.mail.from.address プロパティーの値がヘッダーで使用されませんでした。これは修正され、jbpm.cfg.xml で期待どおりにヘッダーを設定できるようになりました。

jBPM 4 のディスパッチャスレッドがこのリリースにバックポートされました。これにより、MySQL 5.0 に固有のロックの問題によって引き起こされた、複数の JobExecutor スレッドで発生した競合状態が修正されます。これらのロックの問題は、以降の MySQL バージョンには影響しません。この修正の結果、MySQL を使用している場合、ユーザーはこのシナリオで競合状態に遭遇しなくなりました。

このリリースでは、run.conf (および run.conf.bat) のデフォルトの JVM メモリー設定が更新されました。PermSize は設定されなくなり、MaxPermSize は 256 メガバイトに設定されます。これにより、さまざまなプラットフォームでより一貫したサーバー動作が提供されます。

JBossTS TransactionReaper にはバグが含まれており、実行間で一時停止するのではなく、動的モードで実行しているときに継続的に実行されていました。これにより、パフォーマンスが低下しました。この問題を修正するために、JBossTS が更新されました。その結果、Reaper は実行間で一時停止するようになり、パフォーマンスが向上しました。

http://localhost:8080/に表示される最上位の SOA Platform 5.1 ページが拡張され、ESB プロジェクトだけでなく、Teiid、Drools、および jBPM の URL も表示されるようになりました。その結果、ユーザーはこれらのプロジェクトサイトにすばやくアクセスできるようになりました。

Timer.Execute 内のプロセスインスタンスの変更を記録したプロセスログが、データベースに保存されていませんでした。この問題を修正するために、ExecuteTimerCommand.java のコードが変更されました。その結果、JBPM_LOG テーブルには、変数の変更とタイマーからの遷移のエントリーが表示されるようになりました。

SOA Platform の InVM 呼び出しは BusHolder に依存していましたが、これは JBossWS CXF 統合の新しいバージョンまで追加されませんでした。これを修正するには、JBossWS 設定を拡張して InVM 呼び出しをサポートする必要がありました。これは、ESB コードが、BusHolder を使用して ServletControllerExt を作成するか、拡張機能のバッグに格納されているインスタンスを参照するかを選択できることを意味します。

CXF 統合では、XML カタログを指定する必要がありました。そうしないと、スキーマをリモートで解決しようとするためです。この問題を解決するために、juddi Web サービスの jax-ws カタログが追加されました。

シャットダウン中に JMS メッセージが失われ、アクションが途中で終了する可能性がありました。これは、doStop メソッドが呼び出されると、状態が STOPPING に設定され、スレッドが何かを処理しているかどうかに関係なく、executor スレッド (MessageAwareListener.java) がすぐに終了したためです。この問題を修正するために、MessageAwareListener コードが変更されました。その結果、ソフトウェアのシャットダウン時にメッセージが失われることはありません。

Web サービススタックが CXF に切り替えられたときに、Web サービス関連のクイックスタートをデプロイできませんでした。これは、'assert-ws-available' ターゲットが {org.jboss.esb.server.home}/client/ ディレクトリーの代わりに、{org.jboss.esb.server.home}/common/lib/ の cxf-rt-core.jar を検索するためです。正しい場所は前者です。この問題を解決するために、チェックが削除されました。その結果、Web サービスのクイックスタートがデプロイされるようになりました。

Schema Tool を使用して org.jboss.internal.soa.esb.dependencies.DatabaseInitializer を deploy/jbossesb-registry.sar/juddi-ds.xml から deploy/jbossesb-registry.sar/META-INF/juddi-service.xml に移動すると、ユーザーが BPEL エンジンを配置するときにエラーが発生することがありました。この問題を解決するために、新しい build.xml ファイルが提供されました。このファイルでは、個別の /deploy/jbossesb-registry.sar/META-INF/juddi-service.xml ファイルは作成されず、新しいプロトタイプ juddi-service.xml が /deploy/jbossesb-registry.sar/juddi-ds.xml に併合されています。その結果、ユーザーは Schema Tool の実行後に BPEL エンジンをデプロイできるようになりました。

フォームベース認証の SOA オーバーレイが WS-CXF コンソールに正しく適用されませんでした。これにより、コンソールは基本認証にフォールバックしました。コードの修正が適用されました。つまり、フォームベースの認証がそのコンソールで正しく機能するようになりました。

レガシー JBoss メッセージキューイングに関連するキュー定義ファイルは、クイックスタートから削除されました。これは、潜在的なユーザーの混乱を避けるために行われました。

メッセージコンポーザのデフォルトの NullPayloadHandling が NONE に変更されました。以前は、HttpMessageComposer と JBossRemotingMessageComposer.it の両方で LOG に設定されていました。

ソースパッケージを Eclipse にインポートし、ESB サーバーランタイムを追加すると、次のエラーが表示されます。

説明リソースパスロケーションタイプ

タイプ SecurityContext のメソッド setOutgoingRunAs (RunAs) は、引数 (RunAsIdentity) には適用されません。JBossASContextPropagator.java /JBossESB/rosetta/src/org/jboss/internal/soa/esb/services/security line 262 Java Problem

この問題を解決するために、.class-path が更新され、AS4 バージョンの機能が拡張された AS5 JAR を参照するようになりました。その結果、エラーは発生しなくなります。

MessageCounter MBean が、処理されたバイト数を正しく報告していませんでした。これは SOA のバグによるもので、現在は修正されています。その結果、MessageCounter MBean は、正しく処理されたバイト数を報告するようになりました。

SOAPProxy サービスのプロキシー URL に到達できない場合、サーバーがハングしていました。ルーティング Java クラスの一連のコード修正により、この問題が修正され、この状況でサーバーがハングすることはなくなりました。

アグリゲーターへの着信メッセージに存在する ReplyTo EPR が、集約されたメッセージに伝搬されていませんでした。その結果、アグリゲーターの後にパイプラインアクションを使用して EPR を明示的に設定する必要がありました。ここで、アグリゲーターへの着信メッセージのそれぞれに同じ EPR が存在する場合、その EPR は集約されたメッセージに伝搬されます。

設定が特定の方法で設定されている場合、カスタム再試行ハンドラーが取得されませんでした。これは、setConfiguration (ConfigTree):void メソッドが HttpMethod の HttpMethodParams に設定されていないという POSTHttpMethodFactory と GETHttpMethodFactory の両方のバグが原因でした。パラメーターを正しく抽出し、ハンドラーをインスタンス化するタスクが AbstractHttpMethodFactory に追加されました。再試行ハンドラーは、アクションで org.jboss.soa.esb.actions.routing.http.routingHandler パラメーターを指定することによって設定されることに注意してください。このパラメーターの値は、HttpMethodRetryHandler を実装し、パブリックで引数のないコンストラクターを持つクラスの名前である必要があります。

状況によっては、soapui SoapClient が、soap 応答内の要素をコレクションとして誤って識別し、名前に 0 などのインデックスを追加することがありました。これは修正され、これは行われなくなりました。

SOAPClient は常に null オブジェクトを空の要素にマップしていました。これは変更されているため、必要に応じて xsi:nil 属性を使用するオプションもあります。

ビジネスプロセスで fork 操作と join 操作を示すために使用される bpm_orchestration2 クイックスタートでは、分岐されたアクション間で競合が発生する可能性がありました。これは、フォークされたアクションがすべて同じプロセス変数を更新するように設定されていたためです。このクイックスタートは、フォークが異なる変数を使用するように更新されました。これにより、データのマージを担当する結合後のアクションとの競合が防止されます

MessageMulticaster は集約識別子を作成し、この値をメッセージプロパティーに格納しました。これは、InVM トランスポートと組み合わせて使用すると問題を引き起こしました。これは、複数のサービスに送信されると、すべてのサービスが同じプロパティーを参照し、タイミングによっては、同じ集約識別子を参照する可能性があるためです。この問題を解決するために、参照が作成されたときに、このセクションは共有ではなく常に複製されるため、集計値はメッセージコンテキストに格納されるようになりました。

SOA プラットフォームには、JackRabbit および JCR 1.0 API が同梱されています。これらはこのプラットフォームではサポートされていないため、削除されました。

WISE は、クラスが実際にクラスパスに存在する前に、Java クラスを設定するために Smooks 設定をロードしていました。これにより、いくつかのチェックを実行するためにクラスインスタンスをロードできるようにする必要がある名前空間の設定に問題が発生しました。クラスがまだ存在していないため、例外が出力されます。

この問題を解決するために、WISE SmooksMapper クラスに変更が加えられ、Smooks インスタンスの作成がコンストラクターから applyMapping メソッドに移動されました。これが実行されるまでにクラスはすでに生成されているため、例外は発生しなくなります。

最上位 Web アプリケーション (http://localhost:8080/) のカスタマーポータルリンクは、Red Hat Customer Portal に名前が変更されました。

例外処理動作に関する ESB プログラマーズガイドのドキュメントが更新され、呼び出されている Web サービスが SOAP エラーを生成したときに SOAPClient が ActionProcessingException を出力することが反映されました。

SoapUIClientService が古い DOM Document ルート要素への参照をすでに保持していたため、#document フラグメントを対象とした SoapUIClientService 変換が失われていました。この問題を修正するために、Smooks を呼び出す SoapUIClientService.buildSOAPMessage() メソッドに変更が加えられました。その結果、変換が失われることはなくなりました。

オブジェクトマッパーの呼び出しが競合するため、オブジェクトパスが実際のオブジェクトに 2 回変換されていました。オブジェクトパス上のオブジェクトが文字列でない場合、例外が出力されました。それ以外の場合、ルーティングは機能しません。重複が発生しないように一連のコード変更が適用され、これによって引き起こされた問題が解消されました。

POSTHttpMethodFactory と GETHttpMethodFactory の両方にバグがあり、setConfiguration(ConfigTree):void メソッドの http-client-properties が HttpMethod の HttpMethodParams に設定されていませんでした。これは、カスタムの再試行ハンドラーが無視されたことを意味します。このバグは修正され、http.method.で始まるすべてのプロパティーが削除されるようになりました。HttpMethodParams に設定されます。その結果、カスタム再試行ハンドラーが正しく検出されるようになりました。

メッセージの from 属性は、mail.from プロパティーで自動入力されていませんでした。代わりに、message.setFrom() メソッドを明示的に呼び出す必要がありました。MailTest ケースに testFrom メソッドが追加されました。from 属性が正しく設定されていることを確認します。

HTTP ヘッダーの検証プロセスは、空でないことを厳密に確認していました。 ただし、有効に空である場合もあります。これを考慮して、代わりに not null をチェックするように条件が緩和されました。

/http_gateway/readme.txt ファイルが誤って http-gateway ではなく http-listener を参照していたため、ユーザーが混乱していました。修正されました。

このリリースでは、JBossESB 名前空間の XSD URL が変更されました。JBossESB プロジェクトのクイックスタートの jboss-esb.xml ファイルが更新され、現在のネームスペース定義を参照するようになりました。JBoss Developer Studio を使用する場合、またはオートコンプリートが機能しない場合は、正しい名前空間が必要です。

正しい XSD URL は次のとおりです: http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.1.0.xsd

SOAPClient の OGNL ユーティリティーは、SOAP 応答からコレクションを正しくマッピングしていませんでした。これは修正され、正しく動作するようになりました。

ESB は、メッセージの replyTo に依存して、RequestResponse サービスの応答を送信する必要がある場所を認識します。ただし、Aggregator アクションは、シリーズの集約メッセージを作成したときに、replyTo を保持しようとしませんでした。この問題を解決するために、集約されたメッセージに添付されたすべてのメッセージが同じ EPR を持つ場合にのみ、集約されたメッセージにエンドポイント参照をマップするようになりました。

ほとんどの場合、集約されたメッセージの replyTo は同じであると思います。そのため、結果の集約されたメッセージに追加することは良い考えのように思えます。それ以外の場合は、アセンブラーアクションで手動で処理する必要があります。

ユーザーは、宛先タイプが TOPIC の jms-message-filter をトピックの永続サブスクライバーにすることができませんでした。これは、この設定オプションを許可するように変更された jms-listener を介して実際に設定されます。その結果、ユーザーはこれらの永続的なトピックサブスクライバーを作成できるようになりました。

認証が必要な場合、soapui クライアントは複数のインターフェイスをロードできませんでした。これは、httpclient を使用してロードされた WSDL コンテキストが含まれていたのは最後のインターフェイスだけであり、認証情報が含まれていたのはこの httpclient であったためです。そうすることで、UrlWsdlLoader を使用して以前のインターフェイスを強制的にリロードしていました。UrlWsdlLoader は、独自の httpclient をインスタンス化するため、認証について認識していませんでした。この問題を修正するために、JBoss AOP アスペクトが作成されました。これは、EsbWsdlLoader が常に返されるように、soapUI の WsdlContext$Loader.getWsdlLoader() メソッドへの呼び出しをインターセプトします。その結果、認証が必要な場合でも、soapui クライアントは複数のインターフェイスをロードできるようになりました。

ESB Programmer's Guide では、すべてのゲートウェイが ServiceInvoker を使用しているわけではないと誤って断言していました。すべてのゲートウェイが ServiceInvoker を使用するようになり、これを反映するようにドキュメントが更新されました。

以前は JMX コンソール経由で使用できた MBean 属性 StateString は存在しなくなりました。これは、SOA プラットフォームが Application Server 5 で実行されているためです。その結果、ユーザーは JMX コンソールを介して ESB パッケージのデプロイメント状態 (開始または停止など) を見つけることができませんでした。この機能は Application Server 5 に移植され、再び利用できるようになりました。

SOAPProxy、SOAPClient、および HttpRouter はすべて、Apache HTTP クライアントを使用して HTTP 呼び出しを実装します。これらのアクションの URL は静的であるため、常に同じホストを指します。以前は、これらの各クライアントの最大合計接続数とホスト HTTP あたりの最大接続数の値を個別に設定する必要がありました。ユーザーは、代わりに単一のパラメーターを介して設定できるようになりました。

jBPM のパフォーマンスを改善するために、ActionProcessingPipeline にキャッシングの形式が追加されました。これは、キャッシングレジストリーインターセプタをアクティブ化し、その有効期間が指定されていない場合、デフォルトのレジストリーキャッシュと同じになるようにすることで達成されました。

SyncServiceInvoker を使用してプロキシーサービスを呼び出すと、javax.jms.IllegalStateException が出力されました。これは、プールに返された XA セッションの追跡が不十分で、競合が発生したことが原因でした。この問題を修正するために、ソフトウェアがセッションユーザー、プロデューサー、コンシューマー、および XA セッションのキャッシュを追跡するように、いくつかのコードが変更されました。その結果、この例外は発生しなくなりました。

JBoss WebService/CXF スタックのサポートが追加されました。Apache CXF は、オープンソースの Web サービスフレームワークです。

jUDDI は、GetSubscriptionResult を介して受信したサービスの一部を登録できませんでした。これは、jUDDI をバージョン 3.0.2 にアップグレードすることで修正されました。

署名されたマニフェストファイルが、カスタマーサービスポータルで利用可能な soa-5.1.0.zip アーカイブに追加されました。これを使用して、ファイルごとに SOA-P5 jar の整合性とソースを確認する必要があります。

ユーザーが description 属性が "" に設定された JBoss ESB サービスをデプロイした場合、Oracle10g データベースが使用されている場合、サービスが jUDDI に登録されると例外が発生します。これは、jUDDI の問題が原因でした。この問題を回避するために、ESB が変更されました。これで、サービスの説明が存在することが保証されます。

PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml 設定ファイルには、JAX-WS トランスポートを使用してローカル UDDI レジストリーに接続する例が含まれていました。この設定例を使用すると、起動時にサーバーがフリーズしました。JAX-WS トランスポートは、リモート UDDI レジストリーへの接続にのみ使用できます。必要な Web サービスエンドポイントは、サーバーの起動が完了するまで使用できないためです。

JAX-WS 設定例が更新され、${jboss.esb.bind.address}:8080 の値が REMOTE_HOST:REMOTE_PORT に置き換えられました。この設定を使用するには、設定を編集して、リモート UDDI レジストリーの正しいホスト名とポートを含める必要があります。

jUDDI コンソールで使用されるセキュリティーサービスの実装は、クライアント設定ファイルで定義されたリモートサーバーから authToken を取得できませんでした。これは、jUDDI のバグが原因で、そのコンポーネントを新しいバージョンにアップグレードすることで解決されました。(設定されたノードを表示するには、新しいサブスクリプションボタンをクリックする必要があることに注意してください。)

ユーザーが ant を介して ESB をデプロイした場合、特定の状況で JON ツリーモデルで同時実行の問題が発生する可能性がありました。これは、ツリーモデルが別のスレッドによって更新されていたために発生しました。この問題を修正するためにコードが変更されました。その結果、ユーザーはこれらの同時実行の問題に遭遇しなくなります。

HDScanner の scanEnabled 属性を XML 経由で true に設定すると、セッターロジックがクラスの create メソッドがすでに呼び出されているという事実に依存していたため、null ポインター例外が発生していました。この問題を解決するために、HDScanner のテストケースが追加されました。その結果、ユーザーはこの null ポインター例外に遭遇しなくなりました。

ユーザーが不足しているデプロイメントを削除すると、例外が発生しました。これは、ユーザーがクイックスタートを起動し、SOA プラットフォームを JON にインポートし、クイックスタートを (ant アンデプロイを介して) 削除し、JON コンソールを介して再度削除しようとした場合に発生しました。この問題を解決するために、NoSuchDeployment 例外をキャッチするようにソフトウェアが変更されました。

JON コンソールで配備タイプが見つかりませんでした。値フィールドのエントリーには、何も見つかりませんでしたと表示されます。 これは修正され、デプロイメントタイプが正しく表示されるようになりました。

クイックスタートは javax.naming.NamingException: Failed to retrieve Naming interface for provider で失敗します。これは、Load Generator の問題が原因でした。この問題を修正するために、Groovy クラスパスが exec クラスパスに変更されました。その結果、この問題でクイックスタートが失敗することはなくなりました。

JBoss Enterprise Application Platform ネイティブコンポーネントがインストールされていない場合、起動時に常に警告メッセージが表示されます。これらのメッセージは現在表示されません。

BusinessService オブジェクトを定義していない BusinessEntity が jUDDI に保存された場合、ユーザーが jUDDI コンソールでその BusinessEntity のプロパティーを表示しようとするとすぐに NullPointerException が出力されました。これは、コンソールのバグが原因でした。コードが変更され、その結果、ユーザーはこれらの状況で NullPointerException に遭遇しなくなりました。

-c 設定スイッチを指定せずにサーバーを始動すると、default という名前のプロファイルが実行されます。

これは正しい操作です。残念ながら、JON は誤って、プロダクションプロファイルが

代わりに実行されることを想定します。JON は、バインディングアドレスが指定されていない場合、0.0.0.0 であると誤って想定します。

JON がデフォルトのプロファイルを認識し、正しいアドレス 127.0.0.1 にバインドするようにするには、

常に -c および -b パラメーターを使用してください。そうすることで、JON はプラットフォームを認識します。

スキーマの import/include のサポートが SchemaValidationAction に追加されました

ユーザーが ESB 統計レベル内からデプロイメント操作を開始、停止、作成、または破棄しようとすると、例外 (java.lang.Exception) が発生していました。

この問題を軽減するために、これらの操作はこのレベルでは使用できなくなりました。

JBoss Cache が jBPM のクラスター設定で使用されるようになりました。

ESB プログラマーガイドに、カスタムゲートウェイの作成に関する新しいセクション、セクション 7.2.5 が追加されました。カスタムゲートウェイの作成。

unwrap/wrap スイッチのサポートが HttpRouter に追加されました。これにより、API の一貫性が確保されます。