tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [5.0] Property replacement
Date Fri, 17 Oct 2003 16:51:02 GMT
Craig R. McClanahan wrote:

> Remy Maucherat wrote:
>> Hi,
>> I'd like to make a small proposal to do property replacement. Included 
>> are changes that should be made in the digester, and that I'll post on 
>> commons-dev if I have approval.
>> - Add a get/setProperty to Container. This would allow a property 
>> inheritance across containers, similar to Tomcat 3.3 features as 
>> described by Bill.
>> - Add the two introspectionUtil replaceProperties methods to the 
>> digester, along with a way to set the array of PropertySource globally 
>> for a digester instance. The replaceProperties will be called 
>> automagically if the standard set properties rule is added to an 
>> element, and will check all attributes for possible property replacement.
> This sounds like a good addition to Digester.  I would prefer to also 
> have replacement enabled by a boolean property on the Digester instance 
> (default=false), so that we don't mess up people using Digester to parse 
> things that happen to have "${ ... }" in the attribute values or element 
> bodies.

I was thinking about that. This sounds reasonable.

>> - Additionally, we could add the "set all properties" rule to 
>> digester, which would attempt to call a setProperty method on an 
>> object to set properties which have no designated setter. I'm mixed on 
>> this: we need something like that for the Connector, but this is a 
>> very specific situation, and may be abused in the general case.
> I'm dubious on this one as well, but will look at the details of what 
> you'd propose.

I think I'll forget about it in the general case.

>> - Note: The properties used will not be saved when using save-to-XML 
>> from the admin. If anyone has an idea on how to make it work, let me 
>> know ;-) (anyway, save-to-XML should probably be rewritten in a non 
>> hackish and flexible fashion, but this can wait)
> Agree that this code is about as hackish as you can get, but at least it 
> sorta worked :-).

Yes, it worked good :) I added more hacks myself in there to make the 
saved XML look a bit less nasty :)
Scary code :-D


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message