[hibernate-dev] Hibernate Search compatibility with ORM 4.3

[Sanne Grinovero]

That's one possibility, but to recap all options discussed so far:

One alternative which I consider quite tempting is that we don't
implement the new methods defined in Session and EntityManager (JPA
2.1), but keeping it fully compatible in all other ways.

We have this option because I resolved all remaining issues and could
run the testsuite succesfully on both ORM 4.2 and 4.3, with these
exceptions:
 - needs to be compiled with ORM 4.3 to have access to the new types
used in the new method signatures
 - when an application is deployed on JBoss EAP 6.1 or 6.0 it fails
hard as it eagerly realizes that some types aren't availabled

In other words that means that Hibernate Search 4.4 users would
benefit from improvements in latest ORM but not from the new JPA
features.

Our options:

1# Support ORM 4.2
If we compile against ORM 4.2 with these patches, it will work on ORM
4.3 as well, as long as the new methods aren't used.

2# Gunnar's adapters
have two separate Maven modules containing the two different adaptors
needed, and bundle both in the same jar to load them via reflection

3# Proxy
Use proxies to generate the FullTextSessionImpl and
FullTextEntityManagerImpl, delegating to whatever methods are
available at runtime.

The first one is simple and conservative; the second one seems a good
idea but I've had experience with similar mess and I'm not too eager
to fall in it again, the third one is quite more complex but has
potential to get rid of these problems in the longer term.

For the longer term, we also have this class committed in ORM:
https://github.com/hibernate/hibernate-orm/blob/8c95a6077a523c47482fbae14ab54b763fa73a23/hibernate-core/src/main/java/org/hibernate/engine/spi/SessionDelegatorBaseImpl.java

It would have resolved this problem, but we can't use this approach yet as
 a) it's not included in the older ORMs yet, including some which we
should still support
 b) I forgot to make one for EntityManager :-(

Preferences?

Sanne


On 4 September 2013 12:25, Gunnar Morling <gunnar at hibernate.org> wrote:
> One option would be to (temporarily) establish an abstraction layer in
> HSEARCH, which provides a uniform way for accessing the concerned
> functionality from ORM.
>
> You would then have two implementations of this layer, one based on 4.2 and
> one based on 4.3 (e.g. in form of two separate HSEARCH modules built against
> the different ORM versions). At runtime the right implementation would be
> chosen depending on the ORM version present.
>
> I guess that would require some more coding on the HSEARCH side but IMO it
> would be the cleanest approach for addressing the issue.
>
> --Gunnar
>
>
>
> 2013/9/4 Sanne Grinovero <sanne at hibernate.org>
>>
>> There are some small changes in ORM 4.3 which are making HSearch
>> incompatible, while I'm trying to keep Search compatible with bith ORM
>> 4.2.x and 4.3 series.
>>
>> It's more complex than expected, so here is an update on what I'm doing:
>>
>> # Shadowing of interfaces being moved to new packages
>>
>> One change in particular is the move of certain Service interfaces to
>> a new package location, we discussed on IRC that a possible solution
>> would be to re-introduce a "shadow" interface: a patch to ORM
>> re-introducing the missing interfaces as deprecated extensions of the
>> new locations, so that projects compiling againts ORM 4.2 would still
>> work (not guaranteed as I'm exclusively shadowing the ones that I'm
>> needing for Search).
>>
>> In practice this solution doesn't work: we use these interface also as
>> key for a lookup in the ServiceRegistry; obviously if the key is not
>> the same class definition we fail to retrieve the service.
>>
>> At this point I tried to patch the ServiceRegistry itself to make it
>> handle specifically the backwards-friendly shadow interfaces, but it
>> looks like I can't do that as the method signature is locked-down:
>>
>> public <R extends Service> R getService(Class<R> serviceRole) {
>>   return (R) patchedGetService(); <---!!!
>> }
>>
>> At this point I have to introduce the explicit casting or it won't
>> compile, but then also the cast will fail at runtime unless I revert
>> the parent/child relation of the shadow interface.
>> It's getting a bit messy and even the "patchedGetService" isn't very
>> nice I guess.
>>
>> So on this I'm now looking for alternatives. We have two cases in
>> which the JtaPlatform is looked up, I could replace one such usage
>> with this alternative:
>>
>> -         TransactionManager transactionManager = getService(
>> JtaPlatform.class ).retrieveTransactionManager();
>> +        TransactionManager transactionManager = eventSource
>> +            .getTransactionCoordinator()
>> +            .getTransactionContext()
>> +            .getTransactionEnvironment()
>> +            .getJtaPlatform()
>> +            //.canRegisterSynchronization() <- TODO explore: possibly
>> a better option?
>> +            .retrieveTransactionManager();
>>
>> In the second case I don't have an EventSource but I have a
>> SessionFactoryImplementor.. I'm not finding a similar path to get the
>> JtaPlatform without opening a temporary Session: anyone knows better?
>>
>>
>> Tia,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>