Looks like this commit changed that https://github.com/hibernate/hibernate-orm/commit/bf26311474257c2f0118615... On 12/05/2013 10:51 AM, Guillaume Smet wrote: > > Hi all, > > ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId > from the constructor. > > Typically, in HSearch, we have the following call: > > https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/ja... > > As 4.2.8.Final removes the tenantId from the EntityKey constructor, > you get a nice: > java.lang.NoSuchMethodError: > > org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V > at > org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73) > >> From my point of view, the best way to go would be to reintroduce the > > constructor in EntityKey, mark it as deprecated and ignore the > tenantId. > > I think it's worth a respin and a 4.2.8.SP1. > > Thoughts? > > (btw, totally unrelated, it would be nice to have examples of the new > Maven plugin for bytecode enhancement). >

EntityKey is SPI, not API, so typically I allow changes to happen in minor releases (especially in this case where multiple changes were necessary for Wildfly/EAP). That being said, not deprecating the existing constructor was an stupid oversight on my part -- I pulled in a dozen commits at once and must have glossed over a few. However, my vote would be that this doesn't necessarily merit going through an entire SP release. I'd fix it for 4.2.9, before compatibility in other products became an actual issue. Any strong arguments against that? Brett Meyer Software Engineer Red Hat, Hibernate ORM ----- Original Message ----- From: "Guillaume Smet" <guillaume.smet(a)gmail.com&gt; To: "Scott Marlow" <smarlow(a)redhat.com&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; Sent: Thursday, December 5, 2013 11:09:42 AM Subject: Re: [hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and thus HSearch Yes. This commit looks really nice: that's what looks really interesting to me in 4.2.8. But providing a compatibility layer seems necessary. On Thu, Dec 5, 2013 at 5:06 PM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > Looks like this commit changed that > https://github.com/hibernate/hibernate-orm/commit/bf26311474257c2f0118615... > > > On 12/05/2013 10:51 AM, Guillaume Smet wrote: >> >> Hi all, >> >> ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId >> from the constructor. >> >> Typically, in HSearch, we have the following call: >> >> https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/ja... >> >> As 4.2.8.Final removes the tenantId from the EntityKey constructor, >> you get a nice: >> java.lang.NoSuchMethodError: >> >> org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V >> at >> org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73) >> >>> From my point of view, the best way to go would be to reintroduce the >> >> constructor in EntityKey, mark it as deprecated and ignore the >> tenantId. >> >> I think it's worth a respin and a 4.2.8.SP1. >> >> Thoughts? >> >> (btw, totally unrelated, it would be nice to have examples of the new >> Maven plugin for bytecode enhancement). >> > > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Thu, Dec 5, 2013 at 5:31 PM, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: > I'm working on a pull request to fix the problem in search as > requested by Steve. Done: https://github.com/hibernate/hibernate-search/pull/521 -- Guillaume

Hi all, sorry was traveling yesterday, and while I saw & merged Guillaume's pull request, I missed this conversation. We can to an Hibernate Search 4.4 minor release, would that resolve all uncomforts? The release blog would then also be an appropriate medium to warn about the incompatibility. Sanne On 6 December 2013 10:30, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: > Is there any decision taken about this? > > I find the situation to have 2 major Hibernate components incompatible > after an upgrade to a point release a bit uncomfortable. > > The cleanest way to fix it is probably to build a point release of > Search but if it's too much work, maybe we should just communicate > about it? > > Thanks for your feedback. > > On Thu, Dec 5, 2013 at 5:46 PM, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: >> On Thu, Dec 5, 2013 at 5:31 PM, Guillaume Smet < guillaume.smet(a)gmail.com&gt; wrote: >>> I'm working on a pull request to fix the problem in search as >>> requested by Steve. >> >> Done: https://github.com/hibernate/hibernate-search/pull/521 >> >> -- >> Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi all, ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId from the constructor. Typically, in HSearch, we have the following call: https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/ja... As 4.2.8.Final removes the tenantId from the EntityKey constructor, you get a nice: java.lang.NoSuchMethodError: org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V at org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73) >From my point of view, the best way to go would be to reintroduce the constructor in EntityKey, mark it as deprecated and ignore the tenantId. I think it's worth a respin and a 4.2.8.SP1. Thoughts? (btw, totally unrelated, it would be nice to have examples of the new Maven plugin for bytecode enhancement).