views:

35

answers:

1

My goal is pretty simple: to use ant to build an EAR which contains 1 EJB and 1 jar containing all of the dependencies. This jar, called common.jar for the sake of example has vendor jar files in it as well as other xml files that the EJB depends on and will need to be able to see during runtime....

So far I have everything packaged correctly as an EAR like this:

EARFILE.ear
 -EJBFILE.jar
   /META-INF
     -MANIFEST.MF
 -common.jar
   /META-INF
     -MANIFEST.MF
   /lib
     -(all vendor jars inside here)
   -(All the xml config files are inside the root of the common.jar)

Inside the MANIFEST.MF for the EJBFILE.jar is...

Class-path: ../../common.jar

Inside the MANIFEST.MF for the common.jar is...

Class-path: ../lib/some_common.jar

When I deploy this the appserver (websphere) cannot find the JAR file when I try to start the server. I am getting the ClassDefNotFoundError because the classes inside the EJB cant find the vendor JAR files when I try to start the instance. However I know that common.jar is setup correctly though, else the EJB wouldn't have compiled since it needed to have those vendor jars on the classpath for javac.

So what I want to know is this:

  1. How can I get the runtime to correctly see the Vendor jar files.
  2. Will the EJB be able to see the xml files at run-time? I am concerned about this because these xml files are located outside of the EJB inside of a jar that is just in the EAR, it isn't even a module its just a jar inside the EAR.
  3. Does it even matter when using websphere? From what I gather some containers don't even care what is in the Class-path of MANIFEST.MF.
A: 

There are several improvements I can suggest, based on running into similar problems.

  1. First and most importantly, use the appxml attribute of the Ant ear task to specify your deployment descriptor (usually named application.xml); also include references to the vendor JAR files bundled as defined below
  2. I would recommend you not put your vendor JAR files into another JAR - instead, just copy them into the EAR at the same level as EJBFILE.jar
  3. The configuration XML files can go in a sub-directory of the EJBFILE.jar (such as config), and then you can reference them as /config/filename.xml.

The application.xml file will tell WebSphere where to find your JAR files. Classpath traversal in an application server is not the same as that of a compiler, which JBoss has taught me the hard way.

I am using all of the above patterns, and my in-container code (deployed in the EAR) can see all my XML files, as well as find all my dependencies.

mlschechter
Hm, I didn't know you could include jars inside application.xml as non-modules?
Zombies
IF the JAR files are in the root of the EAR, you can just add each of the filenames (and `EJBFILE.jar`) as module references. The module type for the JAR files will be `java`.
mlschechter
You don't need to declare library jars as module type "java"; that will make them application client jars. Simply list them in the EJB MANIFEST.MF. E.g., Class-Path: util.jar
bkail