commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <remy.mauche...@gmail.com>
Subject Re: [logging] JCL2.0 design - Architecture
Date Mon, 20 Feb 2006 00:56:46 GMT
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. See JULI in Tomcat,
and www.x4juli.org for java.util.logging "implementations" (providers
may be more accurate), but both are done using the
full-logging-implementation way, so maybe not very good examples, as
you would want to only develop facades.

--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx

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


Mime
View raw message