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