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 }
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-base
On 9 March 2018 at 13:09, Steve Ebersole 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
>
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 mor
On Fri, Mar 9, 2018 at 2:14 PM, Sanne Grinovero 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
>
Hey,
so the problems related to the type variable handling I did aren't fully
solved. There is one other case that was reported today:
https://hibernate.atlassian.net/browse/HHH-12375
I'm not sure how to handle this. Let me explain you the model and the
problem.
@Entity class BaseEntity { @Id
