Women in Technology

Hear us Roar



Article:
  Understanding Classloaders: log4j in a J2EE Environment
Subject:   Using common libraries in an hot-deployment environment
Date:   2003-06-23 13:20:16
From:   stef_84
...good article putting all the things in the correct way.


Still, one question remains open for me (and actually is an issue in the project I am working in...): Using common libraries (as log4j in your example) in an hot-deployment-environment.


By "hot-deployment-environment" I am not talking about hot-deploying an .ear-file (copy it over to the BEA-dir and it will be deployed without restarting the app-server). I am talking about the hot-deployment of all parts of your web-app, respectivly JSP's, classes and property-files. Therefor you have to deploy your web-app as an "exploded directory", meaning forget about the .war-file and copy over a "normal" directory-structure.


If your web-app is still accessing some EJB-layer, then you could deploy this one as an .ear file. From this moment on (as described in the article) you got two applications with two different class-loaders.


This means for all common libraries: They have to be known to the web-app (/WEB-INF/lib) as well as in the .ear file, meaning they have to be redundantly in both structures. Is that correct or is there any other way around?


The consequence for the overall deployment-process is that we have two different approaches with two different build-scripts: one for hot-deployment and one for the "final" build that kicks out one big .ear-file including the .war and the ejb-layer.


Why is BEA not behaving let's say like JBoss and unpacking the .ear file to an exploding directory-structure therefor allowing it at a later point to exchange classes, JSP's or whatever?


Hints, comments welcome.


Greetings, Stefan