All,
I've changed log4j to use JavaBeans style configuration as discussed on
this list. This means that instead of implementing OptionHandler methods
String[] getOptionStrings();
void setOption(String option, String value);
String getOption(String option);
log4j components (appenders, layouts, errorhandlers, filters, and
categories) will define "standard" Java setters such as
public void setFile(String fileName) { ... }
public String getFile() { ... }
public void setPort(int port) { ... }
public int getPort() { ... }
The PropertyConfigurator and DOMConfigurator have been updated to use
JavaBeans introspection to implement this new scheme. They recognize
String, int, long, boolean, and Priority as property types for setters.
Others can be added as appropriate and components are free to handle
custom types as Strings (e.g. the TextPaneAppender handles Colors via
String setters/getters).
OptionHandler now consists of only one method:
void activateOptions();
which is still needed for components which have interdependent options,
e.g. FileAppenders "File" and "Append", which can't take effect
independently of one another. We could decide to dispense with this
interface altogether and use reflection to invoke this method if
present.
There's no requirement to write a getter for all setters but it's a good
idea.
One thing to look out for is that the JavaBeans introspector reports the
most specific setter available for a given property. This means a method
public void setForeground(Color c)
will be chosen instead of another setter
public void setForeground(String c)
The workaround is to avoid this situation, i.e. remove the Color version
or call it something else.
Another thing to look out for is that in some cases (only one or two,
actually) components had setters which were available for app programs
to invoke directly. These might be for properties which could also be
set via the configurators but with slightly different semantics. An
example is FileAppender, which had a method
public
void setFile(String fileName) throws IOException {
this.setFile(fileName, fileAppend);
}
which causes a new file to be opened.
Under the new scheme setFile(String fileName) is invoked by the
configurators and CANNOT do their job until the Append option has been
set also (if one is specificed). Therefore the new setFile will just set
the filename but the file will be opened when activateOptions is called.
App programs which used to call setFile(String) directly might want to
call the two-arg version of setFile() now to achieve the effect they
used to have. Alternatively they can call activateOptions() dircetly.
--
Anders Kristensen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
