We are currently working on a J2EE application, business logic being archived as jar and web-application archived as war files.

This structure looks fine, till we try and include a custom utility classes which needs to work along with the business logic as well as with the web-application. As J2EE does not clearly defines a proper place for this utility package, we have to package it along with the war file. This is clearly a disadvantage for us, as the classpath has to be modified to call these utility classes seperately.

Also, structurally, web-archive classloader is a child of application classloader and not vice versa. Hence jars deployed inside the lib folder of web-archive are not visible to application. Therefore, this causes a major confusion and classpaths issues.

Our Suggestion: Can we have a lib folder at the application level similar to the lib folder under webapp so that, anyone can include their custom libraries at the application level and it will be automatically visible to entire ear, therefore no classpath changes are required.

Anyone, facing similar issues??

I guess it may depend on what application server you are using. If you want a jar to be global it is usually possible to start the server with the jar in its classpath. (At least with weblogic - I dont see why it shouldnt be possible for any server.) Find the script that starts the server and add something like
export CLASSPATH=$CLASSPATH:somelibrary.jar for a Unixbased system.

I think the best option would be to put add a manifest entry for the utility jar file. This manifest file entry can be put in manifest file of the war file or the ejbs. This way the utilities can be shared across both the web classloader and application classloader. I mean the utilities will be loaded as part of the application classloader (parent of the web classloader).
EAR should be self contained, hence I would put util.jar inside the ear and not in the system classpath. This 'manifest entry' approach is much more flexible.
Mohit

In WebLogic 8.1 (7.0 too? I'm not sure), putting your shared
jars and classes in APP-INF makes to globably available to the entire
ear.

So the structure would look like

EAR FILE
----------
APP-INF/lib/util.jar
APP-INF/classes/Util.class
META-INF/MANIFEST.MF
META-INF/application.xml
ejb1.jar
ejb2.jar
webapp1.war
webapp2.war

This seems to be an ideal solution for this nature of problems. But, this makes web application, application server specific. I guess only Weblogic 8 support this feature of creating APP-INF apart from WEB-INF.

We looked into the J2EE 1.4 specs, but there also this has not been addressed. We hope J2EE specs committee do look into this issue and incorporate this solution.

Other traditional solution, which other people also suggested are modifying application deployment classpaths or modifying INF files. These solution does not make your application portable across other application servers and deployments scenarios.

Isnt it good enough? if so why not, I haven't seen comments on this