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 02:07:44 GMT
I guess I will have to wait to be enlightened ;-(

> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de] 
> Sent: Wednesday, February 13, 2002 6:11 PM
> To: Jakarta Commons Developers List
> Subject: RE: cvs 
> commit:jakarta-commons/logging/src/java/org/apache/commons/log
> ging/implLogFactoryImpl.java
> 
> 
> That is not the problem.
> 
> I do not want to implement a feature of some logger, what I 
> want is that the wrapper does not collide with the "features" 
> I am using.
> 
> Besides, I can imagine a load of scenarios where multiple 
> logging hierarchies could be used without multiple class 
> loaders being involved.
> 
> So, I don't like singletons on libraries and neither static 
> methods that support that idea.
> 
> I hope I will come back with something more constructive 
> later but my CPU is too busy right now.
> 
> 
> Have fun,
> Paulo Gaspar
> 
> 
> > -----Original Message-----
> > From: Scott Sanders [mailto:ssanders@nextance.com]
> > Sent: Thursday, February 14, 2002 2:27 AM
> > To: Jakarta Commons Developers List
> > Subject: RE: cvs 
> > 
> commit:jakarta-commons/logging/src/java/org/apache/commons/logging/imp
> > lL
> > ogFactoryImpl.java
> >
> >
> > <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>
> 
> 
> --
> 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