Hi,
I had inquired about a get(...) feature several weeks ago. I'm happy to see
that it is in the works!
I have no problem with the bean-like getX, setX interface, but it seems to me
that in a non-bean world, the setOption, getOption, getOptionStrings interface
would be much more useful.
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...
Thanks,
Rich Trevor
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 22, 2001 2:25 PM
To: LOG4J Users Mailing List
Cc: anders Kristensen
Subject: Re: Why more set(....) APIs than get(....) APIs in log4j ?
At 22:01 22.02.2001 +0100, Anders Kristensen wrote:
>Jin,
>
>Funny you should ask, because the getters you ask for have actually been
>applied to the log4j version in the CVS repository and will be included
>in the next release. However, we've been discussing the option of
>changing the current option OptionHandler configuration strategy from
>something based on
>
> void setOption(String key, String value) { ... }
> String getOption(String key) { ... }
> String[] getOptionsStrings()
>
>to something based on regular Java setters and getters, e.g.
>
> void setFilename(String name)
> String getFilename() { ... }
>
>and then use a Beans-like strategy or reflection or something to figure
>out which parameters a log4j component knows about. That seems to be a
>better approach but requires a bit more work.
>
>Anders
Anders,
I think that the getX/setX or bean paradigm is more widely accepted. We should probably go with that. The getOption methods are cool except that if they go into an official release it will damn hard to take them back. So if we decide to switch I think we should switch as soon as possible. I actually intend to release 1.1beta before this weekend though that is not a promise... What do you think? Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
