commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject RE: cvs commit:jakarta-commons/logging/src/java/org/apache/commons/logging/implLogFactoryImpl.java
Date Thu, 14 Feb 2002 19:05:13 GMT
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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message