logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <...@qos.ch>
Subject Re: JavaBeans style log4j config
Date Wed, 07 Mar 2001 23:13:15 GMT
At 22:46 05.03.2001 +0100, Anders Kristensen wrote:
>I had a look at how a JavaBeans style log4j configurator might work.
>It's actually pretty straightforward but there are a couple of issues.
>I've got a PropertyConfigurator running which uses the JavaBeans
>Introspector and BeanInfo interface to configure appenders and layouts.
>Actually it will configure any object given a Properties object and a
>property key prefix (e.g. "log4j.appender.console.layout.") so that's
>pretty cool.

This is good news.

>It will configure properties of three types: String, int, and boolean. I
>figure these are the most commonly used ones and we can reasonably leave
>it to individual components to translate to and from String values if
>they need to configure custom values, say an AWT Color object or


>We could go down the route of a pluggable String-to-whatever
>translation architecture but that seems like overkill and apps can
>extend the log4j configurators to do that themselves anyway if they want
>to. OTOH it's not a big deal to add another few known types.


>The main issue is one of property names. JavaBeans has a well-defined
>algorithm for deriving property names from getter/setter method names
>and a method called setFile(String filename) will translate into a
>property "file", NOT a property "File". The log4j convention has been to
>use an uppercase starting letter. The JavaBeans convention is not to. We
>can ignore the JavaBeans convention and translate whatever the
>Introspector tells us into what we think it should be. I'm not sure we'd
>be able to do so reliably and I think if we're going the JavaBeans route
>we might as well do it all the way. This would mean changing case for
>pretty much all option names currently used by log4j components and
>would obviously be a highly backwards incompatible change.

Backward compatibility is a pretty important issue. We cannot afford to break it (massively)
without a very good reason. However, there is nothing wrong with creating a 3rd configurator
that parses property files but which is implemented using Introspector/JavaBeans. 

>A smaller issue is that using the introspector it is not immediately
>obvious which properties are *meant* to be configured from config files
>and which are not. The straightforward impl will see these as being
>properties potentially to be configured:
>  name
>  layout
>  errorHandler
>  filter
>  firstFilter
>  writer
>  contentType
>  header
>  footer
>Some of these are not String, int, or boolean, so giving them a value
>through a configurator would fail anyway, but one could give, say, an
>appender a name by doing
>The actual name here should be "A" but the configurator will happily set
>the name to "joe". We can either ignore this (quite reasonable I think)
>or build in some knowledge about not setting certain properties.
>I'll do a full implementation, including doing the necessary appender +
>layout modifications once we have agreed to these issues, so anyone have
>any opinions?

I might be suffering from early senility but why did we consider the JavaBeans paradigm in
the first place? Was it because we wanted to create a management facility for log4j? In particular
read (get) methods for log4j components. It seems to me that the configurator aspect is related
more to the write (set) part of things. I do not know if the distinction is really useful
but I'd like to clarify the direction that we are heading towards. 

slightly confused, Ceki

ps: I am CCing log4j-dev for the sake of openness. 

I hope to see you at my ApacheCon 2001 presentation 
entitled "Log4j, A Logging Package for Java".

See http://ApacheCon.Com/2001/US/ for more details.

Ceki Gülcü          Web:   http://qos.ch     
av. de Rumine 5     email: cgu@qos.ch (preferred)
CH-1005 Lausanne           ceki_gulcu@yahoo.com
Switzerland         Tel: ++41 21 351 23 15

View raw message