-----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 <ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
