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
<ahardy.str...@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
<ahardy.str...@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-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
