[ovirt-devel] hibernate's internal PersistentBag sent to FE

Liran Zelkha lzelkha at redhat.com
Mon Jun 1 13:56:03 UTC 2015


Guys,

Why is https://gerrit.ovirt.org/#/c/40804/ not enough? 
Where do you get these errors?



> On Jun 1, 2015, at 4:33 PM, Tomas Jelinek <tjelinek at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Alexander Wels" <awels at redhat.com>
>> To: devel at ovirt.org
>> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, "Liran Zelkha" <lzelkha at redhat.com>
>> Sent: Monday, June 1, 2015 3:16:34 PM
>> Subject: Re: [ovirt-devel] hibernate's internal PersistentBag sent to FE
>> 
>>> On Monday, June 01, 2015 09:08:50 AM Tomas Jelinek wrote:
>>> Hey all,
>>> 
>>> since the org.ovirt.engine.core.common.job.Job/Step... has been moved to
>>> use
>>> the JPA we have a problem on frontend. The problem is that the @OneToMany
>>> annotations results in a List which is of type PersistentBag. When we send
>>> this to Frontend it fails during deserialization. It actually fails quite
>>> bad because the FE already has an ui-override of it which is not correct
>>> resulting in a ton of NPEs in development mode.
>>> 
>>> So, there are 2 nasty fixes I have made where none of them should be merged
>>> but demonstrate the possibilities: 1: extend the FE to be able to work with
>>> the PersistentBag (https://gerrit.ovirt.org/#/c/41682/) not really good
>>> solution since the PersistenBag is an internal Hibernate class which is
>>> really not meant to be passed around
>>> 
>>> 2: fix on the backend to not send the PersistentBag but an ArrayList. This
>>> is only a PoC fixed on a command we face the problem
>>> (https://gerrit.ovirt.org/#/c/41797/) Obviously this is not going to work
>>> for other commands accessing the same Job nor for other entities.
>>> 
>>> So, the first option is generic but very very bad. The second option should
>>> be used but not sure how to do this in a cheep way (e.g. without using
>>> reflection to deep traverse everything sent back to frontend checking if it
>>> does not have a PersistentBag in it.
>> 
>> Tomas,
>> 
>> Thanks, I was investigating the same issue, I noticed it last Friday just
>> before leaving, so I was investigating the problem to see what was going on.
>> You are right we should not be sending PersistentBag to the frontend at all.
>> So how about we do a combination of [1] and [2], but instead of delegating in
>> [1] we actually simple throw an exception stating don't sent PersistentBag to
>> the front end. that way anyone inadvertently using it will be notified
>> immediately (since their code won't work).
> 
> Throwing the exception would help us in debugging but the main question is how will we make it work?
> Since we are planning to move more and more to JPA so we will face this issue more and more often. 
> Solving it one by one on backend in each command is not going to work.
> 
>> 
>> Alexander
>> 
>>> Any better ideas?
>>> Thanx,
>>> Tomas
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20150601/74e430b0/attachment-0001.html>


More information about the Devel mailing list