commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: cvs commit:jakarta-commons/logging/src/java/org/apache/commons/logging/implLogFactoryImpl.java
Date Thu, 14 Feb 2002 03:12:41 GMT
LOL
Don't hold your breath. I only "hope", remember?
=;o)

Have fun,
Paulo

> -----Original Message-----
> From: Scott Sanders [mailto:ssanders@nextance.com]
> Sent: Thursday, February 14, 2002 3:08 AM
> To: Jakarta Commons Developers List
> Subject: RE: cvs
> commit:jakarta-commons/logging/src/java/org/apache/commons/logging/implL
> ogFactoryImpl.java
>
>
> 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>


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