On 8/10/2011 4:43 PM, Laird Nelson wrote:
> On Wed, Aug 10, 2011 at 5:42 PM, Mitesh Meswani
> <mitesh.meswani_at_oracle.com <mailto:mitesh.meswani_at_oracle.com>> wrote:
>
> IIUC, there are two probable issues we want to solve here. Please
> let me know if I am missing anything obvious here.
>
> 1. Making sure a newer version of Hibernate is available to
> GlassFish users without much delay
> 2. A hypothetical classloader issue when hibernate jars are dumped
> in $GLASSFISH_HOME/lib dir
>
>
> Not sure it's hypothetical. See "Leon"'s comment here:
> http://eskatos.wordpress.com/2007/10/09/hello-world/ Maybe that's old
> or out of date advice.
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.
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.
>
> Or perhaps what Sahoo is saying here
> (http://www.java.net/forum/topic/glassfish/glassfish/using-hibernate-glassfish#comment-814634)
> is go ahead and dump whatever you want in whatever lib directory you
> want (domain1/lib or $GLASSFISH_HOME/lib) and everything is guaranteed
> to work. I don't really have an issue with this as long as it's (a)
> truly guaranteed to work--remember, Hibernate drags in a lot of
> possibly common dependencies--and (b) is somehow magically guaranteed
> never to contain jars supplied by Oracle/Glassfish that might
> inadvertently stomp on mine.
>
> I don't see how (b) could be the case. Look at the list of
> dependencies recommended in
> http://eskatos.wordpress.com/2007/10/09/hello-world/ (which are
> already out of date, I might add). How do I know which of these
> Glassfish might decide to throw in there in the future? Or use a
> different version of? Again, if you tell me that that's all hidden by
> OSGI and it's OK for me to dump whatever I want in
> $GLASSFISH_HOME/lib, then that's fine; just make sure you and other
> package authors don't overwrite my stuff. :-)
>
> As far as issue 1 is concerned, the work you have posted on github
> will surely help. Producing a hibernate package now would just
> involve changing a property value (provided Hibernate team does
> not change artifacts between their releases). Mind you there is
> still some testing involved before the package actually gets
> pushed onto update center.
>
>
> Of course.
>
> I am not sure whether we want a more sophisticated mechanism for
> libs installed from update center till we actually see the
> classloader issue. We have never seen any issue with the testing
> (although minimal) we do here and as you mentioned you have
> neither. While the approach proposed in this mail thread is more
> flexible and allows different application to chose different
> versions of Hibernate. it is not as simple as just dumping jars in
> $GLASSFISH_HOME/lib.
>
>
> No, you are right. It is not. That's because there isn't a better
> place to put them that I know of. Maybe you know differently?
>
> To explain: I am always wary of putting things into a directory that
> is not under my control. Who knows what Glassfish stores in its own
> lib directory (besides you Glassfish guys :-))?
>
> What if one of the jar files I dump in there gets stomped on by some
> upgrade down the road? Suppose hypothetically I decide to drop
> javahelp.jar in there and--oh, wait, javahelp.jar is already in
> there. :-) Hmm.
>
> What if, for example, the hibernate.jar I dump in there includes a
> dependency that later on you decide to forcibly include in there
> yourself, but with a different version?
>
> I hate mixing user stuff and system stuff, and I hate mixing
> my-customization-of-system stuff with your-official-system stuff. :-)
>
> My proposal is--backing waaaay up--is (looked at another way) to
> introduce, I guess, another kind of lib directory: one for community
> upgrades, package installations, etc. that doesn't rely on people
> crossing their fingers, dumping things in $GLASSFISH_HOME/lib, and
> hoping that no one else will mess with its contents in some way that
> will screw things up. --libraries is a convenient way to do this;
> there may be others.
>
> Short of adding such a directory to Glassfish, I thought that an
> IPS-controlled dump into an off-to-the-side area was a relatively
> conservative way to play it. Then people could use it (via
> --libraries) as they saw fit.
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.
Thanks.
Mitesh
>
> Looking forward to comments,
> Best,
> Laird