5. 解決された問題

このリリースで解決された問題のリストは以下のとおりです。

Hibernate に関する問題

JBPAPP-2440
キャッシュプロバイダーが見つからない場合は、NoClassDefFoundError がメッセージ net/sf/ehcache/CacheException とともにスローされます。
接続プロバイダが見つからない場合に、HibernateException が次のメッセージとともにスローされました: Could not instantiate connection provider: " + providerClass
これらのエラーが発生したときにより多くの情報を持つメッセージがスローされるようになりました。
JBPAPP-3223
Hibernate Query Language (HQL) はタプル構文をサポートしませんでした。また、タプル構文をサポートしないデータベースで、データベース基準がタプル構文から解釈可能な構文に変換されませんでした。これにより、データベースクエリーと HQL 検索で問題が発生しました。修正では、HQL のタプル構文がサポートされ、タプルサポートが利用できないデータベースの場合に Hibernate でクエリーが適切な書式に変換されるようになりました。たとえば、以下のようになります。
where (a,b) in ( (1,2), (3,4) )
が以下のように変換されるようになりました。
where ( (a=1 AND b=2) OR ( (a=3 AND b=4) )
JBPAPP-3946
ignoreCase が false に設定されていない場合に、LikeExpression が、ignoreCase フラグを適切に処理しませんでした。適切な SQL property like ? が構築されますが、getTypedValues 内部のフラグは使用されず、小文字の値が常に生成されていました。この問題は修正され、ignoreCase が false に設定されているときに小文字または元の文字種が使用されます。
JBPAPP-4088
カラム名がバックティック (`) で定義されている場合に、バックティックがあるカラム名が参照されると、@JoinTable マッピングと @JoinColumn マッピングが AnnotationException で失敗しました。Hibernate はテーブルカラム名ではなくカラムの引用名で referencedColumnName を比較するようになりました。
JBPAPP-4095
コレクションで結合フェッチを使用して HQL クエリーをスクロールするとき、カーソルが最後の結果の後に配置される場合 FetchingScrollableResultsImpl.last() は最後の結果に移動しません。代わりに、カーソルは最後の結果の後に配置されたままになります。これにより、org.hibernate.exception.GenericJDBCException: could not perform sequential read of results が発生することがあります。修正により、カーソルは期待されたように最後の結果に移動します。
JBPAPP-4123
制約名が変更された場合に PostgreSQL が SchemaExport をドロップするのに失敗し、制約エラーが発生していました。Hibernate は、テーブルをドロップしようとするときにカスケードを発行するようになり、問題は修正されました。
JBPAPP-4326
ユーザーが非 JDK シリアル化クラスを SerializableType でマップし、これらの値を 2 次キャッシュにキャッシュしようとしたときに、JBPAPP-4471 の変更により、問題が発生しました。SerializableType が、java.io.Serializable のクラスローダーを、非シリアル化に使用するクラスローダーとして報告しました。ただし、このクラスローダーはクラスローダークラスまたは非 JDK クラスを参照できませんでした。
org.hibernate.util.SerializationHelper.deserialize(InputStream, ClassLoader) のクラスローダーが、非シリアル化する必要があるクラスローダーを解決するようになりました。これを正常に行えない場合は、現在のスレッドからのコンテキストクラスローダーと、Hibernate クラスをロードするクラスローダーが使用されます。
JBPAPP-4599
Hibernate のバグにより、次の例外がスローされます: java.lang.IllegalArgumentException: alias not found: tbl. A table object could not be saved to Oracle。一時的な回避策は拡張されたシーケンスを使用することでしたが、これは最適なソリューションではありませんでした。この問題を修正するために Hibernate コードが更新されました。テーブルオブジェクトは期待どおりに Oracle に保存できるようになりました。
JBPAPP-4716
アノテーション @Tables.values がタイピングミスであり、正しくは @Tables.value でした。これは Hibernate で修正されましたが、修正では古いアノテーションに依存するコードとの後方互換性が失われました。@Tables.values が再び追加され、@Deprecated でタグ付けされました。これは使用されるべきではありません。
JBPAPP-4927
カスケード保存操作が、割り当てられた PK を持つ親テーブルにリンクされ、自動的にインクリメントされた Primary Key (PK) テーブルを不適切に処理していました。修正により、カスケード保存操作がテーブル間の親子関係を処理できるようになりました。
JBPAPP-5156
Hibernate Deployer (org.jboss.hibernate.jmx.Hibernate) は .har デプロイメントを制御します。
JBoss Enterprise Application Platform 4.3.0 CP08 では、Hibernate Deployer の AUTO_CLOSE_SESSION パラメータと FLUSH_BEFORE_COMPLETION パラメータがデフォルトで true に設定されていました。Hibernate の古いバージョンから移行する場合、finally ブロックで session.close() を使用するときにエラーが発生していました。Hibernate アーカイブ (.har) をデプロイするときに、"Session was already closed" エラーと "Session is closed" エラーが発生していました。このリリースでは、AUTO_CLOSE_SESSIONFLUSH_BEFORE_COMPLETION がデフォルトで "false" に設定されます。これにより、後方互換性の問題が回避され、機能が期待どおりの動作に戻ります。

クラスタリングに関する問題

JBPAPP-4473
Single Sign On (SSO) は、ユーザーが一度だけ認証すると、そのセッション中に複数のシステム/Web アプリケーションのリソースにアクセスできる特別なユーザー認証形式です。
クラスタ化された SSO は、SSO セッションをカウントするときに Tomcat または JBoss Web ホストまたはコンテキストを考慮しませんでした。ユーザーが同じ SSO セッション ID で複数の Web アプリケーションを使用する場合、ホストまたはアプリケーションのコンテキストが Clustered SSO セッション数から除外されるため、ユーザーはログアウトされることがあります。クラスタ化された SSO 対話は JBoss Cache (JBC) で Tomcat と JBoss Web ホストおよびコンテキストを含む接続可能なコンポーネントにリファクタリングされるようになりました。リファクタリングされた SSO では、ホストとコンテキストの問題が解消されます。

一般的な問題

JBPAPP-4917
Xalan は、 XML ドキュメントを HTML、テキスト、または他の XML ドキュメントタイプに変換する XSLT (Extensible Stylesheet Language Transformation) プロセッサです。原因:
Xalan の XMLReaderManager (org.apache.xml.utils.XMLReaderManager) クラスは ThreadLocal で XMLReader を作成しますが、XMLReader が終了したときに ThreadLocal (null に設定される) から XMLReader を削除しませんでした。
これにより、Xalan を JDK 1.5.0_6 環境で実行する場合に永久的なリークが発生しました。リークの規模は、XMLReader が解析する必要がある XML ファイルのサイズと、サーバーの負荷によって悪化しました。 修正および結果:
Xalan 2.7.0 に対して Xalan が ThreadLocal で XMLReader を処理する方法が変更され、XLST 変換でエラーのある追加ノードが作成されることが回避されます。

Seam1 の問題

JBPAPP-4260
Seam-gen テンプレートが、クラスパスにないオブジェクトの resource:// を使用していました。これにより、RichFaces テンプレート (XCSS) を CSS ファイルに変換しようとするときにエラーが発生していました。Seam-gen は resource:// を使用しなくなり、この問題は解決されました。
JBPAPP-4316
クラスパスで重複する Seam コンポーネントが無視され、初期化中に IllegalStateException が発生していました。重複するクラスは無視され、同じコンポーネント名と優先順位を持つ異なるクラスが適切に検出されるようになりました。これらの条件が満たされない場合は、期待された例外がスローされます。
JBPAPP-4803
JBoss Seam がパラメータ化された特定の JBoss Expression Language (EL) 表現を処理するときに入力サニタイゼーションの脆弱性が存在しました。リモート攻撃者はこの脆弱性を使用して JBoss Seam フレームワークに基づいて特定のアプリケーションに提供される URL (アペンドされ、特別に作成される表現言語パラメータ) を介して Seam コンポーネントに対してパラメータがないメソッドを実行できました。このリリースには、EL 表現を使用した悪意のある対話を防ぐ拡張されたセキュリティが含まれます。
Red Hat は、この問題を責任を持って報告された Google Security Team の Meder Kydyraliev 氏に謝意を表します。

Seam2 の問題

JBPAPP-3125
JBoss Enterprise Application Platform の Drools バージョンが SOA 4.3 CP02 で使用されたバイナリにアップグレードされ、jBPM バージョンが v3.2.9 にアップグレードされました。
JBPAPP-4060
一時停止の時間とテストメソッド違反の問題により、Quartz サンプルテストが RHEL4 と IBM JVM 1.6 で失敗しました。テストスイートは各テストメソッドに対して個別のアカウントを使用して個別のテストメソッドを切り離し、一時停止の時間は 50ms から 1000ms に増加しました。この結果、テストスイートでテスト同士が十分に切り離されるようになりました。
JBPAPP-4064
RichFaces の不正確なバージョンが Seam 2.0.2 にバンドルされ、一部の RichFaces コンポーネントが失敗するか、不正に動作していました。これは、RichFaces (3.3.1) の正しいバージョンを Seam にバンドルすることにより修正されました。
JBPAPP-4492
PassivatedEntity.passivateEntity() メソッドの問題により、パッシブ化フェーズで会話コンテキストに余分な属性が追加される可能性がありました (concurrentModificationException がスローされます)。この問題は修正され、concurrentModificationException がスローされなくなりました。
JBPAPP-4686
JBoss Seam がパラメータ化された特定の JBoss Expression Language (EL) 表現を処理するときに入力サニタイゼーションの脆弱性が存在しました。リモート攻撃者はこの脆弱性を使用して JBoss Seam フレームワークに基づいて特定のアプリケーションに提供される URL (アペンドされ、特別に作成される表現言語パラメータ) を介して Seam コンポーネントに対してパラメータがないメソッドを実行できました。このリリースには、EL 表現を使用した悪意のある対話を防ぐ拡張されたセキュリティが含まれます。
Red Hat は、この問題を責任を持って報告された Google Security Team の Meder Kydyraliev 氏に謝意を表します。
JBPAPP-5312
Bash スクリプト seam/seam.sh が、一部の Linux システムでのみ実行可能パーミッションを持ちます。これは、ディストリビューションに含まれる異なる zip ユーティリティ実装によって引き起こされます。これは、Fedora 12 と Red Hat Enterprise Linux 4 で修正され、実行可能パーミッションが seam/seam.sh に適切に割り当てられるようになりました。この修正は Ubuntu などの他のオペレーティングシステムで使用される zip ユーティリティには反映されていません。
JBPAPP-5379
Internet Explorer 8 (IE8) で Seambay サンプルの Web サービスページを使用したときに、ユーザー名フィールドとパスワードフィールドで入力された値が要求領域に伝播しませんでした。Seambay を使用するカスタマーはログイン画面以降に進むために要求領域で値を手動で更新する必要がありました。Seambay サンプルでは、IE8 に存在する異なるオブジェクトモデルが許可され、Microsoft IE Document Object Model (DOM) 実装がチェックされるようになりました。

ドキュメンテーションの問題

JBPAPP-2950
Windows ユーザー向けの Java Runtime Environment (JRE) の指定手順で、JRE bin ディレクトリへのパスが環境変数で必要であると間違って示されていました。『『インストールガイド (Installation Guide)』』の「『Windows 向け JRE の指定 (Specifying JRE for Windows)』」の手順で、ユーザーは JRE パスを JRE インストールルートディレクトリに設定するよう指示され、Windows で環境変数を設定する手順が記載されるようになりました。
JBPAPP-3207
『『メッセージングユーザーガイド (Messaging User Guide)』』に明確な手順が含まれないため、All および Production サーバープロファイルを使用して非クラスタ化の Messaging サンプルを実行するときに問題が発生しました。ほとんどの Messaging サンプルは非クラスタ化サーバープロファイル (AllProduction を除くすべてのプロファイル) で実行されるよう設計されています。サンプルをクラスタ化セットと非クラスタ化セットに分けることにより、該当する章の内容が改善され、ユーザーは設定手順について、各サンプルに同梱される readme ファイルを参照するよう指示されます。
JBPAPP-4138
『『Seam リファレンスガイド (Seam Reference Guide)』』と『『Seam2 リファレンスガイド (Seam2 Reference Guide)』』に、mail-ra.rar コンポーネントを Seam プロジェクトから JBoss Application Server に手動で変更するのに間違った参照が含まれていました。. これらの指示に従うと、カスタマーの本番稼働環境で Red Hat によりサポートされない機能が実装される可能性がありました。両ガイドの項「電子メールの受信 (Receiving Emails)」で、中核的なコンポーネントを変更した結果とカスタマーサポートへの影響に関する記述が修正されました。
JBPAPP-4638
JBoss Enterprise Application Platform 向けのインストール手順の RNH に関する項では、Supplementary / Extra チャネルを有効にするよう指示されませんでした。java-1.5.0-ibm パッケージと java-1.5.0-ibm-devel パッケージがインストールされていない場合に、インストールが失敗しました。『インストールガイド (Installation Guide)』は Supplementary / Extra チャネルをインストールし、正しいパッケージを選択する手順を含むよう更新されました。更新された手順に従うと、RPM インストールは成功します。
JBPAPP-5311
『JDK6 互換性に関するノート (JDK6 Compatibility Notes)』ガイドには、JAX-WS サポートでユーザーが特定の .jar ファイルを JBoss Enterprise Application Platform ディレクトリの jboss-as/lib/endorsed ディレクトリに移動する必要があることが記述されていました。必要なファイルはデフォルトで /endorsed ディレクトリに保存されるようになりました。JAX-WS は動作するために特別な設定を必要としなくなりました。

EJB に関する問題

JBPAPP-4029
user-type-mapped タイプが EJB-QL 集約関数で使用されたときに、結果セットリーダーから Class Cast Exception (CCE) がスローされました。EJB-QL 関数は正しく実装され、user-type-mapped タイプを使用できるようになりました。