Packaging EJB 3 Applications

Java EE applications offer the promise of write once, run anywhere (WORA), this should clarify the portability of your application. To simplify maintenance you create a JAR to contain all your application, However, enterprise Java applications are packaged as specialized version of JAR files - EAR, WAR and EJB-JAR modules - before they can be deployed to a Java EE compliant application server.

To run your application you have to make it available to the Java EE application server, this is known as deployment. Since EJB is a core part of the Java EE specification you have to follow the Java EE standard for deployment. The deployment will contain all the components of the application - presentation, business and the persistence, you group these components into modules and each module has its own archive type.

I have already discussed deployment regarding the JBoss server, have a look for more details on deploying to a Java EE Server.

Class Loading

There is a misconception that all classes are loaded into memory when the JVM starts up, this is not true. Classes are loaded dynamically as and when they are needed at runtime, the process of locating the byte code for a given class and converting it into a Java class instance is known as class loading. However class loading is vendor specific and some vendors optimize the loading of class for example some use pooling mechanisms, also as applications grow they become more complex and library dependencies means more classes will be loaded when the JVM starts, you may see the odd ClassNotFoundException and NoClassDefFoundError.

Class loading is initially performed by the JVM when it starts up, it loads the required classes first and then the subclasses of the java.lang.ClassLoader class. These class loaders allow applications to load classes that may not be required during the compilation process. below is Sun's JVM hierarchy of three loaders

The class loader follows a Parent First delegation model, it first see's if the class is already loaded in cache, then it checks its parent classloaders and fetches it from their cache and lastly it will read from the CLASSPATH A standard archive may load classes either packaged inside it or from any other archives it is dependent on.

I have already discussed class loading in a number of application servers

• JBoss Class Loading
• Tomcat Class Loading

The picture below details class visibility when using multiple web modules, each child class will have access to its parent classes, so with this knowledge help classes should be packaged in the EAR lib directory.

Deployment Descriptors v Annotations

This debate will probably continue until either one dies, basically it is a matter of choice, annotations are suited to a static environment where as deployment descriptors are best in a more dynamic environment, however you can mix and match but remember that the deployment descriptor will override any annotations.

Here is a table that displays the mappings between annotations and deployment descriptor elements

Also vendors have specific deployment descriptors for there application server

The last table is detailing the persistence annotation association with deployment descriptors