Ejb deployment descriptor file

EJB Concepts. Beans and their deployment descriptors [1] can be packed in Java jar files [2] to make a uniform deployment unit. The jar file is built with the Java jar program and contains the following: One or more beans A deployment descriptor for each bean Application assembly instructions Supporting classes and files. The deployment descriptor DD describes everything that is needed to actually deploy a bean.

This annotation is not used for session or entity beans. Default value: weblogic. Specifies the initial context factory used by the JMS provider to create initial context.

See also message-destination-descriptor. Specifies the transport integrity requirements for the EJB. Using the integrity element ensures that the data is sent between the client and server in such a way that it cannot be changed in transit. The specified method must return a boolean value.

Providing a method and setting it as appropriate can improve performance for EJB 1. However, any errors in the method's return value can cause data inconsistency problems. However, it still applies to BMP and 1. When you deploy EJB 2. TransactionSerializable —Simultaneously executing this transaction multiple times has the same effect as executing the transaction multiple times in a serial fashion. This is because Oracle databases do not lock read data at the TransactionSerializable isolation level.

Additionally, at the TransactionSerializable isolation level, it is possible for concurrent transactions on Oracle databases to proceed without throwing the Oracle exception ORA " can't serialize access for this transaction ".

TransactionReadCommitted —The transaction can view only committed updates from other transactions. TransactionReadUncommitted —The transaction can view uncommitted updates from other transactions.

TransactionRepeatableRead —Once the transaction reads a subset of data, repeated reads of the same data return the same values, even if other transactions have subsequently modified the data. This causes the secluded rows to be locked for update. If the Oracle database cannot lock the rows affected by the query immediately, then it waits until the rows are free.

This causes the selected rows to be locked for update. Refer to your database documentation for more information on support for different isolation levels. See transaction-isolation. Required for durable subscriptions to JMS topics.

Specifies the number of seconds between each attempt to reconnect to the JMS destination. Each message-driven bean listens on an associated JMS destination. Once the JMS Server is up again, the message-driven bean can again receive messages.

When applied to a bean class to indicate the JNDI name of a no-interface view, the className is optional. See resource-description and ejb-reference-description.

The jndi-name element is deprecated in this release of WebLogic Server. Use jndi-binding instead. Assigning a JNDI name to a bean is not recommended. Global JNDI names generate heavy multicast traffic during clustered server startup. The local-jndi-name element is deprecated in this release of WebLogic Server. JNDI name for a bean's local home. If a bean has both a remote and a local home, then it can be assigned two JNDI names; one for each home.

Range of values: 1 to maxBeans. Specifies the maximum number of objects of this class that are allowed in memory. WebLogic Server maintains a free pool of EJBs for every entity bean, stateless session bean, and message-driven bean class.

The max-beans-in-free-pool element defines the size of this pool. Maps a message destination reference in the ejb-jar. Range of values: A valid message destination reference name from the ejb-jar.

Requirements: This element is required if the EJB specifies messages destination references in ejb-jar. Specifies the name of a message destination reference. This is the reference that the EJB provider places within the ejb-jar. See message-destination-descriptor. Range of values: Home Remote Local Localhome. Specifies the EJB interface to which WebLogic Server applies isolation level properties, if the method has the same signature in multiple interfaces. Range of values: Name of an EJB defined in ejb-jar.

If you specify a method-name , the method must be available in the specified ejb-name. The method-params element contains one or more method-param elements, as shown here:. Assigns a custom network channel that the EJB will use for network communications.

A network channel defines a set of connection attributes. The passivate-as-principal-name element, introduced in WebLogic Server 8. The passivate-as-principal-name element only needs to be specified if operations within ejbPassivate require more permissions than the anonymous principal would have.

This element affects the ejbPassivate methods of stateless session beans when passivation occurs due to a cache timeout. See also remove-as-principal-name , create-as-principal-name , and principal-name. Required only for entity EJBs that use container-managed persistence services. The persistence element defines the following options that determine the persistence type, transaction commit behavior, and ejbLoad and ejbStore behavior for entity EJBs in WebLogic Server:.

The persistence-use element stores an identifier of the persistence type to be used for this particular bean. Specifies a file system directory where WebLogic Server stores the state of passivated stateful session bean instances. Specifies the name of a persistent store on the server's file system where WebLogic Server stores timer objects. If you do not specify a persistent store name in this element, WebLogic Server stores timer objects in the default store.

The options are:. Specifies the name of an actual WebLogic Server principal to apply to the specified role-name.

At least one principal-name is required in the security-role-assignment element. You may define more than one principal-name for each role-name. See security-role-assignment. Range of values: 0 to maxSeconds , where maxSeconds is the maximum value of an int. Specifies the number of seconds between ejbLoad calls on a Read-Only entity bean. A value of 0 causes WebLogic Server to call ejbLoad only when the bean is brought into the cache. The following entry causes WebLogic Server to call ejbLoad for instances of the AccountBean class only when the instance is first brought into the cache:.

Specifies the length of time that a remote RMI client will wait before it will time out. This parameter only needs to be specified if operations within ejbRemove need more permissions than the anonymous principal would have.

The remove-as-principal-name element, introduced in WebLogic Server 8. The remove-as-principal-name element only needs to be specified if operations within ejbRemove require more permissions than the anonymous principal would have.

This element effects the ejbRemove methods of stateless session beans and message-drive beans. See also passivate-as-principal-name , create-as-principal-name , and principal-name. If you select None , the state is not replicated. See stateful-session-clustering. Range of values: A valid resource environment reference name from the ejb-jar. See resource-description. Range of values: A valid resource reference name from the ejb-jar. Specifies the name of a resourcefactory reference. Required element if the EJB specifies resource references in ejb-jar.

Maps a resource reference defined in ejb-jar. Maps a resource environment reference defined in ejb-jar. While it is possible to set this value to less than or equal to 0, Oracle recommends that you do not do so because the EJB container will not retry transactions when this value is not greater than or equal to 1. Specifies the number of times you want the EJB container to automatically retry a container-managed transaction method that has rolled back. Specifies the methods for which you want the EJB container to automatically retry container-managed transactions that have rolled back.

Automatic transaction retry is supported for session and entity beans that use container-managed transaction demarcation. Additionally, regardless of the methods specified in this element, the EJB container does not retry transactions that fail because of system exception-based errors.

Identifies an application role name that the EJB provider placed in the ejb-jar. Subsequent principal-name elements in the element map WebLogic Server principals to the specified role-name. The run-as-identity-principal element is deprecated in this release of WebLogic Server. 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 its ejb-jar.

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. 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.

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. Maps a given security-identity run-as role-name specified in the ejb-jar.

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. 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. 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 chooses the first principal-name of a security user in the weblogic-enterprise-bean security-role-assignment for the role-name and uses that principal-name as the run-as-principal-name.

Consider the following excerpts from the corresponding weblogic-ejb-jar. Each of the beans chooses a different principal name to use as its run-as-principal-name. Maps application roles in the ejb-jar. Maps a Web Service destination reference in the ejb-jar. Determines how long the EJB container leaves a passivated stateful session bean on disk.

The container removes a passivated EJB session-timeout-seconds after passivating the bean instance to disk. If session-timeout-seconds is not specified, the default is the value specified by idle-timeout-seconds. See singleton-clustering. Marks the remote business views of the bean as clusterable and supports load balancing and failover. You can define singleton-bean-load-algorithm as one of the following values:.

Defines deployment behaviors, such as caching, clustering, and persistence, for singleton session EJBs in WebLogic Server. The following example shows how to specify the stateful-session-cache element. Specifies the following options that determine how WebLogic Server replicates stateful session EJB instances in a cluster:. Defines deployment behaviors, such as caching, clustering, and persistence, for stateless session EJBs in WebLogic Server.

See stateless-clustering. You can define stateless-bean-load-algorithm as one of the following values:. Defines deployment parameters, such as caching, clustering, and persistence for stateless session EJBs in WebLogic Server. Defines "sticky" load balancing in a cluster. The server chosen for servicing the first request is used for all subsequent requests.

Specifies the persistent store that will be used to store the local timer information for the bean. Clustered —Specifies that timers are cluster aware. This option provides EJB timers with features such as automatic failover, load balancing, and improved accessibility within the cluster.

Local —Specifies that timers will only execute on the server on which they are created and are only visible to the beans on that server.

When you set this element to Local , if you deploy an EJB to a cluster, and invoke the EJB to create a timer, that call could go to any server on the cluster. Another invocation for instance, to cancel the timer could also go to any server on the cluster and will not necessarily go to the same server in which the call to create the timer went. For instance, if the call to create a timer is directed to server1 , and the call to cancel it is directed to server2 , the EJB on server2 would not see the timer on server1 and would, therefore, fail to cancel it.

Pin the EJB deployment to a single server in the cluster. This causes all calls to the EJB to go to server to which the EJB is pinned and all timers to exist on that same server. The trade-off to using this approach is that the EJB cannot take advantage of clustering benefits such as load balancing and failover. Ensure that calls to cancel timers go to all servers in the cluster by using a message-driven bean MDB that listens on a JMS topic. Then, the MDB on each server can invoke a cancelTimer method on the bean.

The trade-off to using this approach is that it makes your application more complex and attempting to cancel timers on all servers is inefficient. Default value: Local the current file store-backed EJB timer service is used. Specifies options that define transaction behavior in WebLogic Server. Currently, this element includes only one child element: trans-timeout-seconds. For more information, see isolation-level. Range of values: 0 to max.

Specifies the maximum duration for an EJB's container-initiated transactions. If a transaction lasts longer than trans-timeout-seconds , WebLogic Server rolls back the transaction. See transaction-descriptor. Range of values: Valid string. Specifies an entity EJB persistence type. If you use a different persistence vendor, consult the vendor's documentation for information on the correct type-identifier. Defines the full path of the file that stores data for this persistence type. The path must specify the file's location relative to the top level of the EJB's JAR deployment file or deployment directory.

Required for entity EJBs that use container-managed persistence service, if multiple versions of the same persistence type are installed. Identifies the version of the specified persistence type. For example, for WebLogic 2. Specifying an incorrect version results in the error:. See the example for entity-clustering.

In WLS version 8. This polling thread was not allocated from the pool specified by dispatch-policy , it was an entirely new thread in addition to the all other threads running on the system.

Because deployment descriptor information is declarative , it can be changed without modifying the source code. At run time, the J2EE server reads the deployment descriptor and acts upon the component accordingly. Most J2EE vendors Application server provide a GUI tool for generating deployment descriptors and performing deployment because creating manual entries is tedious and error prone.

A runtime deployment descriptor is used to configure Java EE implementation-specific parameters. For example, the GlassFish Server runtime deployment descriptor contains such information as the context root of a web application, as well as GlassFish Server implementation-specific parameters, such as caching directives. The GlassFish Server runtime deployment descriptors are named sun-moduleType. The following summarizes the new functionality and simplifications made in EJB 3.

This reduces the amount of code in your bean file in the case where you are programming a typical EJB; you only need to use additional annotations if the default values do not suit your needs. A JAR can contain multiple beans. The standard Java EE deployment descriptor.