Mark, On 2/13/12 5:35 PM, Mark Thomas wrote: > On 13/02/2012 22:01, Christopher Schultz wrote: >> Fair enough, but server.xml is processed only once on startup. > > They also process context.xml files and web.xml files.
These are the classes I was looking at, which all seem to be related to server.xml, possibly context.xml, but probably not web.xml: java/org/apache/catalina//ha/ClusterRuleSet.java java/org/apache/catalina//realm/MemoryRuleSet.java java/org/apache/catalina//startup/ConnectorCreateRule.java java/org/apache/catalina//startup/ContextRuleSet.java java/org/apache/catalina//startup/CopyParentClassLoaderRule.java java/org/apache/catalina//startup/EngineRuleSet.java java/org/apache/catalina//startup/HostRuleSet.java java/org/apache/catalina//startup/LifecycleListenerRule.java java/org/apache/catalina//startup/NamingRuleSet.java java/org/apache/catalina//startup/RealmRuleSet.java java/org/apache/catalina//startup/SetAllPropertiesRule.java java/org/apache/catalina//startup/SetContextPropertiesRule.java java/org/apache/catalina//startup/SetNextNamingRule.java java/org/apache/catalina//startup/TldRuleSet.java java/org/apache/catalina//startup/WebRuleSet.java >> (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. Maybe we're not talking about the same thing: we already have the digester. It has everything we need. I'm suggesting that these classes are not necessary at all, and can be replaced by capability that the digester already provides. > 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. That's fine: we can keep using it. Unless something other than simple package-renaming is going on, we can even make the package-renaming part of our build process and remove the sources from svn. > 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 we have a fork for a reason (none has been specified) then that's fine. I just noticed something and asked about 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. Ok. -chris
signature.asc
Description: OpenPGP digital signature
