[hibernate-dev] Hibernate Search compatibility with ORM 4.3

[Gunnar Morling]

I'm not yet understanding #1. When compiling against 4.2, wouldn't the new
methods be missing or, if you added them, refer to types not being present
with 4.2? How would this option exactly look?

For the adapters to work in this particular case, I think you'd have to
move FTSI and FTEMI to the adapter modules which does not seem so nice,
given that they are such central classes.

So I think I'd go for the proxy approach. As you say we could get rid of
the proxies once we depend on an ORM version which has this
delegating/forwarding base class. And in the long-long term we might even
benefit from Java 8 default methods for this kind of issue :)

--Gunnar



2013/9/4 Sanne Grinovero <sanne at hibernate.org>

> 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
> >
> >
>