1

メッセージ駆動型Beanでは、セッションBean（EJB3またはEJB3.1）と同じルールに制限されていますか。

  • java.lang.reflect Java Reflection APIを使用して、Javaランタイム環境のセキュリティルールで利用できない情報にアクセスします。
  • 非最終静的フィールドの読み取りまたは書き込み
  • これを使用して、メソッドパラメータまたは結果でインスタンスを参照します
  • Javaプログラミング言語のルールによって利用できなくなったパッケージ（およびクラス）にアクセスする
  • パッケージでクラスを定義する
  • java.awtパッケージを使用してユーザーインターフェイスを作成します
  • クラスローダーとセキュリティマネージャーを作成または変更する
  • 入力、出力、およびエラーストリームをリダイレクトします
  • コードソースのセキュリティポリシー情報を取得する
  • セキュリティ構成オブジェクトにアクセスまたは変更する
  • スレッドを作成または管理する
  • スレッド同期プリミティブを使用して、アクセスを他のエンタープライズBeanインスタンスと同期します
  • Java仮想マシンを停止します
  • ネイティブライブラリをロードする
  • ネットワークソケットをリッスンする、接続を受け入れる、またはネットワークソケットからマルチキャストする
  • java.net.Socketまたはjava.net.ServerSocketのソケットファクトリを変更するか、java.net.URLのストリームハンドラファクトリを変更します。
  • ファイル記述子を直接読み取りまたは書き込みます
  • ファイルシステム内のファイルを作成、変更、または削除する
  • Javaシリアル化プロトコルのサブクラスおよびオブジェクト置換機能を使用する
4

2 に答える 2

2

手動でスレッドを作成しないことは常に良い考えです（ExecutorServiceただし、場合によっては問題ないようです）。

実際、MDBは、この制限に対処するために非常に頻繁に使用されます。個別のスレッドを作成する代わりに、タスクオブジェクト（のようなものを入れますMyJob extends Serializable）ObjectMessageをキューに送信し、MDBスレッドプールで実行させます。このアプローチははるかに重いですが、拡張性が非常に高く、スレッドを手動で管理する必要はありません。このシナリオでは、JMSはジョブを非同期で実行するための優れた方法にすぎません。

于 2011-04-17T10:19:21.407 に答える
0

これらのEJB制限は、通常、厳しい制限ではありません。実際、EJBを適切に機能させるための警告ではなく、EJBをEJBコンテナ間で移植可能にする方法に関するアドバイスのようなものです。

時々、非常に厄介なEJBコンテナプロバイダー（cough .... WebSphere ... cough）は、実際にはJavaセキュリティポリシーを通じてこれらの制限を適用しますが、これらの制限の約半分は日常的に無視されます（つまり、 MDBのlog4jは、それらの約30％に違反する可能性があります）。

他の70％に違反している場合は、アーキテクチャまたは設計に問題があることを示している可能性があります。

では、MDBでSystem.exit（）を呼び出すことはできますか？答えはイエスですが、一度だけです... :)

あなたの場合、潜在的に誤動作するプラグインを支配するには、これらの制限のいくつかが必要なようです。MDBがあなたをその問題から解放するかどうかはわかりません。サードパーティの開発者をどれだけ信頼するかにもよると思いますが、EJBで呼び出しベースのモデルを使用するのではなく、コンポーネントをJMXModelMBeansとしてインストールします。Javaセキュリティモデルを使用して、実行できることを制限することはできますが、それでは目的が果たせなくなると思います。

おそらく、実行（またはロード）時のAOPバイトコードエンジニアリングを使用して、割り当てたコンポーネントごとのスレッドファクトリにリダイレクトされるスレッドのすべての要求を書き換えて、作成できるスレッドを制限することができます。彼らがしていることを何でもやめさせたくないので、彼らがクラッシュ/ストール/誤動作したときにサーバー全体を停止させたくないだけです。

興味深い問題。

于 2011-04-18T19:11:52.593 に答える