8. 本リリースにおける既知の問題

リリース時点の既知の問題は次の通りです。
一般的な既知の問題

  • JBPAPP-3929: java.sql.Date.valueOf が yyyy-mm-dd 形式の日付を解析しようとすると、 TCK テストが java.lang.IllegalArgumentException をスローしました。 これは、 最新の Sun JVM の回帰である Sun JDK 1.6.0_18-b07 によるものです (詳細は http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6898593 を参照してください)。 この問題を回避するには、 Sun JDK 1.6.0_17-b04 へダウングレードします。
  • JBPAPP-3766: org.jboss.mail.MailService が設定され、 JNDI へバインドされる度に SessionObjectFactories プロパティが上書きされます。 そのため、 複数の MailService 設定が存在する場合、 JNDI へバインドされるすべての MailService のセッションに、 最も最近設定された MailService が存在することになります。
  • JBPAPP-3171: JBPAPP-544 では、 /status のマップを削除し、安全な /web-console/status のみを残すことでセキュリティの問題を修正しました。 しかし、 JBPAPP-1146 で安全でない /status が再度追加されました。 この問題を回避するには、 JIRA の記述通り、 /status マッピングを ROOT.war/web.xml より削除します。
  • JBPAPP-3133: JVM 実装にバグが存在するため、 ホットデプロイメント中に新しいバージョンのデプロイメントによって未完了のデプロイメントが上書きされると JVM がクラッシュすることがあります。 例えば、 デプロイメントのデプロイメント記述子に形式エラーが存在することがあります。 デプロイされるとエラーが発生し、 デプロイメントに失敗します。 エラーのあるデプロイメント上に正しいデプロイメントをコピーして置き換えると、 新しいバージョンのホットデプロイメント中に JVM がクラッシュすることがあります。 この問題を回避するには、 新規の正しいデプロイメントを deploy ディレクトリにコピーする前に、 完全にデプロイされていない古いアーカイブを削除します。
  • JBPAPP-3036: jboss_init_hpux スクリプトは、 GNU の bash シェルで実行されると環境変数を認識しません。こ の問題は、 JBPAPP-2036 (https://jira.jboss.org/jira/browse/JBPAPP-2306) と関連しています。
  • JBPAPP-3035: shutdown.sh-e および -H 引数を使用して直接 JVM を終了することができません。
  • JBPAPP-2998: サーバーがデスクトップのアイコンより起動されると、 マシンのデフォルト Java セットが使用されます。 JDK 1.6 以外の Java バージョンがデフォルトとして設定されていると、 例外が発生することがあります。 JDK 1.6 がデフォルトの Java バージョンとして設定されていることを確認してから、 デスクトップのアイコンより JBoss Enterprise Application Platform を起動するようにしてください。
  • JBPAPP-2571: Microsoft SQL サーバーを Microsoft JDBC ドライバ 2.0 で実行すると、 Jboss Messaging におけるビルドが不安定になります。 この問題は、 Adaptive Buffering がドライバのデフォルト動作であるため、 get<Type>Streamメソッドを使用して大きな値を一度に読み取ることが原因となっています。 現在の回避策としては、 JDBC 接続 URL の responseBuffering パラメータを adaptive から full に変更します (バージョン 1.2 の JDBC ドライバと同様にします)。
    <url>jdbc:sqlserver://[host];database=[database];responseBuffering=full;</url>
    
  • JBAS-7049: Open JDK 6 に NullPointerException チェックがなかったため、Open JDK 6 が使用されるとサーバーマネージャが正常に動作しませんでした。 imports/server-config.xml ファイルの java.security.debug ステートメントをコメントアウトするとこの問題を回避できます。
  • JBPAPP-2598: JBAS-7049 の問題の回避策を適応すると、 新しい問題が発生します。 Open JDK 6 を使用するセキュリティマネージャを実行しているサーバーが依然起動せず、 アクセス拒否エラーも発生します。 現在、 この問題に対する既知の回避策はありません。
  • JBPAPP-2590: IBM JDK 6 を使用する場合、 ${JAVA_HOME}/jre/lib/security/java.security に定義されている policy.provider に問題が発生します。 デフォルトでは org.apache.harmony.security.fortress.DefaultPolicy が使用されますが、 policy.provider=sun.security.provider.PolicyFile が使用されなければなりません。 手作業で調整することがこの問題の回避策になります。
  • JBPAPP-2576: 現在、 MySQL JDBC ドライバは XA リカバリを正しく実装しません。
  • JBPAPP-2871: JBQA-2610 の通り、 MySQL 5.0.41 の最適化設定が使用されると、 CPU の使用率が上昇し 、パフォーマンスやトランザクションスループットが低下しました。 CPU の使用率を低減し、 パフォーマンスを向上させるため、 MySQL 5.0.86 へアップグレードし、 JBQA-2610 の通りに最適化設定を適応することが推奨されます。
  • JBPAPP-2162: Sun JAXB は拒否すべきである致命的でないエラーのメッセージを許可します。 JBPAPP-2114 の修正がこの問題を修正するため、 悪いメッセージは拒否されます。
  • JBPAPP-2765: ロードの失敗が予期されていたり意図的であっても、 LoadMgr3 はクラスのロードに失敗した際にエラーとしてログに記録しました (例えば、Seam の場合、 特定のクラスが見つからないと不必要なコンポーネントを無効にするため例外をキャッチします)。 そのため、 クラスのロードに失敗した時はエラーではなく警告としてログに記録されるようになりました。
  • JBPAPP-2894: jpa-deployers-jboss-beans.xml 内の hibernate.bytecode.provider システムプロパティは信頼できません。 この問題を回避するには、 -Dhibernate.bytecode.provider=cglibjboss-as/bin/run.conf$JAVA_OPTS に追加します。
  • JBPAPP-2713: org.jboss.test.xml.DDValidatorUnitTestCase が頻繁に失敗し、 Java 仮想マシンがクラッシュします。 この問題の回避策として、 JAVA_COMPILER=NONE を設定して JIT コンパイラを無効にするか、 コマンドラインスイッチ -Djava.compiler=NONE を使用します。
  • JBPAPP-1774: yum を使用して JBoss Enterprise Application Platform rpm をインストールする Red Hat Enterprise Linux 5 ユーザーは、 Sun または IBM Java Development Kit で JBoss Enterprise Application Platform の Java 要件を満たすため、 Red Hat Enterprise Linux Extras チャンネルにサブスクライブしなければなりません。 
    Red Hat Enterprise Linux 5 のベースチャンネルには OpenJDK が含まれていますが、 これを使用して JBoss Enterprise Application Platform をインストールしないでください。 OpenJDK を使用したいユーザーは、 最初に Sun または IBM JDKで JBoss Enterprise Application Platform をインストールしてください。
    yum install jbossas
    その後、 javajavac に対して alternatives を使用します。
    alternatives --config java
    alternatives --config javac
    alternatives により表示されるリストより OpenJDK を選択して切り替えます。
  • JBAS-6966: IBM ディストリビューションの JDK 6 は SSLv2Hello プロトコルをサポートしないため、 使用すると ERROR [AbstractKernelController] が生成されます。 現在、 このプロトコルの使用は推奨されません。

Hibernate における既知の問題

  • JBPAPP-4175: ResultTransformer を使用して Hibernate がキャッシュ可能クエリを実行すると、 ResultTransformer を適用した後に結果をキャッシュしようとします。 しかし、 データが変更された可能性があるため、 Hibernate は読み取ることができません。 この場合、 結果をキャッシュしようとすると ClassCastException が発生します。
  • JBPAPP-4123: 制約名が変更されると、 PostgreSQL は SchemaExport をドロップできません。
  • JBPAPP-4105: hibernate.dialect プロパティが Hibernate プロパティファイルである hibernate.cfg.xmlpersistence.xml にない場合、 Hibernate は StandardDialectResolver を使用して Hibernate 方言を予想します。 StandardDialectResolver はデータベースのメタデータから抽出するデータベース名が Sybase SQL ServerAdaptive Server Enterprise である場合、 SybaseDialect を返します。 しかし、 SybaseDialect は廃止されたため、 問題が発生することがあります。 この問題を回避するには、 hibernate.dialect プロパティを正しい方言に設定します。
  • JBPAPP-4095: コレクション上で join fetch 用いて HQL クエリをスクロールする時、 カーソルが最後の結果以降にあると FetchingScrollableResultsImpl.last() が最後の結果に移動せず、 カーソルはそのまま最後の結果以降に留まります。 これにより、 org.hibernate.exception.GenericJDBCException: could not perform sequential read of results が発生することがあります。
  • JBPAPP-4088: 列名がバックティック (`) で定義されていると、 バックティックを含む列名が参照された時に @JoinTable マッピングと @JoinColumn マッピングが AnnotationException により失敗します。 失敗するのは以下の通りです。
    @JoinTable(name = "SYS_GROUPS_USERS", joinColumns = @JoinColumn(name = "USERID", referencedColumnName = "`uid`"), inverseJoinColumns = @JoinColumn(name = "GROUPID", referencedColumnName = "GROUPID"))
    成功するのは次の通りです。
    @ManyToMany(fetch = FetchType.LAZY)
    @JoinTable(name = "SYS_GROUPS_USERS", joinColumns = @JoinColumn(name = "USERID"), inverseJoinColumns = @JoinColumn(name = "GROUPID"))
    この問題を回避するには、 Hibernate はプライマリキーを自動的に選択するため、 プライマリキーを参照する場所に referencedColumnName を指定しないようにします。
  • JBPAPP-4022: 同じエンティティを比較していても OneToOne マッピングでエンティティを比較すると getColumnSpan0 を返すため、 TypeMismatchException が発生します。 この問題を回避するには、 マッピングを ManyToOne に変更します。
  • JBPAPP-3946: ignoreCase が false に設定されていると、 LikeExpressionignoreCase フラグを正しく処理しません。 正しい SQLの property like ? をビルドしますが、 getTypedValues 内のフラグを使用しません。 小文字の値が常に作成されます。
  • JBPAPP-3913: Oracle 11g R2 (RAC およびスタンドアロン両方) では、 シーケンスが 1 でなく 2 で始まることがあります。 現在、 根本的な原因の分析中です。
  • JBPAPP-3911: Oracle 11g R2 (RAC およびスタンドアロン両方) では、 LockMode.UPGRADE ("for update") を用いた複雑なクエリによって、 "No more data to read from socket" エラーが発生することがあります。 この問題を回避するには、 このようなクエリで LockMode.UPGRADE を使用しないようにします。 根本的原因を分析中です。
  • JBPAPP-3737: ステートレスセッションで、 クエリは 2 段階のプロセスでオブジェクトをロードします。 最初の段階では、 一時永続コンテキストに空のオブジェクトが投入されます。 次の段階では、 オブジェクトのメンバーデータがデータベースより読み取られます。 オブジェクトにアソシエーション (関連) やコレクション (集合) がある場合、 クエリはセッションの get() メソッドへ再帰呼び出しを行います。 これにより、 一時永続コンテキストが消去されます。 親オブジェクトに、 2 段階目の一部として読み取られる他のアソシエーションがある場合、 永続コンテキストにアソシエーションがないため、 Hibernate はアサーションをスローします。
    この問題を回避するには、 hibernate.max_fetch_depth に大きな値を設定して、 エラーが発生しなくなるまでフェッチの最大深さを深くします。
  • JBPAPP-3565: org.hibernate.cfg.OneToOneSecondPass メタデータがランタイム時に org.hibernate.PropertyValueException を発生します。 JOIN が存在しても otherSideProperty プロパティが含まれていない場合、 otherSideJoin が null とならず、 古い無効なデータを保持します。
  • JBPAPP-3487: 場合によって、 Hibernate が table-pre-class 継承ストラテジで誤ったエイリアスを生成することがあります。 例として次のマッピングを見てください。
    <class abstract="true" name="Customer">
    	<composite-id class="PersonID" name="id">
    		<key-property column="NR_RZBK" name="num" />
    		<key-property column="TXT_OID" name="name" />
    	</composite-id>
    	<union-subclass name="CarBuyer">
    		<property column="PID" name="pid" update="false" />
    		<property column="TXT_OID_TESTB" name="sellerName" />
    		<many-to-one cascade="persist, merge, save-update" class="Seller"
    			insert="false" name="seller" update="false">
    			<column name="NR_RZBK" />
    			<column name="TXT_OID_TESTB" />
    		</many-to-one>
    	</union-subclass>
    </class>
    
    この場合、 発行される SELECT ステートメントは次のようになります。
    select
        testc0_.NR_RZBK as NR1_1_,
        testc0_.TXT_OID_TESTB as TXT2_1_,
        testc0_.NR_RZBK as NR1_1_0_,
        testc0_.TXT_OID as TXT2_1_0_,
        testc0_.PID as PID2_0_,
        testc0_.TXT_OID_TESTB as TXT2_2_0_,
        testc0_.NR_RZBK as NR1_2_0_ 
    from
        CarBuyer testc0_ 
    where
        testc0_.NR_RZBK=? 
        and testc0_.TXT_OID_TESTB=?
    org.hibernate.collection.PersistentSet で、 Hibernate は CarBuyer オブジェクトを構築しようとします。
    public Object readFrom(
            ResultSet rs,
            CollectionPersister persister,
            CollectionAliases descriptor,
            Object owner) throws HibernateException, SQLException {
    	Object element = persister.readElement( rs, owner, descriptor.getSuffixedElementAliases(), getSession() );
    	if (element!=null) tempList.add(element);
    	return element;
    }
    しかし、 descriptor.getSuffixedElementAliases() によって返されるエイリアスは以下からのものです。
    org.hibernate.persister.collection.AbstractCollectionPersister
    .AbstractCollectionPersister(Collection, CollectionRegionAccessStrategy, Configuration, SessionFactoryImplementor)
    
    ...
    keyColumnNames = new String[keySpan];
    keyColumnAliases = new String[keySpan];
    int k = 0;
    while ( iter.hasNext() ) {
    	// NativeSQL: collect key column and auto-aliases
    	Column col = ( (Column) iter.next() );
    	keyColumnNames[k] = col.getQuotedName(dialect);
    	keyColumnAliases[k] = col.getAlias(dialect,table);
    	k++;
    }
    この場合、 Column.getAlias(Dialect) アルゴリズムに従い、 キー列 TXT_OID のエイリアスは TXT2_1_ となり、 列 TXT_OID_TESTB のエイリアスと同じになります。
    この問題に対して、 可能な回避策が 3 つあります。
    • 別の列名にマップします。 例えば、 TXT_OID_TESTB を TXT2_OID_TESTB にマップします。
    • 別の継承ストラテジを使用します。
    • Hibernate マッピングにマップされているプロパティの順番を変更します (この方法は Hibernate のアノテーションに対しては検証されていません)。
  • JBPAPP-3485: 現在、 Hibernate にはコミットされていないダーティー読み取りに対するサポートが含まれていません。 そのため、 クエリの実行中に select ステートメントが自動的にテーブルをブロックする DB2 環境では問題が発生することがあります。 次バージョンの JBoss Enterprise Application Platform で、 コミットされていない読み取りサポートの導入が計画されています。
  • JBPAPP-3483: 現在、 Hibernate は各クエリの実行時間をログに記録しません。 この機能は今後の JBoss Enterprise Application Platform で導入される見込みです。
  • JBPAPP-3284: cglib に問題があります。 詳細は http://sourceforge.net/tracker/index.php?func=detail&aid=2796998&group_id=56933&atid=482368 を参照してください。 visitField メソッドに問題があるため、 cglib は TransformingClassGenerator でクラスを変換する時にフィールドアノテーションを削除します。 フィールドの代わりにゲッタをアノテーションとして付けることでこの問題を回避できますが、 JBoss Enterprise Application Platform 5.x へポートされる重いアプリケーションでは実現できない場合があります。
  • JBPAPP-3223: タプル構文をサポートしないデータベース上の HQL やCriteia では、 現在 Hibernate はタプル構文をサポートしていません。 例えば、 データベースがタプル構文をサポートしないとします。
    where (a,b) in ( (1,2), (3,4) )
    Hibernate は次のように変換しなければなりません。
    where ( (a=1 AND b=2) OR ( (a=3 AND b=4) )
    現在、 タプル構文をサポートしないデータベース上でこのような構文クエリを使用しないようにすること以外に回避策はありません。
  • JBPAPP-3075: データベースの予約キーワードが、 Hibernate バリデータアノテーションでプロパティ名として使用されると、 (@Min@Max など)、 列名を指定しても SchemaExport で例外が発生します。 これは、 Hibernate が指定された名前を無視するからです。 この問題を回避するには、 @Column アノテーションでプロパティ名をデータベースの予約キーワード以外にマップします。 この問題は Hibernate 4 で修正される予定です。
  • JBPAPP-3069: デフォルトで ansinull が off に設定されているため、 Sybase でQueryByExampleTest.testJunctionNotExpressionQBE テストに失敗します。 このテストは、 ( OR^ (ex) (NOT ex) ) のような分離述語をビルドします。 これはデータベースのすべてに一致するはずですが、 ANSI SQL は NULL 値が関連するすべての比較を UNKNOWN として評価するため、 一致したものがすべて返されるわけではありません。 この問題を回避するには、 JDBC URL に次の文字列を追加します。
    ?SQLINITSTRING=set ansinull on
    これが可能でない場合は、 Hibernate セッション s を取得した後に次の Java コード (または同様の Java コード) を実行します。
    s.connection().createStatement().execute("set ansinull on");
  • JBPAPP-3034: バッチ挿入ステートメントが要求されると、 組み込みクラスは考慮されません。 この問題の対処策は 2 つあります。 1 つ目の対処策は、組み込みクラスが使用される時に ORDER_INSERTSFALSE に設定します。 2 つ目は、 子オブジェクトに session.save() を明示的に呼び出し、 SQL 挿入要求を強制します。
  • JBPAPP-3032: TIMETIMESTAMP などのデータベース値を返す際、 MySQL はミリ秒やマイクロ秒の単位をサポートしていません。
  • JBPAPP-3031: Sybase では、 トランスレータによって current_timestamp テキストがメソッドモードとして認識されません。 現在、 current_timestamp に代わる関数を使用する以外に回避策はありません。
  • JBPAPP-3030: Sybase では、 チェーンされたトランザクションモードの間に SchemaExport を使用して保存されたプロシージャを作成することはできません。 回避策として、 次のコードを新しく保存されたプロシージャのすぐ後に追加します。
                    <database-object>
                    <create>
                    sp_procxmode paramHandling, 'chained'
                    </create>
                    <drop/>
                    </database-object>
    
  • JBPAPP-2791: java.lang.SecurityException が原因で、 Hibernate が cglib をバイトプロバイダとして使用するようマップするアプリケーションがデプロイしません。 以下のようなエラーメッセージが表示されます。
    Deployment "persistence.unit:unitName=lobtest.ear/
    lobtest-ejb-1.0-SNAPSHOT.jar#lobtest-jpa-jndi" is in error due to the following reason(s):
    java.lang.SecurityException: class 
    "com.redhat.gss.lobtest.jpa.Item$$EnhancerByCGLIB$$defd1a7f"'s signer information does not 
    match signer information of other classes in the same package
    これは、 JBoss Enterprise Application Platform の cglib.jar が署名され、 cglib によってインスツルメントされたプロキシは、アプリケーションターゲットクラスの署名者情報ではなく cglib.jar 署名者情報を使用することが原因です。
    この問題のパッチは JBoss Enterprise Application Platform 5.0 と同時にリリースされ、 Red Hat Support よりダウンロードが可能です。
  • JBPAPP-2945: PostgreSQL 8.3.7 は、 PreparedStatement に対するクエリタイムアウトの設定をサポートしていません。 この制限により、次のようなアノテーションを使用するとクエリに失敗します。
                    @QueryHint(name = "org.hibernate.timeout", value = "100")
    
  • JBPAPP-2867: Sybase は現在 Hibernate の BlobClob をサポートしておらず、 Hibernate は Sybase の textimage データタイプをサポートしていません。 この問題を回避するには、Sybase の textimage タイプにマップするユーザー定義のタイプを作成します。
  • JBPAPP-2789: 宣言されたモデルによって暗黙に固有として定義される列で、 冗長な @Column(unique=true)UniqueContraint(columnnames={...}) アノテーションが使用されると、 Oracle や Sybase 上で ShemaExport に失敗します。 この問題を回避するには、冗長な @Column(unique=true)UniqueContraint(columnnames={...}) アノテーションを削除します。
  • JBPAPP-2613: DB2 バージョン v9.7 ドライバをプログレッシブストリーミング (デフォルト) と使用すると、 Blob ロケータや Clob ロケータ上の操作に失敗します。 この問題には 2 つの可能な回避策があります。
    • クラスパスかクラスパスの JAR に DB2JccConfiguration.properties という名前のプロパティファイルを作成します。 次の行をこのファイルに追加し、 DB2 におけるプログレッシブストリーミングを無効にします。
      db2.jcc.override.progressiveStreaming=2
    • DB2 バージョン 9.7 の代わりに DB2 バージョン 9.1 を使用します。
  • JBPAPP-2440: キャッシュプロバイダが見つからないと、 次のメッセージと共に NoClassDefFoundError がスローされます。
    net/sf/ehcache/CacheException
    接続プロバイダが見つからないと、 次のメッセージと共に HibernateException がスローされます。
    Could not instantiate connection provider: " + providerClass
    このようなエラーが発生したら、 キャッシュまたは接続プロバイダの設定を確認し 、プロバイダがクラスパスに含まれているようにしてください。
  • JBPAPP-2408: ID やネーティブ ID ジェネレータを Hibernate で使用する際、 DB2 v9.7 ドライバに問題ががありました。 DB2 の Statement.getGeneratedKeys() ドライバメソッドが、 生成された鍵でなく空の resultset を返すため、 ネーティブに生成された ID 値をデータベースが返さなかったという内容の例外を Hibernate がスローする原因となっていました。 この問題は、Data Studio 2.2 でリリースされたバージョンの DB2 9.7 JDBC ドライバで修正され、 DB2 のウェブサイトよりダウンロード可能です。 Hibernate ではこのバージョンの使用が推奨されます。
  • JBPAPP-2278: 複数のパスより一時エンティティへのアクセス可能で、 1 つ以上のパスが Save 操作をカスケードしない場合、 Save 操作に失敗することがあります。 現在の回避策として、 失敗した Save を実行する前に一時エンティティを保存します。 これが可能でない場合、カスケードマッピングとエンティティーマッピングのいづれかまたは両方を変更し、 非一時エンティティとなる必要があるエンティティへカスケードする前に一時エンティティが保存されるよう、 カスケードパスの順番を変更します。
  • JBPAPP-2276: JDK 6 の HashMaps および HashSets の反復順序が、 JDK 5 または 6 を使用するかによって union 節や union サブクラスの列順が異なる原因となっていました。 union 節では列順の変更は一貫しているため、 クエリの結果は有効ですが、 変更がパフォーマンスに影響する可能性があります。
  • JBPAPP-2275: JDK 6 では Hibernate をコンパイルできません。 これは、 JDK 6 インターフェースを完全に実装するには、 以下のクラスに対してメソッドを追加する必要があるからです。
    • org.hibernate.jdbc.ResultSetWrapper
    • java.sql.Blob を実装する org.hibernate.lob.BlobImpl
    • org.hibernate.lob.ClobImpl
    • org.hibernate.lob.SerializableBlob
    • org.hibernate.lob.SerializableClob
    実行しているアプリケーションが上記クラスにないメソッドを必要とする場合は、 NoSuchMethodError が生成されます。
  • JBPAPP-2792: 列がオーバーフローすると Sybase は新しいエンティティの挿入に失敗しますが、 例外をスローしないため、 Hibernate は挿入の失敗を認識しません。 この問題を回避するには、 アプリケーションがエンティティプロパティを検証するようにし、 列がオーバーフローしないようにします。
  • JBPAPP-2791: デフォルト値を指定せずに新しい列を追加すると、SchemaUpdate が Sybase ASE 15 テーブルで失敗します。 この問題を回避するため、 SchemaUpdate で新しい列を追加する場合はデフォルト値が含まれるようにしてください。
  • JBPAPP-1895: 形無しテンプレートをサポートしない DB2 で形無しテンプレートを用いてクエリをテストすると、 Hibernate は JoinTest.java をテストし、 QueryAndSQLTest.java に失敗します。 この問題を回避するには、 JIRA に記載されている通り、 適切なデータタイプにパラメータがキャストされるようクエリを編集します。
  • JBPAPP-1613: Sybase で Boolean としてマップされた列の null 値は、 null ではなく 0 として永続されます。 この問題を回避するには、 type="boolean" の代わりに type="org.hibernate.test.where.NumericTrueFalseType" をマップするようにします。
  • JBPAPP-1554: Sybase ではサブクエリ選択リストに 1 つのエントリ (列名や * など) のみが指定できます。 生成された SQL には複数のエントリを持つサブクエリ選択リストが含まれるため、 collection 要素に複合 ID (composite ID) がある場合は HQL 関数である elements() が失敗します。 この問題を回避するため、 要素に複合 ID がある場合は HQL elements() を使用しないようにします。 サブクエリの選択リストに複数のエントリが存在しないよう、HQL を再構成します。
  • JBPAPP-1545: Sybase でクエリに 1 つの ANSI 結合と 3 つ以上の結合が存在し、 1 つの結合に union サブクラスが関係する場合、 SybSQLException によりクエリに失敗することがあります。 これは、列が結合されたテーブル表現の範囲内にないからです。 union サブクラスが関係する結合フェッチを使用しないことが推奨されます。
  • JBPAPP-1230: DetachedCriteria がサブクエリとして使用されると、 生成された SQL のサブクエリに列別名が含まれます。 Sybase ではサブクエリの列別名は許可されていないため、 Sybase では SybSQLException がスローされます。 この問題を回避するには、 サブクエリに DetachedCriteria を使用する代わりに HQL クエリを使用します。
  • JBPAPP-1123: 結合されたクラスに @OrderBy が使用されると (結合テーブルを使用)、「order by」節は実際のテーブル名を使用して列を限定するため、 生成された SQL が MySQL、 PostgreSQL、 Oracle、 MSSQL で無効となります。 「order by」節はテーブルエイリアスを使用するようにしなければなりません。
  • JBPAPP-1082: 初期化されていない char プロパティが使用されると、 Hibernate が char プロパティを 0 に初期化し、 \u0000 を含む文字列を永続します。 PostgreSQL は \u0000 が組み込まれた文字列を許可しないため、 例外をスローします。 現在、 PostgreSQL を使用した char 列の \u0000 の永続に対する回避策は存在しません。
    初期化されていない char プロパティに対して \u0000 ではなく NULL を永続させる場合は、 プリミティブ char タイプの代わりに java.lang.Character を使用します。 これにより、プロパティが初期化された際に例外が発生しないようにします。 \u0000 に設定された java.lang.Character を永続しようとしても例外が発生します。
  • JBPAPP-1071: 場合によっては、 主キー列に外部キーの制約が定義されていると、 CREATE TABLE ステートメントを生成する際に SchemaExport によって列が null 可能であると誤って宣言されることがあります。 この場合、主キー列が null 不可能でなければならない MSSQL、 DB2、 Sybase では障害が発生します。
    この問題を回避するには、下記のように null 不可能な列を明示的に指定します。
    • nullable=false@JoinColumn に追加します。
    • optional=false@ManyToOne に追加します。
    • @CollectionOfElements がマップを使用する場合、@AttributeOverride@Column(name="mapkey", nullable=false) を追加します。
    • @CollectionId 内または @MapKey 内の場合、 @Columnnullable=false を追加します。
  • JBPAPP-3010: EntityRegionAccessStrategy および CollectionRegionAccessStrategyevict(Object) メソッドは、 トランザクション分離を無視してキャッシュからオブジェクトを削除しようとします。 JBoss Cache の removeNode メソッドはトランザクションに対応しないため、 現在サポートされていません。
  • JBPAPP-3019: doc/examples/jboss-web-services-examples コンテキストが例外が発生する原因となっています。 このコンテキストエラーは、JBoss Web Services のサンプルが正しく動作しないことを意味します。

JBoss Messaging における既知の問題

  • JBPAPP-3965: 最新の JDBC ドライバであるバージョン 11.2.0.1.0 を使用すると、 Oracle 11g R1、 R2、 RAC 上で JBoss Messaging Test Suite の 2 つのテストが失敗します。
    • QueueManagementTest.testDestroyDestinationProgrammatically
    • QueueManagementTest.testDestroyDestinationProgrammaticallyWithParams
    これらのテストは、 java.sql.PreparedStatement 上の setFetchSize へ渡される fullSize キュー設定パラメータに対して大きな値を使用します。 JDBC ドライバの問題により、 executeQuery() が呼び出されると通常よりも多くのメモリが消費され、 java.lang.OutOfMemoryError によってテストが失敗します。
  • JBPAPP-3904: Oracle JDBC ドライバのバージョン 11.1.0.7.0 が原因で、 Oracle 11g R1 上で SQLException ("Bigger type length than Maximum") により JBoss Messaging Test Suite が失敗します。 これは、 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.1.0 の使用を推奨します。
  • JBPAPP-3157: メッセージセレクタにユニコードマルチバイト文字が使用されると、 JBoss Messaging は TokenMgrError をスローします。
  • JBPAPP-1745: JBoss Transactions がバージョン 4.4.0 からバージョン 4.6.1 にアップグレードされると、 JBoss Messagingの XAResourceRecoveryTest に失敗します。 このテストはコミット処理中の障害をシミュレートし、 Recovery Manager にトランザクションをリカバリするよう要求するものですが、 JBoss Transactions 4.6.1 ではトランザクションがリカバリされません。 この障害を回避するには、 以下のコードで Recovery Manager を手動で起動します。
                        recoveryManager = RecoveryManager.manager(RecoveryManager.INDIRECT_MANAGEMENT);
    
  • JBPAPP-1746: JGroups がバージョン 2.6.13 にアップグレードされると、 JBoss Messaging の LargeClusterTest に失敗します。 このテストは、テストを実行する前に 1 台のマシン上で 7 つのノードを開始しようとしますが、 開始しないノードがあります。 ノード数を減らすとテストに合格します。
  • JBPAPP-2033: jboss.messaging.ServerPeer JMX インターフェース上の EnableMessageCounterstrue に設定することができません。 この問題を回避するには、 同じJMX インターフェース上で enableMessageCounters() 操作を呼び出すようメッセージカウンタを有効にします。

JBoss mod_cluster における既知の問題

  • JBPAPP-3724: mod-cluster-jboss-beans.xml 内の maxAttempts のデフォルト値が誤って -1 に設定されています。 これは無効な値です。 正しい値である 1 がデフォルトとして使用されます。
  • JBPAPP-3463: アプリケーションがアンデプロイされると、 アンデプロイ通知が受信された前に mod_cluster によってアプリケーションサーバーへ転送されたセッションによってエラー 503 - This application is not currently available が発生することがあります。
  • MODCLUSTER-123: root コンテキスト (「/」) をデプロイし、 有効にすると、 他のコンテキストを無効にすることができません。 また、 他のコンテキストが root コンテキストに転送されないよう指定することも不可能になります。
  • MODCLUSTER-120: [emerg] create_mem_node <node file path> failed エラーが発生したら、 httpd を再起動する前に ipcrm -m コマンドを使用してください。
  • MODCLUSTER-113: org.jboss.modcluster.demo.servlet.ThreadCountLoadServlet は mod_cluster から削除されましたが、 load-demo.war に属する web.xml ファイルには指定されたままになっています。 これにより、 デプロイメントエラーが発生します。 この問題を回避するには、 threads サーブレットの <servlet><servlet-mapping> セクションを削除します。

JBoss Web Services における既知の問題

  • JBPAPP-3785: ヘッダパラメータに追加の名前空間のないメソッドの後に追加の名前空間があるメソッドが呼び出されると、 シリアライズの際に誤った名前空間が SOAP 操作で使用されます。
  • JBPAPP-3028: JBoss Web Services 2.0.1.SP から JBoss Web Services Native 3.1.2.SP へのアップグレードには、 多くの変更や新機能が含まれます。 一部の新しい機能 (リソースインジェクション、 @PostConstruct のサポート、 @PreDestroy など) に必要となる追加の処理時間により、 全体のパフォーマンスが若干劣化します。

Remoting における既知の問題

  • JBPAPP-3709: org.jboss.remoting.marshal.MarshallerLoaderHandler はクラスに対する要求を取得すると、 org.jboss.remoting.loading.ClassBytes のインスタンスを返します。 MarshallerLoaderHandler が希望のクラスを見つけられない場合、 返された ClassBytes オブジェクトには null 値のクラスバイトアレイが含まれます。 しかし、 org.jboss.remoting.loading.ClassByteClassLoader は null バイトアレイの可能性をチェックしないため、 NullPointerException が発生します。
  • JBPAPP-3392: EJB3 クライアントは後続の呼び出しで既存のソケット接続を再使用しません。 呼び出しごとに新しい接続が作成されます。

RESTEasy における既知の問題

  • JBPAPP-2993: spring-hibernate-contacts は Maven レポジトリから削除されたアーカイブに依存するため、 コンパイルできません。
  • JBPAPP-2992: doc/examples/resteasy-examples/resteasy-springMVC/README.txt にある Spring MVC サンプルの readme ファイルに無効な URL が含まれています。 現在の URL は次の通りです。
      List all available contacts:
      http://localhost:9095/contacts
    これを次に置き換えます。
      List all available contacts:
      http://localhost:8080/contacts
  • JBPAPP-2991: doc/examples/resteasy-examples/api-clients にある API クライアントサンプルの readme ファイルに、 Twitter サンプル設定に対して無効なコマンドが含まれています。
    Twitter Client:
    - Run:
        mvn exec:java -Dexec.mainClass="org.jboss.resteasy.examples.twitter.Twitter" -Dexec.args="<userId> <password>"
    そのコードを次のものに置き換えます。
    Twitter Client:
    - Run:
        mvn exec:java -Dexec.mainClass="org.jboss.resteasy.examples.twitter.TwitterClient" -Dexec.args="<userId> <password>"
    doc/examples/resteasy-examples/api-clients/ には 2 つの余分な Eclipse プロジェクトファイル、 .classpath.project が含まれています。 この 2 つのファイルを削除することが推奨されます。

Seam における既知の問題

  • JBPAPP-4015: 複数の WAR ファイルが存在する EAR にホットデプロイメントを使用すると、 最初にアクセスされる Web アプリケーションは正しく動作しますが、 後続の Web アプリケーションに対する Web 要求によって NullPointerException が発生します。 これは、 ホットデプロイメントフィルタが実行される時にアプリケーションコンテキストが設定されないためです。
  • JBPAPP-4013: Internet Explorer 8 で Seambay サンプルの Web サービスページを使用すると、 ユーザー名フィールドとパスワードフィールドに入力された値が要求エリアに伝播されません。 この問題を回避するには、 要求エリアの値を手作業で入力します。
  • JBPAPP-4012: Tasks サンプルが Internet Explorer 8 上で正しく挙動しません。 Resolved Tasks ページで「Undo this Task」が選択されると、 タスクは Tasks ページに戻りますが Resolved Task ページから削除されません。
  • JBPAPP-4010: CAPTCHA イメージなどのリソースサーブレットからのリソースは、 ブラウザによってキャッシュされるため、 正しく再レンダリングしません。 再レンダリングを強制する回避策の例は JIRA を参照してください。
  • JBPAPP-4009: Seam Mail に添付がある場合、 Outlook 2000 では添付が表示されません。 この問題を回避するには、 org.jboss.seam.mail.ui.UIBody を編集します。
    MimeMultipart bodyRootMultipart = new MimeMultipart("related");
    上記の代わりに下記を使用します。
    MimeMultipart bodyRootMultipart = new MimeMultipart("mixed");
    
    そして、 Seam Mail を再コンパイルします。 
  • JBPAPP-4007: org.jboss.seam.transaction.EjbSynchronizations は Java 仕様に準拠していません。 http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/transaction_management/qanda/index.html の記述通り、 SessionSynchronization を実装するクラスに TransactionsAttribute TransactionAttributeType.SUPPORTS がないことがあります。 この問題を回避するには、 代わりに TransactionAttributeType.REQUIRED を使用します。
  • JBPAPP-4006: org.jboss.seam.core.Interpolator はすべての例外をそのまま受け入れ、 情報が限定された警告を出力します。
  • JBPAPP-4005: マスタノードへの接続に失敗すると、 SubscriptionRegistry オブジェクトの topicConnection フィールドが無効になるため、 スレーブノードへのフェイルオーバーの後、 Seam JMS のサポートが動作しません。 SubscriptionRegistry.subscribe() への後続呼び出しがすべて SpyJMSException によって失敗し、 マスタノードが復旧しても JMS サブスクリプションが動作しません。 この問題を回避するには、 JIRA の記述通り、 サブスクライブ要求に失敗した場合に例外をキャッチし、 新しい topicConnection で再試行します。
  • JBPAPP-4004: 「Exeception thrown while executing asynchronous call (非同期呼び出しの実行中に例外がスローされました)」 を処理する時に、 org.jboss.seam.async.AsynchronousExceptionHandler によってログに記録されたメッセージに誤字があります。 "Exeception" は "Exception" でなければなりません。
  • JBPAPP-4003: JBoss Enterprise Application Platform 4.x の要件が JBoss Enterprise Application Platform 5.x で変更になり、 ResourceLoader のページレベルの messages.propertiesMETA-INF/classes に保存されないと動作しなくなりました。 この件について明確に文書化されていません。
  • JBPAPP-4002: Initialization.redeploy には新しいロックを作成し即座にロックするコードが含まれています。 このコードは保護を一切提供しないため、 デバッグモードで問題が発生する可能性があります。
  • JBPAPP-3855: IBM JRE 1.6.0 上で、 SeamSpace の testCreateBlog 単体テストが NullPointerException によって失敗します。
  • JBPAPP-3769: production 以外のプロファイルでは、 MockResponseStateManagerResponseStateManager#isPostback をオーバーライドしません。 そのため、 Faces の要求と Faces でない要求の両方がポストバックとして評価されます。 この問題に対する回避策はありません。
  • JBPAPP-3764: トランザクション終了後に EJBSynchronizationJbpmContext をクリーンアップします。 両要素はイベントコンテキストの一部ですが、 EJBSynchronization のライフサイクルは異なります。 そのため、 EJBSynchronization の前に終了するイベントコンテキストが JbpmContext をクリーンアップすることができますが、 これにより、 メモリーリークの原因となることがあります。 この問題はコンテナ管理によるトランザクションのみに発生します。 そのため、 この問題を回避するには Bean 管理によるトランザクションを代わりに使用します。
  • JBPAPP-3546: iText サンプルには 「Programming Skills」 セクションが含まれています。 複数選択リストで選択された項目は生成された PDF に含まれなければなりませんが、 複数の項目が選択されると最初の項目のみが生成された PDF に含まれます。
  • JBPAPP-3525: jboss-seam.ui.jar/MANIFEST.MFs.tld には、 JSP Taglibrary 記述子の XML スキーマに基づき誤って定義された属性エントリが含まれています。 この問題を回避するには、 jboss-seam-ui.jar/META-INF/s.tldJBPAPP-3525 に添付されている s.tld ファイルに置き換えます。
  • JBPAPP-2385: IBM 仮想マシン上でログインフォームが提出されると、 Seam の Spring サンプルが IllegalStateException により失敗します。 これは、IBM 仮想マシンの不具合が原因です。 この問題の修正は、IBM 仮想マシンが修正されるまで保留されます。
  • JBPAPP-2377: IBM 仮想マシン上で新しいブログエントリが提出されると、 Seamspace サンプルが NullPointerException により失敗します。 これは、IBM 仮想マシンの不具合が原因です。 この問題の修正については、IBM 仮想マシンが修正されるまで保留されます。

文書における既知の問題

  • JBPAPP-3818: 『Seam リファレンスガイド』 の「JBoss ツールで Seam を使用する」の内容は JBoss Enterprise Application Platform 向けに改訂されておらず、 廃止とするべきです。