On Wed, Aug 10, 2011 at 8:24 PM, Mitesh Meswani
<mitesh.meswani_at_oracle.com>wrote:
> The blog refers to GlassFish V2. For GlassFish3+ the jars placed in lib
> dir will not affect GlassFish runtime. See
> http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beadf.html for
> details about classloader hierearchy [sic].
>
Ha; I was just there. :-) So tell me this: who put javahelp.jar in
$GLASSFISH_HOME/lib? :-) How do I know my future xyz.jar placed in the
same library won't be overwritten?
> The comment "We want log4j, commons-logging to be loaded by the application
> classloader, so the configurations thereof apply to the application." is
> interesting. If a user requires a shared library but one classloader
> instance per app for the library, the simple approach will not work. IMO,
> this is an "advanced" use case.
>
I agree. It does seem to be common in Hibernate land, however. I am
unfortunately not a Hibernate *or* a log4j **or** a commons-logging guy.
We are mixing two things here. There is no doubt that --libraries mechanism
> is more flexible and robust. I am not sure whether it is a goal of update
> center to support this. In any case, if we decide to go that route, a
> discussion needs to happen on dev alias about formalizing the mechanism.
>
OK.
Best,
Laird