tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent BENOIT <Florent.BEN...@objectweb.org>
Subject Re: [5.0] Property replacement
Date Fri, 17 Oct 2003 15:51:53 GMT
    Hi,

I thought that when you said "in a non hackish and flexible fashion" it 
will for delegating the save-to-xml feature to an helper class and that 
I can contribute to this task.
Maybe I have misunderstand your sentence and I apologize. So I will let 
my patched class as I have no other choice.

Regards,

Florent


Remy Maucherat wrote:

> Florent BENOIT wrote:
>
>> Henri Gomez wrote:
>>    Hello,
>>
>> 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,
>
>
> To which I replied that I'm against hacking any more on the shaky code 
> we have, which is *bad*.
>
> I didn't change my mind, and I didn't forget about your previous posts 
> wither. No need to post again verbatim, IMO.
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message