On Wed, 13 Feb 2002, Scott Sanders wrote: > Is this just re-inventing logging? Why are we doing all of this? > Aren't we trying to just hide the complexity of Log4J/LogKit/JDK1.4, > while making them transparent?
Unfortunately - yes. The best solution, as I said many times ( including the first time I -1 the commons-logging ) would be to use log4j, which is the jakarta project that seem to have the most users and adoption. It seems that's not possible at this moment - so we need an API to abstract the loggers. > If you wanted domains/guards, wouldn't you implement this in the > container that is using the logging API? That's one use case - but not the only one. > I am just confused as to what we are trying to do. IMHO we are *not* > trying to implement every feature of every logging API, we are just > trying to say: 'be friendly and please do not use system.out.println()'. We'll not implement every feature, but we need a reasonable set of features - and dealing with application isolation in a container environment ) is essential ( IMHO ) ( after all jakarta is developing 'server side' components ). If other logging features are easy to abstract and are supported by most loggers - we should add them as well, in a future version. > If, for example Tomcat wanted to use commons-logging as it's logging API > with pluggable impls to LogKit, Log4J and java.util.logging, I would > assume that it is the responsibility of the container (Tomcat) to give > each webapp its own logging environment. That way my webapp could be > using Log4J while Peter's webapp uses LogKit. Am I completely off base > here? Again, it's one valid use case - but not the only one. Most webapps today are configuring their own logger ( you see log4j.jar in lib, etc), and the servlet spec does not provide any requirement for a container to plug in a logger. So a portable application should include and configure it's logger. If the commons-logging is supported by the container, it can provide additional features - but for that the API must be secure. Even if IOC is a possible solution to provide app isolation, it is not the only one and it's certainly not the common use pattern today and not useable in a servlet environment. > Bottom line is I don't want to participate in the complete duplication > of the existing 'big 3' logging APIs. I was interested in participating > in a small, functional replacement for System.out.println() that would > interact well when components using this API were plugged into a larger > framework. It's not duplication, but abstraction. IF this can't be an API that provides at least some basic security and app isolation - it's worthless, and it would be better for us to just use one of the logging implementations ( prefereable log4j, since it's the closest to 'defacto standard' ) and forget about commons-logging. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
