5.3.1 リリースノート

サーバーが 30 分以上実行されている場合、VFS キャッシングと非コア Camel コンポーネントのデプロイメントに問題があります。キャッシュの有効期限が切れた後 (30 分)、コア以外の Camel コンポーネントをデプロイすると、エラーが出力されます。これを回避するには、サーバーを起動する前、またはこの 30 分の制限の前にアプリケーションをデプロイするか、boss.vfs.cache.TimedPolicyCaching.lifetime プロパティーをより高い値に上げます。(サーバーを起動する前、またはキャッシュの有効期限が切れる前に、コア以外の Camel コンポーネントをデプロイしても問題はありません。)

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

CamelGateway のスケジューリング機能を示すために camel_esbschedule クイックスタートが追加されました。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

jBPM5 のインストール手順 (README.TXT) には、jBPM5 のインストールを検証する方法が説明されていませんでした。ユーザーは、jBPM5 が正しくインストールされているかどうかわかりません。インストールを検証する方法として、business-central URL がインストール手順に記載されるようになりました。jBPM5 統合および BRMS-P デプロイ可能ファイルをインストールしたユーザーを支援するために、リンクも jBPM5 コンソールに追加されました。ユーザーはインストールを検証できるようになります。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

以前は、ソース固有のクエリーをランタイムエンジンに送信できる簡単なメカニズムはありませんでした。ユーザーは、不必要に複雑なユーザー定義関数に頼る必要がありました。ソース固有のクエリー (またはネイティブクエリー) を Teiid Designer で設定できるようになりました。次に、ランタイムエンジンは、FROM 句内のそれぞれのテーブル名の代わりに、このネイティブクエリーをインラインビューとして使用します。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

MS SQL Server 2005 で jBPM を使用すると問題が発生しました。これらを一緒に使用すると、jBPM でデッドロックが発生します。これは、mssql-ds.xml ファイルのリビジョンによって解決されました。その結果、これらのデッドロックは発生しなくなりました。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

JBoss ESB を使用すると、特定のインスタンスで起動時に NullPointerException が発生します。これは、ユーザーが jbossesb-properties.xml ファイルで GenericPipelineInterceptors のコメントを外したときに発生しました。これはその後解決されました。そのため、この例外は発生しなくなりました。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

インデックスが見つからないため、ユーザーは JBPM でデッドロックを経験しています。以下に従って、新しいインデックスを追加することで、デッドロックが回避されるようになりました。# the foreign key constraint (already present in jBPM ddl script): alter table JBPM_TASKINSTANCE add constraint FK_TSKINS_PRCINS foreign key (PROCINST_) references JBPM_PROCESSINSTANCE; # new index to add to the schema: create index IDX_TASKINST_PRCINS on JBPM_TASKINSTANCE (PROCINST_);

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

jBPM5 統合には Javadoc が含まれていませんでした。開発者は、開発目的で参照する Javadoc を持っていませんでした。Javadoc が含まれるようになったため、開発者はそれらを参照できるようになりました。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

HTTP ゲートウェイで SOAPProcessor を使用しているときにエンドポイント URL を指定すると、問題が発生しました。rewrite-endpoint-url を false に設定すると、URL は永続的に上書きされ、元の JBoss ESB URL に置き換えられます。これは、パブリッシャーがゲートウェイで初期化していないことが原因でした。これは、現在のリリースで解決されています。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

jUDDI 3.1.4 へのアップグレードでは、デジタル署名をサポートするためにテーブルが追加されます。ディストリビューションで提供されるファイル: add-juddi-tables.*.txt には、SOA-P 5.3.0 から SOA-P 5.3.1 にアップグレードするときに追加のテーブルを作成する SQL コマンドが含まれています。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

SyncServiceInvoker は Call の ReplyTo ヘッダーと FaultTo ヘッダーを null に設定し、例外が出力されない限り null のままになります。例外が出力された場合、元の値に戻されます。これで、ReplyTo ヘッダーと FaultTo ヘッダーも、プロセスメソッドが成功したときに元の値を保持するようになりました。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

タスクに 10 個を超える変数があり、jBPM コンソールでタスク変数を表示した場合、ビューは結果を 10 行に制限しませんでした。Next リンクが選択されると、IllegalArgumentException が出力されました。結果が期待どおりに表示されるようになり、IllegalArgumentException は発生しなくなりました。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

ODBCServerRemoteImpl の modifySQL メソッドは、クエリーの '::' を正しく処理せず、予期しない結果になりました。ユーザーは、目的の動作を実現するために、それぞれのコロンをエスケープする必要がありました。'::' の発生を正しく識別するように modifySQL が変更されたため、期待される動作を実現するためにクエリーでコロンをエスケープする必要がなくなりました。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

特定のディレクトリーで jUDDI を使用すると、ユーザーが問題を経験していました。名前にスペースを含むディレクトリーが正しく読み込まれませんでした。これは、現在のリリース用にパッチが適用されています。名前が空白になっているディレクトリーが期待どおりに表示されるようになりました。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

以前のリリースでは、SOAPProcessor アクションで JBoss ESB パイプラインを使用して Web サービスを呼び出すと、誤ったエラーが表示されました。ラップされた Web サービスが SOAP エラーと HTTP 応答コード 500 を返した場合、HTTP プロバイダーゲートウェイは、予期された 500 応答ではなく、応答コード 200 を返しました。これは、現在のリリースで修正されています。ユーザーには正しいコード 500 が表示されます。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

soapui-1.7.1.jar が jboss-as/server/configuration/deployers/esb.deployer/lib/ディレクトリーに含まれていないため、ClassNotFoundException が発生します。この問題を回避するには、JAR ファイルをこのディレクトリーに手動で追加します。手動の手順: soapui-1.7.1.jar を jboss-as/server/configuration/deploy/soapui-client.sar/lib から jboss-as/server/configuration/deployers/esb.deployer/lib ディレクトリーにコピーします。注: この変更を加えたプラットフォームは、問題 BZ-881924 を検証する目的でのみテストされています。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

Camel は JBoss ESB のバージョン 2.10.2 にアップグレードされました。この更新では、古いバージョンの Camel に関連するいくつかのバグが修正されています。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

FrameUtil.isProcedure は、projectNode != null をチェックしません。これは、テーブル関数またはアクセスノードのない他のソースを使用する proc リレーショナルクエリーが NullPointerExcpetion で失敗することを意味します。FrameUtil.isProcedure は、続行する前に projectNode != null をチェックするようになり、そのような例外は発生しません。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

マルチソースモデルの更新時に問題が発生しています。マルチソースモデルを使用し、更新を実行し、デフォルトの PROP_TXN_AUTO_WRAP の DETECT を使用している場合は、次の方法を使用してトランザクションモードを明示的に設定してみてください。* local (START TRANSACTION または setAutoCommit (false) * global/XA * URL で autoCommitTxn=ON を設定します

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

jBPM から ESB へのマッピング時に jBPM 変数の 1 つが欠落している場合、例外が出力されました。jBPM 変数が欠落している (null 値がある) 場合、ユーザーは例外ではなくログ警告を受け取ります。

この問題は JBoss Enterprise SOA Platform 5.3.1 で解決されました。

SOAPClient が使用されているときに HTTP 500 エラーが発生すると、SOA-P は、ActionProcessingPipeline によって処理されない HTTP 500 スタックトレースを含む例外を出力し、情報を提供しないメッセージを生成します。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

プロセスの開始時に AbstractBpm5Action がハンドラーを登録する方法に問題があります。ユーザーがコンソール経由でタスクを閉じると、競合状態により例外が発生します。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

SOAPClient が使用されているときに HTTP 500 エラーが発生すると、SOA-P は、ActionProcessingPipeline によって処理されない HTTP 500 スタックトレースを含む例外を出力し、情報を提供しないメッセージを生成します。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

jUDDI バージョン 3.1.4 では、jUDDI との統合をアップグレードすることが望まれます。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

FileUtil.renameTo(..) は、ファイルの名前変更に失敗した場合でも true を返します。その結果、別のプロセスによってロックされているファイルが SOA プラットフォームによって取得され、名前変更が失敗すると、次の試行 (ロックが解除されたとき) でファイルが正常に処理されても、エラーがログに記録されます。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

ユーザーは、以前は機能していたルールが例外になることに気付きました。修正するには、宣言された定数を介してではなく、新しいクラスインスタンスを直接使用するようにソースコードを更新することをお勧めします。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

当社の製品では、ESB から jBPM 変数 (esbToBpmVars) へのマッピングでデフォルト値を使用できなくなりました。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

Ant タスクを使用して jBPM3 プロセスがデプロイされ、サーバーに到達できない場合、エラーメッセージの代わりに値 0 が返されます。サーバーに接続してこの値を取得しようとしている場合は、再デプロイする前にサーバーが使用可能であることを確認してください。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

特定の状況で、HTTP ゲートウェイが無効な空の WSDL ドキュメントを返すことがありました。正しい名前空間になかったため、無効でした。さらに、http-gateway は、SOAP 以外でも使用される可能性があるため、デフォルトで WSDL ドキュメントを返すべきではありません。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

新しい jBPM3 プロジェクトを作成するとき、JBDS は、他のタイプのプロジェクトを作成するときの動作と一致するように、jBPM jPDL パースペクティブに移動するオプションを提供する必要があります。現在、新しい jBPM3 プロジェクトを作成すると、プロジェクトが作成されるだけです。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

JBoss Enterprise SOA Platform が名前にスペースを含むディレクトリーにインストールされている場合、NULL ポインター例外が出力されるため、ESB アーカイブをデプロイできません。この問題を回避するには、-Dorg.jboss.net.protocol.file.useURI=false を起動スクリプトに追加します。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

jmx-console から呼び出された JNDI View MBean の出力が正しくレンダリングされません。これは、HTML ソースコードで HTMNL タグが < と > でエンコードされているため、ブラウザーで正しく表示されないためです。

この動作は JBoss Enterprise SOA Platform 5.3.1 でも持続します。

Java 7 がサポートされるようになりました。