Can I add another lib directory to the server for static jar

[kurt_olsen]

Does anyone know if there is a configuration file in JBoss 4.0.4GA that will allow me to add another 'lib' directory to my desired server configuration?

Our co. has a large number of third-party jars that our application relies on and I'd prefer not to copy them into the standard server lib dir.

We have several ejb3 files we'd like to deploy, but they depend on the third-party stuff - which would typically require us to copy the static jars into the servers lib folder and then deploy the ejb3's

The the number of static jars we rely on is subject to frequent change. Typically, a subsystem developer will require a jar, and put it into our development 'jar pool' - At deployment time we have been copying all of these into the servers lib dir - The problem is that when a jar is no longer needed, we need a way to delete it from the servers lib dir.

I really don't want to have to maintain (in ant) an exact list of these jars so that we can 'clean' the servers lib dir ocassionally. It will more often than not be out-of-date and cause problems.

A better solution for us would be to have another 'lib' folder that the server draws upon, along with the standard server lib folder. I if had this directory then I could delete everything within it before deployment to prevent clutter-n-conflicts.

Thanks,
Kurt

[kurt_olsen]

I found a solution I think. I'm runing the jboss/server/all profile. In this case, if you examine the server/all/conf/jboss-service.xml file you would see this at the top (in 4.0.4GA):

<classpath codebase="${jboss.server.lib.url:lib}" archives="*"/>

I added this just below it.

<classpath codebase="lib2" archives="*"/>

Then, before starting JBoss I created the jboss/server/all/lib2 folder and added our static jars into it. After restarting JBoss, it correctly seems to have added the lib2 folder to the classpath.

Now, if in doubt about the integrity of our static jars I can delete everything in lib2, run our build script and re-populate it without fear of removing any of the jars jboss needs to run.