[hibernate-dev] ORM 4.2.8.Final breaks the EntityKey API and thus HSearch

Guillaume Smet guillaume.smet at gmail.com
Thu Dec 5 11:31:02 EST 2013


Well, you won't have us test 4.2.8 as we are using Hibernate Search in
all our applications and we can't use them together. It might not be a
showstopper but we usually provide useful feedback on the releases of
orm and search.

I think we should either release a fix for search or orm but it's just
my 2 cents.

I'm working on a pull request to fix the problem in search as
requested by Steve.

On Thu, Dec 5, 2013 at 5:24 PM, Brett Meyer <brmeyer at redhat.com> wrote:
> 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 at gmail.com>
> To: "Scott Marlow" <smarlow at redhat.com>
> Cc: "Hibernate" <hibernate-dev at 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 <smarlow at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



More information about the hibernate-dev mailing list