we internally only use class-path entry in the manifest files in war/ejbjar files and include the jars in the ear. The application.xml was (afaik) appserver specific
I'm afraid in my experience getting the libraries loaded correctly in different app servers (or even different versions of the same app server) is a "black art".
From memory, adding the libraries as elements in a module definition worked ok within single applications.
If there are libraries which should be shared accross multiple applications (or multiple ear packages) then it is worth giving serious thought to putting those libraries into a shared location - the serverconfig/lib directory in jboss for example.
You two seem to imply that you CAN reference libraries in the application.xml
This is where i'm not completely sure. But the only thing i found was a module type called 'java'. This is for application clients, NOT for libraries.
So for referencing libraries in .ear files, i currently don't see any alternative then the Class-Path entries in the manifest. Or am i missing something here ?
If there are libraries which should be shared accross multiple applications...
I want to provide a .war with jbpm configured for standard java. And i want to provide a .ear with jbpm configured for enterprise java.
In the documentation, we should describe the jbpm library dependencies. And on the wiki, we can have pages describing the concrete steps for each specific server.
That is what i currently have in mind. Let me know if you see different or just think this is crap :-)
Sounds ok in theory.
What exactly is going into the .ear file?
C:\wsjbpm\jbpm.3_HEAD\enterprise\target>unzip -l jbpm.ear Archive: jbpm.ear Length Date Time Name -------- ---- ---- ---- 0 07/11/06 11:08 META-INF/ 335 07/11/06 11:08 META-INF/MANIFEST.MF 532 03/11/06 12:03 META-INF/application.xml 3511 07/11/06 11:08 jbpm-configs.jar 4726557 07/11/06 11:08 jbpm-console.war 24768 07/11/06 11:08 jbpm-enterprise.jar 664283 07/11/06 11:08 jbpm-jpdl.jar 41395 07/11/06 11:08 jbpm-identity.jar -------- ------- 5461381 8 files
Just had a look at the JEE 5 spec (JSR 244), section EE.8.1.2Application Assembly talks about how to put together .ear files and section EE.8.2Library Support goes on to describe how to include libraries.
Option 2 in section 8.1.2:
A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file?s deployment descriptor contains the name of this directory. If a library-directory element isn?t specified,
or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify
that there is no library directory.
All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bundled
with the application or installed separately, using any of the techniques described herein.
Which sounds like what you are trying to achieve?
That whole section is probably worth a read as it covers the whole ear assembly...
for JEE 5 the lib directory seems indeed the way to go. but i want to concentrate only on J2EE 1.4 for now.
ah... but we could already put the libs in a lib folder so that we are prepared for the jee 5 packaging :-)
I'm all in favour of small steps towards jee4 ;)
or jee5 even!
I apologize if I've missed the answer to this question elsewhere, but does JBoss-5.0.0-Beta1 support the JEE 5 /lib directory in the root of ear file?
I have a JEE 5 application that I've been using on glassfish, with shared library jars in the /lib folder of the ear file, but I am unable to deploy this application on JBoss 5... I get a NoClassDefFound exception for each class in the shared library jars (during deployment of EJBs).
I'd just like to know if I still have to do the ear's manifest Class-Path thing...
... And I'd much rather be using JBoss...
Thanks in advance!
wrong forum.. use the jboss AS forum for this.