Re: [hibernate-dev] Hibernate Search compatibility with ORM 4.3
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev