On 3/24/06, Costin Manolache <[EMAIL PROTECTED]> wrote: > > An alternative is to use the 'no discovery, no plugins, no layers' > implementation of commons-logging > that we have in sandbox :-) - which just implements the commons-logging > APIs > hardcoding everything to java.util.logging. People who want log4j or > another > logger can replace > the jar with the 'official' discovery-based implementation if they need > it. > > There are a lot of benefits of having a logger with discovery and a > mini-logger if no real logger is found, but > for tomcat we know java.util will be found, and it avoids a lot of > problems > to just use the hardcoded one.
+1 sounds like a good plan static binding has many advantages especially when dealing with high level classloaders. it should also be much more preformant. i'll check out the sandbox this weekend and double check the implementation for any known issues with static binding JCL implementations. if a user deploys a web application that uses and ships with JCL, then AFAIK when deployed in a parent-last classloader the dynamic discovery mechanism should work fine. may need to check that the workaround put in place for the hot deployment memory leak functions ok with the proposed configuration. - robert
