[hibernate-dev] Proxying the Session: a requirement ?
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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Proxying the Session: a requirement ?
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
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 = (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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Proxying the Session: a requirement ?
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
> 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 = (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,
>> SanneOn 9 March 2018
>> at 13:09, Steve Ebersole <> href="mailto:st...@hibernate.org";
>> target="_blank">st...@hibernate.org> wrote:> class="gmail_quote" style="margin:0 0 0 .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 course you
>> fix the thread-based current-session stuff which afaik is the only place we
>> actually proxy the Session> class="h5">On Fri, Mar 9, 2018
>> at 7:05 AM Sanne Grinovero > target="_blank">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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Proxying the Session: a requirement ?
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 wrote:
> 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
> > 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 = (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,
> >> SanneOn 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 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 class="h5">On Fri, Mar 9, 2018
> at 7:05 AM Sanne Grinovero target="_blank">sa...@hibernate.org> wrote: 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
> 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
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Proxying the Session: a requirement ?
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 > exercise. > No idea but we should really check that with at least the Spring folks before investing so much time in it. Gaining compatibility by breaking an implicit contract we had before might not be our best move. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Joins over type variable defined assocations NPE problems
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 Integer id; }
@Entity class EntityA extends BaseEntity { @ManyToOne EntityC relation; }
@Entity class EntityB extends BaseEntity { @ManyToOne EntityD relation; }
@Entity class EntityC {...}
@Entity class EntityD {...}
The essence is, that EntityA and EntityB define properties with the same
names but have unrelated types. It's actually the same problem for
collections.
Since EntityA and EntityB extend BaseEntity and because BaseEntity is an
@Entity, the Hibernate code tries to add "EntityA.relation" and
"EntityB.relation" to the PropertyMapping of BaseEntity. Before my fix,
the property which is added first won and subsequent adds are ignored.
This is presumably done to support implicit downcasting. My fix was
about making use of a common super type if possible and disallowing
ambiguous access.
The problem the user now reported is, when using FetchType.EAGER there
is an exception which states that property "relation" could not be found
on type "BaseEntity". This is because I register "null" as type to
signal that it's not really possible to use that property with that
persister(BaseEntity in this case). During booting, the load plan for
BaseEntity is built, for which the SQL is pre-generated. At this point,
the exception happens, because "null" is registered as type for the
property "relation". This will cause the property to be considered as
non-existant wrt getPropertyType. The code before my fix was essentially
broken, because it doesn't handle eager fetching properly due to the
"first property wins" strategy. A property might only be loaded through
a secondary query due to lazy loading rather than by the defined fetch
style. An implicit downcasted join using the property might lead to
non-deterministic results.
One of the reasons for doing the fix, was to prevent the possibility of
being hit by the non-determinism. I had a mapping that was using the
type variable approach and I had to find out the non-determinism the
hard way. I'd like to prevent access to such conflicting attributes from
the top level type through implicit downcasting, so IMO the only real
solution is to exclude the conflicting attributes in the load plan.
The "best" solution would be to introduce a synthetic type that
represents the union of the unrelated property types, but to me this
seems to be quite a lot of work.
I have implemented the proposed solution here:
https://github.com/hibernate/hibernate-orm/pull/2190
We need to release this fix soon as the current state is broken for the
EAGER configuration. What do you think about the solution or the matter
in general?
--
Mit freundlichen Grüßen,
*Christian Beikov*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
