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:[EMAIL PROTECTED]] > 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/implL > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 13, 2002 4:43 PM > > To: Jakarta Commons Developers List; [EMAIL PROTECTED] > > 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:[EMAIL PROTECTED]] > > > > 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:commons-dev-> [EMAIL PROTECTED]> > > > For > > additional commands, > > e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:commons-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
