[morph-user] [beanutils] Beans and Maps mixed up in PropertyUtils
Brought to you by:
orangeherbert,
sgarlatm
Menu
▾
▴
[morph-user] [beanutils] Beans and Maps mixed up in PropertyUtils
|
From: Matt S. <sga...@us...> - 2004-12-12 20:09:58
|
Hi Jack, I saw Craig's (hostile?) response to the bug you entered in BugZilla for BeanUtils. I too am frustrated with some of the design choices that were made in BeanUtils, so I started my own framework that is much more configurable and extensible than BeanUtils. Think of it as BeanUtils 2.0 ;) It has already received some positive initial comments from some of the committers on BeanUtils, specifically from Robert Durrel Donkin. For more information, see http://morph.sourceforge.net I'm not sure I completely understand the exact issue you are facing, but if you are willing to give the Morph framework some serious consideration, I would be more than happy to incorporate the changes you need directly into the Morph framework. Matt For the record, here's the thread from Bugzilla: If we want to use BeanUtils to populate a bean, which we do in Struts with an ActionForm, for example, and want to use the same bean to deliver data to a view in an MVC framework, which we also do in Struts, again with an ActionForm, we cannot do so by making the bean implement a Map. The reason is that PropertyUtils automagically treats Maps in a way that won't allow us to populate a bean that implements a map. This is a serious design flaw, I think, in beanutils. One should be able to use the utilites to both populate a bean and to use the same object to deliver data to a view as a map. The offending code "works", I think, as follows: when you want to populate a bean with BeanUtils (BeanUtilsBean) it hands the bean off to PropertyUtils (PropertyUtilsBean). However, if PropertyUtils "discovers" that the bean is a map, then population fails. I am not 100% certain that this is correct, but it sure looks that way. I think that the inability to populate beans that implements maps is unnecessary and a design flaw severely limiting the use of beanutils. Here is what happens with Struts, for example, if an ActionForm bean implements a Map and the Struts controller attempts to populate the ActionForm bean: java.lang.IllegalArgumentException: Null property value for 'submit' at org.apache.commons.beanutils.PropertyUtils.getNestedProperty(PropertyUtils.java:755) at org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:801) at org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:881) at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:798) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204) at com.crackwillow.filter.GZIPFilter.doFilter(GZIPFilter.java:19) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:233) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:257) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:206) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:833) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:732) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:619) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:688) at java.lang.Thread.run(Thread.java:534) ------- /Additional Comment #1 <http://issues.apache.org/bugzilla/show_bug.cgi?id=32653#c1> From Dakota Jack <mailto:dak...@gm...> 2004-12-12 08:18 / [reply <http://issues.apache.org/bugzilla/show_bug.cgi?id=32653#add_comment>] ------- The central point is that a single bean ought to be able to retrieve and to supply data from the request/response http exchanges. The present beanutils architecture makes that to a large extent difficult by making certain sorts of objects incapable of being retrieval objects, e.g. Map objects. A utilities program ought not to enforce this sort of architectural restriction on the applications it services. I would provisionally suggest that the use of property utils by bean utils be split in its behavior depending upon whether or not the action is one of population (retrieval) versus one of creating the response (supplying data). Jack ------- /Additional Comment #2 <http://issues.apache.org/bugzilla/show_bug.cgi?id=32653#c2> From Craig McClanahan <mailto:cra...@su...> 2004-12-12 20:56 / [reply <http://issues.apache.org/bugzilla/show_bug.cgi?id=32653#add_comment>] ------- It is far too late to make a fundamental change in the architecture of a module that has its current behavior relied on by many thousands of existing applications. At best, you should think of this as an RFE for some additional classes that have different behavior. The current architecture was deliberately designed to solve the problems it does solve, and it continues to do so. However, you are also starting from an incorrect assumption that what you want to achieve is not possible with the current architecture. Simply program the get and put methods of your Map implementation to call through to the corresponding getters and setters for keys that are the properties of this class, and do the normal thing for keys that are not properties. You can do this for specific classes fairly easily, or you can use the solution provided by org.apache.commons.chain.impl.ContextBase that does this thing generally (using reflection to identify what's a property and what's not). |
