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:
https://github.com/spring-projects/spring-framework/blob/master/spring-orm/src/main/java/org/springframework/orm/jpa/ExtendedEntityManagerCreator.java#L219-L238 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. Thanks, Sanne 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 >>> exercise. >> >> >> 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. > > Thanks, > Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
