I'm really struggling with porting back these caching changes (timestamps),
so we have time. I think I will push the CR date another week or 2 to
finish up all these things we all are working on. Just NO MORE scope
creep. What we have already planned to do for 5.3 is what will be in 5.3 -
no more :)
On Fri, Mar 9, 2018 at 7:14 AM Sanne Grinovero <sa...@hibernate.org> wrote:
> 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
