tags:

views:

3353

answers:

1

So I started with a web services project (just a dynamic web project) that builds and debugs correctly from eclipse. We've pulled a chunk of common code out that we want to put into a shared library so now those classes are going into a separate jar project that the web project references.

On the web project, I did Project->Properties->Java Build Path->Projects->Add and added the jar project. And this correctly solved all the compile-time classpath problems and everything builds fine. But at runtime, when the tomcat server fires up, spring attempts to inject some of the classes contained in the jar file and I get a NoClassDefFoundError.

My .class and properties files and the contents of my META-INF directory are showing up in the ./build directory, but my WEB-INF/lib directory seems to be referenced in-place, and the jar dependency doesn't get copied in to it to show up as part of the Web App Library.

What is the magical incantation to tell eclipse that the other jar project needs to be available to tomcat at runtime? From our ant build script, we first just build the other project into WEB-INF/lib and everything works fine, but not for eclipse debugging.

+4  A: 

J2EE/JEE module dependencies would solve this problem. You have already done the task of extracting your common classes into its own project, possibly because other projects depend on these classes. Either way, you'll have to ensure that this is a Utility project (appears under J2EE/JEE in the project wizards), and not just a plain Java project. One that is done, you can proceed to add the Utility project to your build path (compile-time path) as you have figured out.

The additional (final) step is to establish a J2EE/JEE module dependency between your Dynamic Web project and the shared library, which causes the utility's classes to be placed in WEB-INF\lib during deployment, and even during export of the WAR. To do so, visit the dynamic web project's properties, and browse to the J2EE/JEE module dependencies. Ensure that your utility project is selected here. Redeploy/publish your application and you should be good to go.

Vineet Reynolds
That seems to have done the trick, but I'm not sure about what you were saying about it being a "Utility" project. Is there something I can see in my .project file or in .settings/ that would let me know it was the right type?
Brian Deacon
Utility projects are Java projects, though they are more apt for the J2EE context. They represent your code (not third party JARs) that are shared across multiple projects in your Enterprise App. Usually these are classes used across multiple EJBs and often a single Web module.
Vineet Reynolds
I normally do not place Utility projects in plain vanilla Java projects, because Utility projects will have the Server's runtime JARs automatically added to the classpath. For instance I could utilize datasources from the same project without adding the container's JARs to the build path.
Vineet Reynolds
And to answer your question about checking the type of the project, you can check the natures of your project in the .project file. For instance, plain Java projects have the org.eclipse.jdt.core.javanature as the only nature in my Ganymede workspace.
Vineet Reynolds
Very helpful. Thank you!
Brian Deacon