commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [logging] JCL2.0 design - Architecture
Date Sun, 05 Mar 2006 00:17:37 GMT
Remy Maucherat wrote:
> I am not very enthusiastic (from the container perspective). Let's see:
> - Static discovery may look nice to some, but given the most likely
> class overloading rules, it means the whole container and its
> applications would use a single logging framework (which is ok in many
> cases, though). So IMO you need to keep a working dynamic discovery.
> - Please continue providing support for using the TCCL (as the TCCL -
> or similar - is used in most JNDI impls, doing otherwise is a bit
> redudant as far as I am concerned, and JNDI access is most likely
> slower).
> - If you're changing the API, I think you should consider using
> java.util.logging as the facade API to replace the commons-logging 1.0
> API. While the API exposed might be a bit sub optimal, this would be
> the most "standard" way from users' perspective.

I haven't used java.util.logging so I might be way off here. How about 
having *both* JCL 1 and j.u.l APIs in JCL 2. I don't even know if this 
is possible, but it could be a nice path forward if, as someone else 
suggested, j.u.l will be *the* logging API 5 years down the road.


Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message