At 22:46 05.03.2001 +0100, Anders Kristensen wrote:
>Hey,
>
>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
>whatever.
Absolutely!
>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.
Agreed.
>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:
>
>Appender:
> name
> layout
> errorHandler
> filter
>AppenderSkeleton:
> firstFilter
>WriterAppender
> writer
>Layout:
> 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
>
>log4j.appender.A.name=joe
>
>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: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
