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
Jin Zhao wrote:
>
> Maybe the question sucks, but it is from problems i have to face at.
>
> I am writting a web based application aiming at monitoring and controlling
> the logging behavior of our application server, which uses log4j in
> applicaitons code. The problem is, there are so many set(...) methods, but
> lacks related get(...) methods in log4j API, that make it hard to get run
> time information of logging. The following are some examples.
>
> ============================================================================
> ==============
> Appender.java:
> we have setErrorHandler(..), setLayout(...), but have no
> getErrorHandler() and getLayout().
> I really want to know what layout my appender is using at run time.
>
> OptionHandler.java:
> We have "public void setOption(String option, String value)", but no
> "public String getOption(String key)" which return the option value
> as a String. Isn't it convennient that we can know the file name of my
> appender by using something like getOpotion("FileOption") or the
> maxBackupIndex value by using getOtion("Max_Backup_Index_Option") ??
>
> FileAppender.java:
> We have setFile(..), but no getFile()
>
> PatternLayout.java:
> we have setConversionPattern(..), but no getConversionPattern()
> ============================================================================
> ==============
>
> Of course i can get some of these information from the configuration file.
> The problem is, run time logging behavior can change dynamically using those
> set(...), add(....) and remove(..) methods, that make it not consisten with
> the config files. In addition, I want the config files to offer some default
> behavior when the appllications loaded up, but set/reset the logging
> behavior without changing the configuration files. If I really find one
> behavior is better to be written into the config file, I can save it.
>
> I tried to add some get() stuff in the log4j code, and find that a "public
> String getOption(String key)" method is really helpful in my application, it
> fulfills most of the get() tasks.
>
> Is there any concerns related with these get() stuffs behind the log4j
> architecture ?
>
> Thanks a lot.
>
> Jin
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
>
> ------------------------------------------------------------------------
>
> Part 1.2 Type: application/ms-tnef
> Encoding: base64
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
