tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Custom rules for commons-digester
Date Mon, 13 Feb 2012 22:35:55 GMT
Hash: SHA1

On 13/02/2012 22:01, Christopher Schultz wrote:
> 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.

They also process context.xml files and web.xml files.

> (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).

Not if we have to replace it with a library that is bigger than the
code we are removing.

Further, we can't just use commons-digester. We would have to package
rename it in the same way we do with pool, dbcp, file-upload, bcel etc.

pool and dbcp have had enough bugs that we need to keep up to date
with the latest releases. bcel and fileupload haven't needed to be
updated for bug fixes but we have kept them up to date anyay - mainly
because we can. Digester was forked a long time ago and hasn't been
updated - and hasn't needed to be. Absent a bug that needs fixing, I'm
struggling to find a benefit to updating it.

If you have been following trunk, you'll know I am slowing removing
code from digester and modeler that we no longer need. We should end
up with something smaller and more focused at the expense of having to
maintain it. Noting that there have been few/no bugs in that code.

Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla -


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

View raw message