2012/2/14 Christopher Schultz <ch...@christopherschultz.net>: > 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. 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
