[hibernate-dev] Hibernate Search compatibility with ORM 4.3

[Gunnar Morling]

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
>