Child pages
  • Creating deployment plans for EJB applications
Skip to end of metadata
Go to start of metadata

INLINE

Geronimo uses OpenEJB container for providing ejb services. An EJB application requires ejb-jar.xml as deployment descriptor and openejb-jar.xml as deployment plan.

With the advent of Java EE 5, the ejb container services such as transaction management, security, life cycle management can be declared in the ejb class itself using annotations. However, the ejb deployment descriptor can still be provided through ejb-jar.xml file. When both annotations and ejb-jar.xml file are provided, the ejb-jar.xml file takes precedence over the annotations.

The openejb-jar.xml file contains deployment plan for ejb modules. In the openejb-jar.xml file, the application deployer maps the security roles, ejb names, database resources, JMS resources, etc. declared in ejb-jar.xml file to corresponding entities deployed in the server. In addition to that, if there are any ejb container specific configurations to be done, the required settings are configured as well here. If the ejb module depends on any third party libraries or other services running in the server, all these third party libraries and the services are specified in the openejb-jar.xml file. Some ejb applications require class loading requirements different from the default class loading behavior. The openejb-jar.xml file allows application deployer to configure this as well. There are many more configurations that could be done through openejb-jar.xml file depending on the needs of the ejb application. The following sections briefly explain how openejb-jar.xml file can be used to configure the ejb container and ejb applications.

Sample plan for a SSB application

For example, the below XML content is the deployment descriptor (ejb-jar.xml) of a stateless session bean that connects to a back end DB2 database.

ejb-jar.xmlborderStyle=solid Stateless Session Bean Example Stateless Session Bean Example RetrieveEmployeeInfoBean examples.session.stateless_dd.RetrieveEmployeeInfo examples.session.stateless_dd.RetrieveEmployeeInfoBean Stateless Container jdbc/DataSource javax.sql.DataSource Container Shareable examples.session.stateless_dd.RetrieveEmployeeInfoCallbacks construct activate passivate RetrieveEmployeeInfoBean examples.session.stateless_dd.RetrieveEmployeeInfoCallbacks ]]>

The default namespace of the above XML document is http://java.sun.com/xml/ns/javaee. The XML elements that do not have a namespace prefix belong to the default namespace.

In EJB3.0, most of the deployment descriptor declarations can be done through the corresponding annotations in the bean class. However, if a deployment descriptor is supplied (ejb-jar.xml), the declarations in the deployment descriptor will override the annotations.

The ejb module connects to back end datasource using its JNDI name jdbc/DataSource as declared in the ejb-jar.xml. It also declares that the ejb is a stateless session bean and provides an interceptor class for the bean. The interceptor class will have callback methods which container calls when the corresponding events occur in the bean's life cycle.

For the above deployment descriptor, we will have to provide a corresponding deployment plan file (openejb-jar.xml) that maps the declared datasource to actual datasource deployed in the server. The following is the deployment plan.

openejb-jar.xmlborderStyle=solid samples EmployeeDemo-ejb-dd 3.0 jar console.dbpool jdbc/FEmployeeDatasource 1.0 rar RetrieveEmployeeInfoBean jdbc/DataSource jdbc/EmployeeDatasource ]]>

The default namespace of the above XML document is http://openejb.apache.org/xml/ns/openejb-jar-2.2. The XML elements that do not have a namespace prefix belong to the default namespace.

Observe the various XML tags and corresponding namespaces used in the deployment plan for various purposes.

<sys:environment> .. </sys:environment> : These elements provide the moduleId configuration and the dependencies. The moduleId elements provide the configuration name for the ejb module. So, when the ejb module is deployed, it is given the configuration name samples/EmployeeDemo-ejb-dd/3.0/jar. The dependencies elements provide the configurations and third party libraries on which the ejb module is dependent on. These configurations and libraries will be available to the ejb module via a classloader hierarchy. In this case, the ejb module is dependent on console.dbpool/jdbc/FEmployeeDatasource/1.0/jar which is the configuration of the deployed Datasource that connects to a back end DB2 database. The Datasource deploys a database connection pool (javax.sql.Datasource) with name jdbc/EmployeeDatasource.

<enterprise-beans> .. </enterprise-beans> : These elements help us to configure the enterprise beans. In this case, the datasource reference jdbc/DataSource is mapped to jdbc/EmployeeDatasource.

In the ejb bean class, the following java code is used to obtain a connection from the datasource.

examples.session.stateless_dd.RetrieveEmployeeInfoBean.javasolid

The above descriptor and plan are the simple illustrations that explain how ejb modules are developed and assembled for Apache Geronimo. Similarly, many other configurations can be performed in the openejb-jar.xml. The schema for the plan is openejb-jar-2.1.xsd

Sample plan for a MDB application

Apache geronimo ships with ActiveMQ message broker and an inbound and outbound JMS resource adapter for the ActiveMQ broker. This sample illustrates deploying and running two MDBs that listen to a jms topic TextTopic. When the web client publishes a message to this topic, the two MDBs receive the message and process it. Because the message is published to the topic, all the configured listeners, in this case the two MDBs, receive a copy of the message. In addition to that, we will also illustrate how to deploy a JMS resource adapter within the application scope. Usually, the resource adapters are deployed at the server scope and can be used by all other applications as well. In this example, a JMS resource plan is embedded in the application deployment plan geronimo-application.xml and deployed while deploying the application archive.

XMLsolidejb-jar.xml TextMessageBean1 sample.mdb.TextMessageBean1 javax.jms.MessageListener Bean javax.jms.Topic destinationType javax.jms.Topic TextMessageBean2 sample.mdb.TextMessageBean2 javax.jms.MessageListener Bean javax.jms.Topic destinationType javax.jms.Topic ]]>

The ejb-jar.xml declares the two MDBs sample.mdb.TextMessageBean1 and sample.mdb.TextMessageBean2 both listen to a javax.jms.Topic destination.

XMLsolidopenejb-jar.xml Sample MDB-EJB 1.0 car TextMessageBean1 TradeJMSResources destination TextMessageTopic destinationType javax.jms.Topic TextMessageBean2 TradeJMSResources destination TextMessageTopic destinationType javax.jms.Topic ]]>

In the deployment plan openejb-jar.xml, the two MDBs are configured as end point listeners for the jms topic TextMessageTopic.

The code for the two MDBs are as follows.

JAVAsolidTextMessageBean1.java JAVAsolidTextMessageBean2.java

After receiving the message, the MDBs just print the contents of the message.

The web client for the application is as follows.

XMLsolidweb.xml MDBSampleWEB index.html index.htm index.jsp Test Test sample.mdb.Test jms broker jms/broker javax.jms.TopicConnectionFactory Container Predefined Topic jms/Topic/TextTopic javax.jms.Topic Test /Test ]]>

The web client declares the javax.jms.TopicConnectionFactory and the topic to which the servlet has to publish the message. The names declared here are mapped to actual resources in the geronimo-web.xml as follows.

XMLsolidgeronimo-web.xml sample MDB-Web 1.0 car /MDBSampleWEB jms/broker jms/TopicConnectionFactory jms/Topic/TextTopic TextMessageTopic ]]>

Please note that the jms/TopicConnectionFactory and jms/Topic/TextTopic are the names of the actual connection factory and jms topic. These are deployed by a jms resource plan embedded in the EAR's deployment plan as follows.

XMLsolidapplication.xml MDBSampleEAR MDBSampleEJB.jar MDBSampleWEB.war MDBSampleWEB ]]> XMLsolidgeronimo-application.xml default MDBSampleEAR 1.0 car TopicJMSSample org.apache.geronimo.modules geronimo-activemq-ra 2.1 TradeJMSResources tcp://localhost:61616 not needed not needed DefaultWorkManager javax.jms.ConnectionFactory jms/TopicConnectionFactory javax.jms.TopicConnectionFactory 10 0 5000 0 javax.jms.Topic org.activemq.message.ActiveMQTopic TextMessageTopic TextMessageTopic ]]>

The plan for resource adapter is provided under <ext-module> xml elements. Also, the resource adapter archive (rar) file to be used to deploy the plan is mentioned using external-path xml element; the resource adapter plan follows these elements. The plan deploys{{ jms/TopicConnectionFactory}} and TextTopic.

The reference to resource archive file is provided using the following xml elements in the above plan.

JAVAsolidReferencing Libraries org.apache.geronimo.modules geronimo-activemq-ra 2.1 ]]>

The above pattern is the way how geronimo references various libraries available in the server repository. Any external libraries can also be uploaded to server repository using admin console portlet. After starting the server, click on Console Navigation => Services => Repository to display Repository Viewer portlet. In this portlet, users can upload required third party libraries by providing proper groupId, artifactId and version values for the libraries being uploaded. The activeMQ rar file is also available in the repository as org.apache.geronimo.modules/geronimo-activemq-ra/2.1/rar. Click on this link to get the usage instructions on how to reference this library in other modules.

The web client that look up the connection factory and topic and sends messages is as follows.

JAVAsolidTest.java

When the above servlet is accessed on a browser window as http://localhost:8080/MDBSampleWEB/Test?CustomerId=10&CustomerName=Phani, the following output is displayed in the server console.
solid

  • No labels