You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Adam Hardy <ah...@cyberspaceroad.com> on 2009/02/13 18:00:42 UTC
OGNL ClassCastException
I have a situation where OGNL seems to be misinterpreting the class of the HTTP
parameter property it is setting during the ParameterInterceptor call.
As you can see from the exception message, the object is an ArrayList and
certainly not a Set which OGNL thinks it is. I have double, triple and quadruple
checked that I am not using a Set at this point.
How and where is OGNL deciding that this is a Set? And can I configure it?
The HTTP parameter is 'myParameter[0]' and the List is a generic, assuming that
makes a difference.
java.lang.ClassCastException: org.apache.openjpa.util.java$util$ArrayList$proxy
cannot be cast to java.util.Set
at ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
at
com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
at ognl.SimpleNode.getValue(SimpleNode.java:210)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL and OpenJPA proxies
Posted by Musachy Barroso <mu...@gmail.com>.
I don't know how the proxy generation works, but in your getter method
you could return a wrapper to the proxy, which implements List, and
delegates to the proxy.
//a wrapper around a proxy sounds really wrong
musachy
On Mon, Feb 16, 2009 at 11:42 AM, Adam Hardy
<ah...@cyberspaceroad.com> wrote:
> More bad news to report.
>
> My fix for the XWorkCollectionPropertyAccessor allowed OGNL to handle the
> list as a collection. That was simple and good but short-sighted in
> hindsight.
>
> The property being set on the entity bean is a list with indexed access, and
> for that it needs the XWorkListPropertyAccessor. So OGNL immediately blew up
> again with a 'property not found' error because it was expecting a string,
> rejecting the integer index.
>
> Unfortunately OGNL is never going to invoke the List property accessor for
> the proxied list property at this point because /this OpenJPA proxy class
> only implements Collection/.
>
> I have still to ascertain how the OpenJPA proxying works. Obviously
> somewhere along the line in the normal state of play, the OpenJPA proxy can
> morph back into a List somehow.
>
> These OpenJPA proxies are created via Java 6 class redefinition. There are
> other ways of enhancing OpenJPA entities which I'll try if time allows.
>
>
>
>
>
> Musachy Barroso on 16/02/09 14:58, wrote:
>>
>> If you can create an xwork ticket and attach a patch it will be
>> appreciated :)
>>
>> musachy
>>
>> On Mon, Feb 16, 2009 at 5:52 AM, Adam Hardy
>> <ah...@cyberspaceroad.com> wrote:
>>>
>>> I figured out how to get my struts-default.xml to be loaded, in case you
>>> were going tell me how after I asked :O
>>>
>>> Consequently discovered that XWorkCollectionPropertyAccessor is actually
>>> compiled into Struts2 / XWork to allow work-arounds for OGNL, so it's not
>>> configurable.
>>>
>>> I'll build my own struts jar with modified source.
>>>
>>>
>>> Adam Hardy on 16/02/09 09:40, wrote:
>>>>
>>>> I use Sets too and they're not the problem here.
>>>>
>>>> The reason why this bug occurs is because the proxy that is returned by
>>>> my
>>>> entity bean is not recognised as an ArrayList by OGNL. Rather OGNL sees
>>>> it
>>>> as a Collection. I guess this is just a rare situation and a difficult
>>>> one
>>>> to follow. In this context on a stand-alone OGNL basis, it's not a
>>>> problem.
>>>>
>>>> The problem is that struts.xml in the struts jar configures ognl to use
>>>> XWorkCollectionPropertyAccessor for Collections and this class is badly
>>>> mis-named. It is unable to deal with Collections that are Lists, because
>>>> it
>>>> extends ognl.SetPropertyAccessor which casts the Collection to a Set,
>>>> causing a ClassCastException when acting on a List.
>>>>
>>>> In fact there is no ognl.CollectionPropertyAccessor so I created one and
>>>> for now I'm going to override struts-default.xml to set OGNL to use my
>>>> own
>>>> XWorkCollectionPropertyAccessor.
>>>>
>>>> I appreciate that this is an edge case, but if you look at
>>>> struts-default,
>>>> you'll see the bean for type ognl.PropertyAccessor
>>>> name=java.util.Collection
>>>> and name=java.util.Set are the same and you'll appreciate the problem
>>>> straight away when you look at the base class ognl.SetPropertAccessor.
>>>>
>>>> I'd be happy to enter a Jira, but the question is where: OGNL, XWork or
>>>> Struts?
>>>>
>>>> Actually I'm having problems getting my version of struts-default.xml to
>>>> be read. I thought I had to reference the file in struts.properties and
>>>> have
>>>> both in my classpath:
>>>>
>>>> struts.configuration.files = atomic-struts-default.xml
>>>>
>>>> but that doesn't work.
>>>>
>>>>
>>>> Musachy Barroso on 16/02/09 00:24, wrote:
>>>>>
>>>>> It could be a bug, but I doubt it, I have used sets before and it
>>>>> works. Just as a test, try returning an empty HashSet from your
>>>>> method, instead of the proxy that it is returning now, and see if that
>>>>> works.
>>>>>
>>>>> musachy
>>>>>
>>>>> On Sun, Feb 15, 2009 at 7:14 PM, Adam Hardy
>>>>> <ah...@cyberspaceroad.com> wrote:
>>>>>>
>>>>>> Correct me if I'm wrong but this looks like a fundamental class
>>>>>> mismatch.
>>>>>>
>>>>>> I can see in struts-default.xml that both Sets and Collections are
>>>>>> configured to be accessed by the same PropertyAccessor.
>>>>>>
>>>>>> From debugging, I can see OGNL picks the PropertyAccessor for
>>>>>> Collections to
>>>>>> deal with my target property. Logical, since the ArrayList is an
>>>>>> implementation of Collection.
>>>>>>
>>>>>> The problem is that struts has registered
>>>>>> XWorkCollectionPropertyAccessor as
>>>>>> the PropertyAccessor for Collections, but this extends
>>>>>> ognl.SetPropertyAccessor which tries to cast the property to
>>>>>> java.util.Set
>>>>>> with the resulting ClassCastException.
>>>>>>
>>>>>> I noticed in an xwork jira that this seems to have happened before:
>>>>>>
>>>>>> http://jira.opensymphony.com/browse/XW-310
>>>>>>
>>>>>> but that's fixed - unfortunately not helping me though.
>>>>>>
>>>>>> I can work around this by copying XWorkCollectionPropertyAccessor and
>>>>>> writing a method to deal with Collections rather than Sets, but this
>>>>>> is
>>>>>> surely a bug. I'm just wondering why no-one else is suffering with it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Adam Hardy on 14/02/09 13:35, wrote:
>>>>>>>
>>>>>>> Yes, it is a JPA entity bean proxied by OpenJPA.
>>>>>>>
>>>>>>> It has a list property - the bean is a parent in a parent-child
>>>>>>> relationship and this property is the list of children.
>>>>>>>
>>>>>>> This is the incoming HTTP parameter:
>>>>>>>
>>>>>>> portfolio.weightings[0]=123
>>>>>>>
>>>>>>> Despite debugging it I am still not sure what has happened but I do
>>>>>>> see
>>>>>>> that OgnlRuntime looks up the appropriate PropertyAccessor in a map,
>>>>>>> and
>>>>>>> gets the wrong one back (SetPropertyAccessor instead of
>>>>>>> ListPropertyAccessor).
>>>>>>>
>>>>>>> Is there anything I can do to influence that?
>>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>> Adam
>>>>>>>
>>>>>>> Musachy Barroso on 13/02/09 17:10, wrote:
>>>>>>>>
>>>>>>>> It seems like it is not a list but a proxy to it
>>>>>>>> "org.apache.openjpa.util.java$util$ArrayList$proxy" which could be
>>>>>>>> the
>>>>>>>> root of the problem.
>>>>>>>>
>>>>>>>> musachy
>>>>>>>>
>>>>>>>> On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
>>>>>>>> <ah...@cyberspaceroad.com> wrote:
>>>>>>>>>
>>>>>>>>> I have a situation where OGNL seems to be misinterpreting the class
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> HTTP parameter property it is setting during the
>>>>>>>>> ParameterInterceptor
>>>>>>>>> call.
>>>>>>>>>
>>>>>>>>> As you can see from the exception message, the object is an
>>>>>>>>> ArrayList
>>>>>>>>> and
>>>>>>>>> certainly not a Set which OGNL thinks it is. I have double, triple
>>>>>>>>> and
>>>>>>>>> quadruple checked that I am not using a Set at this point.
>>>>>>>>>
>>>>>>>>> How and where is OGNL deciding that this is a Set? And can I
>>>>>>>>> configure
>>>>>>>>> it?
>>>>>>>>>
>>>>>>>>> The HTTP parameter is 'myParameter[0]' and the List is a generic,
>>>>>>>>> assuming
>>>>>>>>> that makes a difference.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> java.lang.ClassCastException:
>>>>>>>>> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
>>>>>>>>> java.util.Set
>>>>>>>>> at
>>>>>>>>> ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
>>>>>>>>> at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
>>>>>>>>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
>>>>>>>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
>>>>>>>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>>>>>>>>> at ognl.SimpleNode.getValue(SimpleNode.java:210)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL and OpenJPA proxies
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
More bad news to report.
My fix for the XWorkCollectionPropertyAccessor allowed OGNL to handle the list
as a collection. That was simple and good but short-sighted in hindsight.
The property being set on the entity bean is a list with indexed access, and for
that it needs the XWorkListPropertyAccessor. So OGNL immediately blew up again
with a 'property not found' error because it was expecting a string, rejecting
the integer index.
Unfortunately OGNL is never going to invoke the List property accessor for the
proxied list property at this point because /this OpenJPA proxy class only
implements Collection/.
I have still to ascertain how the OpenJPA proxying works. Obviously somewhere
along the line in the normal state of play, the OpenJPA proxy can morph back
into a List somehow.
These OpenJPA proxies are created via Java 6 class redefinition. There are other
ways of enhancing OpenJPA entities which I'll try if time allows.
Musachy Barroso on 16/02/09 14:58, wrote:
> If you can create an xwork ticket and attach a patch it will be appreciated :)
>
> musachy
>
> On Mon, Feb 16, 2009 at 5:52 AM, Adam Hardy
> <ah...@cyberspaceroad.com> wrote:
>> I figured out how to get my struts-default.xml to be loaded, in case you
>> were going tell me how after I asked :O
>>
>> Consequently discovered that XWorkCollectionPropertyAccessor is actually
>> compiled into Struts2 / XWork to allow work-arounds for OGNL, so it's not
>> configurable.
>>
>> I'll build my own struts jar with modified source.
>>
>>
>> Adam Hardy on 16/02/09 09:40, wrote:
>>> I use Sets too and they're not the problem here.
>>>
>>> The reason why this bug occurs is because the proxy that is returned by my
>>> entity bean is not recognised as an ArrayList by OGNL. Rather OGNL sees it
>>> as a Collection. I guess this is just a rare situation and a difficult one
>>> to follow. In this context on a stand-alone OGNL basis, it's not a problem.
>>>
>>> The problem is that struts.xml in the struts jar configures ognl to use
>>> XWorkCollectionPropertyAccessor for Collections and this class is badly
>>> mis-named. It is unable to deal with Collections that are Lists, because it
>>> extends ognl.SetPropertyAccessor which casts the Collection to a Set,
>>> causing a ClassCastException when acting on a List.
>>>
>>> In fact there is no ognl.CollectionPropertyAccessor so I created one and
>>> for now I'm going to override struts-default.xml to set OGNL to use my own
>>> XWorkCollectionPropertyAccessor.
>>>
>>> I appreciate that this is an edge case, but if you look at struts-default,
>>> you'll see the bean for type ognl.PropertyAccessor name=java.util.Collection
>>> and name=java.util.Set are the same and you'll appreciate the problem
>>> straight away when you look at the base class ognl.SetPropertAccessor.
>>>
>>> I'd be happy to enter a Jira, but the question is where: OGNL, XWork or
>>> Struts?
>>>
>>> Actually I'm having problems getting my version of struts-default.xml to
>>> be read. I thought I had to reference the file in struts.properties and have
>>> both in my classpath:
>>>
>>> struts.configuration.files = atomic-struts-default.xml
>>>
>>> but that doesn't work.
>>>
>>>
>>> Musachy Barroso on 16/02/09 00:24, wrote:
>>>> It could be a bug, but I doubt it, I have used sets before and it
>>>> works. Just as a test, try returning an empty HashSet from your
>>>> method, instead of the proxy that it is returning now, and see if that
>>>> works.
>>>>
>>>> musachy
>>>>
>>>> On Sun, Feb 15, 2009 at 7:14 PM, Adam Hardy
>>>> <ah...@cyberspaceroad.com> wrote:
>>>>> Correct me if I'm wrong but this looks like a fundamental class
>>>>> mismatch.
>>>>>
>>>>> I can see in struts-default.xml that both Sets and Collections are
>>>>> configured to be accessed by the same PropertyAccessor.
>>>>>
>>>>> From debugging, I can see OGNL picks the PropertyAccessor for
>>>>> Collections to
>>>>> deal with my target property. Logical, since the ArrayList is an
>>>>> implementation of Collection.
>>>>>
>>>>> The problem is that struts has registered
>>>>> XWorkCollectionPropertyAccessor as
>>>>> the PropertyAccessor for Collections, but this extends
>>>>> ognl.SetPropertyAccessor which tries to cast the property to
>>>>> java.util.Set
>>>>> with the resulting ClassCastException.
>>>>>
>>>>> I noticed in an xwork jira that this seems to have happened before:
>>>>>
>>>>> http://jira.opensymphony.com/browse/XW-310
>>>>>
>>>>> but that's fixed - unfortunately not helping me though.
>>>>>
>>>>> I can work around this by copying XWorkCollectionPropertyAccessor and
>>>>> writing a method to deal with Collections rather than Sets, but this is
>>>>> surely a bug. I'm just wondering why no-one else is suffering with it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Adam Hardy on 14/02/09 13:35, wrote:
>>>>>> Yes, it is a JPA entity bean proxied by OpenJPA.
>>>>>>
>>>>>> It has a list property - the bean is a parent in a parent-child
>>>>>> relationship and this property is the list of children.
>>>>>>
>>>>>> This is the incoming HTTP parameter:
>>>>>>
>>>>>> portfolio.weightings[0]=123
>>>>>>
>>>>>> Despite debugging it I am still not sure what has happened but I do see
>>>>>> that OgnlRuntime looks up the appropriate PropertyAccessor in a map,
>>>>>> and
>>>>>> gets the wrong one back (SetPropertyAccessor instead of
>>>>>> ListPropertyAccessor).
>>>>>>
>>>>>> Is there anything I can do to influence that?
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Adam
>>>>>>
>>>>>> Musachy Barroso on 13/02/09 17:10, wrote:
>>>>>>> It seems like it is not a list but a proxy to it
>>>>>>> "org.apache.openjpa.util.java$util$ArrayList$proxy" which could be the
>>>>>>> root of the problem.
>>>>>>>
>>>>>>> musachy
>>>>>>>
>>>>>>> On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
>>>>>>> <ah...@cyberspaceroad.com> wrote:
>>>>>>>> I have a situation where OGNL seems to be misinterpreting the class
>>>>>>>> of
>>>>>>>> the
>>>>>>>> HTTP parameter property it is setting during the ParameterInterceptor
>>>>>>>> call.
>>>>>>>>
>>>>>>>> As you can see from the exception message, the object is an ArrayList
>>>>>>>> and
>>>>>>>> certainly not a Set which OGNL thinks it is. I have double, triple
>>>>>>>> and
>>>>>>>> quadruple checked that I am not using a Set at this point.
>>>>>>>>
>>>>>>>> How and where is OGNL deciding that this is a Set? And can I
>>>>>>>> configure
>>>>>>>> it?
>>>>>>>>
>>>>>>>> The HTTP parameter is 'myParameter[0]' and the List is a generic,
>>>>>>>> assuming
>>>>>>>> that makes a difference.
>>>>>>>>
>>>>>>>>
>>>>>>>> java.lang.ClassCastException:
>>>>>>>> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
>>>>>>>> java.util.Set
>>>>>>>> at
>>>>>>>> ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
>>>>>>>> at
>>>>>>>>
>>>>>>>>
>>>>>>>> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
>>>>>>>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
>>>>>>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
>>>>>>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>>>>>>>> at ognl.SimpleNode.getValue(SimpleNode.java:210)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL ClassCastException
Posted by Musachy Barroso <mu...@gmail.com>.
If you can create an xwork ticket and attach a patch it will be appreciated :)
musachy
On Mon, Feb 16, 2009 at 5:52 AM, Adam Hardy
<ah...@cyberspaceroad.com> wrote:
> I figured out how to get my struts-default.xml to be loaded, in case you
> were going tell me how after I asked :O
>
> Consequently discovered that XWorkCollectionPropertyAccessor is actually
> compiled into Struts2 / XWork to allow work-arounds for OGNL, so it's not
> configurable.
>
> I'll build my own struts jar with modified source.
>
>
> Adam Hardy on 16/02/09 09:40, wrote:
>>
>> I use Sets too and they're not the problem here.
>>
>> The reason why this bug occurs is because the proxy that is returned by my
>> entity bean is not recognised as an ArrayList by OGNL. Rather OGNL sees it
>> as a Collection. I guess this is just a rare situation and a difficult one
>> to follow. In this context on a stand-alone OGNL basis, it's not a problem.
>>
>> The problem is that struts.xml in the struts jar configures ognl to use
>> XWorkCollectionPropertyAccessor for Collections and this class is badly
>> mis-named. It is unable to deal with Collections that are Lists, because it
>> extends ognl.SetPropertyAccessor which casts the Collection to a Set,
>> causing a ClassCastException when acting on a List.
>>
>> In fact there is no ognl.CollectionPropertyAccessor so I created one and
>> for now I'm going to override struts-default.xml to set OGNL to use my own
>> XWorkCollectionPropertyAccessor.
>>
>> I appreciate that this is an edge case, but if you look at struts-default,
>> you'll see the bean for type ognl.PropertyAccessor name=java.util.Collection
>> and name=java.util.Set are the same and you'll appreciate the problem
>> straight away when you look at the base class ognl.SetPropertAccessor.
>>
>> I'd be happy to enter a Jira, but the question is where: OGNL, XWork or
>> Struts?
>>
>> Actually I'm having problems getting my version of struts-default.xml to
>> be read. I thought I had to reference the file in struts.properties and have
>> both in my classpath:
>>
>> struts.configuration.files = atomic-struts-default.xml
>>
>> but that doesn't work.
>>
>>
>> Musachy Barroso on 16/02/09 00:24, wrote:
>>>
>>> It could be a bug, but I doubt it, I have used sets before and it
>>> works. Just as a test, try returning an empty HashSet from your
>>> method, instead of the proxy that it is returning now, and see if that
>>> works.
>>>
>>> musachy
>>>
>>> On Sun, Feb 15, 2009 at 7:14 PM, Adam Hardy
>>> <ah...@cyberspaceroad.com> wrote:
>>>>
>>>> Correct me if I'm wrong but this looks like a fundamental class
>>>> mismatch.
>>>>
>>>> I can see in struts-default.xml that both Sets and Collections are
>>>> configured to be accessed by the same PropertyAccessor.
>>>>
>>>> From debugging, I can see OGNL picks the PropertyAccessor for
>>>> Collections to
>>>> deal with my target property. Logical, since the ArrayList is an
>>>> implementation of Collection.
>>>>
>>>> The problem is that struts has registered
>>>> XWorkCollectionPropertyAccessor as
>>>> the PropertyAccessor for Collections, but this extends
>>>> ognl.SetPropertyAccessor which tries to cast the property to
>>>> java.util.Set
>>>> with the resulting ClassCastException.
>>>>
>>>> I noticed in an xwork jira that this seems to have happened before:
>>>>
>>>> http://jira.opensymphony.com/browse/XW-310
>>>>
>>>> but that's fixed - unfortunately not helping me though.
>>>>
>>>> I can work around this by copying XWorkCollectionPropertyAccessor and
>>>> writing a method to deal with Collections rather than Sets, but this is
>>>> surely a bug. I'm just wondering why no-one else is suffering with it.
>>>>
>>>>
>>>>
>>>>
>>>> Adam Hardy on 14/02/09 13:35, wrote:
>>>>>
>>>>> Yes, it is a JPA entity bean proxied by OpenJPA.
>>>>>
>>>>> It has a list property - the bean is a parent in a parent-child
>>>>> relationship and this property is the list of children.
>>>>>
>>>>> This is the incoming HTTP parameter:
>>>>>
>>>>> portfolio.weightings[0]=123
>>>>>
>>>>> Despite debugging it I am still not sure what has happened but I do see
>>>>> that OgnlRuntime looks up the appropriate PropertyAccessor in a map,
>>>>> and
>>>>> gets the wrong one back (SetPropertyAccessor instead of
>>>>> ListPropertyAccessor).
>>>>>
>>>>> Is there anything I can do to influence that?
>>>>>
>>>>>
>>>>> Regards
>>>>> Adam
>>>>>
>>>>> Musachy Barroso on 13/02/09 17:10, wrote:
>>>>>>
>>>>>> It seems like it is not a list but a proxy to it
>>>>>> "org.apache.openjpa.util.java$util$ArrayList$proxy" which could be the
>>>>>> root of the problem.
>>>>>>
>>>>>> musachy
>>>>>>
>>>>>> On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
>>>>>> <ah...@cyberspaceroad.com> wrote:
>>>>>>>
>>>>>>> I have a situation where OGNL seems to be misinterpreting the class
>>>>>>> of
>>>>>>> the
>>>>>>> HTTP parameter property it is setting during the ParameterInterceptor
>>>>>>> call.
>>>>>>>
>>>>>>> As you can see from the exception message, the object is an ArrayList
>>>>>>> and
>>>>>>> certainly not a Set which OGNL thinks it is. I have double, triple
>>>>>>> and
>>>>>>> quadruple checked that I am not using a Set at this point.
>>>>>>>
>>>>>>> How and where is OGNL deciding that this is a Set? And can I
>>>>>>> configure
>>>>>>> it?
>>>>>>>
>>>>>>> The HTTP parameter is 'myParameter[0]' and the List is a generic,
>>>>>>> assuming
>>>>>>> that makes a difference.
>>>>>>>
>>>>>>>
>>>>>>> java.lang.ClassCastException:
>>>>>>> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
>>>>>>> java.util.Set
>>>>>>> at
>>>>>>> ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
>>>>>>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
>>>>>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
>>>>>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>>>>>>> at ognl.SimpleNode.getValue(SimpleNode.java:210)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL ClassCastException
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
I figured out how to get my struts-default.xml to be loaded, in case you were
going tell me how after I asked :O
Consequently discovered that XWorkCollectionPropertyAccessor is actually
compiled into Struts2 / XWork to allow work-arounds for OGNL, so it's not
configurable.
I'll build my own struts jar with modified source.
Adam Hardy on 16/02/09 09:40, wrote:
> I use Sets too and they're not the problem here.
>
> The reason why this bug occurs is because the proxy that is returned by
> my entity bean is not recognised as an ArrayList by OGNL. Rather OGNL
> sees it as a Collection. I guess this is just a rare situation and a
> difficult one to follow. In this context on a stand-alone OGNL basis,
> it's not a problem.
>
> The problem is that struts.xml in the struts jar configures ognl to use
> XWorkCollectionPropertyAccessor for Collections and this class is badly
> mis-named. It is unable to deal with Collections that are Lists, because
> it extends ognl.SetPropertyAccessor which casts the Collection to a Set,
> causing a ClassCastException when acting on a List.
>
> In fact there is no ognl.CollectionPropertyAccessor so I created one and
> for now I'm going to override struts-default.xml to set OGNL to use my
> own XWorkCollectionPropertyAccessor.
>
> I appreciate that this is an edge case, but if you look at
> struts-default, you'll see the bean for type ognl.PropertyAccessor
> name=java.util.Collection and name=java.util.Set are the same and you'll
> appreciate the problem straight away when you look at the base class
> ognl.SetPropertAccessor.
>
> I'd be happy to enter a Jira, but the question is where: OGNL, XWork or
> Struts?
>
> Actually I'm having problems getting my version of struts-default.xml to
> be read. I thought I had to reference the file in struts.properties and
> have both in my classpath:
>
> struts.configuration.files = atomic-struts-default.xml
>
> but that doesn't work.
>
>
> Musachy Barroso on 16/02/09 00:24, wrote:
>> It could be a bug, but I doubt it, I have used sets before and it
>> works. Just as a test, try returning an empty HashSet from your
>> method, instead of the proxy that it is returning now, and see if that
>> works.
>>
>> musachy
>>
>> On Sun, Feb 15, 2009 at 7:14 PM, Adam Hardy
>> <ah...@cyberspaceroad.com> wrote:
>>> Correct me if I'm wrong but this looks like a fundamental class
>>> mismatch.
>>>
>>> I can see in struts-default.xml that both Sets and Collections are
>>> configured to be accessed by the same PropertyAccessor.
>>>
>>> From debugging, I can see OGNL picks the PropertyAccessor for
>>> Collections to
>>> deal with my target property. Logical, since the ArrayList is an
>>> implementation of Collection.
>>>
>>> The problem is that struts has registered
>>> XWorkCollectionPropertyAccessor as
>>> the PropertyAccessor for Collections, but this extends
>>> ognl.SetPropertyAccessor which tries to cast the property to
>>> java.util.Set
>>> with the resulting ClassCastException.
>>>
>>> I noticed in an xwork jira that this seems to have happened before:
>>>
>>> http://jira.opensymphony.com/browse/XW-310
>>>
>>> but that's fixed - unfortunately not helping me though.
>>>
>>> I can work around this by copying XWorkCollectionPropertyAccessor and
>>> writing a method to deal with Collections rather than Sets, but this is
>>> surely a bug. I'm just wondering why no-one else is suffering with it.
>>>
>>>
>>>
>>>
>>> Adam Hardy on 14/02/09 13:35, wrote:
>>>> Yes, it is a JPA entity bean proxied by OpenJPA.
>>>>
>>>> It has a list property - the bean is a parent in a parent-child
>>>> relationship and this property is the list of children.
>>>>
>>>> This is the incoming HTTP parameter:
>>>>
>>>> portfolio.weightings[0]=123
>>>>
>>>> Despite debugging it I am still not sure what has happened but I do see
>>>> that OgnlRuntime looks up the appropriate PropertyAccessor in a map,
>>>> and
>>>> gets the wrong one back (SetPropertyAccessor instead of
>>>> ListPropertyAccessor).
>>>>
>>>> Is there anything I can do to influence that?
>>>>
>>>>
>>>> Regards
>>>> Adam
>>>>
>>>> Musachy Barroso on 13/02/09 17:10, wrote:
>>>>> It seems like it is not a list but a proxy to it
>>>>> "org.apache.openjpa.util.java$util$ArrayList$proxy" which could be the
>>>>> root of the problem.
>>>>>
>>>>> musachy
>>>>>
>>>>> On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
>>>>> <ah...@cyberspaceroad.com> wrote:
>>>>>> I have a situation where OGNL seems to be misinterpreting the
>>>>>> class of
>>>>>> the
>>>>>> HTTP parameter property it is setting during the ParameterInterceptor
>>>>>> call.
>>>>>>
>>>>>> As you can see from the exception message, the object is an ArrayList
>>>>>> and
>>>>>> certainly not a Set which OGNL thinks it is. I have double, triple
>>>>>> and
>>>>>> quadruple checked that I am not using a Set at this point.
>>>>>>
>>>>>> How and where is OGNL deciding that this is a Set? And can I
>>>>>> configure
>>>>>> it?
>>>>>>
>>>>>> The HTTP parameter is 'myParameter[0]' and the List is a generic,
>>>>>> assuming
>>>>>> that makes a difference.
>>>>>>
>>>>>>
>>>>>> java.lang.ClassCastException:
>>>>>> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
>>>>>> java.util.Set
>>>>>> at
>>>>>> ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
>>>>>> at
>>>>>>
>>>>>> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
>>>>>>
>>>>>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
>>>>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
>>>>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>>>>>> at ognl.SimpleNode.getValue(SimpleNode.java:210)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL ClassCastException
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
I use Sets too and they're not the problem here.
The reason why this bug occurs is because the proxy that is returned by my
entity bean is not recognised as an ArrayList by OGNL. Rather OGNL sees it as a
Collection. I guess this is just a rare situation and a difficult one to follow.
In this context on a stand-alone OGNL basis, it's not a problem.
The problem is that struts.xml in the struts jar configures ognl to use
XWorkCollectionPropertyAccessor for Collections and this class is badly
mis-named. It is unable to deal with Collections that are Lists, because it
extends ognl.SetPropertyAccessor which casts the Collection to a Set, causing a
ClassCastException when acting on a List.
In fact there is no ognl.CollectionPropertyAccessor so I created one and for now
I'm going to override struts-default.xml to set OGNL to use my own
XWorkCollectionPropertyAccessor.
I appreciate that this is an edge case, but if you look at struts-default,
you'll see the bean for type ognl.PropertyAccessor name=java.util.Collection and
name=java.util.Set are the same and you'll appreciate the problem straight away
when you look at the base class ognl.SetPropertAccessor.
I'd be happy to enter a Jira, but the question is where: OGNL, XWork or Struts?
Actually I'm having problems getting my version of struts-default.xml to be
read. I thought I had to reference the file in struts.properties and have both
in my classpath:
struts.configuration.files = atomic-struts-default.xml
but that doesn't work.
Musachy Barroso on 16/02/09 00:24, wrote:
> It could be a bug, but I doubt it, I have used sets before and it
> works. Just as a test, try returning an empty HashSet from your
> method, instead of the proxy that it is returning now, and see if that
> works.
>
> musachy
>
> On Sun, Feb 15, 2009 at 7:14 PM, Adam Hardy
> <ah...@cyberspaceroad.com> wrote:
>> Correct me if I'm wrong but this looks like a fundamental class mismatch.
>>
>> I can see in struts-default.xml that both Sets and Collections are
>> configured to be accessed by the same PropertyAccessor.
>>
>> From debugging, I can see OGNL picks the PropertyAccessor for Collections to
>> deal with my target property. Logical, since the ArrayList is an
>> implementation of Collection.
>>
>> The problem is that struts has registered XWorkCollectionPropertyAccessor as
>> the PropertyAccessor for Collections, but this extends
>> ognl.SetPropertyAccessor which tries to cast the property to java.util.Set
>> with the resulting ClassCastException.
>>
>> I noticed in an xwork jira that this seems to have happened before:
>>
>> http://jira.opensymphony.com/browse/XW-310
>>
>> but that's fixed - unfortunately not helping me though.
>>
>> I can work around this by copying XWorkCollectionPropertyAccessor and
>> writing a method to deal with Collections rather than Sets, but this is
>> surely a bug. I'm just wondering why no-one else is suffering with it.
>>
>>
>>
>>
>> Adam Hardy on 14/02/09 13:35, wrote:
>>> Yes, it is a JPA entity bean proxied by OpenJPA.
>>>
>>> It has a list property - the bean is a parent in a parent-child
>>> relationship and this property is the list of children.
>>>
>>> This is the incoming HTTP parameter:
>>>
>>> portfolio.weightings[0]=123
>>>
>>> Despite debugging it I am still not sure what has happened but I do see
>>> that OgnlRuntime looks up the appropriate PropertyAccessor in a map, and
>>> gets the wrong one back (SetPropertyAccessor instead of
>>> ListPropertyAccessor).
>>>
>>> Is there anything I can do to influence that?
>>>
>>>
>>> Regards
>>> Adam
>>>
>>> Musachy Barroso on 13/02/09 17:10, wrote:
>>>> It seems like it is not a list but a proxy to it
>>>> "org.apache.openjpa.util.java$util$ArrayList$proxy" which could be the
>>>> root of the problem.
>>>>
>>>> musachy
>>>>
>>>> On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
>>>> <ah...@cyberspaceroad.com> wrote:
>>>>> I have a situation where OGNL seems to be misinterpreting the class of
>>>>> the
>>>>> HTTP parameter property it is setting during the ParameterInterceptor
>>>>> call.
>>>>>
>>>>> As you can see from the exception message, the object is an ArrayList
>>>>> and
>>>>> certainly not a Set which OGNL thinks it is. I have double, triple and
>>>>> quadruple checked that I am not using a Set at this point.
>>>>>
>>>>> How and where is OGNL deciding that this is a Set? And can I configure
>>>>> it?
>>>>>
>>>>> The HTTP parameter is 'myParameter[0]' and the List is a generic,
>>>>> assuming
>>>>> that makes a difference.
>>>>>
>>>>>
>>>>> java.lang.ClassCastException:
>>>>> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
>>>>> java.util.Set
>>>>> at
>>>>> ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
>>>>> at
>>>>>
>>>>> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
>>>>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
>>>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
>>>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>>>>> at ognl.SimpleNode.getValue(SimpleNode.java:210)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL ClassCastException
Posted by Musachy Barroso <mu...@gmail.com>.
It could be a bug, but I doubt it, I have used sets before and it
works. Just as a test, try returning an empty HashSet from your
method, instead of the proxy that it is returning now, and see if that
works.
musachy
On Sun, Feb 15, 2009 at 7:14 PM, Adam Hardy
<ah...@cyberspaceroad.com> wrote:
> Correct me if I'm wrong but this looks like a fundamental class mismatch.
>
> I can see in struts-default.xml that both Sets and Collections are
> configured to be accessed by the same PropertyAccessor.
>
> From debugging, I can see OGNL picks the PropertyAccessor for Collections to
> deal with my target property. Logical, since the ArrayList is an
> implementation of Collection.
>
> The problem is that struts has registered XWorkCollectionPropertyAccessor as
> the PropertyAccessor for Collections, but this extends
> ognl.SetPropertyAccessor which tries to cast the property to java.util.Set
> with the resulting ClassCastException.
>
> I noticed in an xwork jira that this seems to have happened before:
>
> http://jira.opensymphony.com/browse/XW-310
>
> but that's fixed - unfortunately not helping me though.
>
> I can work around this by copying XWorkCollectionPropertyAccessor and
> writing a method to deal with Collections rather than Sets, but this is
> surely a bug. I'm just wondering why no-one else is suffering with it.
>
>
>
>
> Adam Hardy on 14/02/09 13:35, wrote:
>>
>> Yes, it is a JPA entity bean proxied by OpenJPA.
>>
>> It has a list property - the bean is a parent in a parent-child
>> relationship and this property is the list of children.
>>
>> This is the incoming HTTP parameter:
>>
>> portfolio.weightings[0]=123
>>
>> Despite debugging it I am still not sure what has happened but I do see
>> that OgnlRuntime looks up the appropriate PropertyAccessor in a map, and
>> gets the wrong one back (SetPropertyAccessor instead of
>> ListPropertyAccessor).
>>
>> Is there anything I can do to influence that?
>>
>>
>> Regards
>> Adam
>>
>> Musachy Barroso on 13/02/09 17:10, wrote:
>>>
>>> It seems like it is not a list but a proxy to it
>>> "org.apache.openjpa.util.java$util$ArrayList$proxy" which could be the
>>> root of the problem.
>>>
>>> musachy
>>>
>>> On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
>>> <ah...@cyberspaceroad.com> wrote:
>>>>
>>>> I have a situation where OGNL seems to be misinterpreting the class of
>>>> the
>>>> HTTP parameter property it is setting during the ParameterInterceptor
>>>> call.
>>>>
>>>> As you can see from the exception message, the object is an ArrayList
>>>> and
>>>> certainly not a Set which OGNL thinks it is. I have double, triple and
>>>> quadruple checked that I am not using a Set at this point.
>>>>
>>>> How and where is OGNL deciding that this is a Set? And can I configure
>>>> it?
>>>>
>>>> The HTTP parameter is 'myParameter[0]' and the List is a generic,
>>>> assuming
>>>> that makes a difference.
>>>>
>>>>
>>>> java.lang.ClassCastException:
>>>> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
>>>> java.util.Set
>>>> at
>>>> ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
>>>> at
>>>>
>>>> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
>>>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
>>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
>>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>>>> at ognl.SimpleNode.getValue(SimpleNode.java:210)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL ClassCastException
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Correct me if I'm wrong but this looks like a fundamental class mismatch.
I can see in struts-default.xml that both Sets and Collections are configured to
be accessed by the same PropertyAccessor.
From debugging, I can see OGNL picks the PropertyAccessor for Collections to
deal with my target property. Logical, since the ArrayList is an implementation
of Collection.
The problem is that struts has registered XWorkCollectionPropertyAccessor as the
PropertyAccessor for Collections, but this extends ognl.SetPropertyAccessor
which tries to cast the property to java.util.Set with the resulting
ClassCastException.
I noticed in an xwork jira that this seems to have happened before:
http://jira.opensymphony.com/browse/XW-310
but that's fixed - unfortunately not helping me though.
I can work around this by copying XWorkCollectionPropertyAccessor and writing a
method to deal with Collections rather than Sets, but this is surely a bug. I'm
just wondering why no-one else is suffering with it.
Adam Hardy on 14/02/09 13:35, wrote:
> Yes, it is a JPA entity bean proxied by OpenJPA.
>
> It has a list property - the bean is a parent in a parent-child
> relationship and this property is the list of children.
>
> This is the incoming HTTP parameter:
>
> portfolio.weightings[0]=123
>
> Despite debugging it I am still not sure what has happened but I do see
> that OgnlRuntime looks up the appropriate PropertyAccessor in a map, and
> gets the wrong one back (SetPropertyAccessor instead of
> ListPropertyAccessor).
>
> Is there anything I can do to influence that?
>
>
> Regards
> Adam
>
> Musachy Barroso on 13/02/09 17:10, wrote:
>> It seems like it is not a list but a proxy to it
>> "org.apache.openjpa.util.java$util$ArrayList$proxy" which could be the
>> root of the problem.
>>
>> musachy
>>
>> On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
>> <ah...@cyberspaceroad.com> wrote:
>>> I have a situation where OGNL seems to be misinterpreting the class
>>> of the
>>> HTTP parameter property it is setting during the ParameterInterceptor
>>> call.
>>>
>>> As you can see from the exception message, the object is an ArrayList
>>> and
>>> certainly not a Set which OGNL thinks it is. I have double, triple and
>>> quadruple checked that I am not using a Set at this point.
>>>
>>> How and where is OGNL deciding that this is a Set? And can I
>>> configure it?
>>>
>>> The HTTP parameter is 'myParameter[0]' and the List is a generic,
>>> assuming
>>> that makes a difference.
>>>
>>>
>>> java.lang.ClassCastException:
>>> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
>>> java.util.Set
>>> at
>>> ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
>>> at
>>> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
>>>
>>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
>>> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
>>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>>> at ognl.SimpleNode.getValue(SimpleNode.java:210)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL ClassCastException
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Yes, it is a JPA entity bean proxied by OpenJPA.
It has a list property - the bean is a parent in a parent-child relationship and
this property is the list of children.
This is the incoming HTTP parameter:
portfolio.weightings[0]=123
Despite debugging it I am still not sure what has happened but I do see that
OgnlRuntime looks up the appropriate PropertyAccessor in a map, and gets the
wrong one back (SetPropertyAccessor instead of ListPropertyAccessor).
Is there anything I can do to influence that?
Regards
Adam
Musachy Barroso on 13/02/09 17:10, wrote:
> It seems like it is not a list but a proxy to it
> "org.apache.openjpa.util.java$util$ArrayList$proxy" which could be the
> root of the problem.
>
> musachy
>
> On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
> <ah...@cyberspaceroad.com> wrote:
>> I have a situation where OGNL seems to be misinterpreting the class of the
>> HTTP parameter property it is setting during the ParameterInterceptor call.
>>
>> As you can see from the exception message, the object is an ArrayList and
>> certainly not a Set which OGNL thinks it is. I have double, triple and
>> quadruple checked that I am not using a Set at this point.
>>
>> How and where is OGNL deciding that this is a Set? And can I configure it?
>>
>> The HTTP parameter is 'myParameter[0]' and the List is a generic, assuming
>> that makes a difference.
>>
>>
>> java.lang.ClassCastException:
>> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
>> java.util.Set
>> at ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
>> at
>> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
>> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
>> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
>> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
>> at ognl.SimpleNode.getValue(SimpleNode.java:210)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: OGNL ClassCastException
Posted by Musachy Barroso <mu...@gmail.com>.
It seems like it is not a list but a proxy to it
"org.apache.openjpa.util.java$util$ArrayList$proxy" which could be the
root of the problem.
musachy
On Fri, Feb 13, 2009 at 12:00 PM, Adam Hardy
<ah...@cyberspaceroad.com> wrote:
> I have a situation where OGNL seems to be misinterpreting the class of the
> HTTP parameter property it is setting during the ParameterInterceptor call.
>
> As you can see from the exception message, the object is an ArrayList and
> certainly not a Set which OGNL thinks it is. I have double, triple and
> quadruple checked that I am not using a Set at this point.
>
> How and where is OGNL deciding that this is a Set? And can I configure it?
>
> The HTTP parameter is 'myParameter[0]' and the List is a generic, assuming
> that makes a difference.
>
>
> java.lang.ClassCastException:
> org.apache.openjpa.util.java$util$ArrayList$proxy cannot be cast to
> java.util.Set
> at ognl.SetPropertyAccessor.getProperty(SetPropertyAccessor.java:46)
> at
> com.opensymphony.xwork2.ognl.accessor.XWorkCollectionPropertyAccessor.getProperty(XWorkCollectionPropertyAccessor.java:80)
> at ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1643)
> at ognl.ASTProperty.getValueBody(ASTProperty.java:92)
> at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170)
> at ognl.SimpleNode.getValue(SimpleNode.java:210)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org