[hibernate-dev] Hibernate Search compatibility with ORM 4.3

Wed Sep 4 11:59:23 EDT 2013

To better explain the SessionDelegatorBaseImpl approach, I guess this
patch is worth 1000 words:

https://github.com/Sanne/hibernate-search/commit/a5dceffba58a1ea6a820e7fa5e11ecdffd079b96

7 additions and 704 deletions: that's a good improvement :-)

The real benefit is however in the strong decoupling in both methods
and imported types from ORM to Search, making it more likely for two
different versions to be compatible.

Sanne

On 4 September 2013 16:35, Sanne Grinovero <sanne at hibernate.org> wrote:
> 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
>>
>>