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 <st...@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 <st...@hibernate.org> > wrote: > >> I just personally never knew about this method :) >> >> On Mon, Mar 2, 2015 at 10:03 AM, Sanne Grinovero <sa...@hibernate.org> >> wrote: >> >>> On 2 March 2015 at 15:49, Gunnar Morling <gun...@hibernate.org> wrote: >>> > >>> > >>> > 2015-03-02 16:22 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>: >>> >> >>> >> On 2 March 2015 at 15:05, Steve Ebersole <st...@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 < >>> gun...@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 <sa...@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@lists.jboss.org >>> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > >>> >> >> _______________________________________________ >>> >> >> hibernate-dev mailing list >>> >> >> hibernate-dev@lists.jboss.org >>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > >>> >> > >>> > >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
