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