At 10:12 15.08.2001 -0700, Craig R. McClanahan wrote:
>On Wed, 15 Aug 2001, Jason van Zyl wrote:
>
>>
>> I really donıt see any downside to binding to log4j in the components. Log4j
>> can easily integrate with anything that comes down the pipe in the future.
>>
>
> From the perspective of a potential user of Commons components, there
>would be a very important downside to locking the components in to using
>Log4J -- that forces the user to use Log4J whether or not they want
>to. (I'm not interested in arguments on why we might want to try to
>convince them otherwise -- not everyone is going to be converted :-).
Hello Craig,
I agree that it is impossible to convince everyone to use
log4j. People have their own set of tools that they like to use.
However, I don't think using log4j in one component keeps anyone from
using another logging package that they are used to. In particular,
Tomcat uses its own logging API but many web application authors use
log4j in their servlets, at least I do. Tomcat logs go to
server.log/catalina.out/whatever and logs from my servlet code are
logged through log4j. It is not at all clear to me whether mixing the
log "streams" of different components is really desirable. As a
servlet developer, I don't really care about Tomcat's logs and Tomcat
probably does not care about my log4j output. That's actually the way
I like it.
The latest version of JBoss uses log4j for its own internal
logging. By default in the JBoss environment, the logs from my EJB
which "happen" to use log4j get mingled with the logs of
JBoss. I have to take special measures so that my EJB logs do not get
mixed with JBoss logs. In an interesting twist, the logs from my
servlets which run fine under Tomcat get mixed up with the JBoss logs
when running under JBoss-embedded Tomcat. Again, I have to configure
log4j by tweaking the log4j configuration file (that jBoss uses) so that
my servlet logs are separate from the JBoss logs.
If jakarta-commons-xxx decides to use log4j, Tomcat can continue to
use its own logging API, and Websphere can continue to use JLog.
>It doesn't matter to such users that they can write adapters and Category
>implementations and such -- they already have their own logging
>environment, and want to use *that* instead without having to learn
>Log4J's configuration formats, or enough internals to integrate it. To
>such users, tying commons components to Log4J will be a showstopper for
>using the commons components in the first place.
Please see my previous point.
>No argument that such a decision might not be rational - but this is
>reality.
>
>Note that the decision is different for something like Turbine, where you
>need more sophisticated logging capabilities. There, it makes perfect
>sense to choose a logging API and use it throughout, plus make it easy for
>applications developed on top of Turbine to take advantage of its
>capabilities.
>
>The decision for commons components should be based on different criteria.
>
>> I think this would also be a step toward making a component API for all the
>> commons projects can use. We can start with logging and go from there :-)
>>
>
>Note that, the way the current abstraction layer works, it defaults to
>Log4J anyway if the classes are visible, so integrating commons components
>into an environment already using Log4J reqauires nothing you aren't
>already doing in terms of configuration.
>
>And, if you don't have Log4J installed, any log output created by Commons
>comopnents is silently thrown away -- you don't have to care at all about
>logging unless you want to.
How is that different when Commons components directly bind to log4j
instead of the abstraction layer? The only difference I see is the
need for log4j.jar to be on the classpath. If the end user logs
through LogXXX API then she can continue doing that and the logs from
Commons components will not log because log4j won't be
configured. Log4j will emit a single complaint message about not being
configured. That complaint message can easily be turned off.
Regards,
--
Ceki Gülcü - http://qos.ch
