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.
Thanks
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail:
user-unsubscribe@...
For additional commands, e-mail:
user-help@...