Hi,
> I have been working on this problem for one whole day but in vain without
> any effective solution.
>
> I have an ear file packaged with an ejb and a handful of jar files
> (including hibernate and the other dependent jar files).The ejb is stateless
> and enabled as a web service.
>
> The ear file has been packaged using maven and has the below structure
>
> ear->projectrelatedejb.jar
>
> ->hibernate.jar
>
> ->otherdependent. jar
>
> ->META-INF/application.xml
>
> ->META-INF/manifest.mf
>
> The application.xml and manifest file are automatically generated by maven
> when I do a package.
>
> When I deploy this ear file on glassfish it gets deployed with the ejb
> methods being accessible using web services. However when accessing the
> application (using soapui),
> the ejb methods that perform some database functionality using hibernate
> throw java.lang.NoClassDefFoundError for the hibernate api during runtime.
>
> It is obvious from the error that the hibernate jars are not on the
> classpath during runtime but since the jars are within the ear Glassfish
> should have
> added it to the application classpath.
>
By EE spec requirement, the ear library jars need to be placed in the
ear library directory to be accessible to the modules. So this is the
expected behavior that the library jars at ear root level were not
automatically added to the classpath.
> I tried various options like adding the classpath entries to the manifest.mf
> during the package (by using the elements
> <manifest><addClasspath>true</addClasspath></manifest
> with the maven-ear-plugin) which didn't do any good.Also with Glassfish we
> cannot add the dependent jars as modules to the application.xml unless the
> jars are application client jars
> (Glassfish wouldn't deploy the ear file if the application.xml has the
> dependent jars declared as modules).
>
Yes, the <java> element in the application.xml is for the appclient
module and not library jars.
> I also tried placing the jars in the lib directory within the ear (which
> isn't actually required) and with the manifest Class-Path header referencing
> the jars in the lib directory which also didn't fix the problem
>
Not sure why the above did not work for you, these two options should work:
1. Put the library jars in the ear library directory (the default is
"lib", you can also specify a name for the directory in the
application.xml). The ear lib library jars will be visible to all the
sub modules in the ear without need any further manifest Class-Path
entries.
OR
2. In the sub module which needs to reference the library jars, put a
Class-Path entry in its Manifest file to explicitly reference the
library jars it needs.
> The quick and dirty fix which I can do to get this working is to place the
> hibernate and the other the dependent jars in Glassfish's lib
> directory.However,this is a bad practice
> and I am somewhat reluctant to do it.
>
Yes, if you put the dependent jars in the glassfish lib directory, the
library jars will be visible to all the applications which may cause
undesired behavior.
There is one alternative here if you don't want to package the library
jars in the application but still want the library jars only visible to
this application, you can use --libraries option of the deploy command
(or equivalent libraries field in the admin console).
But from your description, putting the library jars in the ear lib
directory seems the most straightforward approach for your case:
ear->projectrelatedejb.jar
->lib/hibernate.jar
->lib/otherdependent.jar
->META-INF/application.xml
Please give it another try and if it still doesn't work, maybe you could
provide your test case or more details of the application to discuss
further.
- Hong
> I would really appreciate if someone can provide me with a working solution
> to this problem.I have gone through the net looking for this problem
> but couldn't find any solution.
>
> Wondering if its a bug with glassfish or does glassfish need something
> special to reference the jars in an ear.
>
> Thanks in advance.
>