6. 既知の問題

リリース時点の既知の問題のリストは以下のとおりです。

一般的な既知の問題

JBPAPP-3050
JBoss Enterprise Application Platform が -b <hostname> フラグを使用して起動されるとき、jboss.web:name=ajp-<hostname>/<ip_address>-8009,type=ThreadPool,* でフィルタリングしても結果が返されません。この結果、deploy/snmp-adapter.sar/attributes.xml の設定は Bean を見つけることができないため、SNMP を使用してデータを他のモニタリングツールにエクスポートすることはできません。
以下の定義は機能しません。
<mbean name="jboss.web:name=ajp-<hostname>/<ip_address>-8009,type=ThreadPool" oid-prefix=".1.2.3.4.1">
以下の定義は期待どおりに機能します。
<mbean name="jboss.web:name=ajp-<ip_address>-8009,type=ThreadPool" oid-prefix=".1.2.3.4.1">
JBPAPP-4172
IBM JDK 1.5 を 64 ビットの Red Hat Enterprise Linux 5 でインストールしようとすると、Java バイナリへのリンクが切断されます。これにより、アプリケーションサーバーが起動するのが防がれます。この問題の回避策は代わりに Sun JDK 1.6 を使用することです。
JBPAPP-4917
probe.sh が終了すると、以下のように、該当する文字列に一致する用語のリストと、-match <string> パラメータに一致した応答の数を反映する概要の行が生成されます。
Total responses=1, 1 matches, 3 non-matches
タイムアウト時にマルチキャストソケットを閉じるよう設定されたスレッドによって、マルチキャストソケットが例外を生成し、概要の行が表示される前に返されるため、この概要の行は表示されません。

EJB に関する既知の問題

JBPAPP-3908
ValidateDTD が EJB デプロイヤーで true に設定された場合、メッセージ駆動 Bean (JMSContainerInvoker の Bean など) のプロパティが jboss_4_2.dtd に存在しないため、standardjboss.xml の検証に失敗します。この問題を回避するには、standardjboss.xmljboss_4_2.dtd への参照を削除します。
JBPAPP-5190
クラスタ化された環境では、getCallerPrincipal メソッドは ejbActivate から呼び出されたときに IllegalStateException を発生させました。これは、StatefulHASessionPersistenceManager.synchroSession() が、最初の作成メソッドで getCallerPrincipal を許可しないためです。この問題の回避策は ejbActivate から getCallerPrincipal を移動することです。

メッセージングに関する既知の問題

JBPAPP-2033
jboss.messaging.ServerPeer JMX インターフェースの EnableMessageCounters は、true に設定できません。メッセージカウンターを有効にする回避策は、同じ JMX インターフェースで enableMessageCounters() 操作を呼び出すことです。
JBPAPP-3206
ドキュメンテーションバンドルに含まれる JBoss Messaging のサンプルには、不正確な設定情報が含まれ、これらのサンプルは JBoss Enterprise Application Platform で動作しません。修正されたサンプルアーカイブは、JBoss Enterprise Application Platform 4.3.0 CP09 (http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/) に対して使用できます。
使用しているディストリビューションの /docs/examples/jboss-messaging-examples ディレクトリを、このアーカイブの抽出されたコンテンツで置き換えてください。これらのサンプルを手動で修正する場合は、詳細情報が JIRA で利用可能です。Web サービスのサンプルは動作しないことに注意してください。
JBPAPP-3352
メッセージ駆動の Bean がデフォルト設定 (useDLQ=true, DLQMaxResent=5) でデプロイされ、メッセージの再配信が求められた場合、メッセージは、配信が終了したメッセージのキューに配信されたあとも「配信中」ステータスのキューに残ったままになります。
この問題の回避策は配信されたメッセージのキューを無効にすることです: useDLQ=false
JBPAPP-5420
2 つの JBoss Messaging Test Suite のテストが、Oracle 11g R1、R2、および RAC (JDBC ドライバ v11.2.0.1.0 および v11.2.0.2.0 を使用) で失敗します。
  • QueueManagementTest.testDestroyDestinationProgrammatically
  • QueueManagementTest.testDestroyDestinationProgrammaticallyWithParams
これらのテストは fullSize キュー設定パラメータの大きい値を使用し、値は java.sql.PreparedStatementsetFetchSize に渡されます。JDBC ドライバの問題は、executeQuery() が呼び出されたときに通常よりも大きいメモリ量が消費され、テストが失敗することです。
JBPAPP-5423
Oracle JDBC ドライババージョン 11.1.0.7.0 では、Oracle 11g R1 で JBoss Messaging Test Suite が SQLException ("Bigger type length than Maximum") を発生させて失敗します。これは Oracle JDBC ドライバ 11.1.0.7.0 の問題によって引き起こされます。
この問題を回避するには、Oracle 11g R1、Oracle 11g R2、Oracle RAC 11g R1、および Oracle RAC 11g R2 で Oracle JDBC ドライババージョン 11.2.0.2.0 を使用します。または、Topic または Queue の FullSize 属性 (デフォルト値は 200000) に小さい値 (65000 など) を設定します。

Hibernate の既知の問題

JBPAPP-1545
Sybase では、クエリーに 3 つ以上の結合とともに ANSI 結合が含まれ、1 つの結合が union サブクラスに関連する場合に、カラムが結合されたテーブル表記の範囲内でないため、クエリーが SybSQLException で失敗することがあります。現時点で推奨する解決策は、union サブクラスに関連する結合フェッチを使用することを回避することです。
JBPAPP-1546
Sybase を使用する場合は、SchemaExport を使用してチェーントランザクションモードでストアドプロシージャを作成できません。この場合の推奨される回避策は、新しいストアドプロシージャの定義後に以下のコードを追加することです。
<database-object>
   <create>sp_procxmode paramHandling, 'chained'</create>
   <drop/>
</database-object>
JBPAPP-1554
Sybase では、サブクエリー選択リストで 1 つのエントリ (たとえば、カラム名または '*') しか許可されません。コレクション要素に複合 ID が含まれる場合、HQL 関数 elements() は失敗します。これは、生成された SQL に複数のエントリを持つサブクエリー選択リストが含まれるためです。回避策は、要素に複合キーが含まれる場合に HQL elements() を使用するのを回避することです。代わりに、サブクエリーの選択リストに複数のエントリーが含まれないよう HQL を再び作成します。
JBPAPP-1613
Sybase で Boolean とマップされたカラムの null 値が、null の代わりに 0 として永続化されます。この問題の回避策は type="boolean" の代わりに type="org.hibernate.test.where.NumericTrueFalseType" をマップすることです。
JBPAPP-1709
JBoss Enterprise Application Platform 4.x の現在のバージョンに同梱された ejb3-persistence.jar のバージョンは不正確です。Hibernate Entity Manager には現在 ejb3-persistence.jar 1.0.0.GA が同梱されますが、ejb3-persistence.jar 1.0.1.GA を使用する必要があります。JAR の 1.0.0.GA バージョンと 1.0.1.GA バージョン間には 2 つの変更があります。
  1. JPA 仕様では、クラス名にタイピングエラーがある値を持つ定数が定義されています。
    javax.persistence.Persistence.PERSISTENCE_PROVIDER = "javax.persistence.spi.PeristenceProvider"
    JBoss Enterprise Application Platform に含まれる JAR にはこのタイピングエラーが含まれないため、この JAR は JPA 仕様に準拠しません。詳細については、http://opensource.atlassian.com/projects/hibernate/browse/EJB-321 を参照してください。
  2. javax.persistence.Query.getSingleResult() の Javadoc には、結果がない場合に、EntityNotFoundException がスローされることが記述されています。これは NoResultException と記述するべきです。
JBPAPP-1722
エンティティがカラムをオーバーフローする場合に Sybase は新しいエンティティを挿入するのに失敗します。ただし、例外をスローしないため、Hibernate は挿入が失敗したことを認識できません。この問題を回避するには、アプリケーションでエンティティプロパティを検証して値が基礎となるカラムをオーバーフローしないようにします。以下のいずれかの回避策を使用してください。
  1. jconn3.jarDYNAMIC_PREPARE=true オプション (Hibenate 設定ファイル) で使用し、適切な JDBC を指定します。例を以下に示します。
    <property name="connection.url">jdbc:sybase:Tds:aurum:1503/masterDb?   DYNAMIC_PREPARE=true</property>
    
    <property name="connection.driver_class">com.sybase.jdbc3.jdbc.SybDriver</ 
    property>
  2. jconn4.jar を使用し、適切な JDBC ドライバ (Hibernate 設定ファイル内) を指定してください。例えば、以下のようになります。
    <property name="connection.driver_class">com.sybase.jdbc4.jdbc.SybDriver</ 
    property>
JBPAPP-1895
DB2 v91 (型指定のないパラメータをサポートしない) に対して型指定のないパラメータでクエリーをテストする場合は、Hibernate のテスト JoinTest.javaQueryAndSQLTest.java が失敗します。UPPER 関数はパラメータのデータ型に非常に厳密です。パラメーターマーカーはプリコンパイルされたときにデータ型を持たないため、DB2 は使用するデータ型を認識せず、エラーを発生させません。
この問題を回避するには、パラメータが適切なデータ型にキャストされるようにクエリを変更します。
UPPER(CAST(? AS CHAR(10)) 
UPPER(CAST(? AS VARCHAR(50))
JBPAPP-2315
Hibernate は、アプリケーションが java.sql.Types.LONGVARCHAR または java.sql.Types.CLOB カラムでデータを Java String として処理できるようにするプロパティタイプを提供します。java.sql.Types.LONGVARBINARY または java.sql.Types.BLOB を Java byte[] として処理することもできません。これらの機能は JBoss Enterprise Application Platform 6 ストリームで期待されます。
JBPAPP-2839
エントリがシリアル化解除された PersistenceContext から取得されたときに、インストルメント化されたエンティティのインターセプターを再挿入するのに失敗しため、NullPointerException が発生します。
JBPAPP-2945
PreparedStatement に対するクエリータイムアウトの設定は PostgreSQL 8.3.7 でサポートされていません。この制限のため、クエリーは以下のようなアノテーションを使用する場合に失敗します。
@QueryHint(name = "org.hibernate.timeout", value = "100").
JBPAPP-3069
QueryByExampleTest.testJunctionNotExpressionQBE は、( OR^ (ex) (NOT ex) ) などの論理和述語をビルドします。 ansinull がデフォルトで無効に設定されているため、テストが Sybase で失敗します。これはデータベースのすべての一致するはずですが、ANSI SQL が NULL 値に関連するすべての比較を UNKNOWN と評価したため、すべての一致対象が返されるわけではありません。以下の回避策が存在します。
  1. 次の文字列が JDBC URL に追加される: ?SQLINITSTRING=set ansinull on
  2. Hibernate セッションの取得後に次の Java コード (または同様のもの) を実行: s.connection().createStatement().execute("set ansinull on");
JBPAPP-3075
データベース予約キーワードが Hibernate Validator アノテーションでプロパティ名として使用された場合 (@Min@Max など) は、カラム名を指定しても SchemaExport で例外が発生します。これは、Hibernate が使用された名前を無視するためです。回避策は、プロパティ名を、@Column アノテーションでデータベース予約キーワードでないものにマップすることです。この問題は、Hibernate 4 で修正される予定です。
JBPAPP-3913
Oracle 11g R2 (RAC とスタンドアロンの両方) で、シーケンスは 1 ではなく 2 で開始されることがあります。原因は分析中です。現時点では、この問題に対して 2 つの回避策が存在します。
  1. 別の ID ジェネレータークラスを使用します。
  2. 初期化パラメータ DEFERRED_SEGMENT_CREATIONFALSE に設定して、Oracle の遅延セグメント作成を無効にします。CREATE TABLE ステートメントで新しい句 SEGMENT CREATION DEFERREDSEGMENT CREATION IMMEDIATE を利用できます。これらの句は、DEFERRED_SEGMENT_CREATION 初期化パラメータの設定よりも優先されます。
JBPAPP-4334
jConnect にバグがあるため、FetchingScrollableResultsImpl.isResultSetEmpty() メソッドが、ResultSet が空白であるかどうかを調べるために以下のものを返します。
currentPosition == 0 && ! getResultSet().isBeforeFirst() && ! getResultSet().isAfterLast();
ResultSet が空白の場合、FetchingScrollableResultsImpl.isResultSetEmpty() は false を返しますが、Sybase JDBC は true を返します。現時点では、この問題の回避策はありません。
JBPAPP-4377
Hibernate が ResultTransformer を使用してキャッシュ可能なクエリを実行した場合、ResultTransformer の適用後に結果のキャッシュが試行されます。ただし、データは変更され、Hibernate がデータを読み取れない場合があります。この場合、結果をキャッシュしようとすると、ClassCastException が発生します。
JBPAPP-4465
Oracle 11g R2 (RAC とスタンドアロンの両方) で、LockMode.UPGRADE (つまり、「更新用」) を含む複雑なクエリーにより、"No more data to read from socket" エラーが引き起こされることがあります。この回避策はこのようなクエリーで LockMode.UPGRADE を使用しないことです。この原因は分析中です。
JBPAPP-5152
refresh() メソッドが insert() の直前に呼び出され、2 次キャッシュが有効な場合は、エンティティが 2 次キャッシュに挿入されます。ただし、refresh() が正常にコミットしない場合は、キャッシュされたデータは自動的に削除されません。この理由は、refresh() がエンティティステータスを追跡しないためです。生成されたプロパティに対しては通常 refresh() 操作が使用されるため、この問題の 1 つの回避策は @Generated アノテーションを使用することです。別の回避策はキャッシュを手動で削除することです。

Seam1 に関する既知の問題

JBPAPP-4153
ajax4jsf を使用する Java Server Faces アプリケーションは IBM JDK 1.6 と動作しません。この問題の回避策は、以下の環境変数を設定して OSCache などの異なるキャッシュを使用することです。
org.ajax4jsf.cache.CacheFactory=org.ajax4jsf.cache.OSCacheCacheFactory
または、カスタマーは components.xml で次のパラメータをキャッシュを無効にできます: enable-cache=false
components.xml は Seam 内の以下の場所に保存されます。
  • WAR の WEB-INF ディレクトリ
  • JAR の META-INF ディレクトリ
  • @Name アノテーションを持つクラスを含む任意の JAR ディレクトリ。

Seam2 に関する既知の問題

JBPAPP-4065
複数の Seam 2.0.2 ユニットおよび統合テストが Red Hat Enterprise Linux の IBM JVM で失敗します。影響を受ける例としては、DVD ストア、予約、ネストされた予約、登録、seamdiscs の例などがあります。
JBPAPP-5350
seam-gen により生成され JBDS にインポートされたプロジェクトに対して、JBDS 4 で Seam Expression Language (EL) コードの完了が機能しません。この問題を回避するには、生成されたプロジェクトで Seam Support を有効にし、再びアクティブにします。