On Wed, Aug 10, 2011 at 5:42 PM, Mitesh Meswani
<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.
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.
Looking forward to comments,
Best,
Laird