OGNL

[Adam Hardy-3]

Hi,

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.


Thanks
Adam

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Jeromy Evans - Blue Sky Minds]

Adam Hardy wrote:
> Hi,
>
> 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.
>

Hi Adam,
It gives precedence to the setters. Why would it not be able to see or
set the property?


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Adam Hardy-3]

Jeromy Evans on 08/05/08 09:26, wrote:

> Adam Hardy wrote:
>> Hi,
>>
>> 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.
>>
>
> Hi Adam,
> 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.

Could it be the way I am using converters?

I set up a converter to instantiate an entity bean, rather than doing it in the
ModelDriven interceptor. Could that force OGNL to set its fields directly rather
than using its setters?


rgds
Adam

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Jeromy Evans - Blue Sky Minds]

Adam Hardy wrote:

> Jeromy Evans on 08/05/08 09:26, wrote:
>> Adam Hardy wrote:
>>> Hi,
>>>
>>> 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.
>>>
>>
>> Hi Adam,
>> 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.
>
> Could it be the way I am using converters?
>
> I set up a converter to instantiate an entity bean, rather than doing
> it in the ModelDriven interceptor. Could that force OGNL to set its
> fields directly rather than using its setters?
>

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Adam Hardy-3]

Jeromy Evans on 08/05/08 11:41, wrote:

> Adam Hardy wrote:
>> Jeromy Evans on 08/05/08 09:26, wrote:
>>> Adam Hardy wrote:
>>>> Hi,
>>>>
>>>> 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.
>>>>
>>>
>>> Hi Adam,
>>> 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.
>>
>> Could it be the way I am using converters?
>>
>> I set up a converter to instantiate an entity bean, rather than doing
>> it in the ModelDriven interceptor. Could that force OGNL to set its
>> fields directly rather than using its setters?
>>
> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Adam Hardy-3]

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@...

[Chris Pratt]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Adam Hardy-3]

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@...

[Jeromy Evans - Blue Sky Minds]

Adam Hardy wrote:

> 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

I've lost track of what you're doing here.  Is it correct that you have
an interceptor or prepare method that's loading an Entity and then
you're using the ParametersInterceptor (via custom converters) to set
properties in a collection of that Entity?  Adding/removing entries in
the collection?  If so, how are you not interfering with the Collection
impl created by the persistence provider (eg. PersistentBag/PersistentSet)?

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Adam Hardy-3]

Jeromy Evans on 09/05/08 08:05, wrote:

> Adam Hardy wrote:
>> 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
>
> I've lost track of what you're doing here.  Is it correct that you have
> an interceptor or prepare method that's loading an Entity and then
> you're using the ParametersInterceptor (via custom converters) to set
> properties in a collection of that Entity?  Adding/removing entries in
> the collection?  If so, how are you not interfering with the Collection
> impl created by the persistence provider (eg. PersistentBag/PersistentSet)?

I mapped the entities with field access, so the getters and setters are
irrelevant to JPA.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...