I initially shied away from doing that because I figured that later on in the
show we might want to use Collection sub-class x, y or z.
However the alternatives were too time-consuming, so I have done just what you
said.
I am now the proud owner of BidirectionalChildList() which takes the parent
entity and the name of the property on the children in its constructor.
It's pretty restrictive - but I guess if other Collection sub-classes are
needed, it's pretty quick to knock up another implementation.
Thanks
Adam
Chris Pratt on 08/05/08 16:39, wrote:
How about adding a specific list implementation rather than using a
generic list. Then your list implementation can maintain the
relationships instead of the action.
(*Chris*)
On Thu, May 8, 2008 at 7:04 AM, Adam Hardy
<[EMAIL PROTECTED]> wrote:
Adam Hardy on 08/05/08 12:21, wrote:
when the Params interceptor populates my entity beans, it must be
setting the member variables directly without using the setters.
Is there a way to tell it to use the setters? There is some logic in
the setters which it would be good if it executed.
It gives precedence to the setters. Why would it not be able to see or
set the property?
Really? That's good to know - any work-around was looking distinctly
horrific.
These are JPA pojos, so the setters should be available.
Maybe it's breaking the javabean spec in some subtle way - I
double-checked the memvar, getter, setter and constructor though and it
looks OK.
I'm not sure. I ran into this same issue recently and cursed at lot at
OGNL only to find out it was caused by erasure of the generic type (ie. the
class of the setters argument was Object, not what I thought). It's worth
debugging this with a breakpoint. The OGNL implementation is quite
straight-forward in the way it searches for properties/methods/members
matching the right signature. As it loops through all the properties you
should see why it missed the one it should have set.
Doing that now - hopefully the answer will point to a simple solution. I
can already see that Hibernate has got its grubby nose in there.
Debugging unmasked what the problem was. OGNL was calling getChildren() and
modifying the collection of children, rather than calling
setChildren(newList) at any point - logically.
I thought I had disabled that by returning a
Collections.unmodifiableList(list) but in this case I had forgotten.
Unfortunately for me, returning an unmodifiable collection breaks OGNL.
I need to maintain the consistency of entity relationships, insuring that
the "one" and the "many" sides of a bidirectional relationship are
consistent with one another when the application updates the relationship at
runtime.
I'll have to find another way rather than trying to control the list.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
