All very good questions. I don't have any good or completed answers. I'll have to
think about it and get back to you. Cheers, Ceki
At 11:03 23.02.2001 -0600, Jin Zhao wrote:
>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]
><br>
></blockquote></x-html>
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
