Re: LoggerStore

Peter Donald wrote:
> I change a few things - most of them cosmetic and should no effect. The only 
> significant change I made was moving the constants for the logger type to the 
> configurator as thats the only place they are actually used.
> 
ok

> Other things to think about;
> 
> LoggerStore vs LoggerStoreFactory Responsibilities
> --------------------------------------------------
> 
> It may be better to push all the construction code for input to LoggerStores 
> into LoggerStoreFactory. In some cases the LoggerStoreFactory passes in an 
> InputStream into the LoggerStore implementation and the LoggerStore will use 
> that to build the properties/XML. 
> 
> A better idea to move the construction of properties/XML into 
> LoggerStoreFactory. That way it becomes easier to change how this is loaded 
> in the future without changing the LoggerStore implementation. ie We could 
> load the properties/XML from ContextClassLoader or perhaps classloader passed 
> into factory. 
> 
> If we did all the construction in the LoggerStoreFactory then we would just 
> need to change that rather than having to change both the LoggerStore and the 
> coresponding factory. It also makes testing the LoggerStore much more easier.

that's the way I started off - but there are a issues that made me go in 
this way:
1. I had problems configuring log4j using JDK14
(to do with the fact that dtd is specified in the DOCTYPE)
You could pass in a w3c.Document but the log4j api only accepts 
InputStream, File or Element.

2. JDK14 accept only properties but only in an InputStream object
(don't know why!)

3. There are different types of XML resources - eg Log4j XML and LogKit 
Configuration.

4. The InputStream on the other hand is a general input object that can 
be tranformed input all types - XML, Properties, etc ...
What is the problems with InputStream?  It can be loaded from any 
classloader, can it not?

My aim was to have unified approach with all three loggers, with the
differences encapsulated in the InputStream they were passed.
The loading can still be changed in the factory, just need to pass it
as an InputStream rather than a Properties or Element or Configuration.


> Testing Output
> --------------
> 
> Currently the tests just do some configuration and assume it all works. What 
> we should really do is be testing the output produced by the configured 
> loggers matches what we think it should be. 

testing is code is not complete and it will test more that just config
once the other bits are agreed.

> 
> LogKit1.2/Next Log4j
> --------------------
> 
> I think we are using unreleased features from both of these toolkits. We 
> should push to get them released as soon as possible.
> 

We certainly use the CVS version of logkit - but we use the released 
1.2.8 of log4j.
Yes a quick release would of logkit is essential.


Cheers




-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com