10/14/2009

A sample application-client.xml (Java EE 5)

Application client is another type of Java EE module, the least utilized one. It attempts to wrap up Java SE application, deploy it to application server, and make use of deployed EJB, platform services and resources.

The following application-client.xml declares an env-entry, ejb-ref and resource-ref.

<?xml version="1.0" encoding="UTF-8"?>
<application-client xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="5"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application-client_5.xsd">

<display-name>A sample application client</display-name>

<env-entry>
<description>admin email</description>
<env-entry-name>adminEmail</env-entry-name>
<env-entry-value>admin@example.x</env-entry-value>
</env-entry>

<ejb-ref>
<ejb-ref-name>ejb/testBean</ejb-ref-name>
<remote>test.TestRemoteInterface</remote>
<ejb-link>TestBean</ejb-link>
</ejb-ref>

<resource-ref>
<res-ref-name>HRDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<mapped-name>jdbc/__default</mapped-name>
</resource-ref>

</application-client>
The env-entry can be looked up with name "java:comp/env/adminEmail", or injected into the application client main class or its superclasses. For example:
@Resource(name="adminEmail")
//use static modifier in application client main class only
private static String adminEmail;
The ejb-ref and resource-ref can be looked up with names "java:comp/ejb/testBean" and "java:comp/env/HRDS", respectively.

The reason I include ejb-ref and resource-ref is to show how they fit in descriptors. In Java EE 5 and later, it is easier to use @EJB and @Resource to declare and inject them into component classes.

10/13/2009

A sample application.xml (Java EE 5)

The following is a sample application.xml that declares 3 modules (application client, ejb jar, and war), and a library directory. The library-directory element is redundant here since the default value is "lib".

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="5"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd">

<module>
<java>test-client.jar</java>
</module>

<module>
<ejb>test-ejb.jar</ejb>
</module>

<module>
<web>
<web-uri>test.war</web-uri>
<context-root>test</context-root>
</web>
</module>

<library-directory>lib</library-directory>
</application>

10/12/2009

A sample ejb-jar.xml (EJB 3.0)

ejb-jar.xml is optional starting from EJB 3.0. Annotations are extensively used to declare metadata in place of descriptor elements. In certain cases, ejb-jar.xml is still necessary, and 2 such cases I can think of are the declaration of env-entry and default interceptor.

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
<enterprise-beans>
<session>
<ejb-name>TestBean</ejb-name>
<env-entry>
<description>admin email</description>
<env-entry-name>adminEmail</env-entry-name>
<env-entry-value>admin@example.x</env-entry-value>
</env-entry>
</session>
</enterprise-beans>

<interceptors>
<interceptor>
<interceptor-class>test.Interceptor1</interceptor-class>
</interceptor>
</interceptors>

<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>test.Interceptor1</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar>
This ejb-jar.xml assumes that TestBean is already annotated with either @Stateless or @Stateful. The descriptor adds a env-entry resource to this session bean's naming environment. This env-entry can be injected into TestBean class, or looked up in TestBean's naming environment.

The interceptor-binding element binds Interceptor1 to all EJBs packaged in the current ejb jar.