Spring seems to choke on a single, specific method; sadly it's not
even meant to proxy a Session but it happens to do so:
This is meant to create a proxy of *EntityManager* yet when the
`emIfc` argument is null it will list all interfaces the wrapped
object implements, and pass them all to the Proxy method.
I will guess they have some good reason to do so, we could see if they
could change the approach, possibly simply blacklist the Session to
filter it out from this inferred set of interfaces, or make sure this
argument is never null.
The parameter seems to be null at least when running the Spring Data
integration tests; I would say that's not reassuring.
Either way, seems like we should abandon this idea: while this
approach could be improved in future libraries, it doesn't look like
it will help backwards compatibility of existing applications.
On 13 March 2018 at 11:50, Sanne Grinovero <sa...@hibernate.org> wrote:
> On 9 March 2018 at 13:42, Guillaume Smet <guillaume.s...@gmail.com> wrote:
>> On Fri, Mar 9, 2018 at 2:14 PM, Sanne Grinovero <sa...@hibernate.org> wrote:
>>> Thanks Steve; anybody knows about Spring et al possibly using AOP on
>>> the native Session ?
>>> Yes I'm working on the "thread-based current-session stuff" but that's
>>> massive, might be days of just coding; hoping it won't be a pointless
>> No idea but we should really check that with at least the Spring folks
>> before investing so much time in it.
>> Gaining compatibility by breaking an implicit contract we had before might
>> not be our best move.
> Sorry, forgot to send my reply.. but yes I absolutely agree, I'm
> concerned about this change. I'm trying to reach out / test at least
> with Spring and Grails as a starting point.
> In the meantime I've been working on some improvements within ORM with
> our proxies, those improvements won't hurt anyway.
hibernate-dev mailing list