tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: Custom rules for commons-digester
Date Mon, 13 Feb 2012 23:01:42 GMT
2012/2/14 Christopher Schultz <>:
> Konstantin,
> On 2/13/12 4:32 PM, Konstantin Kolinko wrote:
>> 2012/2/14 Christopher Schultz <>:
>>> All,
>>> There are 15 or so custom rule classes in the Tomcat sources for
>>> handling various commons-digester events.
>>> I've only taken a brief glance at their content, but I'm wondering if we
>>> can't replace these classes with an XML-based configuration that the
>>> Digester itself can handle for us.
>>> Such a change would eliminate those classes form our own code base as
>>> well as allow us to remove the package-renamed code from
>>> commons-digester in SVN (of course, we'd still have to re-package
>>> commons-digester for distribution, but at least we'd have less source to
>>> deal with).
>>> Other than some logging (I can see, for instance, that
>>> ConnectorCreateRule emits warnings when setter methods can't be found on
>>> the target class), is there a compelling reason to have source-based
>>> rules instead of configuration-based rules?
>> They are faster.
> Fair enough, but server.xml is processed only once on startup. Unless
> you're seeing an insane performance increase, I would suggest that
> maintainability might be more important than performance.

That is not the only XML file parsed by Tomcat. There are context
files, web.xml, web fragments, tld files in tag libraries etc.  (Maybe
JSP Documents as well, but I am not sure whether Digester is involved
with them or not. It is likely that it is not.)

There is no problem with maintainability that I know about.

Some rule sets are used in different situations. E.g. web.xml and
web-fragment.xml have much in common, as well as context.xml and
Context element in server.xml.

In my view having an XML configuration for the digister here adds one
more level of indirection. (As in saying that every problem in
computer science can be solved by another level of indirection).

There are two different rule sets for server.xml (parsing it at
startup vs. at shutdown), two different rule sets for context.xml
(parsing its root element, vs. parsing it as whole).

I think maintaining a yet another set of XML files is harder than the
current approach.

(But if it is your itch you may try implementing it and we will see
how far it can go).

> (This also assumes that maintaining an XML-based configuration file
> represents less effort than maintaining the equivalent source code, but
> as I said previously, it would allow us to purge our copies of the
> Digester from our own svn repo as well, which I see as a win).

DBCP and Pool are essentially optional dependencies.

Digester, Fileupload and BCEL are core dependencies that you cannot
run without.

Building them as standalone modules like DBCP might be better, but I
do not see much benefits from breaking the current way of things.

Best regards,
Konstantin Kolinko

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

View raw message