3. 既知の問題

Apache CXF インストーラーは、jboss-as/common/lib/ディレクトリーと、すべて、デフォルト、実稼働、標準、および Web の含まれるサーバープロファイルを変更します。追加されたその他のサーバープロファイルは、インストーラーの影響を受けず、共通のサーバー設定と互換性がありません。カスタムサーバープロファイルを作成するには、最初にインストーラーを実行してから、サポートされているプロファイル (all、default、または production) のいずれかのコピーを作成してプロファイルを作成します。

バイナリー JBoss Rules パッケージの下位互換性は、バージョン間で保証されません。クライアントアプリケーションとサーバーアプリケーションの両方が同じバージョンを使用して、それらの間のシリアル化の互換性を確保することが重要です。あるバージョンから別のバージョンにアップグレードする場合、アップグレード先のバージョンの古いバージョンからバイナリーパッケージを再コンパイルする必要があります。

スプレッドシートが Excel 95 以前で作成されている場合、Microsoft Excel スプレッドシートをナレッジベースにインポートすると、例外が出力されます (StringIndexOutOfBoundsException)。これは、これらのファイルの処理に使用される JXL ライブラリーの問題が原因です。これは、Microsoft Excel 97 以降または OpenOffice.org Calc でスプレッドシートを開いて保存することで回避できます。

これは今後のリリースで修正される予定です。

JBoss Enterprise SOA Platform 5.0.0 以降では、ルートフラグメントに適用される単一の XSLT のみが Smooks 設定に含まれている場合、フラグメントフィルターはバイパスされます。この状況では、XSLT が直接適用されます。これは、パフォーマンス上の理由から行われます。

この動作は、enableFilterBypass というパラメーターを追加して false に設定することで無効にすることができます

<param name="enableFilterBypass">false</param>

<param name="enableFilterBypass">false</param>

jUDDI コンソールは、ユーザーが削除できないはずのアカウントを削除しようとするのを防ぎません。このインターフェイスでは、どのユーザーも jUDDI コンソールで root、uddi、および esbpublisher の管理者アカウントを削除できるように見えますが、実際に適切な権限を持っていない限り、アカウントは削除されません。また、root ユーザーが自分自身を削除しようとすると、例外 (UndeclaredThrowableException) が出力されます。恒久的な問題は発生せず、コンソールの表示はサーバーの再起動後に復元されます。

UDDI サブスクリプションが定義されていない場合、jUDDI コンソールのサブスクリプションページは、動作していないように見える 4 つのアイコンを除いて空白になります。少なくとも 1 つのサブスクリプションが定義されるまで、ボタンはアクティブになりません。

JBoss Enterprise SOA Platform 4.3 用の JBoss Developer Studio 3 で作成された JBoss Rules プロジェクトでは、JAR ファイル mvel2-2.0.12.jar および xstream-1.2.2.jar を classpath に追加する必要がありました。JBoss Enterprise SOA Platform 5 ではこれらのファイルが各サーバープロファイルに含まれるようになったため、これは不要になりました。それらは $SOA_ROOT/server/$PROFILE/deployers/esb.deployer/lib/ にあります。

JBoss Enterprise SOA Platform 5.0 では、ESB アーカイブ内の JAR ファイルをアーカイブのルートディレクトリー、/jars ディレクトリー、または /lib ディレクトリーに配置する必要があります。以前のバージョンには、この制限はありませんでした。

このリリースではロギングが変更されました。過去のリリースからカスタマイズしたロギング定義をコピーしないでください。パフォーマンスの問題が発生する可能性があります。

この問題の詳細は、https://jira.jboss.org/jira/browse/SOA-1754 をご覧ください。

ロギング方法の変更については、http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/ の EAP 管理ガイドを参照してください。

5.0 の HttpResponse クラスは、ESB HTTP クラスを統一するために変更が加えられたため、以前のバージョンとの後方互換性がありません。これは、新しいサーブレットベースの HTTP ゲートウェイの一部として行われました。

HttpResponse を使用するアプリケーションとサービスは、JBoss Enterprise SOA Platform 5.0 にデプロイする前に更新する必要があります。必要な変更は、表2「HttpResponse のリファクタリング要件」 にまとめています。

JBoss Enterprise SOA Platform は、そのコンポーネントが使用する新しいデータベースを作成します。コミュニティーバージョンのデータベースはテストされていないため、動作しない可能性があります。既存のデータベースを使用する必要がある場合は、Red Hat JBoss サポートに連絡してアドバイスを受けてください。

Groovy がバージョン 1.0 から 1.5.4 にメジャー 更新されました。言語に多くの変更が加えられたことに注意してください。ほとんどのスクリプトは引き続き機能しますが、いくつかの小さな作業が必要になる場合があります。移行プロセスの一環としてそれらをテストしてください。詳細は、http://groovy.codehaus.org/Documentation を参照してください。

Smooks は addToList オプションに対応しなくなりました。このオプションに依存するすべての設定を更新して、代わりにリストを処理できる新しい <jb:bean> 設定名前空間を使用するようにします。詳細は、Smooks ユーザーガイド の Java バインディングの章を参照してください。

jBPM コンソールがデプロイメントの認証をサポートするようになったため、プロセスのデプロイメントにセキュアでないバージョンの jBPM コンソールは必要なくなりました。Process Deployer は http://localhost:8080/gpd-deployer/ で入手できます。これにより、以前のバージョン http://localhost:8080/app/upload と http://localhost:8080/upload のデプロイヤーが置き換えられます。

独自の jbpm-jpdl.jar を含む Seam アプリケーションは、提供された jBPM-ESB 統合 (EsbNotifier など) を jBPM プロセス内で使用して、同じサーバーでホストされている ESB サービスを呼び出すことができません。これは、Seam アプリケーションの jBPM クラスと jBPM ESB サービス間のクラ出力ダーの問題が原因です。

次の 3 つの回避策があります。

2 番目の回避策を実装する方法の詳細は、http://community.jboss.org/wiki/WorkaroundforSeamESBjBPMClassloadingIssue を参照してください。

JBoss クラスローディングの詳細はhttp://community.jboss.org/wiki/JbossClassLoadingUseCases を参照してください。

JON コンソールを使用して ESB アーカイブを削除しようとすると、関連するキューが削除されません。それらはそこに残り、DOWN として表示されます。さらに、これらのキューを削除しようとすると、java.lang.IllegalStateException 例外が発生します。

プロキシーされたサービス URL の WSDL を取得するように SOAPProxy が設定されている場合、警告がログに記録されます。これは、Web サービスが応答するコンテンツの長さが制限を超えているか、指定されていないためです。

現在、spring_aop クイックスタートは署名付き JAR では機能しません。このクイックスタートで ant deploy を実行しようとすると、org.jboss.deployers.client.spi.IncompleteDeploymentException がスローされます。

問題この問題を回避するには、cglib JAR を署名していないバージョンに置き換えます。

Web サービスプロキシーを使用して一方向の Web サービスを呼び出すと、HTTP コード 500 で実行時例外が誤って出力され、エラーメッセージと共にクライアントに返されます。メッセージが ESB に正常に送信されたため、Code 200 または 202 のみが返されるため、これらの状況では HTTP Code 500 は無効です。

現在、UDP ゲートウェイのデフォルトの ESB handler クラスは XSD スキーマにハードコードされており、変更または削除することはできません。

Web サービスが ESB アーカイブ内に埋め込まれてデプロイされ、WAR に WEB-INF/jboss-web.xml ファイルが含まれていない場合、Web サービスの WSDL は無効になり、404 エラーが返されます。

現在、Scout は BusinessQuery/BusinessLifecycle Manager を介して発生するすべての呼び出しに対して新しい AuthToken を作成します。これにより、jUDDI 認証テーブルが急速に拡大します。

この問題を回避する方法として考えられるのは、特定のタイムスタンプパラメーター内の行を削除することです。たとえば、10 分以上前に作成されたすべての行を削除できます。