WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド

weblogic-ejb-jar.xml デプロイメント記述子のリファレンス

以下の節では、WebLogic 固有のデプロイメント記述子である weblogic-ejb-jar.xml の要素について説明します。このリリースの WebLogic Server では、weblogic-ejb-jar.xml は XML スキーマ (XSD) に基づいています。旧リリースでは、weblogic-ejb-jar.xml は文書型定義 (DTD) に基づいていました。下位互換性を保持するために、このリリースの WebLogic Server は XSD ベースと DTD ベースの EJB 記述子をサポートしています。また、このリリースでは、EJB コンテナは従来の DTD ベースの記述子もすべてサポートしているので、DTD ベースのデプロイメント記述子を使用するアプリケーションも記述子を変更せずにデプロイできます。

詳細情報

2.1 の weblogic-ejb-jar.xml ファイルの構造

WebLogic Server の weblogic-ejb-jar.xml デプロイメント記述子ファイルには、WebLogic Server 固有の要素を記述します。

WebLogic Server の weblogic-ejb-jar.xml の最上位要素は次のとおりです。

2.1 の weblogic-ejb-jar.xml の要素

以下の weblogic-ejb-jar.xml 要素のリストには、このリリースの WebLogic Server でサポートされているすべての要素が含まれています。

allow-concurrent-calls

機能

ステートフル セッション Bean インスタンスがメソッドの同時呼び出しを許可するかどうかを指定します。デフォルトでは、EJB の仕様に従って allows-concurrent-calls は False であり、ステートフル セッション Bean のインスタンスでメソッド呼び出しを処理しているときにまた別の (同時) メソッド呼び出しがサーバに到着すると WebLogic Server から RemoteException が送出されます。

True に設定すると、EJB コンテナはメソッドの同時呼び出しをブロックするため、前の呼び出しが完了してから次のメソッドが呼び出されるようになります。

例

「stateful-session-descriptor」を参照してください。

allow-remove-during-transaction

機能

ステートフル セッション Bean の remove メソッドをトランザクション コンテキスト内で呼び出すことができることを指定します。

例

「stateful-session-descriptor」を参照してください。

cache-between-transactions

機能

以前の db-is-shared 要素に相当し、EJB コンテナがエンティティ Bean の永続データをトランザクション間でキャッシュするかどうかを指定します。

EJB コンテナによるデータの長期キャッシングの実行を有効にする場合、True を指定します。EJB コンテナによるデータの短期キャッシングの実行を有効にする場合、False を指定します。

読み込み専用 Bean の場合、WebLogic Server はこれの長期キャッシングを常に実行するので、cache-between-transactions 要素の値は無視されます。

詳細については、「cache-between-transactions によるデータベース読み込みの制限 (長期キャッシング)」を参照してください。

例

「persistence」を参照してください。

cache-type

機能

EJB がキャッシュから削除される順番を指定します。値は次のとおりです。

例

<stateful-session-cache>
     <cache-type>NRU</cache-type>
</stateful-session-cache>

client-authentication

機能

EJB がクライアント認証をサポートするか、または、必要とするかを指定します。

例

「iiop-security-descriptor」を参照してください。

client-cert-authentication

機能

EJB が転送レベルでのクライアント証明書認証をサポートするか、または、必要とするかを指定します。

例

「transport-requirements」を参照してください。

clients-on-same-server

機能

EJB がデプロイされた際、WebLogic Server がこの EJB に JNDI の通知を送るかどうかが指定されます。この属性が False (デフォルト) の場合、WebLogic Server クラスタでは、ある特定のサーバ上にあるこの EJB の場所を示すために、自動的に JNDI ツリーを更新します。これにより、そのクライアントが同じサーバ上で連結されてなくても、すべてのクライアントがこの EJB にアクセスできるようになります。

EJB にアクセスするクライアントのすべてが、その Bean がデプロイされているのと同じサーバ上からアクセスすることが分かっている場合には、clients-on-same-server を True に設定できます。この場合、EJB がデプロイされる際、WebLogic Server クラスタは JNDI の通知をこの EJB に送信しません。クラスタ内の JNDI の更新ではマルチキャスト トラフィックが利用されるため、clients-on-same-server を True に設定することにより大容量のクラスタでの起動時間を短縮できます。

連結された EJB の詳細については、『クラスタの使用』の「連結されたオブジェクトの最適化」を参照してください。

例

<weblogic-enterprise-bean>
	<ejb-name>AccountBean</ejb-name>
	...
	<clients-on-same-server>True</clients-on-same-server>
</weblogic-enterprise-bean>

component-factory-class-name

機能

EJB がデプロイされた際、WebLogic Server がこの EJB に JNDI の通知を送るかどうかが指定されます。この属性が False (デフォルト) の場合、WebLogic Server クラスタでは、ある特定のサーバ上にあるこの EJB の場所を示すために、自動的に JNDI ツリーを更新します。これにより、そのクライアントが同じサーバ上で連結されてなくても、すべてのクライアントがこの EJB にアクセスできるようになります。

EJB にアクセスするクライアントのすべてが、その Bean がデプロイされているのと同じサーバ上からアクセスすることが分かっている場合には、clients-on-same-server を True に設定できます。この場合、EJB がデプロイされる際、WebLogic Server クラスタは JNDI の通知をこの EJB に送信しません。クラスタ内の JNDI の更新ではマルチキャスト トラフィックが利用されるため、clients-on-same-server を True に設定することにより大容量のクラスタでの起動時間を短縮できます。

連結された EJB の詳細については、『クラスタの使用』の「連結されたオブジェクトの最適化」を参照してください。

concurrency-strategy

機能

コンテナがエンティティ Bean への同時アクセスを管理する方法を指定します。以下の 4 つの値のいずれかに設定します。

Exclusive および Database のロック動作の詳細については、「同時方式の選択」を参照してください。read-only エンティティ Bean の詳細については、「読み書き対応エンティティ Bean と読み込み専用エンティティ Bean」を参照してください。

例

<weblogic-enterprise-bean>
	<ejb-name>AccountBean</ejb-name>
	<entity-descriptor>
		<entity-cache>
			<concurrency-strategy>ReadOnly</concurrency-strategy>
		</entity-cache>
	</entity-descriptor>
</weblogic-enterprise-bean>

confidentiality

機能

EJB における転送の機密性の要件を指定します。confidentiality 要素を使用すると、他のエンティティに内容を見られることなく、クライアントとサーバ間でデータが送信されるようになります。

例

「transport-requirements」を参照してください。

connection-factory-jndi-name

機能

メッセージ駆動型 EJB がキューとトピックを作成するためにルックアップする JMS 接続ファクトリの JNDI 名を指定します。「送り先を考慮した MDB のコンフィグレーション」および「connection-factory-jndi-name の設定方法」を参照してください。

例

<message-driven-descriptor>
     <connection-factory-jndi-name>
     java:comp/env/jms/MyConnectionFactory
     </connection-factory-jndi-name>
</message-driven-descriptor>

connection-factory-resource-link

機能

ejb-jar.xml に定義されている JMS モジュール内のリソースを WebLogic Server の実際の JMS モジュール参照にマップします。

create-as-principal-name

機能

WebLogic Server 8.1 SP01 で導入され、本来は ejbCreate が匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。

create-as-principal-name が設定されている場合
そのプリンシパルを使用します。
あるいは
     ejb-jar.xml で Bean に対して run-as ロールが指定されている場合
     run-as-role-assignment を設定するためのルールに従ってプリンシパルを使用します。
     あるいは
           ejbCreate を匿名プリンシパルとして実行します。

create-as-principal-name 要素は、ejbCreate 内の処理が匿名プリンシパルよりも高レベルのパーミッションを必要とする場合にのみ指定する必要があります。

この要素は、ステートレス セッション Bean とメッセージ駆動型 Bean の ejbCreate メソッドに影響します。

「remove-as-principal-name」、「passivate-as-principal-name」、および「principal-name」も参照してください。

delay-updates-until-end-of-tx

機能

トランザクションの完了時にトランザクションですべての Bean の永続ストレージを更新するには、delay-updates-until-end-of-tx 要素を True (デフォルト) に設定します。通常、この設定によって不要な更新を防ぐことができるため、パフォーマンスが向上します。ただし、データベース トランザクション内のデータベース更新の順序は保持されません。

データベースがアイソレーション レベルとして TransactionReadUncommitted を使用している場合は、進行中のトランザクションに関する中間結果を他のデータベースのユーザに表示することもできます。この場合、delay-updates-to-end-of-tx を False に設定して、各メソッド呼び出しの完了時に Bean の永続ストレージを更新するように指定します。詳細については、「ejbLoad() と ejbStore() の動作について」を参照してください。

例

<entity-descriptor>
     <persistence>
     ...
     ...
     <delay-updates-until-end-of-tx>False</delay-updates-until-end-of-tx>
     </persistence>
</entity-descriptor>

description

機能

親要素を説明します。

例

<description>Contains a description of parent element</description>

destination-jndi-name

機能

WebLogic Server JNDI ツリーにデプロイされている実際の JMS キューまたはトピックにメッセージ駆動型 Bean を関連付けるために使用する JNDI 名を指定します。

例

「message-destination-descriptor」および「message-driven-descriptor」を参照してください。

destination-resource-link

機能

ejb-jar.xml に定義されている JMS モジュール内のリソースを WebLogic Server の実際の JMS モジュール参照にマップします。

disable-warning

機能

ID を指定した警告メッセージを WebLogic Server が無効化するように指定します。以下の 4 つの値のいずれかに設定します。

例

警告メッセージ「Call-by-reference not enabled」を無効にするには、次のように <disable-warning> を設定します。

<disable-warning>BEA-010202</disable-warning>

dispatch-policy

機能

EJB が実行されるべきスレッド プールをどのサーバが実行するかを指定します。ディスパッチ ポリシーは、エンティティ、セッション、メッセージ駆動型など、すべての種類の Bean でサポートされています。

dispatch-policy が指定されていないか、指定された dispatch-policy が存在しないサーバ実行スレッド プールを参照していた場合、代わりにサーバのデフォルトの実行スレッド プールが使用されます。

WebLogic Server は、対応する名前を持つ実行スレッド キューがホスト サーバ インスタンスになければ、dispatch-policy を無視します。

メッセージ駆動型 Bean (MDB) が外部の (WebLogic 以外の) 送り先ソースによって駆動されている場合、MDB は外部プロバイダのスレッド メカニズムで実行される可能性があるので、WebLogic Server は dispatch-policy を無視することがあります。たとえば、IBM WebSphere MQSeries メッセージング ソフトウェアの場合、dispatch-policy は非トランザクション キューについては対応されていません。アプリケーション コードは MQSeries スレッド内で実行されます。MQSeries トランザクション キュー、および非トランザクションとトランザクションの両トピックにおいては、dispatch-policy は受け付けられます。

同時に実行中の MDB インスタンスの最大数は、max-beans-in-free-pool と dispatch-policy の値の組み合わせによって指定されます。『WebLogic Server パフォーマンス チューニング ガイド』の「MDB スレッド管理」を参照してください。

例

<dispatch-policy>queue_name</dispatch-policy>

distributed-destination-connection

機能

同じクラスタ内の WebLogic JMS 分散キューにアクセスする MDB が、リソースをすべての分散送り先メンバーから消費するか、現在の Weblogic Server のローカル メンバーのみから消費するかを指定します。

有効な値は以下のとおりです。

EveryMember に設定すると、合計接続数が (メッセージ駆動型 Bean がデプロイされているサーバの数) x (送り先の数) に等しくなります。より大きなデプロイメントの場合、この接続数により、かなりのリソースが消費される場合があります。

EveryMember 設定では、リモート サーバからローカル MDB へメッセージを転送するため、ネットワークおよび CPU のオーバーヘッドが増大します。したがって、この設定は、現在のサーバにユニークな JMS セレクタ フィルタを使用する MDB など、限定的なケースで利用するようにしてください。

例

<distributed-destination-connection>EveryMember</distributed-destination-connection>

durable-subscription-deletion

機能

MDB がアンデプロイまたは削除されるときに、恒久トピック サブスクリプションが自動的に削除されるようにするかどうかを指定します。

例

<durable-subscription-deletion>True</durable-subscription-deletion>

ejb-local-reference-description

機能

Bean が ejb-local-ref 要素で参照する WebLogic Server インスタンスの EJB の JNDI 名をマップします。

例

<ejb-local-reference-description>
	<ejb-ref-name>AdminBean</ejb-ref-name>
	<jndi-name>payroll.AdminBean</jndi-name>
</ejb-local-reference-description>

ejb-name

機能

ejb-jar.xml で指定された同じ名前を使用して、エンタープライズ Bean の名前を指定します。エンタープライズ Bean のコードは名前に左右されないので、アプリケーション アセンブリ処理中に名前を変更してもエンタープライズ Bean の機能には影響しません。デプロイメント記述子の ejb-name と、デプロイヤがエンタープライズ Bean のホームに割り当てる JNDI 名との間には、構築された関係はありません。

例

「method」を参照してください。

ejb-reference-description

機能

WebLogic Server の EJB の JNDI 名を、ejb-jar.xml の ejb-ref-name 要素でそれを指定するのに使われる名前にマップします。

例

<ejb-reference-description>
	<ejb-ref-name>AdminBean</ejb-ref-name>
	<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>

ejb-ref-name

機能

リソース参照名を指定します。この要素は、EJB プロバイダが ejb-jar.xml デプロイメント ファイル内に配置する参照です。

例

<ejb-reference-description>
	<ejb-ref-name>AdminBean</ejb-ref-name>
	<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>

enable-bean-class-redeploy

機能

デフォルトでは、EJB 実装クラスは他の EJB クラスと同じクラスローダにロードされます。enable-bean-class-redeploy 要素が有効化されていると、実装クラスは、スーパー クラスと共に、EJB モジュール クラスローダの子クラスローダにロードされます。これにより、EJB 実装クラスは EJB モジュール全体を再デプロイしなくても再デプロイできるようになります。

Bean クラスを子クラスローダにロードすると、いくつかの問題が発生する可能性があります。まず、Bean クラスが親クラスローダにロードされたどのクラスからも見えなくなってしまうため、これらのクラスが Bean クラスを参照できなくなったり、エラーが発生したりします。また、Bean クラスは別のクラスローダにロードされたクラスに対しては、パッケージ保護されたメソッドを呼び出せなくなります。したがって、Bean クラスが同じパッケージ内のヘルパー クラスを呼び出した場合、ヘルパー クラス メソッドは public として宣言する必要があります。そうしないと、IllegalAccessErrors が発生します。

例

次の XML 要素では、単独の Bean クラスの再デプロイメントが可能です。

<enable-bean-class-redeploy>True</enable-bean-class-redeploy>

enable-call-by-reference

機能

enable-call-by-reference が False の場合、EJB メソッドのパラメータは EJB がリモートから呼び出されるか、同じ EAR から呼び出されるかに関係なくコピーされます (または値で渡される)。

enable-call-by-reference が True の場合、同じ EAR ファイル内またはスタンドアロンの JAR ファイルから呼び出された EJB メソッドは引数を参照で渡します。パラメータはコピーされないので、これによってメソッド呼び出しのパフォーマンスが向上します。

例

<weblogic-enterprise-bean>
     <entity-descriptor>
          <ejb-name>AccountBean</ejb-name>
          ...
          <enable-call-by-reference>False</enable-call-by-reference>
     </entity-descriptor>
</weblogic-enterprise-bean>

enable-dynamic-queries

機能

True に設定すると、動的クエリが有効になります。動的クエリは、EJB 2.x CMP Bean を使用している場合にのみ使用できます。

例

<enable-dynamic-queries>True</enable-dynamic-queries>

entity-always-uses-transaction

機能

WebLogic Server 9.0 で導入された要素で、エンティティ Bean が常にトランザクションを使用しなければならないかどうかを指定します。WebLogic Server 9.0 より前では、エンティティ Bean が不特定のトランザクションで動作している場合、EJB コンテナはそのエンティティ Bean のトランザクションを作成しました。現在は、エンティティ Bean が不特定のトランザクションで動作している場合、EJB コンテナはトランザクションを作成しません。この動作を無効にし、EJB コンテナが不特定のトランザクションで動作するエンティティ Bean のトランザクションを作成するようにする場合、この要素の値を True に設定します。

entity-cache

機能

WebLogic Server 内のエンティティ EJB インスタンスのキャッシュに使用する以下のオプションを定義します。

詳細については、「エンティティのキャッシングについて」を参照してください。

例

<entity-descriptor>
	<entity-cache>
		<max-beans-in-cache>...</max-beans-in-cache>
		<idle-timeout-seconds>...</idle-timeout-seconds>
		<read-timeout-seconds>...<read-timeout-seconds>
		<concurrency-strategy>...</concurrency-strategy>
	</entity-cache>
	<persistence>...</persistence>
	<entity-clustering>...</entity-clustering>
</entity-descriptor>

entity-cache-name

機能

エンティティ Bean が使用する、アプリケーション レベルのエンティティ キャッシュを参照します。アプリケーション レベルのキャッシュは、同じアプリケーション内の複数エンティティ Bean によって共有されるキャッシュです。entity-cache-name で指定する値は、weblogic-application.xml ファイルでアプリケーション レベルのエンティティ キャッシュに当てた名前と一致させる必要があります。

weblogic-application.xml ファイルの詳細については、『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。

例

「entity-cache-ref」を参照してください。

entity-cache-ref

機能

同じアプリケーションに属する複数のエンティティ Bean のインスタンスをキャッシュできるアプリケーション レベルのエンティティ キャッシュを表します。アプリケーション レベルのエンティティ キャッシュは、weblogic-application.xml ファイルで宣言されます。

concurrency-strategy を使用し、その Bean に使用させたい同時方式のタイプを定義します。同時方式はアプリケーション レベル キャッシュのキャッシュ戦略と適合していなくてはなりません。たとえば、Exclusive キャッシュは、concurrency-strategy が Exclusive である Bean だけをサポートします。MultiVersion キャッシュは、Database、ReadOnly、および Optimistic 同時方式をサポートします。

例

<entity-cache-ref>
	<entity-cache-name>AllEntityCache</entity-cache-name>
	<read-timeout-seconds>600</read-timeout-seconds>
	<cache-between-transactions>true</cache-between-transactions>
	<concurrency-strategy>ReadOnly</concurrency-strategy>
	<estimated-bean-size>20</estimated-bean-size>
</entity-cache-ref>

entity-clustering

機能

エンティティ Bean が WebLogic クラスタでどのようにレプリケートされるのかを指定します。

例

<entity-clustering>
	<home-is-clusterable>True</home-is-clusterable>
	<home-load-algorithm>random</home-load-algorithm>
	<home-call-router-class-name>beanRouter</home-call-router-
	class-name>
	<use-serverside-stubs>True</use-serverside-stubs>
</entity-clustering>

entity-descriptor

機能

エンティティ Bean に適用する以下のデプロイメント パラメータを指定します。

例

<entity-descriptor>
	<pool>...</pool>
	<timer-descriptor>...</timer-descriptor>
	<entity-cache>...</entity-cache>
	<persistence>...</persistence>
	<entity-clustering>...</entity-clustering>
	<invalidation-target>...</invalidation-target>
	<enable-dynamic-queries>...</enable-dynamic-queries>
</entity-descriptor>

estimated-bean-size

機能

エンティティ Bean のインスタンスの推定平均サイズ (バイト単位) を指定します。各インスタンスが消費するメモリのバイト数の平均値です。

estimated-bean-size 要素は、Bean をキャッシュするのに使用する、アプリケーション レベルのキャッシュがともにバイト数や MB 単位で指定されている場合に併せて使用します。

エンティティ Bean インスタンスが消費する正確なバイト数が分からなくても、サイズを指定することにより、ある一時点でキャッシュを共有する Bean に対し相対的な重みを与えることができます。

たとえば、Bean A と Bean B が 1000 バイトのキャッシュを共有し、A のサイズが 10 バイト、B のサイズが 20 バイトであるとします。その場合、キャッシュに格納できるのは、最大で、A のインスタンスで 100、B のインスタンスで 50 です。A のインスタンスが 100 個キャッシュされた場合、B のインスタンスは 0 個キャッシュされたことになります。

例

「entity-cache-ref」を参照してください。

externally-defined

機能

特定のセキュリティ ロールが、デプロイメント記述子の外の、セキュリティ レルム内で外部定義されていることを示します。セキュリティ ロールおよびその principal-name のマッピングが別のところで定義されているため、principal-name はデプロイメント記述子内では指定されません。このタグは、principal-name 要素のセットの代わりに、指示を行うプレースホルダとして使用されます。この要素は、非推奨になって WebLogic Server 9.0 で削除されたグローバル ロールの代わりに使用します。

finders-load-bean

機能

CMP エンティティ EJB でのみ有効です。finders-load-bean は、ファインダ メソッドの呼び出しによって Bean への参照が返されてから WebLogic Server が EJB をキャッシュにロードするかどうかを指定します。この要素を True に設定した場合、Bean への参照がファインダによって返されると、WebLogic Server はすぐにその Bean をキャッシュにロードします。この要素を False に設定した場合、WebLogic Server は、最初のメソッドが呼び出されるまで Bean を自動的にロードしません。この動作は、EJB 1.1 の仕様と一致しています。

例

<entity-descriptor>
	<persistence>
		<finders-load-bean>True</finders-load-bean>
	</persistence>
</entity-descriptor>

generate-unique-jms-client-id

機能

EJB コンテナが MDB のインスタンスごとにユニークなクライアント ID を生成するかどうかを指定します。このフラグを有効にすると、恒久 MDB を WebLogic Server クラスタ内の複数のサーバ インスタンスに簡単にデプロイできるようになります。

global-role

global-role 要素は非推奨となっており、WebLogic Server 9.0 で削除されました。代わりに externally-defined 要素を使用してください。

home-call-router-class-name

機能

Bean のメソッド呼び出しのルーティングに使用するカスタム クラスの名前を指定します。このクラスは weblogic.rmi.cluster.CallRouter() を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼び出しの前に呼び出されます。ルータ クラスでは、メソッドのパラメータを基に、ルーティングするサーバを選択できます。このクラスは、サーバ名を返すか、または現在のロード アルゴリズムがサーバを選択する必要があることを示す null を返します。

例

「entity-clustering」および「stateful-session-clustering」を参照してください。

home-is-clusterable

機能

home-is-clusterable が True の場合、クラスタ内の複数の WebLogic Server から EJB をデプロイできます。ホーム スタブの呼び出しは、Bean がデプロイされるサーバ間で負荷が分散されます。Bean のホスト サーバにアクセスできなかった場合、呼び出しは、Bean を提供する他のサーバに自動的にフェイルオーバします。

例

「entity-clustering」を参照してください。

home-load-algorithm

機能

クラスタ内の EJB ホームのレプリカ間のロード バランシングに使用するアルゴリズムを指定します。この要素を定義しない場合、WebLogic Server はサーバ要素、weblogic.cluster.defaultLoadAlgorithm で指定されたアルゴリズムを使用します。

home-load-algorithm は以下のいずれかの値に定義できます。

詳細については、『クラスタの使用』の「EJB と RMI オブジェクトのロード バランシング」を参照してください。

例

「entity-clustering」および「stateful-session-clustering」を参照してください。

idempotent-methods

機能

同じメソッドを同じ引数で繰り返し呼び出したとしても、1 回呼び出したときとまったく同じ結果になるように記述される、クラスタ化された EJB のメソッドのリストを定義します。これにより、フェイルオーバ ハンドラは、失敗したサーバ上で実際に呼び出しがコンパイルされるかどうかを知らなくても、失敗した呼び出しを再試行できるようになります。あるメソッドに対し多重呼び出し不変メソッドを有効にした場合、EJB スタブは、EJB のホスト サーバに接続できるかぎり、あらゆる失敗から自動的に回復することができます。

EJB でクラスタリングが有効である必要があります。クラスタ化を有効にするには、「entity-clustering」、「stateful-session-clustering」、および「stateless-clustering」を参照してください。

ステートレス セッション Bean ホームおよび読み込み専用エンティティ Bean のメソッドは、自動的に多重呼び出し不変に設定されます。これらについては多重呼び出し不変を明示的に設定する必要はありません。

例

<idempotent-method>
	<method>
		<description>...</description>
		<ejb-name>...</ejb-name>
		<method-intf>...</method-intf>
		<method-name>...</method-name>
		<method-params>...</method-params>
	</method>
</idempotent-method>

identity-assertion

機能

EJB が ID アサーションをサポートするか、または、必要とするかを指定します。

例

「iiop-security-descriptor」を参照してください。

idle-timeout-seconds

機能

EJB がキャッシュに保持される最長時間を定義します。この時間を過ぎると、キャッシュ内の Bean の数が max-beans-in-cache で指定した値を超えている場合、WebLogic Server では Bean インスタンスが削除されます。削除された Bean インスタンスに対してはパッシベーションが行われます。詳細については、「ステートフル セッション EJB のキャッシュとパッシベーション」および「エンティティ Bean のプールとキャッシュの管理」を参照してください。

また、フリー プール内の EJB が削除されるまでの最長アイドル時間を定義します。この時間の経過後、WebLogic Server は Bean の数が initial-beans-in-free-pool の値を下回らない限り、その Bean をフリー プールから削除します。

例

次のエントリでは、max-beans-in-cache の値に達し、Bean がキャッシュに 20 分保持されている場合、ステートフル セッション EJB AccountBean が削除の対象になります。

<weblogic-enterprise-bean>
	<ejb-name>AccountBean</ejb-name>
	<stateful-session-descriptor>
		<stateful-session-cache>
			<max-beans-in-cache>200</max-beans-in-cache>
			<idle-timeout-seconds>1200</idle-timeout-seconds>
		</stateful-session-cache>
	</stateful-session-descriptor>
</weblogic-enterprise-bean>

iiop-security-descriptor

機能

Bean レベルのセキュリティ コンフィグレーション パラメータを指定します。これらのパラメータにより、IOR に含まれる IIOP セキュリティ情報が決定します。

例

<iiop-security-descriptor>
	<transport-requirements>...</transport-requirements>
	<client-authentication>supported<client-authentication>
	<identity-assertion>supported</identity-assertion>
</iiop-security-descriptor>

init-suspend-seconds

機能

EJB コンテナが JMS リソースの停止を検出したときに MDB の JMS 接続を中断する初期秒数を指定します。詳細については、「JMS リソース停止中のメッセージ配信の中断のコンフィグレーション」を参照してください。

initial-beans-in-free-pool

機能

initial-beans-in-free-pool の値を指定する場合は、プールの初期サイズを設定することになります。WebLogic Server は起動時に、Bean クラスごとに指定された数の Bean インスタンスをフリー プールに格納します。この方法で Bean インスタンスをフリー プールに格納しておくと、要求が来てから新しいインスタンスを生成せずに Bean に対する初期要求が可能になるため、EJB の初期応答時間が短縮されます。

例

「pool」を参照してください。

initial-context-factory

機能

JMS プロバイダが初期コンテキストの作成に使用する初期コンテキスト ファクトリを指定します。「送り先を考慮した MDB のコンフィグレーション」および「initial-context-factory の設定方法」を参照してください。

例

<message-driven-descriptor>
    <initial-context-factory>fiorano.jms.rtl.FioranoInitialContextFactory
    </initial-context-factory>
</message-driven-descriptor>

「message-destination-descriptor」を参照してください。

integrity

機能

EJB の転送の整合性の要件を指定します。integrity 要素を使用すると、クライアントとサーバ間で、データが途中で変化することなく転送されるようになります。

例

「transport-requirements」を参照してください。

invalidation-target

機能

コンテナ管理による永続性エンティティ EJB が変更された場合に、無効化する読み込み専用エンティティ EJB を指定します。

対象の ejb-name は読み込み専用エンティティ EJB でなければならないので、この要素は EJB 2.x のコンテナ管理による永続性エンティティ EJB に対してのみ指定できます。

例

<invalidation-target>
	<ejb-name>StockReaderEJB</ejb-name>
</invalidation-target>

is-modified-method-name

機能

EJB の保存時に WebLogic Server によって呼び出されるメソッドを指定します。指定したメソッドはブール値を返す必要があります。メソッドを指定しない場合、WebLogic Server では、EJB は常に変更されていると見なされて保存されます。

メソッドを指定して適切な値を設定すると、EJB 1.1 準拠の Bean、および Bean 管理の永続性を使用する Bean のパフォーマンスが向上します。ただし、メソッドの戻り値にエラーがあると、データに矛盾が発生する場合があります。

例

<entity-descriptor>
	<persistence>
	<is-modified-method-name>semidivine</is-modified-method-name>
	</persistence>
</entity-descriptor>

isolation-level

機能

EJB のメソッドレベルのトランザクション アイソレーション設定を定義します。有効な値は以下のとおりです。

Oracle のみのアイソレーション レベル

以下の追加の値は、Oracle データベース、およびコンテナ管理による永続性 (CMP) EJB でのみサポートされています。

異なるアイソレーション レベルのサポートの詳細については、各データベースのドキュメントを参照してください。

例

「transaction-isolation」を参照してください。

jms-client-id

機能

JMS 送り先に接続するときの MDB のクライアント ID を指定します。JMS トピックに対する恒久サブスクリプションで必須です。

connection-factory-jndi-name で MDB が使用する接続ファクトリを指定した場合、クライアント ID は config.xml 内の関連付けられている JMSConnectionFactory 要素の ClientID 要素で定義できます。

config.xml の JMSConnectionFactory で ClientID を指定しないか、デフォルト接続ファクトリを使用する (connection-factory-jndi-name を指定しない) 場合、メッセージ駆動型 Bean は jms-client-id 値をそのクライアント ID として使用します。

例

<jms-client-id>MyClientID</jms-client-id>

jms-polling-interval-seconds

機能

JMS 送り先に再接続しにいく間隔の秒数を指定します。各メッセージ駆動型 Bean は、関連付けられている JMS 送り先でリスンします。JMS 送り先が別の WebLogic Server インスタンスまたは外部 JMS プロバイダに配置されている場合には、JMS 送り先にアクセスできなくなることもあります。この場合、EJB コンテナは自動的に JMS サーバに再接続しようとします。JMS サーバが再び起動した時点で、メッセージ駆動型 Bean は再びメッセージを受信できるようになります。

例

<jms-polling-interval-seconds>5</jms-polling-interval-seconds>

jndi-name

機能

WebLogic Server で使用可能な実際の EJB、リソース、または参照の JNDI 名を指定します。

例

「resource-description」および「ejb-reference-description」を参照してください。

local-jndi-name

機能

Bean のローカル ホームの JNDI 名。Bean がリモート ホームとローカル ホームを持つ場合は、それぞれのホームに 1 つずつの JNDI 名を割り当てることもできます。

例

<local-jndi-name>weblogic.jndi.WLInitialContext
</local-jndi-name>

max-beans-in-cache

機能

メモリの許容範囲内で、このクラスのオブジェクトの最大数を指定します。max-bean-in-cache の値に達すると、WebLogic Server では、最近クライアントに使用されていない EJB の一部に対してパッシベーションが行われます。また、「ステートフル セッション EJB のキャッシュとパッシベーション」で説明されているように、max-beans-in-cache の値は、EJB を WebLogic Server のキャッシュからいつ削除するかにも影響を与えます。

例

<weblogic-enterprise-bean>
	<ejb-name>AccountBean</ejb-name>
	<entity-descriptor>
		<entity-cache>
			<max-beans-in-cache>200</max-beans-in-cache>
		</entity-cache>
	</entity-descriptor>
</weblogic-enterprise-bean>

max-beans-in-free-pool

機能

WebLogic Server は、すべてのエンティティ Bean、ステートレス セッション Bean、およびメッセージ駆動型 Bean クラスについて EJB のフリー プールを保持します。max-beans-in-free-pool 要素は、このフリー プールのサイズを定義します。

例

「pool」を参照してください。

max-messages-in-transaction

機能

MDB のトランザクションに入れることができるメッセージの最大数を指定します。

max-queries-in-cache

機能

WebLogic Server 9.0 で導入された要素です。Bean レベルでキャッシュできる読み込み専用エンティティ クエリの最大数を指定します。アプリケーション レベルでの読み込み専用エンティティ クエリのキャッシュについては、

max-suspend-seconds

機能

EJB コンテナが JMS リソースの停止を検出したときに MDB の JMS 接続を中断する最大秒数を指定します。EJB コンテナが JMS リソースの停止を検出したときに JMS 接続が中断しないようにするには、この要素の値を 0 に設定します。詳細については、「JMS リソース停止中のメッセージ配信の中断のコンフィグレーション」を参照してください。

message-destination-descriptor

機能

ejb-jar.xml ファイル内のメッセージ送り先の参照を、WebLogic Server の実際のメッセージ送り先 (JMS キュー、トピックなど) にマップします。

例

<message-destination-descriptor>
   <message-destination-name>...</message-destination-name>

   <destination-jndi-name>...</destination-jndi-name>

   <resource-link>...</resource-link>

   <initial-context-factory>...</initial-context-factory>

   <provider-url>...</provider-url>
</message-destination-descriptor>

message-destination-name

機能

メッセージ定義参照の名前を指定します。これは、EJB プロバイダによって ejb-jar.xml デプロイメント記述子ファイル内に記載される参照です。

例

「message-destination-descriptor」を参照してください。

message-driven-descriptor

機能

メッセージ駆動型 Bean を WebLogic Server の JMS 送り先に関連付けます。

例

<message-driven-descriptor>
   <pool>...</pool>
   <timer-descriptor>...</timer-descriptor>
   <destination-jndi-name>...</destination-jndi-name>
   <initial-context-factory>...</initial-context-factory>
   <provider-url>...</provider-url>
   <connection-factory-jndi-name>...</connection-factory-jndi-name>
   <jms-polling-interval-seconds>...</jms-polling-interval-seconds>
   <jms-client-id>...</jms-client-id>
   <generate-unique-jms-client-id>...</generate-unique-jms-client-id>
   <durable-subscription-deletion>...</durable-subscription-deletion>
   <max-messages-in-transaction>...</max-messages-in-transaction>
   <distributed-destination-connection>...</distributed-destination-connection>
   <use81-style-polling>...</use81-style-polling>
   <init-suspend-seconds>...</init-suspend-seconds>
   <max-suspend-seconds>...</max-suspend-seconds>
</message-driven-descriptor>

method

機能

エンタープライズ Bean のホームまたはリモート インタフェースのメソッドあるいはメソッドのセットを定義します。

例

<method>
	<description>...</description>
	<ejb-name>...</ejb-name>
	<method-intf>...</method-intf>
	<method-name>...</method-name>
	<method-params>...</method-params>
</method>

method-intf

機能

WebLogic Server がアイソレーション レベルのプロパティを適用する EJB のインスタンスを指定します (メソッドが複数のインタフェースで同じシグネチャを持つ場合)。

例

「method」を参照してください。

method-name

機能

WebLogic Server がアイソレーション レベルのプロパティを適用する個々の EJB メソッドの名前を指定します。アスタリスク (*) を使用すると EJB のホームおよびリモート インタフェースの全メソッドを指定できます。

method-name を指定する場合、そのメソッドは指定の ejb-name になければなりません。

例

「method」を参照してください。

method-param

機能

メソッド パラメータの完全修飾 Java タイプ名を指定します。

例

「method-params」を参照してください。

method-params

機能

各メソッド パラメータの Java タイプ名を定義する 1 つまたは複数の要素があります。

例

method-params 要素には、次のように 1 つまたは複数の method-param 要素が含まれます。

<method-params>
	<method-param>java.lang.String</method-param>
	...
</method-params>

network-access-point

機能

EJB でネットワーク通信に使用されるカスタム ネットワークを割り当てます。ネットワーク チャネルによって、一連の接続属性が定義されます。詳細については、『サーバ環境のコンフィグレーション』の「ネットワーク リソースのコンフィグレーション」を参照してください。

例

<weblogic-enterprise-bean>
     <network-access-point>SSLChannel</network-access-point>
</weblogic-enterprise-bean>

passivate-as-principal-name

機能

WebLogic Server 8.1 SP01 で導入された passivate-as-principal-name 要素は、本来は ejbPassivate が匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。

passivate-as-principal-name が設定されている場合
そのプリンシパルを使用します。
あるいは
     ejb-jar.xml で Bean に対して run-as ロールが指定されている場合
     run-as-role-assignment を設定するためのルールに従ってプリンシパルを使用します。
     あるいは
           ejbPassivate を匿名プリンシパルとして実行します。

passivate-as-principal-name 要素は、ejbPassivate 内の処理が匿名プリンシパルよりも高レベルのパーミッションを必要とする場合にのみ指定する必要があります。

この要素は、キャッシュのタイムアウトでパッシベーションが行われたときにステートレス セッション Bean の ejbPassivate メソッドに影響します。

「remove-as-principal-name」、「create-as-principal-name」、および「principal-name」も参照してください。

persistence

機能

コンテナ管理の永続性サービスを使用するエンティティ EJB でのみ必須です。persistence 要素は、WebLogic Server のエンティティ EJB に対する永続性タイプ、トランザクション コミット動作、ejbLoad() 動作、および ejbStore() 動作を決定するプロパティを定義します。

例

<entity-descriptor>
   <persistence>
      <is-modified-method-name>...</is-modified-method-name>
      <delay-updates-until-end-of-tx>...</delay-updates-until-end-of-tx>
      <finders-load-beand>...</finders-load-bean>
      <persistence-use>...</persistence-use>
   </persistence>
</entity-descriptor>

persistence-use

機能

コンテナ管理の永続性サービスを使用するエンティティ EJB でのみ必須です。persistence-use 要素は、この特定の Bean に使用する永続性タイプの識別子を格納します。

例

<persistence-use>
	<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
	<type-version>5.1.0</type-version>
	<type-storage>META-INF/weblogic-cmp-jar.xml</type-storage>
</persistence-use>

persistent-store-dir

機能

パッシベーションされたステートフル セッション Bean インスタンスの状態を WebLogic Server が格納するファイル システム ディレクトリを指定します。詳細については、「パッシベーションされた Bean の永続ストア ディレクトリの指定」を参照してください。

例

<stateful-session-descriptor>
   <stateful-session-cache>...</stateful-session-cache>
   <allow-concurrent-calls>...</allow-concurrent-calls>
   <persistent-store-dir>MyPersistenceDir</persistent-store-dir>
   <stateful-session-clustering>...</stateful-session-clustering>
   <allow-remove-during-transaction>
</stateful-session-descriptor>

persistent-store-logical-name

機能

WebLogic Server がタイマー オブジェクトを格納する、サーバのファイル システム上の永続ストアの名前を指定します。この要素で永続ストアの名前を指定しない場合、タイマー オブジェクトはデフォルト ストアに格納されます。

pool

機能

エンティティ EJB、ステートレス セッション EJB、およびメッセージ駆動型 EJB の WebLogic Server フリー プールの動作をコンフィグレーションします。オプションは以下のとおりです。

例

<stateless-session-descriptor>
	<pool>
		<max-beans-in-free-pool>500</max-beans-in-free-pool>
		<initial-beans-in-free-pool>250</initial-beans-in-free-pool>
	</pool>
</stateless-session-descriptor>

principal-name

機能

指定した role-name に適用される実際の WebLogic Server プリンシパルの名前を指定します。security-role-assignment 要素に少なくとも 1 つの principal-name が必要です。各 role-name に対して複数の principal-name を定義することもできます。

例

「security-role-assignment」を参照してください。

provider-url

機能

InitialContext で使用される URL を指定します。「送り先を考慮した MDB のコンフィグレーション」および「provider-url の設定方法」を参照してください。

例

<message-driven-descriptor>
     <provider-url>WeblogicURL:Port</provider-url>
</message-driven-descriptor>

「message-destination-descriptor」を参照してください。

read-timeout-seconds

機能

Read-Only エンティティ Bean で ejbLoad を呼び出す間隔の秒数を指定します。値を 0 にすると、WebLogic Server は Bean がキャッシュに送られたときだけ ejbLoad() を呼び出します。

例

次の例では、インスタンスが最初にキャッシュされた場合にのみ WebLogic Server が AccountBean クラスのインスタンスに対して ejbLoad() を呼び出します。

<weblogic-enterprise-bean>
	<ejb-name>AccountBean</ejb-name>
	<entity-descriptor>
		<entity-cache>
			<read-timeout-seconds>0</read-timeout-seconds>
		</entity-cache>
	</entity-descriptor>
</weblogic-enterprise-bean>

remote-client-timeout

機能

リモート RMI クライアントがタイムアウトするまでの待機時間を指定します。『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI の機能」の「RMI タイムアウトの使用」を参照してください。

例

以下のエントリの場合、リモート RMI クライアントは 5 秒待機してからタイムアウトします。

<weblogic-enterprise-bean>
	<ejb-name>AccountBean</ejb-name>
	...
	<remote-client-timeout>5</remote-client-timeout>
</weblogic-enterprise-bean>

remove-as-principal-name

機能

このパラメータは、ejbRemove 内の処理が匿名プリンシパル以上のパーミッションを必要とする場合にのみ指定する必要があります。

WebLogic Server 8.1 SP1 で導入された remove-as-principal-name 要素は、本来は ejbRemove が匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。

remove-as-principal-name が設定されている場合
そのプリンシパルを使用します。
あるいは
     ejb-jar.xml で Bean に対して run-as ロールが指定されている場合
     run-as-role-assignment を設定するためのルールに従ってプリンシパルを使用します。
     あるいは
           ejbRemove を匿名プリンシパルとして実行します。

remove-as-principal-name 要素は、ejbRemove 内の処理が匿名プリンシパルよりも高レベルのパーミッションを必要とする場合にのみ指定する必要があります。

この要素は、ステートレス セッション Bean とメッセージ駆動型 Bean の ejbRemove メソッドに影響します。

「passivate-as-principal-name」、「create-as-principal-name」、および「principal-name」も参照してください。

replication-type

機能

クラスタ内の WebLogic Server インスタンスのステートフル セッション EJB の状態を WebLogic Server がレプリケートするかどうかを指定します。InMemory を指定した場合、EJB の状態はレプリケートされます。None を指定した場合、状態はレプリケートされません。

例

「stateful-session-clustering」を参照してください。

res-env-ref-name

機能

リソース環境参照名を指定します。

例

「resource-description」を参照してください。

res-ref-name

機能

resourcefactory 参照の名前を指定します。これは、EJB プロバイダによって ejb-jar.xml デプロイメント記述子ファイル内に記載される参照です。EJB が ejb-jar.xml のリソース参照を指定する場合にのみ必須になります。

例

「resource-description」を参照してください。

resource-adapter-jndi-name

機能

この MDB がメッセージを受け取るリソース アダプタを指定します。

resource-description

機能

ejb-jar.xml に定義されているリソース参照を WebLogic Server 内に用意されている実際のリソースの JNDI 名にマップします。

例

<resource-description>
	<res-ref-name>. . .</res-ref-name>
	<jndi-name>...</jndi-name>
</resource-description>
<ejb-reference-description>
	<ejb-ref-name>. . .</ejb-ref-name>
	<jndi-name>. . .</jndi-name>
</ejb-reference-description>

resource-env-description

機能

ejb-jar.xml に定義されているリソース環境参照を WebLogic Server 内に用意されている実際のリソースの JNDI 名にマップします。

例

<resource-env-description>
	<res-env-ref-name>. . .</res-env-ref-name>
	<jndi-name>...</jndi-name>
</reference-env-description>

jndi-name が有効な URL でない場合、WebLogic Server はそれを URL に対応し、すでに JNDI ツリーにバインドされているオブジェクトとして取り扱い、LinkRef とその jndi-name をバインドします。

resource-link

機能

ejb-jar.xml に定義されている JMS モジュール内のリソースを WebLogic Server の実際の JMS モジュール参照にマップします。

例

「message-destination-descriptor」を参照してください。

retry-count

機能

EJB コンテナが、ロールバックされたコンテナ管理によるトランザクション メソッドを自動的に再試行する回数を指定します。

retry-methods-on-rollback

機能

ここで指定したメソッドに対して、EJB コンテナはロールバックされたコンテナ管理によるトランザクションを自動的に再試行します。自動的なトランザクションの再試行は、コンテナ管理のトランザクションの境界設定を使用するセッション Bean およびエンティティ Bean について、サポートされています。また、この要素で指定されたメソッドに関わらず、EJB コンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。

role-name

機能

EJB プロバイダが ejb-jar.xml デプロイメント記述子に指定したアプリケーションのロール名を示します。要素の次の principal-name 要素で、WebLogic Server プリンシパルを、指定した role-name にマップします。

例

「security-role-assignment」を参照してください。

run-as-identity-principal

機能

run-as-identity-principal 要素は、ejb-jar.xml デプロイメント記述子で、セキュリティ ID run-as-role-name を指定した Bean の run-as プリンシパルとして使用されるセキュリティ プリンシパル名を指定します。

run-as role-name の run-as-identity-principal または run-as-principal-name へのマッピングがどのようにして生じるかの説明は、run-as-role-assignment 要素のコメントを参照してください。

例

<run-as-identity-principal>
     Fred
</run-as-identity-principal>

run-as-principal-name

機能

ejb-jar.xml デプロイメント記述子で、security-identity run-as role-name を指定した Bean の run-as プリンシパルとして使用されるセキュリティ プリンシパル名を指定します。

run-as role-name の run-as-principal-name へのマッピングがどのようにして生じるかの説明は、run-as-role-assignment 要素のコメントを参照してください。

例

<run-as-principal-name>
     Fred
</run-as-principal-name>

run-as-role-assignment

機能

ejb-jar.xml デプロイメント記述子ファイルで指定された security-identity run-as role-name を run-as-principal-name にマップします。

ここで指定した特定の role-name に対する run-as-principal-name の値は、ejb-jar.xml デプロイメント記述子内のすべての Bean を対象とし、role-name を security-identitiy run-as-role-name として指定したすべての Bean に適用されます。

ここで指定した run-as-principal-name 値は、その Bean の weblogic-enterprise-bean 要素の下で run-as-principal-name を指定することによって、個々の Bean レベルでオーバーライドできます。

例

ejb-jar.xml デプロイメント記述子ファイルが、次のような状況であると仮定します。

対応するデプロイメント記述子ファイル weblogic-ejb-jar.xml から抜粋した次のコードを検討してください。

<weblogic-ejb-jar>
     <weblogic-enterprise-bean>
          <ejb-name>
               A_EJB_with_runAs_role_x
          </ejb-name>
     </weblogic-enterprise-bean>

     <weblogic-enterprise-bean>
          <ejb-name>
               B_EJB_with_runAs_role_X
          </ejb-name>
          <run-as-principal-name>
               Joe 
          </run-as-principal-name>
     </weblogic-enterprise-bean>

     <weblogic-enterprise-bean>
          <ejb-name>
               C_EJB_with_runAs_role_Y
          </ejb-name>
     </weblogic-enterprise-bean>

     <security-role-assignment>
          <role-name>
               runAs_role_Y
          </role-name>
          <principal-name>
               first_principal_of_role_Y
          </principal-name>
          <principal-name>
               second_principal_of_role_Y
          </principal-name>
     </security-role-assignment>

     <run-as-role-assignment>
          <role-name> 
               runAs_role_X 
          </role-name>
          <run-as-principal-name>
               Fred
          </run-as-principal-name>
     </run-as-role-assignment>
</weblogic-ejb-jar>

各 Bean は、その run-as-principal-name として異なるプリンシパル名を選択します。

A_EJB_with_runAs_role_X

この Bean の run-as-role-name は「runAs_role_X」です。使用するプリンシパルの名前のルックアップには、jar スコープの <run-as-role-assignment> マッピングが使用されます。

<run-as-role-assignment> マッピングにより、<role-name>「runAs_role_X」に対して、<run-as-principal-name>「Fred」を使用すべきであることが指定されます。

「Fred」が、使用されるプリンシパル名です。

B_EJB_with_runAs_role_X

この Bean の run-as-role-name も「runAs_role_X」です。この Bean は使用するプリンシパルの名前のルックアップに jar スコープの <run-as-role-assignment> を使用することはありません。なぜなら、この値はこの Bean の <weblogic-enterprise-bean> <run-as-principal-name> 値である「Joe」でオーバーライドされているからです。

「Joe」が、使用されるプリンシパル名です。

C_EJB_with_runAs_role_Y

この Bean の run-as-role-name は「runAs_role_Y」です。「runAs_role_Y」の run-as プリンシパル名としての明示的なマッピングはありません。つまり、「runAs_role_Y」に対する jar スコープの <run-as-role-assignment> も、Bean スコープの <run-as-principal-name> も、この Bean の weblogic-enterprise-bean では指定されていません。

使用するプリンシパル名を決定するには、<role-name>「runAs_role_Y」の <security-role-assignment> を検証します。ユーザ (つまり、グループではない) に対応する最初の <principal-name> が選択されます。

「first_principal_of_role_Y」が、使用されるプリンシパル名です。

security-permission

機能

J2EE Sandbox と関連するセキュリティ パーミッションを指定します。

詳細については、Sun によるセキュリティ パーミッション仕様の実装を参照してください。

http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax

例

<security-permission>
     <description>任意指定の説明がここに入る</description>
     <security-permission-spec>
          ...
     </security-permission-spec>
</security-permission> 

security-permission-spec

機能

セキュリティ ポリシー ファイル構文に基づいて単一のセキュリティ パーミッションを指定します。

詳細については、Sun によるセキュリティ パーミッション仕様の実装を参照してください。

http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax

例

「java.vm.version」に「read」パーミッションを与え、それが上書きされるのを防止するには、次の手順に従います。

security-role-assignment

機能

ejb-jar.xml ファイルのアプリケーション ロールを WebLogic Server のセキュリティ プリンシパルの名前にマップします。

例

<security-role-assignment>
	<role-name>PayrollAdmin</role-name>
	<principal-name>Tanya</principal-name>
	<principal-name>system</principal-name>
	<externally-defined>True</externally-defined>
	...
</security-role-assignment>

service-reference-description

機能

ejb-jar.xml 内の Web サービス送り先の参照を、WebLogic Server の実際の Web サービスにマップします。

例

<service-reference-description>
    <service-ref-name>service/WebServiceBroker</service-ref-name>

    <wsdl-url>http://@PROXY_SERVER@/webservice/
          BrokerServiceBean?wsdl</wsdl-url>

    <call-property>...</call-property>

    <port-info>
       <port-name>BrokerServiceIntfPort</port-name>
      <stub-property>
       <name>javax.xml.rpc.service.endpoint.address</name>
        <value>http://@PROXY_SERVER@/webservice/BrokerServiceBean<;/value>
      </stub-property>

    </port-info>
</service-reference-description>

session-timeout-seconds

機能

EJB コンテナがパッシベーションされたステートフル セッション Bean をどのくらいディスクに置いておくのかを指定します。コンテナは、Bean インスタンスをディスクにパッシベーションした後にパッシベーションされた EJB の session-timeout-seconds を削除します。session-timeout-seconds を指定しない場合、デフォルトは idle-timeout-seconds で指定された値です。

例

<stateful-session-descriptor>
     <stateful-session-cache>
          <max-beans-in-cache>4</max-beans-in-cache>           <idle-timeout-seconds>5</idle-timeout-seconds>           <session-timeout-seconds>120</session-timeout-seconds>
          <cache-type>LRU</cache-type>
     </stateful-session-cache>
</stateful-session-descriptor>

stateful-session-cache