Where is ejb-jar.xml?

This is the file created by the Deploy Tool that maps your bean's deployment descriptor (ejb-jar.xml) to actual containers and resources declared in your OpenEJB configuration (openejb.conf). In fact, the Deploy tool really does nothing more than create this file and put it in your jar, that's it.

At startup, any jar containing a openejb-jar.xml is loaded by the container system. The configuration tools will go looking in all the directories and jars you have declared in your openejb.conf with the element. For every jar file it finds, it will look inside for an openejb-jar.xml. If it finds one, it will attempt to load and deploy it into the container system.

Nope. Typically you would only use the deploy tool to create your openejb-jar.xml, then just keep your openejb-jar.xml in your CVS (or other repository). If you learn how to maintain this openejb-jar.xml file, you'll never need the deploy tool again! You can do all your builds and deploys automatically.

The openejb-jar.xml file just goes in the META-INF directory of your jar next to the ejb-jar.xml file.

If you can understand the ejb-jar.xml, the openejb-jar.xml should be a breeze.

This is the openejb-jar.xml that is created by the Deploy tool in the Hello World example. As you can see, the file format is extremely simple.

The ejb-name attribute is the name you gave the bean in your ejb-jar.xml. The deployment-id is the name you want to use to lookup the bean in your client's JNDI namespace. The container-id is the name of the container in your openejb.conf file that you would like the bean to run in. There MUST be one ejb-deployment element for each EJB in your jar.

Then you simply add a element to your element like this

The res-ref-name attribute refers to the element of the bean's declaration in the ejb-jar.xml. The res-id attribute refers to the id of the declared in your openejb.conf that will handle the connections and provide access to the desired resource.

You will need one element for every element in your ejb-jar.xml. So if you had an ejb-jar.xml like the following

Then you would need two elements for that bean in your openejb-jar.xml file as such.

This would require two declarations in your openejb.conf, one with the id attribute set to "My Oracle JDBC Database" , and another with it's id attribute set to "My PostgreSQL JDBC Database"

The ejb-jar. xml deployment descriptor file, and any other descriptor file, must be placed in the WEB-INF directory of the WAR. Any instance of an EJB descriptor file elsewhere in the WAR, including in the META-INF directory of a JAR file in the WEB-INF/lib directory, is ignored.

ejb-jar.xml is the optional deployment descriptor that is packaged in an EJB module. ejb-jar.xml has two primary elements: enterprise-beans is used to define beans, resources, and services used by the beans, and assembly-descriptor is used to declare security roles, method permissions, declarative transaction settings, and interceptors. In this section we provide references only to the elements relevant to EJB 3, and we don’t discuss any elements in the schema that are for the sole purpose of backward compatibility with EJB 2. You can refer to the schema of ejb-jar.xml at http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd.

The enterprise-beans element is used to define EJBs in an EJB-JAR module. You can use session or message-driven tags to define session beans or MDBs.

Corresponding annotation: Ojavax.ejb.Session The session tag is used to define a session bean.

Corresponding annotation: @javax.ejb.MessageDriven The message-driven-bean tag is used to define an MDB.

Common elements for session and message-driven beans

The following elements are commonly used with session and message-driven beans.

ejb-local-ref

Corresponding annotation: Ojavax.ejb.EJB Used to specify dependencies on local EJBs.

ejb-ref

Corresponding annotation: Ojavax.ejb.EJB Used to specify remote EJB references.

resource-ref

Corresponding annotation: @javax.annotation.Resource Used to specify resource references, e.g., data source, JMS connection factories, etc.

resource-env-ref

Corresponding annotation: @javax.annotation.Resource Used to specify resource JMS destination references, such as a Queue or Topic.

env-entry

Corresponding annotation: @javax.annotation.Resource Defines environment entries for an EJB.

service-ref

Corresponding annotation: Ojavax.xml.ws.WebServiceRef Used to specify dependency on a web service.

The referenced schema is javaee_web_services_client_1_2.xsd, and we have discussed only elements that are useful for EJBs.

persistence-context-ref

Corresponding annotation: Ojavax.persistence.PersistenceContext Defines references to a container-managed entity manager.

persistence-unit-ref

Corresponding annotation: @javax.persistence.PersistenceUnit

Defines references to a persistence unit (i.e., entity manager factory).

injection-target

This defines the name of a class and a name (field or property) within that class into which a resource, EJB, entity manager, etc. should be injected.

post-construct, pre-destroy, pre-passivate, post-activate

Corresponding annotations: Ojavax.annotation.PostConstruct, Ojavax.annota-tion.PreDestroy, Ojavax.ejb.PrePassivate, Ojavax.ejb.PostActivate Used to define lifecycle methods.

security-role-ref

Corresponding annotation: Ojavax.annotation.security.DeclareRoles Used to specify security role references.

You can use the assembly-descriptor element to specify declarative transactions, security role and method permissions, and interceptor binding.

security-role

Corresponding annotation: Ojavax.annotation.security.DeclareRoles

Used to define the security roles used in the application. This is similar to the

@DeclareRoles annotation.

method-permission

Corresponding annotation: @javax.annotation.security.RolesAllowed

Defines the security for EJB methods and signifies which roles are allowed to execute which methods.

container-transaction

Defines the transaction settings for different EJB methods. Equivalent of the

@TransactionAttribute annotation.

interceptor-binding

Defines interceptors either at the module (default interceptor), class, or method level. Similar to the @javax.interceptor.Interceptors annotation.

exclude-list

Corresponding annotation: @javax.annotation.security.DenyAll

Lists the names of the methods customers are not allowed to execute.

application-exception

Corresponding annotation: @javax.ejb.ApplicationException Defines an application exception.