Re: OGNL ClassCastException
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:
Re: OGNL ClassCastException
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
Re: OGNL ClassCastException
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
Re: OGNL ClassCastException
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
Re: OGNL ClassCastException
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
Re: OGNL ClassCastException
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 - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
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-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: OGNL ClassCastException
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
