Application Packaging and deployment has always been an interesting topic for most enterprise java developers. The Java EE 5.0 that became proposed final draft a couple weeks back certain enhancements that may life easier for developers.
The most notable changes are:
Packaging of a deployment descriptor in EAR is optional
We will no longer require packaging an application.xml in an EAR and the container will determine the type of applications based on its name and introspecting its contents. For example, an EAR contains the following modules and does not contain the descriptor:
MyWeb.war
OurCon.RAR
YourEJB.jar
HisClient.jar
MyWeb.war and OurCon.RAR will be treated as web and resource adapter modules respectively based on their names.
The container will read the contents of modules with .jar extension (YourEJB.jar, HisClient.jar)
-
If it finds an ejb-jar.xml or any classes with EJB annotations such as (Stateless, MessageDrivenBean, etc) the container will assume that to be an EJB module.
-
If the jar module contains either an application-client.xml or Manifest file with Main-Class entry. It will ignore any jars if above
-
Other jar files will be ignored.
Ability to package library jars at the EAR level
Now we can package common jar files in a standard manner without depending upon proprietary extension supported by application server vendors. You can put common libraries into a library (named lib by default) directory as follows and the classes packaged in the library will automatically available to all modules.
MyWeb.war
YourEJB.jar
lib/ourCommon.jar
Using library-directory element in the application.xml packaged in the EAR file can customize the name of this lib directory.
Ability to express dependency on Installed JAR files
Either an EAR or modules in an EAR can express dependencies on installed jar files by using the Extension-List as specified for Applet by Java SE specification. If an EAR expresses dependency on an installed jar by using this mechanism then the classes packaged in the JAR will be available to modules in the EAR.
This will address some inconvinience and portability issues with EAR between application server vendors. I wil some other changes in this area in future.
6:35:44 AM 
|
