Re: JavaBeans style log4j config

[Ceki Gülcü <cg...@qos.ch>]

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: cgu@qos.ch (preferred)
CH-1005 Lausanne           ceki_gulcu@yahoo.com
Switzerland         Tel: ++41 21 351 23 15

Re: JavaBeans style log4j config

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

Sorry for being such a slug in responding! Work (the stuff I'm paid to
do) has been pretty hectic lately.


Ceki Gülcü wrote:
> 
> 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.

Agreed. This issue isn't important enough for such a big inconvenience.

> 
> >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.

I'm not sure what would be involved in creating a complete management
framework, but it doesn't sound like something we'll want to do.

However, I do think it's very worthwhile to support reads in addition to
writes. The ability to recreate the log4j configuration for a running
JVM means we can potentially do some very interesting things, e.g.
connect to a running JVM and ask it for its configuration, and then
reconfigure it to log to a remote logging server which has a hierarchy
set up identically to how the client JVM was configured.

Now, that's starting to sound like a lot of additional work, but all I'm
arguing for with regards to this JavaBeans style configuration is that
we don't rule out the possibility for recreating knowledge of
configuration from a running log4j system itself.  The existing
OptionHandler set/getOption() + getOptionStrings() allows that and we
should still be able to get it with a beans approach.

What we'd like to be able to do is to recreate a configuration file so
that configuring log4j using that config file will result in a
configuration identical to the one it was recreated from.  The main
issue is that JavaBeans maps the case of property names. This means that
for a given getter method we can't necessarily know the exact case of
the property name as it appeared in the config file.

I'd like to propose an approach which is slightly different from what I
proposed earlier. Basically the idea is that given an
appender/layout/whatever option pair, say <param name="File"
value="System.out"/>, we run the param name through
Introspector.decapitalize(), look up the setter associated with the
result, check the getter signature and convert the argument as
appropriate, and invoke the setter.

Then in order to recreate a configuration we find all getters for an
object (appender/layout/...), for each of them figure out what the
parameter name is, do the reverse operation of
Introspector.decapitalize(), etc. etc.

I've got this modified scheme coded up and it seems to work. This way of
doing things does not break existing configuration files. In fact I
don't think anyone would have to notice the changeat all, except for
appender/layout writers who will have nicer looking source code.

It does imply a change in how parameter names are considered, though. 
It means, for example, that a parameter "File" is the same as "file",
and that "ConversionPattern" is the same as "conversionPattern" (as
former names are mapped to the latter by the JavaBeans introspector) but
"URL" is *not* the same as "Url" or "url".

It would be a bad idea to have different properties for the same
component which differ only in case so I think in practice this is not
likely to cause problems.

Hopefully all this doesn't sound *too* confused. If it doesn't, I'll
code it up properly and modify all those components which will need
change this weekend.

Cheers,
Anders

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org