On 9 March 2018 at 13:09, Steve Ebersole <st...@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 <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<div class="gmail_extra"><br><div class="gmail_quote">On 9 March 2018
>> at 13:09, Steve Ebersole <span dir="ltr"><<a
>> href="mailto:st...@hibernate.org";
>> target="_blank">st...@hibernate.org</a>></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. 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. 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 <<a href="mailto:sa...@hibernate.org";
>> target="_blank">sa...@hibernate.org</a>> 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>
Session.class.getClassLoader()<wbr>,<br>
new Class[] { Session.class }<br>
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>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
