Hi Laird,
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
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.
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. I want to understand the
hypothetical classloader issue more before we decide to give away the
simplicity.
Thanks,
Mitesh
On 8/10/2011 1:53 PM, Laird Nelson wrote:
> On Wed, Aug 10, 2011 at 4:40 PM, Mitesh Meswani
> <mitesh.meswani_at_oracle.com <mailto:mitesh.meswani_at_oracle.com>> wrote:
>
> While I understand that the version of Hibernate is out-of-date in
> update center and needs to be updated, I am not able to totally
> grasp what is being proposed as the solution here. Are you
> proposing that GlassFish update center will have multiple versions
> of Hibernate and user can chose the version that he wants to use
> with his application using the mechanism described above?
>
>
> No, although that doesn't sound so bad. :-)
>
> I'm proposing a hibernate add-on package that is easy to maintain so
> that we don't go years in between upgrades. I'm also proposing that
> the current Hibernate support be constructed and packaged in such a
> way that it can be used when applications want it, and not part of the
> running classpath when applications don't want it. I was informed
> that --libraries was the best way to accomplish this.
>
> I was also told that Update Center is a great way for delivering
> packages to end users without any hunting, and for upgrading those
> packages when called for.
>
> Lastly, I was told that IPS packages should not attempt to install
> inside domains/domain1 (or any other "user space" areas), which makes
> all kinds of sense.
>
> The net result was that I was proposing:
>
> * A Hibernate package consisting of an empty jar with a MANIFEST.MF
> file with a Class-Path: in it pointing at jar files in a
> well-known sibling directory
> * Locating this package in some off-to-the-side directory under,
> say, domains. Something like domains/applibs.
> * asadmin deploy be updated to resolve relative file names both from
> within a domain's applibs directory (as it does today) and from
> some domain-independent directory somewhere (like, say,
> domains/applibs, or simply $GLASSFISH_HOME/applibs--doesn't matter
> to me).
>
> The goal behind including Hibernate in update center is to provide
> "out-of-the-box-ease-of-use".
>
>
> Understood. If I'm reading the "please allow Hibernate to be used in
> Glassfish" history properly from all over the web, the current Update
> Center Hibernate package doesn't even work entirely properly (though I
> confess it works OK for our company). Dumping Hibernate in the main
> lib directory doesn't either. Nor, apparently, does simply packaging
> Hibernate in your application. I'm looking for an easy-to-use out of
> the box solution to this problem.
>
> I would vote for documenting the mechanism above in general for
> any external library that can be used with GlassFish and not
> implementing it as part of update center for a specific external
> library.
>
>
> As arcane as I find the update center and IPS, I would vote for
> keeping it as the distribution mechanism for interesting third-party
> libraries that thousands of developers need on a daily basis, or
> popular alternative implementations of standards. For other
> company-specific stuff, or odd bits that are better packaged with your
> own application, I obviously wouldn't condone such things.
>
> Best,
> Laird