[hibernate-dev] Proxying the Session: a requirement ?

[Sanne Grinovero]

On 9 March 2018 at 13:09, Steve Ebersole <steve at hibernate.org> 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 at 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<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 at hibernate.org" target="_blank">steve at hibernate.org</a>&gt;</span> 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 at hibernate.org" target="_blank">sanne at hibernate.org</a>&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>