9. 本リリースで修正された問題

Microcontainer bean は、デプロイメント時にMBeans として登録されていました。これらのMBeans は任意で、デバッグの情報を一部提供します。この動作はデフォルトではオフになりました。デフォルトでは、Microcontainer Beans はデプロイメント時に MBeans として登録されなくなりました。

64ビットハードウェアにてJBoss Nativeを使い、-javaagentのJavaオプションを実行するという特定な場合のみ、run.sh スクリプトの実行時にシステムが停止してしまっていました。このスクリプトは、システムアーキテクチャーのチェックをするために呼出しを行っている際に、ユーザ提供のパラメータをJava に渡していました。この呼出しが行われている時に、run.sh スクリプトがユーザ提供のパラメータを無視するように修正され、この条件でこのスクリプトがハングしなくなりました。

管理ツールが (埋め込みコンソールのように) ProfileService管理層を使って、ServiceBindingManagerサービスをアップデートすると、受け取った情報が正しくマッピングがされませんでした。バインディングの"fixedHostName"プロパティに対して受け取った値は"fixedPort"として適用されていました (逆の場合も同じ)。プロパティは両方 "false"であるため、多くの場合無害でした。しかし、いずれかのプロパティが true の場合、更新済みの値が適用されると、この間違ったマッピングが原因で、サーバー再起動時のバインディングが不正となっていました。この問題は修正され、マッピングは期待どおりに適用されるようになりました。

user-type-mappedタイプを MIN や MAX などの ejbql 集約関数で使う場合、CCE の例外がスローされていました。これは修正され、user-type-mappingタイプにマッピングされたCMPフィールドをEJB-QL クエリのSELECT 句にある集約関数に表示することができるようになっています。

run.sh スクリプトはファイルを作成することで、プロセスを追跡しプロセスID、jboss.pidfileをより簡単に取得できるようなっています。詳細はJIRAを参照してください。

<distributable> なWeb アプリケーションに対して、ステータスサーブレットエラーが存在していました。Cache セッションマネージャは、Web マネージャと違う属性を持ちますが、大文字小文字の区別がないため、同じJMX オブジェクトとして認識されてました。StandardManager は'activeSessions' を、クラスタ版は'ActiveSessions' を使っていました。サーブレットがステータス情報をレンダリングするのに利用するコードで、セッションマネージャの JMX 属性で使われている大文字、小文字を検知、処理することができます。

JBPAPP-544にて、 /statusのマッピングを削除し、セキュアな /web-console/status のみを残すことで、セキュリティの問題が修正されました。しかし、JBPAPP-1146で再度セキュアでない /status が含まれるようになりました。これは、 ROOT.war webappのセキュリティを設定することで修正されました。/status を失うことなしに、元にあったセキュリティ化の問題が解決されています

Microsoft JDBC drivers 2.0 を持つMicrosoft SQL サーバを実行すると、JBoss Messaging のビルドが不安定になります。この問題はAdaptive Buffering がドライバのデフォルト動作となっていることから発生しています。これは、get<Type>Stream メソッドを使うことで大きな値のみの読み込みを可能にするためです。この問題に対する現在の回避策は、JDBC 接続の URLのresponseBuffering パラメータをadaptiveからfullに変更することです (JDBC ドライバのバージョン 1.2 と同じです)。

<url>jdbc:sqlserver://[host];database=[database];responseBuffering=full;</url>

<url>jdbc:sqlserver://[host];database=[database];responseBuffering=full;</url>

Red Hat Enterprise Linux 5 上で JBoss Enterprise Application Platform rpm をyum を使ってインストールする場合、Sun あるいはIBM Java Development Kit との JBoss Enterprise Application Platform での Java 要件を満たすため、Red Hat Enterprise Linux Extras チャネルをサブスクライブする必要があります。

NativeSQLQuerySpecification のequals と hashCode メソッドが正しく実装されていないため、session.createSQLQuery を使うとメモリリークが発生していました。また、LRUMap の同時利用により、マッピングが最大許容範囲よりも大きくなっていました。これらの問題は修正され、メモリリークも発生しなくなっています。

JBPAPP-4471 へ変更を加えたため、ユーザがJDK Serializable 以外のクラスとSerializableTypeをマッピングしこれらの値を二次キャッシュに問題がキャッシュしようとすると問題が発生していました。SerializableType がjava.io.Serializable のクラスローダをデシリアライズ用のクラスローダとしてレポートしていましたが、このクラスローダはクラスローダや非 JDK クラスの判断がつきません。

org.hibernate.util.SerializationHelper.deserialize(InputStream, ClassLoader) からのクラスローダは、デシリアライズが必要なクラスローダを解決しようと試みるようになりました。これに失敗すると、現在のスレッドからのコンテキストクラスローダとHibernate クラスをロードするクラスローダを使います。

Hibernate は、キャッシュからクエリをリトリーブすると、キャッシュ化されたクエリのタイプスタンプと、現在のセッションのタイムスタンプを比較するため、Query Cache を有効にする前にセッションマネージャあるいはエンティティマネージャを閉じる必要がありました。これは修正され、Hibernate はnextTimestamp() を使い、キャッシュされたタイムスタンプではなく、現在のタイムスタンプをフェッチしています。

@CollectionId は、bag の識別子カラムを記述します (例：idbag)。nullable は明示的に false に設定する必要がありました。これは修正されnullable はデフォルトでfalse に設定されています。

制約名が変更された場合、PostgreSQL はSchemaExportのドロップに失敗していました。Hibernate は、テーブルのドロップが試行されるとカスケードを発行することで、この問題を解決しています。

Hibernate プロパティファイル、hibernate.cfg.xml、 persistence.xmlに、hibernate.dialect プロパティが見付からない場合、Hibernate はStandardDialectResolver を使い Hibernate 方言を推測しています。データベースのメタデータから抽出されたデータベース名がSybase SQL Server や Adaptive Server Enterpriseの場合、StandardDialectResolver はSybaseDialect を返していました。しかし、SybaseDialect は廃止予定であるため、これは若干問題でした。hibernate.dialect が設定されていない場合、StandardDialectResolver は正しい方言を使い推測するようになりました。

HQL クエリをコレクション時に join fetch でスクロールしてもカーソルが最後の結果よりも後ろにある場合、FetchingScrollableResultsImpl.last() は最後の結果まで移動しませんでした。代わりに、カーソルは最後の結果の後ろで留まっていました。結果、org.hibernate.exception.GenericJDBCException: could not perform sequential read of resultsが発生する可能性がありました。この問題の修正により、期待通り、カーソルが最後の結果に移動するようになっています。

カラム名がバッククォート (`)で定義された場合、バッククォートの付いたカラム名が参照されていると@JoinTable と @JoinColumn のマッピングがAnnotationException で失敗していました。Hibernate は、テーブルのカラム名ではなく、 referencedColumnName とカラムの引用名を比較するようになっています。

OneToOne マッピングのエンティティを比較するとgetColumnSpan は0 を返していました。同じエンティティを比較している場合でも、TypeMismatchExceptionの結果を返していました。カラムスパンが識別子あるいは一意のキータイプにより識別されるように、getColumnSpan のアルゴリズムが変更されました。

ignoreCase が false に設定されている場合、LikeExpression はignoreCase フラグを正しく処理しませんでした。正しいSQLのproperty like ?が構築されていますが、getTypedValues 内のフラグが使われておらず小文字の値が常に生成されていました。この問題は修正され、ignoreCase が false に設定されている場合、小文字、大文字のいずれかが利用されるようになっています。

ステートレスセッションでは、クエリは２フェーズプロセスでオブジェクトをロードします。最初のフェースで、一時的な永続性コンテキストが空のオブジェクトで生成され、第二フェーズで、オブジェクトのメンバーデータがデータベースから読み込まれます。オブジェクトが関係あるいはコレクションを含んでいる場合、クエリは、セッションのget() メソッドに対し再帰呼出しを実行します。これにより、一時的な永続性コンテキストは削除されます。

親オブジェクトが第二フェーズの一部で読み込むべき別の紐付けを含んでいる場合、永続コンテキストに紐付けが見付からないため、Hibernate はアサーションをスローしていました。

新しいメソッドorg.hibernate.engine.PersistenceContext.isLoadFinished()を導入することで、これは修正されました。このメソッドがStatelessSession に一時的な永続コンテキストを消去するタイミングを指示します。

org.hibernate.cfg.OneToOneSecondPassコードのバグにより、一対一のマッピングの処理時にorg.hibernate.PropertyValueExceptionが発生することがありました。JOINにotherSidePropertyが含まれていない場合、otherSideJoin が null ではなく古いデータを保持してしまうため、この例外が発生していました。org.hibernate.cfg.OneToOneSecondPass コードが修正されています。

Hibernate はtable-pre-class の継承ストラテジに間違ったエイリアスを生成することがありました (例についてはJIRAを参照してください)。AbstractCollectionPersister は、Column.getAlias(Dialect,Table)により生成されたキーカラムのエイリアスを使うようになり、table-pre-class 継承ストラテジのマッピングが訂正されています。

キャッシュプロバイダが見付からない場合、NoClassDefFoundError が以下のメッセージ付きでスローされていました。

net/sf/ehcache/CacheException

net/sf/ehcache/CacheException

接続プロバイダが見付からない場合、以下のメッセージ付きでHibernateException がスローされていました。

Could not instantiate connection provider: " + providerClass

Could not instantiate connection provider: " + providerClass

これらのエラーが発生した場合、より分かりやすいメッセージが出されるようになりました。

JDK 6 に対するHashMaps と HashSets のイテレーション順番が原因で、 union 句あるいは union サブクラスのカラムの順番がJDK 5、6 のいずれが使われているかにより違いました。カラムの順番の変化がunion句全体で一貫しているため、結果クエリは有効でした。しかし、この変化によりパフォーマンスが影響を受けることがありました。HashSet の実装をLinkedHashSet に変更することでJDKが違っても全く同じパフォーマンスが実現できるようになっています。

以下のクラスがJDK 6 インターフェースを完全実装しないため、Hibernate は以前はJDK 6 にまとめられていました。

アプリケーションがこのようなクラスから抜けているメソッドを必要とする場合、NoSuchMethodError が発生していました。これらのメソッドは実装され、このエラーも発生しなくなっています。

org.jboss.remoting.marshal.MarshallerLoaderHandler がクラスに対してリクエストを受け取った場合、org.jboss.remoting.loading.ClassBytesのインスタンスを返していました。MarshallerLoaderHandler が希望のクラスを見つけられない場合、返されたClassBytes オブジェクトはクラスのbyte array値が null となります。しかし、org.jboss.remoting.loading.ClassByteClassLoaderは、byte array が nullの可能性があること前提にチェックしないため、NullPointerException が返されていました。この問題を起こしているJBREM-1184は、修正されています。

jBPM ProcessInstance をSeam のコンポーネントにインジェクションする際、返されるプロセスインスタンスは自動保存に登録されていました。jBPM ManagedContext は終了するとautoSaveProcessesList に全インスタンスを保存するため、パフォーマンスの問題が発生していました。インジェクション時にProcessInstanceを返すコードが変更され、プロセスインスタンスも自動保存に登録されなくなっています。

JBoss Seam が特定のパラメータ化されたJBoss Expression Language (EL) 表現を処理する方法にて、入力のサニタイジングエラーが発見されました。リモートからの攻撃者はこのエラーを使い、特別に作り上げられた正規言語の添付パラメータを含むURL経由で任意のコードを実行することができました。JBoss Seam フレームワークをベースとする特定のアプリケーションに渡されていました。注意：Java Security Managerを正しく設定、有効化することで、このエラーを利用するのを阻止できるでしょう(CVE-2010-1871)。

責任を持ってこの問題を報告してくださったGoogle Security Team のMeder Kydyraliev 氏に、Red Hat は感謝の意を表します。

Seam のgetInstanceFromFactory メソッドを変更し並行処理の問題を修正すると、アプリケーションによっては非常に特定な環境の組み合わせの下でデッドロックの状況に陥ることがありました。元のgetInstanceFromFactoryに対する修正が改正されてから、この問題は発生していません。

Seam は/lib ディレクトリにactivation.jarのコピーとともに配信されていました。このファイルはJDK 6 demo提供されており、Seam のほうは削除されました。

seam-gen で作成されたSeam アプリケーションのRich:comboBoxコンポーネントには、ドロップダウンの矢印画像がありませんでした。Web ブラウザのコンポーネント表示を制御するのに使われるCSS (カスケードスタイルシート) を変更することで、これは修正されています。矢印の画像は正しく表示されるようになっています。

Seam は、同じクラス名を持つコンポーネントがクラスパスで２つあると、"java.lang.IllegalStateException: Two components with the same name and precedence -"のエラーの後にコンポーネントとクラス名が表示され、機能しなくなっていました。Seam はアップデートされ、重複したクラスを無視するようになっています。同じクラス名を持つ重複コンポーネントがあった場合、最初に出てきたコンポーネントがロードされ、その後出てくる同クラス名を持つコンポーネントは無視されます。

MockServletContextは、JBoss Enterprise Application Platform 5 が仮想ファイルシステム (VFS) を利用しているとの認識を持っていません。そのため、URIへファイルとしてアクセスしようとしていました。MockServletContext は、Web アプリケーションのルートを認識し、URL クラスのパスをフェッチすることで、プロトコルがjava.io.Fileコンストラクタパラメータの一部を形成しないようにしています。

Seam-gen テンプレートは、クラスパスに存在しないオブジェクトにresource:// を使っていました。結果、RichFaces テンプレート (XCSS) をCSS ファイルに変換しようと試行するとエラーが発生していました。Seam-gen でresource://を使用しないようにすることで、この問題は修正されています。

複数のWARファイルを含むEARに対してホットデプロイメントが利用されると、最初にアクセスする Web アプリケーションは正しく機能しますが、それ以降のWeb アプリケーションに対するWeb リクエストが原因でNullPointerExceptionが発生していました。これは、ホットデプロイメントフィルタ実行時のアプリケーションコンテキストが設定されていなかったためです。Web アプリケーションコンテキスト関連の各オペレーションで、現在のjavax.servlet.ServletContextを確認するようになり、この問題は解決されています。

Internet Explorer 8 でSeambay 例のWeb サービスページを利用すると、JavaScript のオブジェクトが定義されていないため、ユーザ名、パスワードフィールドに入力した値はリクエストエリアに伝搬されませんでした。これは修正されています。

Tasks の例はInternet Explorer 8 では正しく機能しませんでした。Resolved Tasks ページで"Undo this Task" を選択すると、このタスクはTasks ページを返しますがResolved Tasksページから消えませんでした。Ajax リクエストキャッシングをオフにすることで、この問題は修正されています。

CAPTCHA の画像など、リソースサーブレットからのリソースはブラウザでキャッシュ化され、org.jboss.seam.captcha.CaptchaImageのレスポンスヘッダが正しくないため、再レンダリングが正しく行われませんでした。このレスポンスヘッダが修正され、この問題は発生しなくなっています。

Seam Mail で、添付はインラインに含まれておらず、メールクライアントによっては添付が表示されませんでした。この問題のパッチはJBSEAM-4630からバックポートされ、添付は表示されるようになっているはずです。

最初のパラメータ 'obj' がBigDecimalインスタンス、またタイプがBigDecimal.classで、ELSupport.coerceToType が呼び出されると、BigDecimalは倍に変換され、BigDecimal に戻されるため、違った値が返される結果となっていました。

アップストリームで対処され、 JBoss-EL のSeam 依存性を1.0_02.CR5に変更することで、JBoss Enterprise Application Platform 5.1.0 にて修正されました。

特定のタイプに代入可能な場合、ELSupport.coerceToTypeは入力値を返すようになっています。

org.jboss.seam.transaction.EjbSynchronizations は、Java 仕様に準拠していませんでした。http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/transaction_management/qanda/index.htmlに記載されているように、SessionSynchronizationを実装するクラスは、TransactionsAttribute TransactionAttributeType.SUPPORTSを持つことができません。TransactionsAttributeType.SUPPORTSは、TransactionsAttributeType.REQUIREDで置き換えられました。

org.jboss.seam.core.Interpolator は例外を報告せず、限られた情報を警告で出力していました。例外が報告されるようになり、警告の情報が詳細になり説明が分かりやすくなりました。

マスターノードへの接続に失敗するとSubscriptionRegistryオブジェクトのtopicConnection フィールドが無効になるため、Seam JMSサポートはスレーブノードに対してフェールオーバーした後、機能しませんでした。それ以降のSubscriptionRegistry.subscribe()に対する呼出しはSpyJMSExceptionで失敗し、JMSサブスクリプションは、マスターノードが復活しても機能しなくなっていました。この問題は修正されています。

"Exeception thrown while executing asynchronous call"処理時にorg.jboss.seam.async.AsynchronousExceptionHandler によってログされたメッセージに誤植がありました。"Exeception" は"Exception"であるべきで、これについては修正されています。

JBoss Enterprise Application Platform 4.x と JBoss Enterprise Application Platform 5.x の間の要件がResourceLoader にあるページレベルのmessages.propertiesはMETA-INF/classesに格納される必要があり、さもなければ機能しないというように変更されました。本文書は、これについて明示的ではありません。この問題については修正されています。

Initialization.redeploy には、新規ロックを作成し即座にロックするというコードが含まれていました。これには保護が全くなく、デバッグモードで問題が発生することがありました。これは、このロック自体を完全に消去することで修正されています。

SeamSpace testCreateBlog は、IBM JDK 1.6上でNullPointerException をスローして失敗していました。getIdentifierメソッドはJDK 1.6 で正しく動作するようになっています。

production以外のプロファイルでは、MockResponseStateManager はResponseStateManager#isPostbackをオーバーライドしませんでした。つまり、Facesリクエスト、Faces 以外のリクエスト両方がpostback として評価されていたということです。isPostback(FacesContext context) メソッドがorg.jboss.seam.mock.MockResponseStateManagerに追加され、古いメソッドをオーバーライドし、NonFacesRequest を許可することで postback を認識しています。

EJB トランザクション内で実行されるJAX-RS Web サービスは、Seam HTTP 認証を利用できません。AuthenticationFilter で保護されたWeb サービスへのHTTP リクエストは、２つのContextualHttpRequestsに分割し、2つ目でEjbSynchronization beanをルックアップできないため、Component.getInstance("org.jboss.seam.transaction.synchronizations", ScopeType.EVENT)がNoSuchEjbExceptionの例外で失敗していました。

この問題は修正されています。

jboss-seam.ui.jar/MANIFEST.MF のs.tld は、JSP Taglibrary記述子のXMLスキーマに従い誤って定義されている属性エントリを含んでいました。これは、Richfaces 3.3.1.SP1にアップグレードすることで修正されています。

ユーザがログインしようとすると、Seam Chatroom の例は、EJBTransactionRolledbackException をスローしていました。この例外は、アプリケーションの機能に影響を与えるものではありませんが、JBoss Cache へのアップデートで修正されます。

/status サーブレットは認証なしに、http://localhost:8080/status?full=trueからアクセスできていました (CVE-2008-3273)。

この問題は修正され、このサーブレットでは認証が必要となりました。

hibernate.cfg.xml の解析、デプロイの仕組みは不安定でした。これにより、プロパティはorg.jboss.hibernate.jmx.Hibernate classにマッピングされる必要があるため、正規のHibernate プロパティ名を利用できませんでした。解析されたkey/value ペアの元のセットは、新たなsetProperties(Set<BaseNamedElement>)メソッドで、o.j.h.hmx.Hibernate オブジェクトに挿入されるようになっています。その後、start() メソッドは、そのプロパティセットから設定を構築します。

Seam のリファレンスガイドの誤植が数点、修正されています。

『インストールガイド』 のWindows上でサービスとして実行 に関する項で、誤ったサービス名 (長短問わず) やservice.bat スクリプトの場所をリストアップしていました。これは修正されています。

Drools 5 のRuleBasedPermissionResolver要件は最新ではありませんでした。結果、文書に誤った情報が記載されていました。古くなった情報は最新の正確なコンテンツで置き換えられています。

Seam リファレンスガイドは、重複情報が含まれていましたが、これは削除されています。

Seam リファレンスガイドの'Charting (図表)' の項で、 <p:chart> タグの情報が抜けていました。これは「Seam コンポーネントですでにJava で作成された表を表示」という説明つきで修正されています。

Seam の参照文書にあるソースコードブロックには構文がハイライトされておらず、ソースコードを読むのが困難でした。このコードは、正しいハイライトを使い、更新されています。

Seam Reference Guide はコードブロック例で付記の番号が抜けていました。コードと関連する凡例をつなぎあわせるのが困難でした。付記を導入することで、これは修正されています。

『Seam Reference Guide』 の"Using Seam with JBoss Tools" は、JBoss Enterprise Application Platform で利用するように改訂されておらず、古い情報とみなされるべきでしたが、

文書は修正、更新されています。

ServerConsumerEndpoint.localClose()は、シャットダウン時にNullPointerException をスローしていました。JBoss Messagingの更新版では修正されています。

unicode マルチバイト文字がメッセージのセレクタで利用されると、JBoss MessagingはTokenMgrErrorはスローします。

この問題は修正され、マルチバイト文字は利用可能になりました。

JBoss Transactionsのバージョンが4.4.0 から4.6.1にアップグレードされた場合、JBoss Messaging のXAResourceRecoveryTest は失敗します。このテストはコミット処理中に障害を起こさせ、Recovery Manager がそのトランザクションを回復させるよう促進するものですが、 JBoss Transactions 4.6.1ではこのトランザクションは回復されません。

この問題は修正され、新たなテストを作成し、トランザクションの動作の変化に対応するようになっています。

Enterprise Application Platform 5.1.0がMTOMを有効化せずに大容量のファイルを転送処理する方法に問題があるとテストで判明しました。大容量のファイルを転送するにはMTOM を有効にするように注記すべきで、この種のサービスは大量のメモリを消費します。しかし、MTOMを使用しないと決めた場合、以下を実装しApplication Server がクラッシュしないよう阻止することができます。

Web Services コンテキストの例は機能せず、ClassCastExceptionをスローしました。この例は修正され、期待どおりに機能します。

ヘッダパラメータに追加の名前空間を持つメソッドが、この追加の名前空間を持たないメソッドの後に呼び出された場合、このメソッドがシリアル化される際に間違った名前空間がSOAP オペレーションで利用されていました。この問題は、Java オブジェクトとXMLの間での移行方法が修正されることで解決されており、最後のSOAP メッセージが正しい名前空間で生成されるようになっています。

doc/examples/jboss-web-services-examplesのコンテキストにより、いくつか例外が発生していました。このコンテキストエラーは、JBoss Web Services の例は正しく機能しないという意味です。このコード例は JBPAPP-2995に従い変更され、JBoss WS の例は正しく実行されます。

Sun JAXB は、致命的でないエラーを持つメッセージを拒否するべきにも拘らず、警告なしに受け入れます。JBPAPP-2114に対するパッチはこれを修正し、正しく構成されていないメッセージは拒否されるようになっています。

インタフェースが実装ではなくアノテーションがつけられているため、POJOResourceFactory でIndexOutOfBoundsExceptionが発生していました。アノテーション付きのインターフェースにも対応が追加されました。

クラスタ化されたHibernate の二次キャッシュを使うようにJPAあるいはHibernate を使うアプリケーションが設定された場合、アプリケーションサーバーのCacheManager Serviceに対する明示的な依存性を導入します。この依存性は、アプリケーションサーバーのサービス依存性の仕組みに記録されておらず、当プラットフォームが停止した場合、CacheManager はアプリケーションがシャットダウンする前にシャットダウンすることができます。これにより、アプリケーションがシャットダウンされるとWARNメッセージがログに残されてしまいます。この問題によりエラーログの警告のみが発生していましたが、HA Server Cache アップグレードにより修正されています。

ha-server-cache-jbc は2.0.3.Finalにアップグレードされました。

SystemMemoryUsageLoadMetricを使用時、mod_cluster は、他のマシンより多くのシステムメモリを利用するマシンに対するディスパッチリクエストを優先化します。このメトリックは、期待どおりの「使用済メモリ」ではなく「空きメモリ」として「ロード」を返していました。これは修正され、このエラーも発生しなくなりました。

org.jboss.modcluster.demo.servlet.ThreadCountLoadServletがmod_cluster が削除されていますが、web.xml ファイルではload-demo.warに属しているように指定されています。結果、デプロイメントエラーが発生していました。この問題は修正され、存在しないサーブレットは削除されています。