On Sun, 2004-04-25 at 20:06, Joel McConaughy wrote:
> I'm trying to extend Hugo's hibernate sample to handle queries that 
> return multiple rows but have run into a problem.  I can load the query 
> results, edit existing rows and delete rows successfully using the 
> following flow:
> 
>     var factory = 
> cocoon.getComponent(Packages.com.displayware.hiblib.PersistenceFactory.ROLE);
>     var hs = factory.createSession();
>     // NOTE:  users class type is 'java.util.ArrayList'
>     var users = hs.find("from User");
>     form.load(users);
>     form.showForm("simpleuseradmin-display-pipeline");
>     form.save(users);
>     hs.flush();
>     hs.close();
>     cocoon.releaseComponent(factory);
> 
> However, when the add method specified in this binding snippet is called:
> 
>    <wb:on-insert-row>
>       <wb:insert-bean classname="com.displayware.hiblib.User"
>       addmethod="add" />
>     </wb:on-insert-row>
> 
> I get the following error:
> 
>     org.apache.avalon.framework.CascadingRuntimeException:
>     "resource://org/apache/cocoon/woody/flow/javascript/woody2.js", line
>     198: uncaught JavaScript exception: at simpleuseradmin
>     
> (file:/home/joel/jakarta-tomcat-5.0.19/webapps/cocoon/StorePortal/flow/useradmin.js,
>     Line 35) at
>     (resource://org/apache/cocoon/woody/flow/javascript/woody2.js, Line
>     198): org.apache.avalon.framework.CascadingRuntimeException:
>     InsertBean failed. 
> 
> I've traced thru the code and found the exception is thrown in the 
> doSave() method in insertBeanJXPathBinding.java at line 109:
> 
>            // lookup the named method on the parent
>             Method addMethod =
>                 parent.getClass().getMethod(this.addMethodName, argTypes);
> 
> The problem appears to be that the getMethod call requires that the 
> argTypes match the exact signature of the corresponsign method.  In this 
> case, ArrayList.add(Object o).  However, the binding is passing in the 
> class associated with the row com.displayware.hiblib.User which causes 
> getMethod() to throw an exception.  The funny thing is that this call 
> ***would work*** if called directly since com.displayware.hiblib.User is 
> derived from Object.
> 
> Is there any way to wrk around this?  Thanks.

The problem is the Class.getMethod method which searches for exact
matching argument types. It doesn't seem the standard Java API contains
something to find methods with compatible argument types.

A quick look at jakarta commons beanutils
(http://jakarta.apache.org/commons/beanutils/) shows that they have an
utility for that: MethodUtils.getMatchingAccessibleMethod()

If you are capable of doing this yourself, could you try if you can fix
it by using that, and if so submit a patch?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]                          [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to