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.s...@gmail.com> To: "Scott Marlow" <smar...@redhat.com> Cc: "Hibernate" <hibernate-dev@lists.jboss.org> 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 <smar...@redhat.com> wrote: > Looks like this commit changed that > https://github.com/hibernate/hibernate-orm/commit/bf26311474257c2f0118615e003553095c2d87b0 > > > 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/java/org/hibernate/search/query/hibernate/impl/PersistenceContextObjectsInitializer.java#L74 >> >> 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@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
