commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Micael <>
Subject Re: [Digester] problem calling methods with a primitive parameter but no xml attribute specified
Date Sat, 12 Apr 2003 16:14:43 GMT
Boy, Sis,

You were up late.  Let me know about these things before hand and then I 
can tell you how much I love you and how well I hope things go.  I know 
that won't change anything, but it will give you another person sitting in 
your corner in your head and heart.  You don't have to do these things 
alone.  That is why you have older and younger brothers.  I am glad that 
things went well.  You must have been really scared.  We are pretty 
vulnerable as people.  Seems like everyone is having their share of things 
this last couple months.



At 10:26 AM 4/12/03 +0100, you wrote:
>digester 1.4.1 should be backwards compatible with digester 1.3 so i'd say 
>that this sounds like a bug. i'm having trouble replicating the problem 
>exactly and i haven't been able to write a unit test for this case.
>could you give me more details about when the problem occurs including the 
>rules that you are using and details about the parameters that the method 
>takes. ideally, if you could create a simple test case that exhibits this 
>problem with generic classes which you would be willing to donate the the 
>apache software foundation, then so much the better.
>- robert
>On Friday, April 11, 2003, at 10:24 AM, xPosting 02 wrote:
>>I've got a problem as I wanted to update digester 1.3 to 1.4.1 in one of our
>>I call a method with a primitive (boolean) parameter in a parse rule. if I
>>don't specify an attribute for this parameter in XML, digster 1.3 converted
>>the null value to false (boolean). digester 1.4.1 doesn't converts the null
>>value to false (boolean) but tries to call the method with the null value.
>>because the method expects a
>>primitive boolean value java.lang.reflect.Method.invoke(Native Method) throws
>>a NullPointerException.
>>I think this different behavior between 1.3 and 1.4.1 is because of a
>>difference in CallMethodRule.end()
>>--- digester 1.4.1 ---
>>// Construct the parameter values array we will need
>>// We only do the conversion if the param value is a String and
>>// the specified paramType is not String.
>>Object paramValues[] = new Object[paramTypes.length];
>>for (int i = 0; i < paramTypes.length; i++) {
>>     if(parameters[i] instanceof String &&
>>        !String.class.isAssignableFrom(paramTypes[i])) {
>>         paramValues[i] =
>>                 ConvertUtils.convert((String) parameters[i], paramTypes[i]
>>     } else {
>>         paramValues[i] = parameters[i];
>>     }
>>--- ---
>>--- digester 1.3 ---
>>// Construct the parameter values array we will need
>>Object paramValues[] = new Object[paramTypes.length];
>>for (int i = 0; i < paramTypes.length; i++) {
>>     paramValues[i] =
>>             ConvertUtils.convert(parameters[i], paramTypes[i]);
>>--- ---
>>is this behavior in 1.4.1 a bug or is it 'by design'.
>>if 'by design' is there another solution than writing a method which expects
>>a java.lang.Boolean parameter?
>>MySign AG, Switzerland
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:


This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message