JavaBeans style configuration

[Anders Kristensen <ak...@dynamicsoft.com>]

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: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org