commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: cvs commit:jakarta-commons/logging/src/java/org/apache/commons/logging/implLogFactoryImpl.java
Date Thu, 14 Feb 2002 01:26:30 GMT
<rant>

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?

If you wanted domains/guards, wouldn't you implement this in the
container that is using the logging API?

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()'.

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?

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.

</rant>

Sorry for the rant, I just believe that we are starting down the
slippery slope of wholesale duplication of all logging APIs.

Scott

> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net] 
> Sent: Wednesday, February 13, 2002 4:43 PM
> To: Jakarta Commons Developers List; paulo.gaspar@krankikom.de
> Subject: RE: cvs 
> commit:jakarta-commons/logging/src/java/org/apache/commons/log
> ging/implLogFactoryImpl.java
> 
> 
> On Thu, 14 Feb 2002, Paulo Gaspar wrote:
> 
> > What about multiple logging hierarchies?
> 
> I think the best solution is to add an explicit 'guard' or 
> 'domain' to the 
> API. 
> 
> We don't have to do it now - but we must make sure it is clear that 
> getInstance() _should_ return a local logger in a container env - 
> so 2 different applications using the same name for a logger 
> will not get mixed up. 
> 
> Using the thread class loader as the default 'domain' ( in case 
> getInstance( name ) is called ) is reasonable, given that most 
> containers will use that, and that the factory/logger 
> discovery is dependent on the class loader.
> 
> In a future version ( or in this one ? ) we can add the 
> explicit getInstance( Object domain, String name ), and 
> different apps will be able to share a Log ( assuming they 
> have access to a common 
> guard object ).
> 
> Costin
> 
> 
> > 
> > Have fun,
> > Paulo Gaspar
> > 
> > > -----Original Message-----
> > > From: Jon Scott Stevens [mailto:jon@latchkey.com]
> > > Sent: Wednesday, February 13, 2002 11:40 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: cvs 
> > > 
> commit:jakarta-commons/logging/src/java/org/apache/commons/logging/i
> > > mplL
> > > ogFactoryImpl.java
> > > 
> > > 
> > > on 2/13/02 1:52 PM, "Jon Scott Stevens" <jon@latchkey.com> wrote:
> > > 
> > > >   public Log getInstance(String foo)
> > > 
> > > Sorry, that should be:
> > > 
> > > public static Log getInstance(String foo)
> > > 
> > > But you get my point...
> > > 
> > > -jon
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:   
> > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <mailto:commons-dev-help@jakarta.apache.org>
> > > 
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For 
> additional commands, 
> e-mail: 
> > <mailto:commons-dev-help@jakarta.apache.org>
> > 
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 

--
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