Inferring Application Configuration
By aseembajaj on May 04, 2007
JEE 5 makes most of the deployment descriptors optional. For example, the annotation @Stateless can be used to identify a stateless session bean instead of adding a
With configuration scattered around in source files and packaging details, an administrator might want to examine the consolidated configuration. The developer of the application might also want to examine the container’s view of the configuration for debugging. Two of the build time tools packaged with WebLogic Server help the administrators & the developers do exactly this. Both AppMerge & AppC now support a new flag “writeInferredDescriptors”. When this flag is used, these tools write out an updated version of the descriptors that include the configuration information from annotations and packaging. In case, the descriptors does not exist in the source application, these tools write out new descriptors if the flag is used.
Let’s assume we have an application flight.ear that has no descriptors. It has two archived modules:
$ jar tf flight.ear
Let’s assume that statusApp.war has no descriptors and has one Servlet that is annotated with @WLServlet annotation.
$ jar tf statusApp.war
Let’s assume that the statusCheck.jar has no descriptors either. It has some class files, one of which is a Stateless session bean that’s annotated with @Stateless & @Remote annotations
$ jar tf statusCheck.jar
If we were to invoke AppMerge in the following way, it’ll generate a new version of flight.ear, called flightX.ear.
$ java weblogic.appmerge -writeInferredDescriptors -output flightX.ear/ flight.ear
(In this example, I appended a ‘/’ at the end of flightX.ear so that the tool creates the output application as a directory. We could drop the '/' in the end (-output flightX.ear) and the tool would generate an archive.)
If we were now to examine flightX.ear, it’ll have a deployment descriptor.
$ cat flightX.ear/META-INF/application.xml
<?xml version='1.0' encoding='UTF-8'?>
Similarly, the two modules in flightX.ear would now have descriptors:
$ jar tf flightX.ear/statusApp.war WEB-INF/web.xml
$ jar tf flightX.ear/statusCheck.jar META-INF/ejb-jar.xml
These descriptors can now be examined to see how the containers would deal with the module deployment. Note that the descriptors in the modules would have “metadata-complete” attribute on the root element set to true.
The flag "writeInferredDescriptors" can also be used for deployment optimization. If we were to deploy flightX.ear, the annotation processing would not be done because metadata-complete is set to true. Module discovery wouldn’t be done either because META-INF/application.xml would now be present in the application.