On Fri, 2005-06-03 at 14:28 +0800, Eugene.Ng@hbosa.com.au wrote:
> Hi Simon,
> 
>       I might have missed your point, but how does this explain the
> different call order for those with "paramtypes" declared versus those
> without "paramtypes"? I'm guessing here that if paramtypes are not
> declared, it gets triggered immediately (WITHOUT being pushed into the
> stack) ..but when paramtypes are declared it gets pushed into the stack
> thus LIFO ???

I can't explain why you are seeing different behaviour when paramtypes
are explicitly declared vs not. It really seems unlikely to me, and to
be honest I suspect what you describe is not actually what is happening.
But if you can build a simple test case that demonstrates that
specifying a paramtype really can affect call order then I would
certainly be willing to look into it. Or if you provide a test that
demonstrates such an issue and a patch to fix it I will be even more
enthusiastic to look at it!

What *can* happen is that one of your calls can get skipped completely.
There's a special case for CallMethodRule when it has only one
parameter: if the parameter is not available, the call isn't made. This
is intended to avoid overriding a default value with "null" (though I
wouldn't have designed it to work that way myself). In combination with
the fact that two CallMethodRule rules associated with the same pattern
can get their params mixed up, this can mean that one of the
CallMethodRule rules gets its param set twice (then makes the call with
whatever param value got set second) while the other thinks its
parameter never got set so never makes the call at all. Mix into that
the issue that one method takes a Boolean but due to param mixups the
string that CallMethodRule tries to pass to it may not be convertible to
a Boolean and things get really complicated to diagnose. It wouldn't be
hard to misunderstand what's happening.

But all of this is not relevant anyway if my suggestion solves the issue
for you.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org