tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Custom rules for commons-digester
Date Mon, 13 Feb 2012 22:35:55 GMT
-----BEGIN PGP SIGNED MESSAGE-----
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 <chris@christopherschultz.net>:
>>> 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.

Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPOZBKAAoJEBDAHFovYFnnx00P/j1ljXBqJoNn+akP1T/1QAyd
jbywsJNf+kT4LxBHUTfbJ9WwmCjI61ViB3HaZHCJo437WZN3dzl0rsnJyYpVEcET
7bYC9gFm6IWlM1XCteN1PVkbuabk54xSLR9ivRCGNl59DwRvrG7Gekyob7FWRGbi
QLR304L9EwPbnOzFXqSN22+EUEeh/JYOu65Dv428mXpt/Qc51+7nQE6lIXeuTxd8
7e5z6I0MijdmPQ3BkIPg5ucDKhqbEmRIVsrLyoOSTgf2NG8/Z+y+kMXFwhoocTdF
/Au54Z34oTY+AIkUGdI+e5Jm6vq44iOKLjryFMD3iIu8Y3mOkF4/KHy30H5f1RPI
OSqMYzSd3zWvWDn7LeI56JC+VH6UhbiowLw382Mcv8ux9NqB0A8ZBozkQtowhqLa
UT72ADCu1bglycyjC9rOjyZ5C70wycM7pVrCjGyfsL7njocrgm9eLtsiCeRlZgbF
bISLD15cRwty5Nx8N0XIsD/ggeqT/EgCNCilWG1e5FBoQn7V6NhiSmgteCBXefjq
K6Ja8qKVLnC5jVdAhUo8kR0IjM+sn5OUgxzkmDbDLYULswY84266HbhBijU3lUzV
hd34Ga4b2RPUQGX6ZobI/8icIMfVYB7oLSBv7lw2g6uETML1gsVNJ3Z0uUWDya6J
l5qsjoSbd/iucn+Sf3eV
=41V0
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message