[hibernate-dev] To identify the version of Hibernate ORM at runtime

[Steve Ebersole]

It was the "release family".  4.3, or 4.2...
On Mar 2, 2015 9:22 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:

> On 2 March 2015 at 15:05, Steve Ebersole <steve at hibernate.org> wrote:
> > Hmm, I had used to set the set the Specification-* entries too, but it
> looks
> > like those are no longer there :(
>
> Just out of curiosity, what would these define?
> But not too bad, I think I'll simply rely on parsing
> org.hibernate.Version#getVersionString
>
> > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> > Or we could improve on those methods, if not actually adding some easy
> >> to consume resource in the orm jars.
> >>
> >> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF
> >> ->
> >> key "Implementation-Version"?
>
> Right that could work as well. There will be many manifests on
> classpath I'd guess, but we could identify the one from ORM from the
> other keys, such as Bundle-Name, Implementation-Vendor-Id, etc..
> But how would that be better over using
> org.hibernate.Version#getVersionString ?
>
> I guess one benefit of basing on resources would be that we'd be able
> to check for duplicate ORM jars, but are we interested into going to
> that length? It wouldn't be fool-proof either, as in a modular world
> it's possible that ORM version A has visibility on Search (and
> attempts to start it) but Search could be validating on resources from
> ORM module B - and not be able to "see" ORM version A's resources. I
> guess I'd stick with the method invocation, as obviously we can't
> implement a bullet proof validation either way.
>
> Sanne
>
> >>
> >> Based on that you should be able to raise a meaningful error if the ORM
> >> version is "too old". It doesn't help with incompatible future ORM
> >> versions, but it should improve the experience in some cases.
> >>
> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> > All,
> >> > it looks like people get easily confused by which version of ORM is
> >> > compatible with - for example - Hibernate Search.
> >> >
> >> > The expected versions are documented plenty, in readme, project
> >> > sources, documentation and we even remind about the expectations
> >> > frequently in blog posts.
> >> >
> >> > Wondering if it would be more effective to have some marker in ORM, to
> >> > validate at least for most critical known incompatibilities at
> >> > runtime?
> >> >
> >> > I realize there is no 100% foolproof in any possible solution, but
> >> > providing a nice error message to 90% of these cases could be helpful
> >> > to a large population already, and doesn't seem too complex for us to
> >> > do.
> >> >
> >> > I guess it could be simple enough to use the existing
> >> > org.hibernate.Version ?
> >> > Or we could improve on those methods, if not actually adding some easy
> >> > to consume resource in the orm jars.
> >> >
> >> > WDYT?
> >> >
> >> > Sanne
> >> >
> >> >  - https://hibernate.atlassian.net/browse/HSEARCH-1816
> >> >  -
> >> >
> >> >
> http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>