3. 解決された問題

EDS プラグインは、セッション数を除くすべてのメトリックに対してゼロしか表示しませんでした。これは、実行時間の長いクエリーの計算方法に問題があったためです。コード修正が適用され、その結果、正しいメトリックが表示されるようになりました。

Windows オペレーティングシステムの 32 ビットバージョンは、サポートされていない設定になっていることに注意してください。ただし、32 ビット Windows を引き続き実行している場合は、既定の設定では、スレッドスタックおよびその他の割り当て用のプロセスのアドレス空間にほとんどメモリーがないことに注意してください (既定では、Windows ではアドレス空間の半分がシステム用に予約されています)。これにより、SOA を実行すると、次のタイプのエラーが発生します。java.lang.OutOfMemoryError: Chunk::new に対して 842040 バイトが要求されました。スワップ領域が不足していますか?これを修正するには、ヒープを減らすか、より小さいスレッドスタックサイズを設定します (-Xss128k など)。プロセス空間の分割を変更することもできます。

ユーザーが Web 管理コンソールから ESB アプリケーションをデプロイしようとすると、リソース Quickstart_helloworld.esb の作成に失敗しました - 原因: java.lang.NullPointerException:null というエラーが発生しました。これは、DeploymentName が null であったために発生しました。自動的に追加されるようになったため、ユーザーはこの問題に遭遇しなくなりました。

process メソッドのバグにより、HTTP 要求ペイロードがコンソールに正しく抽出されませんでした。これは、メソッドの変更によって修正されました。

bpel_management クイックスタートの readme ファイルに、ファイル名に関する誤った情報が含まれていました。これは修正されました。

ユーザーが bpm_orchestration クイックスタートを複数回再デプロイすると、競合状態が発生し、java.lang.NoClassDefFoundError が発生する可能性があります。これに対処するためにコード修正が適用されました。その結果、ユーザーにはこのエラーが表示されなくなります。

EDS には、JCR API を使用して Modeshape に接続してクエリーを実行する方法を示すクイックスタートが装備されています。

ESB には、以前に削除されたにもかかわらず、いくつかの古いファイルへの参照がまだ含まれていました。これらのファイルは jbossesb-listener.xml と jbossesb-gateway.xml でした。参照は削除されました。

2 つのテキストファイルに対して結合操作を実行すると、非常に時間がかかりました。これは、結合計画によって、ふさふさしたツリーが、最上位にネストされたテーブル結合を持つ線形ツリーに変換されたため、各行のネストされたテーブルの 1 つを再評価する必要があったためです。これは、計画がより選択的になるように変更されました。その結果、テキストファイルに対して結合操作を実行する速度が向上しました。

jcr*.jar が SOA から削除されたため、JCR ノードマッピングも jbpm.varmapping.xml から削除されました。これは、ユーザーが java.lang.NoClassDefFoundError メッセージに遭遇するのを防ぐためでした。

BPEL エンジンのインストーラーが強化され、JBoss Enterprise SOA Platform のスタンドアロンサーバーエディションがサポートされるようになりました。

DEBUG に設定された Teiid ロギングで実稼動設定が使用され、set showplan debug がアクティブであるときに、ユーザーが結果セットのキャッシュをロードして照会すると、java.io.NotSerializableException が発生していました。(これは、クエリーがキャッシュによって供給された場合には発生しませんでした。) ユーザーが結果セットキャッシュをクエリーするときにこれらの設定を使用しても、このエラーが発生しないように、コードが変更されました。

ユーザーが ESB サービスリスナーの 1 つとして http-gateway を含む ESB をデプロイし、アーカイブ名の長さが 4 文字未満の場合、java.lang.StringIndexOutOfBoundsException が発生していました。これは、コードが .war ファイル拡張子を取り除こうとしていたためで、この場合は適用できませんでした。コードが変更されたため、ユーザーはこの例外に遭遇しなくなりました。

https://issues.jboss.org/browse/SOA-3214 システムのプロファイリング中に、ユーザーは org.jbpm.job.executor.JobExecutorThread.getWaitPeriod (int) および org.jbpm.job.executor.JobExecutorThread.getNextDueDate () メソッドの実行に 2.58 秒かかっていました。これは、クエリーにインデックスがないことが原因でした。このコードは JBPM の最新バージョンで修正され、その結果、メソッドがより迅速に実行されるようになりました。

Wise が処理できないエラーに遭遇した場合、パイプラインを終了します。例外が一貫した方法で処理されるように、コード修正が適用されました。

メインの LOG4J 設定ファイルである jboss-log4j.xml は、ロガー定義にカテゴリー要素を使用していました。EDS には、特定のロガー定義用の新しいロガー要素が付属しています。したがって、お客様が EDS を SOA-P にインストールした場合、jboss-log4j.xml ファイルに 2 つの異なるロガー定義が含まれます。これらの設定は統合されたため、設定間に競合はなくなりました。

org.teiid.SECURITY ログメッセージが拡張され、クライアントの IP アドレスが含まれるようになりました。この機能は、セキュリティーコンプライアンス要件を満たすために一部のお客様に必要とされていました。

仮想プロシージャをプレビューしてから変更して保存した場合、プレビューでは以前の変換の結果が引き続き表示されます。正しい結果を表示するには、ユーザーは JBoss Developer Studio を閉じてから再度開き、再度開く必要がありました。これを修正するために、コーディングパッチが適用されました。その結果、プレビューが更新され、正しい結果が反映されるようになりました。

以前に ClientTransaction のフォーマットにリカバリーフラグを含めるように変更したことで、古いクライアントの Wire プロトコルが壊れていました。このリグレッションを修正するソフトウェアの変更が適用され、Wire プロトコルが再び機能するようになりました。

EDS クエリープランナーは、group by 句内のエイリアスを正しく解決していませんでした。計画内で自己結合が必要でした。コードの更新によりこの問題が修正され、その結果、エイリアスが正しく解決されるようになりました。

WSDL に soapAction がなく、メッセージに添付ファイルがある場合、SOAPProxy は SAXParseException を出力しました。コード修正によりこの問題が修正され、その結果、ユーザーはこの例外に遭遇しなくなりました。

ロールバックで発生した例外は、DbPersistenceService.endTransaction() でコミット時に元の例外を覆い隠していました。その結果、ユーザーは問題の原因を知ることができませんでした。jBPM へのアップグレードでこの問題が修正されたため、ユーザーはエラーを確認できるようになりました。

DefaultJMSPropertiesSetter は、JMS で始まるプロパティーを除外しませんでした。現在はそうするように変更されています。

入力データにバイトオーダーマーク (BOM) が含まれていると、ContentBasedRouter が失敗しました。新しい ESB BOMFilter アクションがエンタープライズサービスバスに追加されました。これにより、ソフトウェアでバイトオーダーマークを確実に処理できるようになり、ユーザーはこの障害を認識しなくなりました。バイトオーダーマークを除外するには、アクションチェーンに BOMFilter アクションを追加する必要があります。

refreshMatView は、シングルノード環境で teiid-cache-manager-jboss-beans.xml が有効になっているデータを更新しなくなりました。ソフトウェアのアップグレードによりこの問題が解決されたため、クラスターリングが有効になっている場合に refreshMatView が期待どおりに機能するようになりました。

ユーザーは、Java でコーディングしなくても、特定のデータに対してプッシュダウン関数を有効にできるようになりました。

SQL に対して返されるメタデータがエイリアスを使用している場合、getColumnName() メソッド呼び出しではなく、getColumnLabel() 呼び出しでエイリアスが返されます。後方互換性サポートをオンにして逆にするには、useJDBC4ColumnNameAndLabelSemantics=false プロパティーを接続 URL に追加します。

内部マテリアライズドビューが使用された場合、IMV キャッシュのコピーを持っていなかったノードは、ソースにクエリーを実行して別のノードがクラスターをキャッシュしたかどうかを確認する代わりに、ゼロ行を返します。ソフトウェアのアップグレードによりこの問題が修正されたため、ユーザーはキャッシュが正しく調査されていることがわかります。

EDS で内部実体化ビューが使用されている場合、クラスタに再参加したノードがクラスタのキャッシュを無視することがありました。これにより、同期の問題が発生しました。パッチにより、この問題が解決されました。その結果、クラスターに再参加するノードは、キャッシュに問い合わせることができるようになりました。

org.teiid.jdbc.StatementImpl では、バッチ更新がない場合、batchedUpdates メンバーはインスタンス化されないため、clearBatch() はヌルポインター例外を出力します。正しくインスタンス化されるようにコード修正が適用されたため、ユーザーはこの例外に遭遇しなくなりました。

HibernateStringUpdateLog ゲッターは常に null を返しました。HibernateStringUpdateLog クラスのコードが更新され、正しい結果が返されるようになりました。

SOA に含まれる Spring には、競合する 2 つの異なるバージョンが含まれていました。冗長バージョンは削除され、単一の最新バージョンのソフトウェアに置き換えられました。

Modeshape インデックスの構築方法が強化され、パフォーマンスが向上しました。XSD および WSDL シーケンサーも標準設定に追加されました。

ユーザーが 'process' 属性を指定して DeployProcessTask を実行すると、NullPointerException が発生していました。この問題を修正するために、コードの変更が適用されました。したがって、ユーザーはこの NullPointerException に遭遇しなくなります。

テキストテーブルは有効な入力をチェックしていませんでした。値に無効なエントリーがある場合、ファイル全体がメモリーに読み込まれました。文字を 1 つずつ読み取り、予想される最大値に対して検証するための readline ロジックが追加されました。

Freemarker 変換の入力ファイルに名前空間宣言が含まれていると、freemarker.core.NonStringException が発生していました。これらの名前空間が削除されるように修正が適用されたため、ユーザーにはエラーが表示されなくなりました。

SpringSource Spring Framework 2.5.x (2.5.6.SEC02 以前), 2.5.7 (2.5.7.SR01 以前)、3.0.x (3.0.3 以前) では、HTTP リクエストに class.classLoader.URLs[0]=jar: と細工した .jar ファイルの URL を指定すると任意のコードを実行できる可能性があります。したがって、これらのファイルは更新されています。詳細は、http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1622 を参照してください。

BPEL-SB SAML の例は、空のタグリスナーが原因で失敗しました。これらは削除されました。その結果、この例は正しく機能するようになりました。

ユーザーが Salesforce インポーターから作成されたリレーショナルモデルをクエリーしようとしたときに、基準がゼロ行を返した場合、Null ポインター例外が発生しました。コーディングの変更により、この問題が修正されました。その結果、代わりに空の結果セットが提供されるようになりました。

ユーザーは、XML 設定を介して jBPM の非同期トークン機能を設定できるようになりました。

AdminApi を介した VDB のデプロイメントにより、アプリケーションサーバーがサーバーソケットとリッスンスレッドをリークし、開いているファイルハンドルが多すぎるために障害が発生する可能性がありました。この問題を修正するパッチが適用されました。その結果、サーバーソケットとリッスンスレッドがリークされなくなり、ユーザーはこれらのエラーに遭遇しなくなります。

ODBC 経由でアクセスされる仮想データベースを構築したお客様は、MAX_INT の既定値が使用されたときに、エラーログに次の例外が表示されます: FunctionExecutionExceptionこの問題を解決するためにコード修正が適用されました。

Modeshape は、ユーザーが最初にデータをクエリーしたときに応答が遅くなっていました。コーディングの変更が適用され、より迅速に応答するようになりました。

JON コンソールを介して ESB アーカイブ (圧縮またはデプロイメント) をデプロイすると、次のエラーが発生します: java.lang.NoSuchMethodError。プラグインパックの更新によりこのエラーが修正されたため、ユーザーは問題に遭遇することなくアーカイブをデプロイメントできるようになりました。

分離していない条件基準のコーディングが不正確でした。これは現在修正されているため、ユーザーはこれらの条件を追加して、ソフトウェアによって正確に解釈されることがわかります。

スタックオーバーフローエラー java.lang.StackOverflowError が発生します。これは、エントリー削除コードのバグが原因でした。このコードは修正されたため、ユーザーはこの問題を認識しなくなりました。有効期限キューのロジックも同時に更新され、適切に制限されるようになりました。

部分修飾名は可視性ルールの対象となり、セッションレベルのテーブルと競合する可能性がありました。これを修正するために、設計時のメタデータであるかのように変換を解決するようにランタイムメタデータが調整されました。

ユーザーが ESB5 の例をインポートしようとして、SOA ランタイムの名前が間違っていた場合、異なるレベルのエラーが表示され、その後、SOA ランタイムがまったくインストールされていない場合よりも詳細が少なくなります。コードが変更され、正しいエラーレベルと詳細が表示されるようになりました。

setSpecificEPR は、型拡張が存在しない場合に型拡張を初期化しましたが、これは同時障害につながるため、安全に実行できませんでした。EPR への変更は、建設時点でのみ行う必要があります。コードが変更されたため、このようになりました。

多くの SOA-P 5.1 クイックスタートには、.settings および .project ビルドファイルが含まれていました。これらはユーザーには影響しませんでしたが、よりクリーンにするためにリリースから削除されました。

BPEL プロセスが Web サービスを消費すると、パフォーマンスが低下しました。当時、BPEL エンジンは Axis2 で ODE2.0 を使用していました。ODE1.3.3 に対して JBossWS ネイティブを使用するようにアップグレードされ、パフォーマンスの問題はなくなりました。

ユーザーが、CXF スタックが設定された SOA-P 5.1 に BPEL プロセスをデプロイした場合、WSDL が無効になり、java.lang.Exception: javax.wsdl.WSDLException が発生します。この問題を修正するために、riftsaw.sar/lib にある Saxon JAR は単一の saxon バージョン 9.2 jar に置き換えられました。その結果、ユーザーはこの例外に遭遇しなくなりました。

ユーザーは、同じデプロイメントで EBWS と SOAPProxy の両方のデプロイメントの種類を持つことはできませんでした。これは、EsbWebServiceDeployer が、EsbDeployer および EsbMetaData を介して、EsbDeployment の publishers プロパティーを初期化するために使用される発行者のリストを作成したためです。残念ながら、EsbMetaData は変更不可能なリストを返しましたが、Configuration.create が変更を試みたにもかかわらず、java.lang.UnsupportedOperationException が発生しました。コードが変更され、その結果、ユーザーは同じデプロイメントで 2 つの異なるデプロイメントの種類を持つことができるようになりました。

デプロイメント記述子ファイル (deploy.xml) が欠落しているため、デプロイメントが失敗していました。(BPEL プロジェクトには、ランタイムがプロセスのエンドポイントを決定するために、デプロイメント記述子ファイルが必要です。) このファイルがソフトウェアに追加されました。

ユーザーが BPEL コンソールのログイン画面で間違ったユーザー名またはパスワードを入力しても、エラーメッセージは表示されませんでした。これが変更され、間違った認証情報の提供に関するフィードバックがユーザーに提供されるようになりました。

プロセスインスタンスにキーを設定すると、インスタンス変数が間違った場所に配置されていました。変数が正しく保存されるように、コード修正が適用されました。

business_ruleservice_cep クイックスタートのデプロイメント記述子のサービス要素に説明属性がありませんでした。これにより、ユーザーは java.lang.IllegalStateExceptions に遭遇しました。これは修正されたため、ユーザーはこれらの例外に遭遇しなくなりました。

BPEL のエンジン終了ハンドラー (プロセスの強制終了を制御する) にバグがあり、java.lang.IllegalArgumentExceptions をトリガーしていました。終了ハンドラーが期待どおりに動作するように、コードが修正されました。

Teiid Dynamic Portfolio の例の readme ファイルは、dynamicportfolio である必要があるときに、間違った VDB 名 (weather) を参照していました。この間違いを修正するために、readme ファイルが修正されました。

ユーザーが ant runtest を実行すると、警告メッセージが表示されます。これは小さなコーディングエラーが原因でしたが、現在は修正されています。その結果、ユーザーにはこのエラーメッセージが表示されなくなります。

all、production、default サーバープロファイルは、EDS でサポートされていますが、EMBEDDED サーバーでのみサポートされています。サポート/認定された設定ではないため、EDS をスタンドアロンサーバーにインストールしようとしないでください。

モデルが非表示とマークされている場合、クエリープランナーは EDS プロシージャを解決できませんでした。これは、コードの変更によって修正されたため、基になるモデルが表示されていない場合でも、プロシージャを解決済みとしてマークできるようになりました。

teiid-security-roles.properties ファイルには、事前設定された管理ロールが含まれていました。インストール時に定義されたときに、ロールが含まれていてはなりません。これらのロールは削除されました。

ビルド番号が http://localhost:8080/jbossws/ に表示されていませんでした。ユーザーが使用しているビルドを確認できるように、コード修正が適用されました。

このペースでは、http://localhost:8080/jbossws/ のリンク切れが多数ありました。これらは修正されました。

MVELMonitoringAction は正しい数のメッセージを保存していましたが、それぞれが最後に渡されたメッセージの複製に過ぎませんでした。このバグは、MonitoringPatternBean (メッセージ値を含む) の再利用によって引き起こされ、リスト内のすべてのエンティティーが同じインスタンスを参照する結果になりました。コード修正が適用され、その結果、メッセージが正しく保存されるようになりました。

jboss-as/samples/quickstarts/readme.txt ファイルは、内容が古いため更新されました。

ユーザーがノードをチェックインしようとすると、PathNotFoundException が発生することがありました。Modeshape ソフトウェアの更新によりこの問題が修正されたため、ユーザーは問題なくノードをチェックインできるようになりました。

ユーザーが Salesforce コネクターを実行しようとすると、java.lang.NullPointerException が発生します。この問題を修正するためにコード変更が適用されたため、問題が発生することなく Salesforce コネクターを実行できるようになりました。

以前は、WSDL なしで JBDS/Teiid Designer から EDS Web サービス接続を作成する方法がありませんでした。これは、ds.xml ファイルを手動で作成してデプロイしないと、ツールから SOAP 以外の HTTP サービスを呼び出す仮想データベースを開発およびテストできないことを意味していました。ユーザーが仮想データベースをより簡単に開発およびテストできるように、機能が強化されまxxした。

BPEL エディターのウィザードツールで、ユーザーはメッセージ相関プロパティーを作成できませんでした。この機能は修正されました。

Smooks ルーターは、実際には永続化すべきメッセージを非永続化するように設定していました。これは、現在修正されているルーターのコードのバグによるものでした。その結果、メッセージは永続的に設定されるようになりました。

ユーザーは、faultHandler でフォルト変数のデータ型を選択できませんでした。この問題を解決するために、タイプ選択ダイアログとプロパティーセクションがリファクタリングされ、選択された変数またはプロパティーのコンテキスト内で有効なタイプのみにフィルターが制限されるようになりました。

OnMessage と OnAlarm には異なるコンテキストメニューがありました。これは、両方が同じメニューを表示するように変更され、より一貫したユーザーエクスペリエンスを実現します。

JUDDI コンソールが正しくロードを完了する前にユーザーがハイパーリンクをクリックすると、エラーメッセージが表示されました。このメッセージが表示されなくなり、ハイパーリンクが期待どおりに機能するように、コード修正が適用されました。

BPEL エンジンは、HP Systinet UDDI レジストリーを使用してプロセスを登録および検索できませんでした。この問題を修正するために、代わりの JAX-WS トランスポートが ESB コードベースに追加されました。その結果、ユーザーは HP Systinet Registry を使用できるようになります。

Modeshape JBDC ドライバーは、一部の列について間違ったメタデータを報告していました。非文字列型であっても、文字列として設定されていました。これらの列に正しいメタデータ型が設定されるように、コード修正が適用されました。

無効なファイル名フィルターが指定された場合、設定の問題を説明するわかりやすい例外ではなく、javax.jcr.PathNotFoundException が出力されました。この問題を修正するパッチが Modeshape に適用されました。

JBoss BPM インストールが複数のビジネスカレンダープロパティーファイルを採用し、タイマーを繰り返すように設定した場合、タイマーが作成されたときにどのビジネスカレンダープロパティーファイルが使用されていたかジョブ実行者が認識できませんでした。この更新により、CALENDARRESOURCE_ という新しい列が、タイマーの作成に使用されるビジネスカレンダープロパティーリソースの名前を格納する JBPM_JOB テーブルに導入されます。影響を受けていない顧客が前述の列を手動で作成することを強制されないようにするために、この更新は既定で無効になっています。これを有効にするには、列を作成した後、Hibernate 設定で org/jbpm/job/Timer.hbm.xml マッピングリソースを org/jbpm/job/Timer.calendar.hbm.xml に置き換えます。

BIRT のアクティブ化に失敗したことを示すエラーメッセージがログに表示されました。BIRT はデフォルトで無効になっているオプション機能であるため、このメッセージは少し誤解を招くものでした。より正確な状態に変更されました。"BIRT service has not been activated.Please check the DEBUG log for further details."

Resteasy プラグイン情報メッセージがログに誤ってエラーとして記録されていました。ソフトウェアのアップグレードによりこの問題が修正され、メッセージが正しく分類されるようになりました。

認証が失敗したときに、BPEL コンソールがユーザーにフィードバックを提供していませんでした。ユーザーにこの情報を伝えるように強化されました。

jboss-service.xml ファイルが正しく解析されていませんでした。パーサーは空白を無視していませんでした。コードの変更が適用された結果、このファイルは正しく解析されるようになりました。

このソフトウェアは、トランジションのサポートに関して不安定でした。条件が満たされない場合、デフォルト遷移が実行されるように変更されました。(デフォルト遷移は、存在する場合は最初の無条件遷移であり、存在しない場合は最初の条件付き遷移です。) 条件付き (保護された) 遷移のみが使用可能で、遷移の条件がいずれも true と評価されない場合、例外が出力されます。保護された遷移のいずれも実行できない場合に例外を出力すると、プロセスが正しくないことがユーザーに通知されます。

ユーザーが管理コンソールの Web ページにログインするのに時間がかかりすぎると、例外が発生します。代わりにタイムアウトメッセージが表示されるようになりました。

jUDDI root_BusinessEntity には、juddiv3.war によって公開された多数のビジネスサービス (valuesetcaching、replication、および valuesetvalidation) がありませんでした。この問題を解決するために、すべての公開されたサービスが jUDDI に登録され、実装されていないサービスが削除されました。

jUDDI コンソールクエリーは長いログメッセージを生成し、時間の経過とともにハードディスクを無駄な要求でいっぱいにしました。ログメッセージにサイズ制限が追加され、一般的な NumberFormatException in maxRows メッセージが記録されるようになったため、すべてのユーザー入力がエコーされなくなりました。

ユーザーが jUDDI コンソール内からユーザーアカウントを削除した場合、確認は必要ありませんでした。安全策として、アカウントの偶発的な消去を防ぐために確認が追加されました。

SOA サーバーによって公開されたサーブレットとコンソールの URL はパスワードで保護されていましたが、jUDDI v3.0 によって公開された URL は保護されていませんでした。juddi-client-3.1.1 を使用すると、基本認証によって保護されている WebServices デプロイメントに対して WSTransport を使用できるようになりました。

パブリッシャーの詳細を含むフォームが送信されるたびに、ビジネスごとの最大サービスの値がサービスごとの最大バインディングの値によって上書きされました。この値が上書きされないようにコード修正が適用され、ユーザーに正確なデータが表示されるようになりました。

jUDDI コンソールで URL にカーソルを合わせると、表示ボックスのサイズが変更されました。これは、ユーザーがフォントの上にマウスを置いたときにフォントが太字に変わり、テキストの長さとカプセル化ボックスの形状が変化するスタイルシート設定が原因でした。スタイルシートのフォント設定の変更によりこれが修正され、テキストとボックスのサイズが変更されなくなりました

セッションがすでに期限切れになった後にユーザーが JUDDI コンソールを使用しようとすると、Javascript アラートが表示されました。このアラートには、ログインページのソースコードが含まれていました。セッションがタイムアウトした場合にこの警告ダイアログボックスが表示されないように、コード修正が適用されました。

JUDDI コンソールは、タイトル属性を間違った領域に置き忘れていました。これは修正され、属性が正しく表示されるようになりました。

パブリッシャーポートレットのアクションボタンは、管理者以外のユーザーに対して無効になりました。

JUDDI コンソールからログアウトして再度ログインする簡単な方法はありませんでした。ログアウトリンクが追加されました。

EJBProcessor は、アプリケーションの起動時にリモート EJB を探しました。ルックアップが失敗した場合、EJBProcessor は例外を出力しました。つまり、アプリケーションを開始できませんでした。このコードは、最初にルックアップを実行し、プロキシーを再利用してターゲット EJB のメソッドを呼び出すだけでした。リモート EJB を処理できるように変更されました。その結果、例外は発生せず、アプリケーションは正しく起動します。