commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject [digester] CallMethodRule order [bug12997] attn: Emmanuel, Craig
Date Thu, 26 Feb 2004 15:15:29 GMT
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 testcase fix is required to ensure that no patch changes the current
CallMethodRule invocation order, and
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

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.




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

View raw message