I think most environments would proxy the JPA contracts if anything. For
Session we do offer the "base delegator" for a delegation solution rather
than proxying.
All told, unless we hear differently I'd say you are safe to break proxying
of the Session. Assuming of course you fix the thread-based
current-session stuff which afaik is the only place we actually proxy the
Session
On Fri, Mar 9, 2018 at 7:05 AM Sanne Grinovero <sa...@hibernate.org> wrote:
> It turns out that using Bridger to restore backwards binary
> compatibility will make the Session un-proxable.
>
> Specifically any code attempint to invoke something like:
>
> Session wrapped = (Session) Proxy.newProxyInstance(
> Session.class.getClassLoader(),
> new Class[] { Session.class }
> wrapper
> );
>
> will fail at runtime, as the JDK Proxy utility can't deal with bridge
> methods.
>
> We do proxy the Session in some of our own code - which is of course
> something that could be resolved with alternatives - but I wonder if
> this approach will break many more frameworks and tools I'm not aware
> of.
>
> What do you all think, is this a deal breaker? I'm starting to think
> the cure is worse than the disease :/
>
> Thanks,
> Sanne
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
