Fundamentally, the Java EE 7 platform contains three containers: Enterprise Java Beans (EJB) in Chapter 3, Enterprise Java Beans, Context and Dependency Injection (CDI) in Chapter 2, Context and Dependency Injection and Servlet in Chapter 6, Java Servlets and Asynchronous Request-Response.
The EJB container manages endpoints, EJBs, which by default support transactions, concurrency, and remoting. EJBs do not have a contextual scope. Stateful EJBs share a one-to-one relationship with the EJB client. Stateless EJBs may be shared by magnitude orders of clients simultaneously in a pool of instances.
The CDI container manages the POJOs with a contextual scope; these managed beans have a scoped life cycle and may or may not be communication service endpoints. CDI managed beans can be conversational. They can be made transactional with the JTA 1.2 @Transactional annotation. They can also have concurrency and asynchronous behavior through careful application of the Concurrency Utilities API.
The Servlet container manages the lifecycle of specific types of beans: Servlet, ServletFilter, ContextListener, HttpSessionListener, and other web container listeners. The servlet container is also responsible for dynamic content such as JSP, JSF, and other types of templates.
Dependency Injection (DI) is type safe, because the information is available on the Java interface or object is available to the Java compiler. DI is available across the Java EE 7 containers. In fact, all specifications are explicitly updated to rely on annotations and dependency injection, and a developer should rely on Configuration over Configuration as the preferred method to build applications.
Resource Injection (RI) is not type safe because databases, messaging endpoints, and managed executors are injected by name. In Java EE 7, these resources must be administratively created. Because the type information is unavailable, there is no way for the Java compiler to create and verify references by name through annotations (or XML descriptors).
Let's summarize this advice on dependency injection:
Sometimes there really is no other choice but to rely on Java Naming and Directory Interface (JNDI) to access a resource, bean, or connector through dependency lookup. The Java EE 7 container generates a global JNDI name for enterprise endpoints such as stateless and singleton session beans. The standard enforces the following scheme:
java:global[/<app-name>]/<module-name>/<bean-name>#<fully-qualified-interface-name>
We can, therefore, reliably access every deployed session bean portably across application servers.
Java EE 7 application servers expect user software to be packed into a JAR, WAR, EAR, or RAR file. These are all fundamentally ZIP archives.
Java Archive (JAR) files contain EJB modules and CDI Managed Beans with optional class path resources. The JAR file is the standard packaging of Java classes. EJB modules may optionally have an associated XML deployment descriptor (/META-INF/ejb-jar.xml).
Web Archive (WAR) files contain web applications. A WAR file contains special markup language HTML files, dynamic content files in the JSP or JSF form or other presentation templates, a web XML deployment descriptor (/WEB-INF/web.xml), Java classes with optional resources. The web deployment descriptor configures the context root of the application, servlets, filters, listeners, and resources such as JMS destinations, managed executors, and database connections. Library archive files are stored in the specific folder (WEB-INF/lib). Compiled Java classes have their own reserved folder (/WEB-INF/classes).
Resource Adapter Archive (RAR) files are descriptors of XML files, Java classes, and other objects specifically aimed for Java EE Connector Architecture applications. A RAR file has a XML deployment descriptor (/META-INF/ra.xml).
Here is an example of a RAR file for JCA that stores data to the container's file system:
<?xml version="1.0" encoding="UTF-8"?>
<connector xmlns="http://java.sun.com/xml/ns/connector
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/connector_1_6.xsd"
version="1.6">
<display-name>File System Adapter</display-name>
<vendor-name>JBoss</vendor-name>
<eis-type>FileSystem</eis-type>
<resourceadapter-version>1.0</resourceadapter-version>
<resourceadapter>
<resourceadapter-class>
je7hb.jca.basic.DummyResourceAdapter
</resourceadapter-class>
<outbound-resourceadapter>
<connection-definition>
<managedconnectionfactory-class>
je7hb.jca.basic.FSManagedConnectionFactory
</managedconnectionfactory-class>
<config-property>
<config-property-name>
FSRootFolder
</config-property-name>
<config-property-type>
java.lang.String
</config-property-type>
<config-property-value>
/tmp/fstore
</config-property-value>
</config-property>
<connectionfactory-interface>
je7hb.jca.basic.FolderContextFactory
</connectionfactory-interface>
<connectionfactory-impl-class>
je7hb.jca.basic.FolderContextFactoryImpl
</connectionfactory-impl-class>
<connection-interface>
javax.naming.directory.DirContext
</connection-interface>
<connection-impl-class>
je7hb.jca.basic.FSDirContext
</connection-impl-class>
</connection-definition>
<transaction-support>NoTransaction
</transaction-support>
</outbound-resourceadapter>
</resourceadapter>
Enterprise Archive (EAR) files contain one or more Java EE components, which can be EJB or Web modules. They can also contain RAR modules. An EAR file typically also has an associated XML deployment descriptor (/META-INF/application.xml).
Here is an example of an EAR file:
<?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"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/application_6.xsd"
version="7" >
<application-name>post-trade-services</application-name>
<initialize-in-order>true</initialize-in-order>
<module>
<web>
<web-uri>ptsp-portal-web-2.1.0.war</web-uri>
<context-root>ptsp-portal</context-root>
</web>
</module>
<module>
<ejb>ptsp-core-2.1.0.jar</ejb>
<ejb>ptsp-services-2.1.4.jar</ejb>
<ejb>ptsp-container-2.3.7.jar</ejb>
<ejb>ptsp-valuations-2.1.2.jar</ejb>
</module>
<library-directory>lib</library-directory>
</application>The file beans.xml configures CDI. An empty file is required in Java EE 6 in order to trigger the CDI container to start scanning and processing annotations. In Java EE 7, CDI is on by default and you no longer need this explicit file, if you don't want it. However, we recommend its usefulness for portability with older Java EE 6 and third-party frameworks.
Developers should understand where to save the
beans.xml file:
Locate the file
beans.xmlin the/META-INFfolder for EJB module, a library jar, EJB jar, an application client jar, or RAR archive.Locate the file
beans.xmlin the/WEB-INF/classesfolder for a web application archive.Locate the file
beans.xmlon the JVM's class path if there is no obvious file namedbeans.xmlin the META-INF directory of any component. (Unsurprisingly, we strongly recommend against choosing this option in a Java EE application! For Java SE, though, this is perfectly fine.)
The file persistence.xml defines the persistence unit for a Java EE application to connect to a relational database. Normally, you find one file, which contains one or two connectors to databases. Sometimes, however, there may be two or three different
persistent.xml files aimed at tackling complicated requirements in a business enterprise with several persistence database choices (separate trade, order management, and audit databases spring to our minds).
It is important for developers, to know exactly where to place the persistent.xml file:
Locate the
persistence.xmlin the/META-INF/folder for an EJB jar, a library jar or RAR file.Locate the
persistence.xmlin the/WEB-INF/classes/META-INFfolder for a web application.