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 > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
