|
»
»
»
« Return to Thread: OGNL
Re: OGNL
by Adam Hardy-3
::
Rate this Message:
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
> <ahardy.struts@...> 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: user-unsubscribe@...
For additional commands, e-mail: user-help@...
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
> <ahardy.struts@...> 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: user-unsubscribe@...
For additional commands, e-mail: user-help@...
« Return to Thread: OGNL
| Free Forum Powered by Nabble | Forum Help |