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

On 9 March 2018 at 13:09, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > 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 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. > > On Fri, Mar 9, 2018 at 7:05 AM Sanne Grinovero <sanne(a)hibernate.org&gt; 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<div class="gmail_extra"><br><div class="gmail_quote">On 9 March 2018 at 13:09, Steve Ebersole <span dir="ltr">&lt;<a href="mailto: steve(a)hibernate.org&quot; target=&quot;_blank&quot;&gt;steve(a)hibernate.org&lt;/a&gt;&amp;gt;&lt;/span&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think most environments would proxy the JPA contracts if anything.&nbsp; For Session we do offer the "base delegator" for a delegation solution rather than proxying.<div><br></div><div>All told, unless we hear differently I'd say you are safe to break proxying of the Session.&nbsp; Assuming of course you fix the thread-based current-session stuff which afaik is the only place we actually proxy the Session</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 9, 2018 at 7:05 AM Sanne Grinovero &lt;<a href="mailto:sanne@hibernate.org" target=&quot;_blank&quot;&gt;sanne(a)hibernate.org&lt;/a&gt;&amp;gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It turns out that using Bridger to restore backwards binary<br> compatibility will make the Session un-proxable.<br> <br> Specifically any code attempint to invoke something like:<br> <br> Session wrapped = (Session) Proxy.newProxyInstance(<br> &nbsp; &nbsp; &nbsp; Session.class.getClassLoader()<wbr>,<br> &nbsp; &nbsp; &nbsp; new Class[] { Session.class }<br> &nbsp; &nbsp; &nbsp; wrapper<br> );<br> <br> will fail at runtime, as the JDK Proxy utility can't deal with bridge methods.<br> <br> We do proxy the Session in some of our own code - which is of course<br> something that could be resolved with alternatives - but I wonder if<br> this approach will break many more frameworks and tools I'm not aware<br> of.<br> <br> What do you all think, is this a deal breaker? I'm starting to think<br> the cure is worse than the disease :/<br> <br> Thanks,<br> Sanne<br> </blockquote></div> </div></div></blockquote></div><br></div>

On Fri, Mar 9, 2018 at 2:14 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; 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.