morph-user — For users of the Morph framework. Please post questions here.

[morph-user] [beanutils] Beans and Maps mixed up in PropertyUtils

[Matt S. <sga...@us...>]

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).

[morph-user] HttpServletRequest to object using Hibernate ClassMetaData

[Steven D. <ste...@gm...>]

Hi,

Would it be possible using Morph to set parameters in a
HttpServletRequest to properties on an object using a Hibernate
ClassMetaData object as a property definition? How should I go ahead
to do this?

Steven