From steve at hibernate.org Fri Mar 9 08:24:18 2018 Content-Type: multipart/mixed; boundary="===============2836933714471162056==" MIME-Version: 1.0 From: Steve Ebersole To: hibernate-dev at lists.jboss.org Subject: Re: [hibernate-dev] Proxying the Session: a requirement ? Date: Fri, 09 Mar 2018 13:24:07 +0000 Message-ID: In-Reply-To: CAFm4XO1EnD=9XKMfmX4rUQKuas6ZVH7+3EKH2goNLdQUxyhGqQ@mail.gmail.com --===============2836933714471162056== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 wrot= e: > On 9 March 2018 at 13:09, Steve Ebersole wrote: > > I think most environments would proxy the JPA contracts if anything. F= or > > Session we do offer the "base delegator" for a delegation solution rath= er > > 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 > 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 =3D (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 Ma= rch > 2018 at 13:09, Steve Ebersole < steve(a)hibernate.org" target=3D"_blank">steve(a)hibernate.org> > wrote:
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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 cour= se > you fix the thread-based current-session stuff which afaik is the only > place we actually proxy the Session
class=3D"h5">
On Fri, Mar = 9, 2018 > at 7:05 AM Sanne Grinovero < target=3D"_blank">sanne(a)hibernate.org> wrote:
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex">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 =3D (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
>
>

> --===============2836933714471162056==--