tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent BENOIT <>
Subject Re: [5.0] Property replacement
Date Fri, 17 Oct 2003 15:35:19 GMT
Henri Gomez 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.
>> - 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.
>> - 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)
> +1
> The save could be implemented by saving all the discovered properties
> to an another xml file which will be load at next start time ?

As I had already said in a previous mail, I'm interesting in the 
customisation of the save-to-XML feature. If it can be more flexible in 
order to specify our own save instead of supplying a patched 
StandardServer class (We can not extend extended the class as it's a 
final class. And I understand that it's can be a final class)

So, maybe I can contribute on a helper class, but I have some questions.
The helper class will be for the method storeConfig() or for 
storeServer() ? Because the name of the config file will remain the same 
name in the same place.
But it's true that the helper class must allow the best flexibility so 
maybe it would be for storeConfig.

So, the Helper class can be on the form StoreConfigHelper with a 
constructor which take a Server Object.
The storeConfig() method of StandardServer will call :
All the stuff concerning exceptions, persistables, skippables could be 
in this helper class. Or it can be arguments for the constructor of the 
helper class.
StandardServer will also have a method for setting the helper class.
So there is a need of an interface. My next question is : Can we 
authorize the default StoreConfigHelper class to be extended and by 
allowing the fact that storeListener, storeContext, etc will be 
protected and not private.
Or if we have only choice by implementing a class of the 
StoreConfigHelper interface.

My last question is about the name and the package of these classes.
The helper class must go on the util package or stay in the core package.
The interface must go on root package where there are a lot of interfaces ?
Do you have advice for the name of these classes or architecture for 
this helper class.

I'm very interesting by having an helper class for customize the 
save-to-xml without having to patch StandardServer class


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

View raw message