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

[Sanne Grinovero]

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