Re: [picocontainer-dev] Logging Frameworks for 2.3

Paul Hammant wrote:
> Mike,
> 
>> 1 - Deprecate Tracing Container:  Paul's new methods to 
>> ComponentMonitor take
>> care of all requirements for the container and then some.  (I figure 
>> to remove
>> on v 3.0)
>>
> 
> +1
> 
>> 2 - I know Mauro wanted to only support Commons-Logging in Gems while 
>> I was a
>> raw Log4j fan.  However, lately, I've been using Slf4j + Logback, and 
>> I realized
>> that if we supported CommonsLogging and Slf4j as the only two monitor 
>> types
>> (officially supported, of course) that we would cover the two major
>> Monitor-Strategy libraries and that would probably be sufficient for 
>> common use.
>> So I would:
>>         A - Add Slf4j Component Monitor
> 
> +1
> 
>>
>>         B - Deprecate Log4j Component Monitor. (We can keep it if others
>> use it)
> 
> -1
> 
> People may want to use Log4J direct ... not via CommonsLogging.
> 
> Additonally,
> 
> Maybe we would also want to add formal (optional) ..
> 
>  public class LogFactoryInjector extends FactoryInjector<Log> {
>  }
> 
> .. for each permutation of logging framework.
> 
> - Paul
> 
> PS - Death to static Logging!!
> 
> 

I've actually gone back in time to the good ol days of ...
http://spice.codehaus.org/loggerstore/index.html
(a little component we developed with Peter Donald many years ago)

Reason is that I got frustrated with commons-logging pityful 
configurability and static nature.

LoggerStore is truely IoC friendly - unlike CL.

We could possibily fork it and move it to pico-land (would cheery-pick 
bits we need to the logging specific - ie would not want the whole of 
DNA ported), under pico-logging module.  Thoughts?

Cheers


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email