tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Custom rules for commons-digester
Date Tue, 14 Feb 2012 16:25:47 GMT
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


Mime
View raw message