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

[Gunnar Morling]

Yes, that's true. It returns null when being run for classes obtained from
a directory rather than a JAR.

I noticed the same btw. when running tests in the IDE for the injection
stuff we e.g. use in HV, but it never was a problem for us there.


2015-03-03 16:20 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> 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
>>>
>>
>>
>