To my understanding, utility jars can be referenced by including them in a Class-Path entry in the manifest file of a jar.
There are a couple of articles here:
you can also define all the utility jars in the application.xml file.
<module> <java>util.jar</java> </module>
it's not portable (but why would you ever want to leave jboss), but it does work and i find it's easier then dealing w/ the manifest files.
Along the lines of this thread, and having tried the suggestions, I still have the following problem:
I have the need to have an EJB and a WAR in a single EAR. Originally, the jars are in the WAR (WEB-INF\lib). When I add the EJB, I need the ejb and the war to share those jars, originally in the web-inf\lib. They need not remain at the web-inf\lib directory. Preferably, we have a top-level directory "lib" that has all shared jars in it, or the jars sit at the top level of the ear.
We are using maven to build the ejb/war/ear, and on JBoss 3.2.3.
I have tried putting all the utility jars in a single "common.jar" and putting that in the manifest classpath. No luck.
I have tried changing all the <war.bundle> tags to <ear.bundle>, hoping to put all the jars at the top level, making them available to both. No luck.
I have tried using the <ejb.manifest.classpath> and <war.manifest.classpath> tags. No luck.
have you tried defining the jars in the application.xml file inside the ear?
what you'll end up having is something like this (there are no jar files contained in the WEB-INF\lib directory of the war):
and your application.xml file will look like this:
<?xml version="1.0" encoding="UTF-8"?> <application> <display-name>My App</display-name> <module> <java>utility.jar</java> </module> <module> <ejb>ejb.jar</ejb> </module> <module> <web> <web-uri>webapp.war</web-uri> </web> </module> </application>
hopefully this will help get you past your problems.
BTW, I think the classpath in MANIFEST way is cleaner.
Here's another question along the same thread. What if I a class within an ejb.jar within an ear and I want to access utility classes bundled into another ear. How would want configure that ?
read this wiki page
you are better off externalizing the utility classes bundled in the other ear into it's own standalone library that is deployed seperately.
the wiki page looks at it from the standpoint of doing hot deployments, but the overall idea is the same.