Remy Maucherat wrote:Hello,
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 : storeConfigHelper.store(server)
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
Regards,
Florent
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
