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

[Sanne Grinovero]

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