<!--
This is the DTD for the EJB deployment parameters that are specific to the
WebLogic Server in WebLogic 8.1.0.
Overview of changes since weblogic-510-ejb-jar.dtd:
* Reorganized information into descriptors for each type of bean
* Moved transaction-isolation to weblogic-ejb-jar element
* Removed weblogic-version element
* Added elements relating to message driven beans
* Added new elements for caching of stateful beans
* Stylistic changes to be more consistent with EJB 2.0 ejb-jar.dtd style
Copyright (c) 2001-2002 by BEA Systems, Inc. All Rights Reserved.
-->
<!--
The cache-between-transactions element tells the EJB container whether
to cache the persistent data of an entity bean across (between)
transactions.
When a value of 'true' is specified caching between transactions is
enabled and long term caching of data is performed. If a value of
'false' is specified, (the default) short term caching is done, which
means that data is only cached during an individual transaction. A
value of 'true' is only allowed if the concurrency-strategy for a bean
is either Exclusive, ReadOnly, or Optimistic.
A ReadOnly bean simply ignores the value of the
cache-between-transactions element since long term caching of readonly
data is always performed.
When long term caching is enabled for Exclusive concurrency, the EJB
container must have exclusive update access to the underlying data,
i.e. the data must not be updated by another application outside of
the EJB container. If an Exclusive bean is deployed in a cluster, long
term caching is disabled automatically because any node in the cluster
may update the data, making long term caching impossible. (Note: In
releases prior to WLS 7.0, this feature was controlled using the
db-is-shared element.)
When long term caching is enabled for Optimistic concurrency, the EJB
container reuses cached values from previous transactions, but ensures
that updates are transactionally consistent by checking for optimistic
conflicts at the end of the transaction. In addition, notifications
for updates of optimistic data are broadcast to other cluster members
to help avoid optimistic conflicts.
Used in: entity-cache, entity-cache-ref
Default value: false
Since: WLS 7.0
Example:
<cache-between-transactions>true</cache-between-transactions>
-->
<!ELEMENT cache-between-transactions (#PCDATA)>
<!--
The concurrency-strategy specifies how the container should manage concurrent
access to an entity bean.
The concurrent-strategy can be one of the following values:
- "Exclusive": The exclusive locking scheme used in WebLogic
Server versions 3.1 through 5.1
- "Database": A scheme where a separate Entity Bean instance is
allocated for each transaction and the locking and
caching is handled by the database.
- "ReadOnly" : For read-only entity beans
- "Optimistic" : When using optimistic concurrency, no locks are
held in the EJB container or database during a
transaction. The EJB container verifies that none
of the data that was updated by a transaction has
changed before committing the transaction. If any
updated data has been changed, the transaction is
rolled back.
Used in: entity-cache
Default value: Database
-->
<!ELEMENT concurrency-strategy (#PCDATA)>
<!--
This parameter specifies the JNDI name of the JMS ConnectionFactory
that the MessageDriven Bean should look up to create its Queues and Topics.
If not specified, it will default to weblogic.jms.MessageDrivenBeanConnectionFactory,
which must have been declared in config.xml.
Used in: message-driven-descriptor
-->
<!ELEMENT connection-factory-jndi-name (#PCDATA)>
<!--
This parameter is used to specify the principal to be used in
those cases in which ejbCreate would otherwise run with an anonymous principal.
Under such conditions, the choice of which principal to run as is governed
by the following rule:
if create-as-principal-name is set
then use that principal
else
if a run-as role has been specified for the bean
then use a principal according to the rules for setting the run-as-role-assignment
else
run ejbCreate as an anonymous principal
This parameter only needs to be specified if operations within ejbCreate need
more permissions than the anonymous principal would have.
This element has an effect on the ejbCreate methods of:
StatelessSessionBeans
MessageDrivenBeans
Since: WebLogic Server 8.1SP01
Used in: weblogic-enterprise-bean
-->
<!ELEMENT create-as-principal-name (#PCDATA)>
<!--
The disable-warning element allows you to specify particular EJB deployment
warnings that you would like to disable. The following warning message
numbers, along with a summary of the warning are supported:
BEA-010001: EJB class loaded from system classpath during deployment.
BEA-010054: EJB class loaded from system classpath during compilation.
BEA-010202: Call-by-reference not enabled.
To get more information about the particular warning, use the
weblogic.GetMessage tool. For example:
java weblogic.GetMessage -detail -id BEA-010202
example:
<disable-warning>BEA-010054</disable-warning>
Since: WebLogic Server 8.1
Used in: weblogic-ejb-jar
-->
<!ELEMENT disable-warning (#PCDATA)>
<!--
Each Message-Driven EJB listens on an associated JMS destination. If
the JMS destination is located on another WebLogic Server instance or
a foreign JMS provider, it is possible that the JMS destination will
become unreachable. In this case, the EJB container automatically
attempts to reconnect to the JMS Server. Once the JMS Server is up
again, the Message-Driven EJB can again receive JMS messages.
The jms-polling-interval-seconds determines the number of seconds
between each attempt to reconnect to the JMS destination.
Default value: 10 seconds
Example:
<jms-polling-interval-seconds>5</jms-polling-interval-seconds>
Since: WebLogic Server 6.1
-->
<!ELEMENT jms-polling-interval-seconds (#PCDATA)>
<!--
The JMS specification allows JMS consumers to specify an associated
id. This id is necessary for durable subscriptions to
JMS topics.
A Message-Driven EJB with a durable subscription needs an associated
client id. If a separate connection factory is used, the
client id can be set on the connection factory. In this case,
the Message-Driven EJB uses this client id.
If the associated connection factory does not have a client id
(or you are using the default connection factory), the Message-Driven
EJB uses the jms-client-id value as its client id.
Default:
The default client identifier is the ejb-name for this EJB.
Example:
<jms-client-id>MyClientID</jms-client-id>
Since: WebLogic Server 6.1
-->
<!ELEMENT jms-client-id (#PCDATA)>
<!--
Applicable to entity beans only (both container- and bean-managed).
This optional optimization affects when changes to a bean's state
propogated to the persistent store. If this is set to "True" (which is
the default) updates of the persistent store of all beans in the
transaction will be performed just before the end of the transaction.
If this is set to "False" the pstore update of a bean will be
performed at the conclusion of each method invoke.
Used in: persistence
Default value: True
-->
<!ELEMENT delay-updates-until-end-of-tx (#PCDATA)>
<!--
The description element is used to provide text describing the parent element.
Used in: weblogic-ejb-jar, method
-->
<!ELEMENT description (#PCDATA)>
<!--
The destination-jndi-name element is used to associate a message-driven bean
with a JMS Queue or Topic that has been deployed in the WebLogic JNDI tree.
Used in: message-driven-descriptor
-->
<!ELEMENT destination-jndi-name (#PCDATA)>
<!--
This specifies a thread pool dispatch policy queue for a bean, including
message driven beans.
Used in: weblogic-enterprise-bean
-->
<!ELEMENT dispatch-policy (#PCDATA)>
<!--
The ejb-name element specifies an enterprise bean's name. This name is
assigned by the ejb-jar file producer to name the enterprise bean in
the ejb-jar file's deployment descriptor. The name must be unique
among the names of the enterprise beans in the same ejb-jar file. The
enterprise bean code does not depend on the name; therefore the name
can be changed during the application-assembly process without
breaking the enterprise bean's function. There is no architected
relationship between the ejb-name in the deployment descriptor and the
JNDI name that the Deployer will assign to the enterprise bean's home.
The name must conform to the lexical rules for an NMTOKEN.
Used in: weblogic-enterprise-bean, method
Example:
<ejb-name>EmployeeService</ejb-name>
-->
<!ELEMENT ejb-name (#PCDATA)>
<!--
The ejb-ref-name element contains the name of an EJB reference. The
EJB reference is an entry in the enterprise bean's environment.
Used in: ejb-reference-description, ejb-local-reference-description
Example:
<ejb-ref-name>ejb/EmplRecords</ejb-ref-name>
-->
<!ELEMENT ejb-ref-name (#PCDATA)>
<!--
The ejb-reference-description is used to map the JNDI name in the WebLogic
server of an EJB that is referenced by the bean in an ejb-reference.
Used in: reference-descriptor
Example:
<ejb-reference-description>
<ejb-ref-name>
AdminBean
</ejb-ref-name>
<jndi-name>
payroll.AdminBean
</jndi-name>
</ejb-reference-description>
-->
<!ELEMENT ejb-reference-description (ejb-ref-name, jndi-name)>
<!--
The ejb-local-reference-description is used to map the JNDI name in the
WebLogic server of an EJB that is referenced by the bean in an ejb-local-ref.
Used in: reference-descriptor
Since: WLS 6.1
Example:
<ejb-local-reference-description>
<ejb-ref-name>
LocalAdminBean
</ejb-ref-name>
<jndi-name>
local.payroll.AdminBean
</jndi-name>
</ejb-local-reference-description>
-->
<!ELEMENT ejb-local-reference-description (ejb-ref-name, jndi-name)>
<!--
By default, the EJB implementation class is loaded in the same
classloader as the rest of the EJB classes. When the
enable-bean-class-redeploy element is enabled, the implementation
class, along with its super classes, gets loaded in a child
classloader of the EJB module classloader. This allows the EJB
implementation class to be redeployed without redeploying the
entire EJB module. There are some potential problems with loading
the bean class in a child classloader. First, the bean class will
no longer be visible to any classes loaded in the parent
classloader, so those classes cannot refer to the bean class or
errors will occur. Also, the bean class will not be able to invoke
any package protected methods on any classes loaded in a different
classloader. So, if your bean class invokes a helper class in the
same package, the helper class methods must be declared public or
IllegalAccessErrors will result.
Note that two-phase deployment must be used for this feature to
be enabled. The enable-bean-class-redeploy setting will be
ignored if two-phase deployment is not used.
The value of enable-bean-class-redeploy must be "True" or "False".
Used in: weblogic-ejb-jar
Default value: False
Since: WLS 8.1
-->
<!ELEMENT enable-bean-class-redeploy (#PCDATA)>
<!--
Pass by value is always necessary when the EJB is called remotely (not
from within the server). By setting enable-call-by-reference to
"True", EJB methods called from within the same ear file or standalone
jar file will pass arguments by reference. This increases the
performance of method invocation since parameters are not copied.
The value of enable-call-by-reference must be "True" or "False".
Used in: weblogic-enterprise-bean
Default value: False
Note: Default value inverted to 'False' Since: WLS 8.1
-->
<!ELEMENT enable-call-by-reference (#PCDATA)>
<!--
This optional element must be present for Dynamic Queries to be
enabled for the EJB. Dynamic Queries are only available for
EJB 2.0 CMP beans.
The value of enable-dynamic-queries must be "True" or "False".
Used in: entity-descriptor
Default value: False
-->
<!ELEMENT enable-dynamic-queries (#PCDATA)>
<!--
The entity-cache element is used to specify various options for the
caching of an entity bean. It is used to configure a cache that
contains instances of a single entity bean deployment.
Used in: entity-descriptor
-->
<!ELEMENT entity-cache
(max-beans-in-cache?,
idle-timeout-seconds?,
read-timeout-seconds?,
concurrency-strategy?,
cache-between-transactions?)
>
<!--
The entity-cache-ref element is used to refer to an application level
entity cache, which can cache instances of multiple entity beans that
are part of the same application. Application level entity caches are
declared in the weblogic-application.xml descriptor.
The entity-cache-name element must contain the name of the application
level cache.
The concurrency-strategy element defines the type of concurrency used by
the bean. The concurrency-strategy must be compatible with the application
level cache's caching strategy. For example, an 'Exclusive' cache only
supports beans with a concurrency-strategy of Exclusive. While, a
'MultiVersion' cache supports the Database, ReadOnly, and Optimistic
concurrency strategies.
Used in: entity-descriptor
Since: WLS 7.0
Example:
<entity-cache-ref>
<entity-cache-name>AllEntityCache</entity-cache-name>
<concurrency-strategy>ReadOnly</concurrency-strategy>
<estimated-bean-size>20</estimated-bean-size>
</entity-cache-ref>
-->
<!ELEMENT entity-cache-ref (entity-cache-name,
read-timeout-seconds?,
concurrency-strategy,
cache-between-transactions?,
estimated-bean-size?)>
<!--
The entity-cache-name element is used to name the application level
entity cache that an entity bean uses. An application level entity
cache is a cache that may be shared by multiple entity beans in the
same application. Application level entity caches are declared in the
weblogic-application.xml deployment descriptor.
The value specified for the entity-cache-name element must match the
name given to an application level entity cache in the
weblogic-application.xml descriptor.
Used in: entity-cache-ref
Since: WLS 7.0
Example:
<entity-cache-name>AllEntityCache</entity-cache-name>
-->
<!ELEMENT entity-cache-name (#PCDATA)>
<!--
The estimated-bean-size element is used to specify the estimated
average size of the instances of an entity bean in bytes. This is the
average number of bytes of memory that is consumed by each instance.
The estimated-bean-size is used when the size of the application level
cache that is being used to cache the beans is also specified in terms
of bytes or megabytes. The estimated-bean-size limits the maximum
number of instances that may exist in the cache at any one time.
Although an application deployer/developer probably does not know the
exact number of bytes that will be consumed by the instances of an
entity bean, specifying a size allows him/her to give some relative
weight to the beans that are sharing a cache. For example, suppose
that beans A and B share a cache 'AB-cache' that has a size of 1000
bytes. And suppose that the size of A is 10 and that the size of B is
20 bytes. Then the cache can hold at most 100 instances of A or 50
instances of B at any one time (100*10 = 50*20 = 1000). If 100
instances of A are cached, this implies that 0 instances of B are
cached.
Used in: entity-cache-ref
Since: WLS7.0
Example:
<estimated-bean-size>20</estimated-bean-size>
-->
<!ELEMENT estimated-bean-size (#PCDATA)>
<!--
The entity-clustering element is used to specify various options for
how an entity bean will be invoked in a WebLogic cluster. Setting
home-is-clusterable to "True" enables clustering for both the home and
remote stubs of the Entity bean.
Note that clustered, remote stubs are 'pinned' to the server where
they are created, so the load algorithm and router class only apply
to home stubs. Invocations on a clustered remote stub will be directed
to the originating server unless there is a failure in which case they
will fail over to another node in the cluster, or their affinity for
the originating server is overridden by the local transaction
optimization.
Used in: entity-descriptor
-->
<!ELEMENT entity-clustering (
home-is-clusterable?,
home-load-algorithm?,
home-call-router-class-name?,
use-serverside-stubs?)
>
<!--
The entity-descriptor element is used to specify deployment parameters
that are applicable to an entity bean.
Used in: weblogic-enterprise-bean
-->
<!ELEMENT entity-descriptor (
pool?,
(entity-cache | entity-cache-ref)?,
persistence?,
entity-clustering?,
invalidation-target?,
enable-dynamic-queries?)
>
<!--
Applicable to CMP entity beans only. This optional optimization
affects whether the beans returned by a finder (or ejbSelect method) are
loaded immediately into the cache before the finder method returns.
If this is set to "True", the beans will immediately be loaded into
the cache by the finder. If this is set to "False", the beans will not
be loaded into the cache until the first invoke of the bean.
The default value is "True", which generally provides the best performance.
Used in: persistence
-->
<!ELEMENT finders-load-bean (#PCDATA)>
<!--
The home-call-router-class-name specifies a custom class to be used for
routing home method calls. This class must implement
weblogic.rmi.cluster.CallRouter. If specified, an instance of
this class will be called before each method call and be given the
opportunity to choose a server to route to based on the method
parameters. It either returns a server name or null indicating
that the current load algorithm should be used to pick the server.
Used in: stateful-session-clustering, entity-clustering, stateless-clustering
-->
<!ELEMENT home-call-router-class-name (#PCDATA)>
<!--
The valid values of the home-is-clusterable parameter are
"True" or "False."
If "True," this bean can be deployed from multiple servers
in a cluster. Calls to the home stub will be load-balanced
between the servers on which this bean is deployed, and if
a server hosting the bean is unreachable, the call will
automatically failover to another server hosting the bean.
Used in: stateless-clustering,
stateful-session-clustering,
entity-clustering
Default: true
-->
<!ELEMENT home-is-clusterable (#PCDATA)>
<!--
The home-load-algorithm specifies the algorithm to use for load-balancing
between replicas of this home. If this property is not specified, the
algorithm specified by the server property
weblogic.cluster.defaultLoadAlgorithm will be used.
The value of this element must be one of the following:
RoundRobin
Random
WeightBased
RoundRobinAffinity
RandomAffinity
WeightBasedAffinity
Used in: stateful-session-clustering, entity-clustering
-->
<!ELEMENT home-load-algorithm (#PCDATA)>
<!--
The idempotent-methods element contains a list of methods which are written
such that repeated calls to the same method with the same arguments has
exactly the same effect as a single call. This allows the failover handler
to retry a failed call without knowing whether the call actually completed
on the failed server. Enabling this for a method makes it possible for the
bean stub to automatically recover from any failure as long as another server
hosting the bean can be reached.
Note: Idempotent method settings are only used if clustering is enabled for
the EJB. To enable clustering for your EJB, see the entity-clustering,
stateless-clustering and stateful-session-clustering elements in this DTD.
Also, the methods on stateless session bean home and read-only entity bean
component interfaces are automatically set to be idempotent so it isn't
necessary to explicitly set mark them as such.
Since: WebLogic Server 7.0
Used in: weblogic-ejb-jar
-->
<!ELEMENT idempotent-methods (method*)>
<!--
The cache (see "max-beans-in-cache" above) is scrubbed of
inactive objects after at least this many seconds. Objects
scrubbed are passivated.
Used in: cache
Default value: 600
-->
<!ELEMENT idle-timeout-seconds (#PCDATA)>
<!--
The stateful session beans that are passivated to the disk
will stay alive for this many seconds. After this interval,
the passivated beans will be removed from the disk.
Used in: cache
Since: WebLogic Server 7.0 sp3
Default value: 600
-->
<!ELEMENT session-timeout-seconds (#PCDATA)>
<!--
The cache-type can be one of "NRU" or "LRU".
Used in: stateful-session-cache
Default value: NRU.
Since: WLS 6.1
-->
<!ELEMENT cache-type (#PCDATA)>
<!--
WebLogic EJB maintains a free pool of beans for every bean class.
This property decides the initial size of the pool.
Used in: pool
Default value: 0
-->
<!ELEMENT initial-beans-in-free-pool (#PCDATA)>
<!--
This element specifies the initial ContextFactory that the container will
use to create its connection factories. If not specified, it will default
to weblogic.jndi.WLInitialContextFactory.
For example, to use Fiorano as a JMS provider:
<message-driven-descriptor>
...
<initial-context-factory>fiorano.jms.rtl.FioranoInitialContextFactory</initial-context-factory>
<connection-factory-jndi-name>java:comp/env/jms/MyConnectionFactory</connection-factory-jndi-name>
Used in: message-driven-descriptor
-->
<!ELEMENT initial-context-factory (#PCDATA)>
<!--
Applies to bean managed persistence or EJB 1.1 container-managed
persistence entity EJBs. EJB 2.0 entity EJBs do not need to implement
an is-modified-method. The EJB container can automatically detect
which fields were modified in a transaction.
This parameter declares the name of an EJBean method that tells the
container whether the bean data has been modified. The method is
called when the bean managed EJBean is stored. If a method is not specified,
WebLogic always assumes that the EJBean has been modified and always
saves it. Providing a method and setting it as appropriate will
improve performance.
Used in: persistence
-->
<!ELEMENT is-modified-method-name (#PCDATA)>
<!--
Specify a transaction isolation level
The value of this element must be one of the following:
TransactionSerializable
TransactionReadCommitted
TransactionReadUncommitted
TransactionRepeatableRead
Special value for use with Oracle DBMS Only:
TransactionReadCommittedForUpdate
When this Isolation level is set for a method, the following happens:
The Isolation Level is set to: TransactionReadCommitted
For duration of the Transaction, all SQL 'SELECT' statements
executed in any method are executed with 'FOR UPDATE'
appended to them. This causes the SELECTed rows to be locked for update.
This isolation level can be used to avoid the error:
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
which can happen when using the TransactionSerializable isolation with Oracle DBMS
Special value for use with Oracle DBMS Only:
TransactionReadCommittedForUpdateNoWait
When this Isolation level is set for a method, the following happens:
The Isolation Level is set to: TransactionReadCommitted
For duration of the Transaction, all SQL 'SELECT' statements
executed in any method are executed with 'FOR UPDATE NO WAIT'
appended to them. This causes the SELECTed rows to be locked for update.
In contrast to the setting TransactionReadCommittedForUpdate
noted previously, this setting: TransactionReadCommittedForUpdateNoWait
will cause the Oracle DBMS to NOT WAIT if the required Locks cannot be
acquired immediately. If the Oracle DBMS cannot immediately acquire the
Locks need by the query, then the the affected SELECT Query will fail and
an Exception will be thrown by the Container.
TransactionReadCommittedForUpdateNoWait
Since: WebLogic Server WLS7.0
Used in: transaction-isolation
Default value: the default of the underlying DBMS
-->
<!ELEMENT isolation-level (#PCDATA)>
<!--
This specifies a jndi-name for a bean, resource or reference.
Used in: weblogic-enterprise-bean, resource-description,
ejb-reference-description, ejb-local-reference-description
-->
<!ELEMENT jndi-name (#PCDATA)>
<!--
This specifies if all the clients are colocated with the ejb on the same
server.
Used in: weblogic-enterprise-bean
Default value: False
-->
<!ELEMENT clients-on-same-server (#PCDATA)>
<!--
This specifies a jndi-name for a bean's local home. If a bean has both a
remote home and a local home, then it may be given two JNDI names; one
for each home.
Used in: weblogic-enterprise-bean
-->
<!ELEMENT local-jndi-name (#PCDATA)>
<!--
Maximum number of objects of this class that are allowed in memory.
Objects are kept in an LRU chain, and the ones dropped from the
end of the chain are passivated.
Used in: cache
Default value: 1000
-->
<!ELEMENT max-beans-in-cache (#PCDATA)>
<!--
WebLogic EJB maintains a free pool of beans for every bean class.
This property decides the maximum size of the pool.
Used in: pool
Default value: 1000
-->
<!ELEMENT max-beans-in-free-pool (#PCDATA)>
<!--
The message-driven-descriptor element is used to specify deployment
parameters that are applicable to a message-driven bean.
Used in: weblogic-enterprise-bean
-->
<!ELEMENT message-driven-descriptor (
pool?,
destination-jndi-name?,
initial-context-factory?,
provider-url?,
connection-factory-jndi-name?,
jms-polling-interval-seconds?,
jms-client-id?
)
>
<!--
The method element is used to denote a method of an enterprise bean's
home or remote interface, or a set of methods.
For further information, see the description of the element in
ejb-jar.dtd.
Used in: transaction-isolation, idempotent-methods
-->
<!ELEMENT method (
description?,
ejb-name,
method-intf?,
method-name,
method-params?)
>
<!--
The method-intf element allows a method element to differentiate
between the methods with the same name and signature that are defined
in both the remote and home interfaces. The method-intf element must
be one of the following:
<method-intf>Home</method-intf>
<method-intf>Remote</method-intf>
<method-intf>LocalHome</method-intf>
<method-intf>Local</method-intf>
Used in: method
-->
<!ELEMENT method-intf (#PCDATA)>
<!--
The method-name element contains a name of an enterprise bean method,
or the asterisk (*) character. The asterisk is used when the element
denotes all the methods of an enterprise bean's remote and home
interfaces.
Used in: method
-->
<!ELEMENT method-name (#PCDATA)>
<!--
The method-param element contains the fully-qualified Java type name
of a method parameter.
Used in: method-params
-->
<!ELEMENT method-param (#PCDATA)>
<!--
The method-params element contains a list of the fully-qualified Java
type names of the method parameters.
Used in: method
-->
<!ELEMENT method-params (method-param*)>
<!--
This parameter is used to specify the principal to be used in
those cases in which ejbPassivate would run with an anonymous principal.
Under such conditions, the choice of which principal to run as is governed
by the following rule:
if passivate-as-principal-name is set
then use that principal
else
if a run-as role has been specified for the bean
then use a principal according to the rules for setting the run-as-role-assignment
else
run ejbPassivate as an anonymous principal
This parameter only needs to be specified if operations within ejbPassivate need
more permissions than the anonymous principal would have.
This element has an effect on the ejbPassivate methods of:
StatefulSessionBeans when passivation occurs due to a cache timeout
Since: WebLogic Server 8.1SP01
Used in: weblogic-enterprise-bean
-->
<!ELEMENT passivate-as-principal-name (#PCDATA)>
<!--
The persistence element is used to specify persistence options
Used in: entity-descriptor
-->
<!ELEMENT persistence (
is-modified-method-name?,
delay-updates-until-end-of-tx?,
finders-load-bean?,
persistence-use?)
>
<!--
The persistence-use tag stores an identifier of the Persistence Type to be
used for this particular bean.
Used in: persistence
Example:
<persistence-use>
<type-identifier>WebLogic_CMP_JDBC</type-identifier>
<type-version>1.3.2</type-version>
<type-storage>META-INF/weblogic-cmp-jar.xml</type-storage>
</persistence-use>
-->
<!ELEMENT persistence-use (type-identifier, type-version, type-storage)>
<!--
The persistent-store-dir specifies the directory in the
server's file system where the state of passivated stateful session beans is
to be stored.
Used in: stateful-session-descriptor
-->
<!ELEMENT persistent-store-dir (#PCDATA)>
<!--
The allow-concurrent-calls specifies whether a stateful session bean
instance will allow concurrent method calls. The value of this
element may be either "True" or "False".
When a stateful session bean instance is currently in a
method call and another (concurrent) method call arrives on the
server, the EJB specification requires that the server throw a
RemoteException. By default, allow-concurrent-calls is false, and the
EJB container will follow the EJB specification. When this value is
set to true, the EJB container will block the concurrent method call
and allow it to proceed when the previous call has completed.
Used in: stateful-session-descriptor
Default value: False
-->
<!ELEMENT allow-concurrent-calls (#PCDATA)>
<!--
The allow-remove-during-transaction specifies that the remove method
on stateful session bean could be invoked within a transaction context.
Stateful Session beans implementing the Synchronization interface should not
use this tag and call remove before the transaction ends. If this is done
the container will not invoke the synchronization callbacks.
Used in: stateful-session-descriptor
Default value: False
-->
<!ELEMENT allow-remove-during-transaction (#PCDATA)>
<!--
The pool element is used to specify various options for instance pooling.
Used in: stateless-session-descriptor, entity-descriptor,
message-driven-descriptor
-->
<!ELEMENT pool (
max-beans-in-free-pool?,
initial-beans-in-free-pool?)
>
<!--
The principal-name element contains the name of a security principal.
Used in: security-role-assignment
-->
<!ELEMENT principal-name (#PCDATA)>
<!--
The read-timeout-seconds is the number of seconds between ejbLoad calls on
a Read-Only entity bean. If read-timeout-seconds is 0,
ejbLoad will only be called when the bean is brought into the cache.
Used in: entity-cache, entity-cache-ref
Default value: 600
-->
<!ELEMENT read-timeout-seconds (#PCDATA)>
<!--
The reference-descriptor specifies a list of resource-descriptions that
describe the resources used in the bean.
Used in: weblogic-enterprise-bean
Example:
<reference-descriptor>
<resource-description>
<res-ref-name>
jdbc/EmployeeAppDB
</res-ref-name>
<jndi-name>
weblogic.jdbc.jts.ejbPool
</jndi-name>
</resource-description>
<resource-description>
<res-ref-name>
jdbc/PersonDB
</res-ref-name>
<jndi-name>
weblogic.jdbc.jts.personPool
</jndi-name>
</resource-description>
</reference-descriptor>
-->
<!ELEMENT reference-descriptor (
resource-description*,
resource-env-description*,
ejb-reference-description*,
ejb-local-reference-description*
)>
<!--
This parameter is used to specify the principal to be used in
those cases in which ejbRemove would run with an anonymous principal.
Under such conditions, the choice of which principal to run as is governed
by the following rule:
if remove-as-principal-name is set
then use that principal
else
if a run-as role has been specified for the bean
then use a principal according to the rules for setting the run-as-role-assignment
else
run ejbRemove as an anonymous principal
This parameter only needs to be specified if operations within ejbRemove need
more permissions than the anonymous principal would have.
This element has an effect on the ejbRemove methods of:
StatelessSessionBeans
MessageDrivenBeans
Since: WebLogic Server 8.1SP01
Used in: weblogic-enterprise-bean
-->
<!ELEMENT remove-as-principal-name (#PCDATA)>
<!--
The replication-type element describes how to replicate stateful session
beans in a cluster. The legal values are:
"InMemory": The bean will be replicated in memory across the cluster
"None": The bean will not be replicated.
Used in: stateful-session-clustering
Default value: None
-->
<!ELEMENT replication-type (#PCDATA)>
<!--
The res-env-ref-name element specifies the name of a resource environment
reference.
Used in: resource-env-description
-->
<!ELEMENT res-env-ref-name (#PCDATA)>
<!--
The res-ref-name element specifies the name of a resource factory
reference.
Used in: resource-description
-->
<!ELEMENT res-ref-name (#PCDATA)>
<!--
The resource-description element is used to map a resource-ref, declared in
the ejb-jar.xml deployment descriptor, to the JNDI name of the server resource
factory it represents.
Used in: reference-descriptor
Example:
<resource-description>
<res-ref-name>
jdbc/EmployeeAppDB
</res-ref-name>
<jndi-name>
weblogic.jdbc.jts.ejbPool
</jndi-name>
</resource-description>
-->
<!ELEMENT resource-description (res-ref-name, jndi-name)>
<!--
The resource-env-description element is used to map a resource-env-ref,
declared in the ejb-jar.xml deployment descriptor, to the JNDI name of the
server resource it represents.
Used in: reference-descriptor
Example:
<resource-env-description>
<res-env-ref-name>
jms/StockInfo
</res-env-ref-name>
<jndi-name>
mystockapp.jms.queue.nasdaq
</jndi-name>
</resource-description>
-->
<!ELEMENT resource-env-description (res-env-ref-name, jndi-name)>
<!--
DEPRECATED: The global-role element is now deprecated and will be removed
in a future version of WebLogic.
Please use the externally-defined element instead.
The global-role element indicates that a particular security role
is defined 'globally' in a security realm. Because the security role
and it's principal-name mapping is defined elsewhere, principal-names
are not to be specified in the deployment descriptor. This tag
is used as an indicative placeholder instead of a set of <principal-name>
elements.
Used in: security-role-assignment
Since: 7.0SP01
-->
<!ELEMENT global-role EMPTY>
<!--
The externally-defined element indicates that a particular security role
is defined 'externally' in a security realm, outside of the deployment descriptor.
Because the security role and it's principal-name mapping is defined elsewhere, principal-names
are not to be specified in the deployment descriptor. This tag
is used as an indicative placeholder instead of a set of <principal-name>
elements.
Used in: security-role-assignment
Since: 8.1
-->
<!ELEMENT externally-defined EMPTY>
<!--
The role-name element contains the name of a security role.
Used in: security-role-assignment
-->
<!ELEMENT role-name (#PCDATA)>
<!--
DEPRECATED: the <run-as-identity-principal> element is deprecated in 8.1
use <run-as-principal-name> instead.
The run-as-identity-principal element specifies which security principal name is
to be used as the run-as principal for a bean that has specified a security-identity
run-as role-name in its ejb-jar deployment descriptor.
For an explanation of how the mapping of run-as role-names to run-as-identity-principals or
run-as-principal-names occurs, see the comments for the run-as-role-assignment element.
Used in: weblogic-enterprise-bean
Example:
<run-as-identity-principal>
Fred
</run-as-identity-principal>
-->
<!ELEMENT run-as-identity-principal (#PCDATA)>
<!--
The run-as-principal-name element specifies which security principal name is
to be used as the the run-as principal for a bean that has specified a security-identity
run-as role-name in its ejb-jar deployment descriptor.
For an explanation of how the mapping of run-as role-names to run-as-principal-names
occurs, see the comments for the run-as-role-assignment element.
Used in: weblogic-enterprise-bean, run-as-role-assignment
Example:
<run-as-principal-name>
Fred
</run-as-principal-name>
-->
<!ELEMENT run-as-principal-name (#PCDATA)>
<!--
The run-as-role-assignment is used to map a given security-identity run-as
role-name that is specified in the ejb-jar deployment descriptor to a run-as-principal-name.
The value of the run-as-principal-name for a given role-name that is specified
here is scoped to all beans in the ejb-jar deployment descriptor, it applies to
all beans that specify that role-name as their security-identity run-as role-name.
The run-as-principal-name value specified here can be overridden at the
individual bean level by specifying a run-as-principal-name under that
bean's weblogic-enterprise-bean element.
Note that for a given bean, if there is no run-as-principal-name specified in
either a run-as-role-assignment or in a bean specific run-as-principal-name tag,
then the ejb container will choose the first principal-name of a security User in the
weblogic-enterprise-bean security-role-assignment for the role-name and use
that principal-name as the run-as-principal-name.
Example:
In the ejb-jar descriptor,
Beans 'A_EJB_with_runAs_role_X' and
'B_EJB_with_runAs_role_X'
specify a security-identity run-as role-name 'runAs_role_X'.
Bean 'C_EJB_with_runAs_role_Y'
specifies a security-identity run-as role-name 'runAs_role_Y'.
Consider the following excerpts from the corresponding weblogic-ejb-jar descriptor:
<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>
Each of the 3 beans in this example will choose a different principal name
to use as its run as principal.
A_EJB_with_runAs_role_X
This bean's run-as role-name is 'runAs_role_X'. The jar scoped
<run-as-role-assignment> mapping will be used to look up the
name of the principal to use.
The <run-as-role-assignment> mapping specifies that for
<role-name> 'runAs_role_X' we are to use <run-as-principal-name> 'Fred'.
'Fred' is the principal name that will be used.
B_EJB_with_runAs_role_X
This bean's run-as role-name is also 'runAs_role_X'. This bean will
not use the jar scoped <run-as-role-assignment> to look up the name
of the principal to use because that value is overridden by this
bean's <weblogic-enterprise-bean> <run-as-principal-name> value 'Joe'.
'Joe' is the principal name that will be used.
C_EJB_with_runAs_role_Y
This bean's run-as role-name is 'runAs_role_Y'. There is no explicit
mapping of 'runAs_role_Y' to a run-as principal name, i.e. there is no
jar scoped <run-as-role-assignment> for 'runAs_role_Y' nor is there a
bean scoped <run-as-principal-name> specified in this bean's
<weblogic-enterprise-bean>.
To determine the principal name to use, the <security-role-assignment>
for <role-name> 'runAs_role_Y' is examined. The first <principal-name>
corresponding to a User (i.e. not a Group) is chosen.
'first_principal_of_role_Y' is the principal name that will be used.
Used in: weblogic-ejb-jar
Since: 8.1
-->
<!ELEMENT run-as-role-assignment (role-name, run-as-principal-name)>
<!--
The security-role-assigment declares a mapping between an EJB security role
and one or more principals in the WebLogic server.
Example:
<security-role-assignment>
<role-name>
PayrollAdmin
</role-name>
<principal-name>
Tanya
</principal-name>
<principal-name>
Fred
</principal-name>
<principal-name>
system
</principal-name>
</security-role-assignment>
Example: using role 'An_Externally_Defined_Role' which is defined for a security realm.
<externally-defined/> is used to indicate that the role and its principal
mapping is defined globally in a security realm.
<security-role-assignment>
<role-name>An_Externally_Defined_Role</role-name>
<externally-defined/>
</security-role-assignment>
<security-role-assignment>
Used in: weblogic-ejb-jar
-->
<!ELEMENT security-role-assignment (role-name, (principal-name+ | externally-defined | global-role )) >
<!--
The stateful-session-clustering element is used to specify various options for
how a stateful session bean will be invoked and replicated in a WebLogic
cluster.
Used in: stateful-session-descriptor
-->
<!ELEMENT stateful-session-clustering (
home-is-clusterable?,
home-load-algorithm?,
home-call-router-class-name?,
use-serverside-stubs?,
replication-type?)
>
<!--
The stateful-session-cache element is used to specify various options for the
caching of a stateful session bean.
Used in: stateful-session-descriptor
-->
<!ELEMENT stateful-session-cache (
max-beans-in-cache?,
idle-timeout-seconds?,
session-timeout-seconds?,
cache-type?)
>
<!--
The stateful-session-descriptor element is used to specify deployment
parameters that are applicable to a stateful session bean.
Used in: weblogic-enterprise-bean
-->
<!ELEMENT stateful-session-descriptor (
stateful-session-cache?,
persistent-store-dir?,
stateful-session-clustering?,
allow-concurrent-calls?,
allow-remove-during-transaction?)
>
<!--
The stateless-bean-call-router-class-name specifies a custom class
to be used for routing bean method calls. This class must implement
weblogic.rmi.cluster.CallRouter. If specified, an instance of
this class will be called before each method call and be given the
opportunity to choose a server to route to based on the method
parameters. It either returns a server name or null indicating
that the current load algorithm should be used to pick the server.
Used in: stateless-clustering
-->
<!ELEMENT stateless-bean-call-router-class-name (#PCDATA)>
<!--
The valid values of the stateless-bean-is-clusterable parameter
are "True" or "False."
The parameter is applicable only to session EJBeans with a
session-type value of "Stateless" (see ejb-jar.dtd).
If home-is-clusterable is "True" and this parameter is also "true",
calls to this bean stub will be load-balanced between all the
the servers on which this bean is deployed, and if a server
hosting the bean becomes unreachable, the call will automatically
failover to another server hosting the bean.
Used in: stateless-clustering
Defaut value: True
-->
<!ELEMENT stateless-bean-is-clusterable (#PCDATA)>
<!--
The stateless-bean-load-algorithm specifies the algorithm to use
for load-balancing between replicas of this bean. If this property
is not specified, the algorithm specified by the server property
weblogic.cluster.defaultLoadAlgorithm will be used.
The legal values of stateless-bean-load-algorithm are:
RoundRobin
Random
WeightBased
RoundRobinAffinity
RandomAffinity
WeightBasedAffinity
Used in: stateless-clustering
-->
<!ELEMENT stateless-bean-load-algorithm (#PCDATA)>
<!--
DEPRECATED: The stateless-bean-methods-are-idempotent element is
now deprecated and will be removed in a future version of WebLogic.
Please use the idempotent-methods element instead.
The value of the stateless-bean-methods-are-idempotent must be
either "True" or "False."
This parameter is applicable only to session EJBeans with a
session-type of "Stateless" (see ejb-jar.dtd).
The value should be set to "True" only if the bean is written
such that repeated calls to the same method with the same arguments
has exactly the same effect as a single call. This allows the failover
handler to retry a failed call without knowing whether the call
actually completed on the failed server. Setting this property to
"true" makes it possible for the bean stub to automatically recover
from any failure as long as another server hosting the bean can be
reached. Setting stateless-clustering to "True" will override any
per-method idempotency settings in the idempotent-methods element.
Used in: stateless-clustering
Default value: False
-->
<!ELEMENT stateless-bean-methods-are-idempotent (#PCDATA)>
<!--
The stateless-clustering element is used to specify various options for
how a stateless session bean will be invoked in a WebLogic cluster.
Used in: stateless-session-descriptor
-->
<!ELEMENT stateless-clustering (
home-is-clusterable?,
home-load-algorithm?,
home-call-router-class-name?,
use-serverside-stubs?,
stateless-bean-is-clusterable?,
stateless-bean-load-algorithm?,
stateless-bean-call-router-class-name?,
stateless-bean-methods-are-idempotent?)
>
<!--
The stateless-session-descriptor element is used to specify deployment
parameters that are applicable to a stateless session bean.
Used in: weblogic-enterprise-bean
-->
<!ELEMENT stateless-session-descriptor (
pool?,
stateless-clustering?)
>
<!--
Specify transaction isolation level on a per-method basis.
Used in: weblogic-ejb-jar
-->
<!ELEMENT transaction-isolation (isolation-level, method+)>
<!--
Sets the default timeout for container-initiated transactions for this
bean. If a transaction's duration is longer than this value, it will
be rolled back.
Used in: transaction-descriptor
-->
<!ELEMENT trans-timeout-seconds (#PCDATA)>
<!--
The transaction-descriptor specifies properties relating to transactions
Used in: weblogic-enterprise-bean
-->
<!ELEMENT transaction-descriptor (
trans-timeout-seconds?)
>
<!--
This stores the identifier of the Persistence Type that this tag describes.
Used in: persistence-use
Example:
<type-identifier>WebLogic_CMP_JDBC</type-identifier>
-->
<!ELEMENT type-identifier (#PCDATA)>
<!--
The type-storage tag stores a file (path relative within the ejb-jar file)
which stores data specific to this Persistence Type.
Used in: persistence-use
Example:
<type-storage>persistence/weblogic/cmp_jdbc.xml</type-storage>
-->
<!ELEMENT type-storage (#PCDATA)>
<!--
This element specifies the URL provider to be put in the Properties used
by the InitialContext. It is typically host:port and used in conjunction
with initial-context-factory and connection-factory-jndi-name.
Used in: message-driven-descriptor
-->
<!ELEMENT provider-url (#PCDATA)>
<!--
The type-version tag stores the version of the Persistence Type to be used for
this particular bean. Most useful when a server deployment has multiple
compatible versions of the same Persistence Type installed, as the Persistence
Type identifier is not unique between versions.
Used in: persistence-use
Example:
<type-version>1.3.2</type-version>
-->
<!ELEMENT type-version (#PCDATA)>
<!--
This tag enforces home to use server-side stubs in the context of server.
Used in: stateless-clustering,
stateful-session-clustering,
entity-clustering
Default: false
-->
<!ELEMENT use-serverside-stubs (#PCDATA)>
<!--
The weblogic-ejb-jar is the root element of the weblogic component of the
EJB deployment descriptor
-->
<!ELEMENT weblogic-ejb-jar (description?, weblogic-enterprise-bean*,
security-role-assignment*,
run-as-role-assignment*,
security-permission?,
transaction-isolation*,
idempotent-methods?,
enable-bean-class-redeploy?,
disable-warning*)
>
<!--
The weblogic-enterprise-bean element contains the deployment
information for a bean that is specific to the WebLogic Server
Used in: weblogic-ejb-jar
-->
<!ELEMENT weblogic-enterprise-bean (
ejb-name,
(entity-descriptor|
stateless-session-descriptor|
stateful-session-descriptor|
message-driven-descriptor
)?,
transaction-descriptor?,
iiop-security-descriptor?,
reference-descriptor?,
enable-call-by-reference?,
clients-on-same-server?,
(run-as-identity-principal|
run-as-principal-name
)?,
create-as-principal-name?,
remove-as-principal-name?,
passivate-as-principal-name?,
jndi-name?,
local-jndi-name?,
dispatch-policy?)
>
<!--
The invalidation-target element specifies a Read-Only Entity EJB which
should be invalidated when this Container-Managed Persistence Entity
EJB has been modified.
Note that the target ejb-name must be a Read-Only Entity EJB, and this
tag may only be specified in an EJB 2.0 Container-Managed Persistence Entity
EJB.
Example:
<invalidation-target>
<ejb-name>StockReaderEJB</ejb-name
</invalidation-target>
Since: WebLogic Server 6.1
-->
<!ELEMENT invalidation-target (
ejb-name)
>
<!--
The iiop-security-descriptor element is used to specify security configuration
parameters on a per-bean level. These parameters determine the IIOP security
information contained within the IOR.
Used in: weblogic-enterprise-bean
-->
<!ELEMENT iiop-security-descriptor (
transport-requirements?,
client-authentication?,
identity-assertion?)
>
<!--
The transport-requirements tag contains transport requirements for
the bean.
Used in: iiop-security-descriptor
-->
<!ELEMENT transport-requirements (
integrity?,
confidentiality?,
client-cert-authentication?)
>
<!--
The integrity tag determines transport integrity requirements
for the bean. Integrity ensures that the data be sent between the client
and server in such a way that it cannot be changed in transit.
The integrity can be one of the following values:
- "none": No integrity is supported.
- "supported": Integrity is supported, but not required.
- "required" : Integrity is required.
Used in: transport-requirements
Example:
<integrity>none</integrity>
-->
<!ELEMENT integrity (#PCDATA)>
<!--
The confidentiality tag determines transport confidentiality requirements
for the bean. Confidentiality ensures that the data be sent between the client
and server in such a way to prevent other entities from observing the contents
of the transmission.
The confidentiality can be one of the following values:
- "none": No confidentiality is supported.
- "supported": Confidentiality is supported, but not required.
- "required" : Confidentiality is required.
Used in: transport-requirements
Example:
<confidentiality>none</confidentiality>
-->
<!ELEMENT confidentiality (#PCDATA)>
<!--
The client-cert-authentication tag determines whether the bean supports
or requires client cert authentication at the transport level.
The client-cert-authentication can be one of the following values:
- "none": No client certificate authentication is supported
- "supported": Client certificate authentication is supported, but not required.
- "required" : Client certificate authentication is required.
Used in: transport-requirements
Example:
<client-cert-authentication>supported</client-cert-authentication>
-->
<!ELEMENT client-cert-authentication (#PCDATA)>
<!--
The client-authentication tag determines whether the bean supports
or requires client authentication.
The client-authentication can be one of the following values:
- "none": No client authentication is supported
- "supported": Client authentication is supported, but not required.
- "required" : Client authentication is required.
Used in: iiop-security-descriptor
Example:
<client-authentication>supported</client-authentication>
-->
<!ELEMENT client-authentication (#PCDATA)>
<!--
The identity-assertion tag determines whether the bean supports
identity assertion.
The identity-assertion can be one of the following values:
- "none": No identity assertion is supported
- "supported": Identity assertion is supported, but not required.
- "required" : Identity assertion is required.
Used in: iiop-security-descriptor
Example:
<identity-assertion>supported</identity-assertion>
-->
<!ELEMENT identity-assertion (#PCDATA)>
<!--
The element security permission specifies a security permission that
is associated with a J2EE Sandbox.
Used in: weblogic-ejb-jar
-->
<!ELEMENT security-permission (description?, security-permission-spec)>
<!--
The element permission-spec specifies a single security permission based
on the Security policy file syntax. Refer to the following URL for
Sun's implementation of the security permission specification:
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
ignore the "codebase" and "signedBy" clauses.
e.g:
<security-permission-spec>
grant { permission java.net.SocketPermission "*", "resolve" };
</security-permission-spec>
Used in: security-permission
-->
<!ELEMENT security-permission-spec (#PCDATA)>
扫一扫
6258
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
