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.
<snip/> -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
