commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [digester] CallMethodRule order [bug12997] attn: Emmanuel, Craig
Date Thu, 26 Feb 2004 11:19:17 GMT
Hi Simon, thank you for taking care of this issue. Actually I expected a 
"real world" test case demonstrating the need for a specific order 
rather than my own test case with the opposite assertion, but that's 
fine :) I wish i had more time to investigate and isolate the Tomcat 
issue, maybe I just missed a trivial side effect that was easily fixable.

I don't plan to (re)open the bug in a near future, I can't remember 
exactly why I needed this feature at that time, but I think a 
FactoryCreateRule would solve the issue I encountered.

Emmanuel Bourg

Simon Kitching wrote:

> Hi Emmanuel,
> Re your comments on bugzilla
> I'd like to transfer this discussion to email rather than bugzilla form,
> if that's ok. It's a pain typing and reading bugzilla comments :-)
> I guess the problem is that the bugzilla entry is now addressing two
> separate issues:
> (a) 
> A testcase fix is required to ensure that no patch changes the current
> CallMethodRule invocation order, and
> (b) 
> an enhancement request from you (2002-10-30) to add a new rule or add an
> optional feature to the existing CallMethodRule.
> I've just fixed (a), but (b) is still pending it seems..
> Your comment of 2002-10-30 said that the digester test cases were
> running fine, and asked for a quick example that would break with your
> patch. Well, that is clearly a flaw with the existing test cases, and
> the test case change I recently committed provides that example you
> asked for. The test you did with Tomcat (broke with your patch) shows
> that the current CallMethodRule invocation order is deliberate and
> should not change.
> Are you intending to create an alternate version of your attached patch
> which implements a new rule (eg CallMethodImmediateRule), or an
> enhancement to CallMethodRule which adds this behaviour as *optional*
> and *off-by-default*? I'm neutral on this myself. But if you do, it
> might be nice to create a new Bugzilla entry so we can close this
> existing one which is now rather confusing due to the two intermixed
> issues.
> I don't really understand Craig's comments re "hierarchical
> structure that is isomorphic to a tree of beans that is being created".
> However I do understand his comment re "backwards incompatibility problem",
> which is what I have addressed here.
> Comments?
> Regards,
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message