Hi Kristian
I feel your pain. I've really struggled putting things in the domain lib
with GlassFish.
Basically I have banned anything in the domain lib except the database
drivers for my sanity sake.
Apache Tomcat has the concept of a shared/lib (that all the web apps use)
and a common/lib that Tomcat and everything uses.
This prevents this kind of thing.
What I would suggest is create a EJB project with your core logic and
dependencies and use that in your web front ends.
All the more static logic goes into the EJB, and then the more dynamic logic
goes into the war.
hope this helps
Richard.
2009/9/23 Kristian Rink <rink_at_planconnect.de>
> Folks;
>
> just found a peculiar behaviour in b64 while trying to get our app to run
> there: In gfv2, we deploy most of the (shared) jars used by all the webapps
> making up our application to domain1/lib/ in order to keep the wars smaller
> (most of this code is third-party and/or open source stuff anyway). Just
> tried the same thing straightforward in b64, restarted the domain, to
> figure
> out the admin gui is not starting anymore. Exception to be found in the log
> file:
>
> [...]
>
> [#|2009-09-23T15:10:15.498+0200|SEVERE|glassfish|javax.enterprise.system.core.org.glassfish.internal.data|_ThreadID=21;_ThreadName=Thread-3;|Exception
> while invoking class com.sun.enterprise.web.WebApplication start method
> java.lang.Exception: java.lang.IllegalStateException:
> ContainerBase.addChild: start: org.apache.catalina.LifecycleException:
> com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! This
> parser does not support specification "null" version "null"
> at
> com.sun.enterprise.web.WebApplication.start(WebApplication.java:124)
> at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126)
> at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:229)
> at
> org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:214)
> at
>
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:307)
> at
>
> com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:307)
> at
>
> com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:285)
> at
>
> com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:100)
> |#]
>
>
> [#|2009-09-23T15:10:15.499+0200|SEVERE|glassfish|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=21;_ThreadName=Thread-3;|Exception
> while loading the app
> [...]
>
>
> Playing with the dependencies a little, I figured out that this behaviour
> can be "reproduced" by copying a xercesImpl.jar (i.e. [1] which is used
> here) to domain1/lib/ and restarting the domain.
>
> Is this an issue in gfv3, or should I (same as not including servlet jars
> in
> a webapp) keep such code out of domain1/lib/ generally? At least this
> behaviour differs from how gfv2 does it...
>
> Cheers,
> Kristian
>
>
> [1]
> http://repo1.maven.org/maven2/xerces/xercesImpl/2.4.0/xercesImpl-2.4.0.jar
>
>
> --
> Dipl.-Ing.(BA) Kristian Rink * Software- und Systemingenieur
> planConnect GmbH * Könneritzstr. 33 * 01067 Dresden
> fon: 0351 215 203 71 * cell: 0176 2447 2771 * mail: rink_at_planconnect.de
> Amtsgericht Dresden HRB: 20 015 * St.-Nr. FA DD I 201 / 116 / 05360
> Geschäftsführer: Stefan Voß, Karl Stierstorfer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>
>