views:

47

answers:

2

If I create a utility project and multiple dynamic web projects within Eclipse and set it up so that dynamic web projects depend on the utility project, I'm guessing that I will have to redeploy all the dynamic web projects to the server if at some point I make enhancements to the utility project. If I understand correctly, setting dependancies will package the utility classes into each dynamic web project's WEB-INF/lib folder thus creating multiple have copies of the utility jar/classes.

But is there a way to have one copy of the utility jar/classes deployed to my server and shared between my apps? I work for a company that has a Configuration Management procedure (red tape, paper work, no value added) so I'd rather not have to redeploy ALL my apps and go through the CM process everytime I make a change to my utility class. I'd like to be able to CM the utility and then have all my apps just start using the updated utility project.

+4  A: 

In Eclipse, reference the utility project in build path, but do not export it as JEE module dependency. To share it among all webapps on the same server, just drop in server's classpath. It's unclear which one you're using, so I can't give a more detailed answer. In case of Tomcat it's the /lib folder. Alternatively you can also add its path to Tomcat's shared classpath as definied in catalina.properties. After updating, just restarting/redeploying should be sufficient to get the webapp(s) to pick the changes. Other servletcontainers/appservers offers similar possibilities. See also Tomcat Classloader HOW-TO.

BalusC
Note: test, test, test.
BalusC
@BalusC, Both you and Chris Aldrich gave spot on anwsers. But you have 500 times the reputation as Chris! Every one knows who BalusC is - your reputation precedes you! So since I can only accept one answer, I will help Chris out and accept his answer.
jeff
+2  A: 

First of all from a governance perspective you should know what all uses that jar and what will be affected by a change to it.

If you could be impacting multiple projects, then it might be better to actually package it with the application, as you can control when you "upgrade" to the newest version of the jar on a per project/application basis.

If you want to update them all at the same time without redeploying them all, then it might be best to place the file in a spot that is accessable to your application server (a shared library directory).

Then set up your application to add that jar to its classpath. Now if you update the jar it affects all of them at once.

You still may need to bounce the applications or the server for the change to take affect (depends on the server).

Chris Aldrich
+1 to the governance, and work it out earlier rather than later! If application X breaks because of a change in your utility jar that Team X couldn't be bothered to update against... not fun. Then again supporting several versions at once is no fun either.
Rodney Gitzel
I totally agree about the governace. I actually wrote about that concern in my question but deleted it before submitting because I was in a sense answering my own question and I also didn't want to influence the answers.
jeff