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

[Steve Ebersole]

I think we should point out that this method is only available (iiuc) when
running with "from a jar".  Which means it won't work, for example, in our
test suites.  I assume we'd just get blanks or nulls there.

On Tue, Mar 3, 2015 at 9:18 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I just personally never knew about this method :)
>
> On Mon, Mar 2, 2015 at 10:03 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 2 March 2015 at 15:49, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >
>> >
>> > 2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> 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 ?
>> >
>> >
>> > The "Implementation-Version" value can be obtained through a standard
>> API:
>> >
>> >     Session.class.getPackage().getImplementationVersion();
>> >
>> > So it basically renders that custom method superfluous.
>>
>> Cool trick, I had no idea :)
>> So why do we have those methods? Just to log it?
>>
>> >
>> > No huge difference apart from that. Only pointing out that there is no
>> need
>> > for another "easy to consume resource in the orm jars".
>> >
>> >> 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.
>> >
>> >
>> > +1 for keeping it simple.
>> >
>> >>
>> >>
>> >> 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
>> >> >
>> >> >
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>