> The implementation of the feature had little to do with the StandardServer class itself.
> It should really be a separate helper class (no more hacks, sorry ;-) ).
Well, I can do the 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 it would be for storeConfig.
So, the Helper class can be on the form StoreConfigHelper with a constructor which take a Server Object.
so 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.
Regards,
Florent
Florent BENOIT wrote:
For the saving feature :
> That feature is thought out for standalone mode. It's hard to predict what are the components which should be saved, and which should not.
> Now if you want to refactor the save-to-xml code to a separate class (and allow configuring that class, of course), then I'm waiting for your patch :)
There is no problem for doing a contribution. But maybe I have to use the skippable mechanism already defined in StandardServer.
So, by adding a public method addSkippable(String classname) (and maybe a removeSkippable(String)) and by adding the isSkippable() mechanism in the storeContext like for storeListener()
I think that addSkippable(String classname) is better than setSkippables(string skippables) as we don't have to know the existing skippables.
These methods will not be called in standalone mode but can be useful in the embedded mode.
If you agree with this, I can propose a patch for the current catalina 5.x cvs.
The implementation of the feature had little to do with the StandardServer class itself. It should really be a separate helper class (no more hacks, sorry ;-) ).
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
