Re: RE: Why more set(....) APIs than get(....) APIs in log4j ?

[Jin Zhao]

First I am glad to see there are also people inteterested in this topic. That means I don't need to keep my modified version of log4j updated with the official releases. However, I still have questions about how to do that. Since I know little of Beans stuff, please point out where my questins suck.



>Why do you think so?
>
>The bean paradigm provides information on the type of the option values. The getOption/setOption approach does not give >you info on the value type. Moreover, the java beans have provision for finding editors for a given type, e.g. we could write >a PriorityEditor for graphically manipulating priorities.
>
>Java Beans just give us more room to maneuver. Beans are also non-intrusive. It's pretty brilliant stuff IMHO.

Does this also mean we will replace setOptions approach with setXXX() too ? Then what will be the usage of OptionHandler ? Should we give it up ? From my experience of using getOptions/setOptions, this approach make us happy where we don't need to know(or have no way to know) the names of the paramerters to be configured. In fact, I use xml communication bettween the application server and my web application. I can get parameter names by using getOptionStrings() and their values by getOption(key), set/reset them by setOptions(key, value), and then I can use activateOptions() to make the new configuration really work. How can I set a fiieName but don't know the parameter name is "FileName" by using setFileName() ? Should I need a test statement to see if the target is a FileAppender ?


>>Is it a big deal to support both interfaces? I guess I don't understand the downside
>>of putting out the ...Option interface. (Other than cluttering up the API, I guess).
>>Correct me if I'm wrong, but if you are not in a bean environment, you'd have to do some
>>work to figure out all the get(...) methods to call...
>>
>Yes, unfortunately it is a big deal. It is 2 times the number of options in all appenders. Assuming there are 15 appenders with >3 options on average, that gives 45 more things to worry about. That is definitely not acceptable. It's one way or the other >but not both. Cheers, Ceki

What if we have a optionsProperty which is a java Properties to hold all the parameter key/value pairs ? The value can be set in setOptions(XXX). The real implementation lies in activateOptions(). The getOptions(XXX) just need return the value from the properties. The original log4j API confuse me a liite in that the real implementation of activateOptions() lies in setXXX(), and setXXX() duplicate the job of assigning values which also exists in setOptions(XXX). What if let the setOptions(XXX) to do the "set" job, and change the name of the current setXXX() to activateXXX() ?

I will go back to read the config() code in log4j to see how they work now. Maybe I also need read how Java Bean works before using the coming 1.1 Beta.


Jin


-- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]