On Thu, 14 Feb 2002, James Strachan wrote: > How about we do the following > > * each component by default initializes itself from the default hierarchy > (as we're all doing now anyways).
What do you mean by 'default hierarchy' ? What we are doing now is wrong, 2 applications shouldn't get the same Log object even if they use the same name ( especially in the current case with names derived from class name ). If 2 apps use the same library, their logs will get mixed up - that's unacceptable IMHO. The current model works only if the commons-logging is strictly local to each application - but that prevents the container to plug in. > * each component may decide to make the Log object available as a public > property. Doing so allows it to be explicitly set when deployed in some > container environment. This will enable an application developer to tinker > with hierarchies if they wish, to explicitly share logs across seperate web > apps or whatever. So the container will have to know about every application and the public properties it defines ? 2 webapps can't share a custom class or API - they are in different class loaders, so it's quite hard to call each other's APIs, even if they know it. Costin > > Then all bases are covered right? So things stay simple from the component > developers perspective then application developers can do complex & wacky > stuff if they wish. > > James > ----- Original Message ----- > From: "Steve Downey" <[EMAIL PROTECTED]> > To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]> > Sent: Thursday, February 14, 2002 3:19 AM > Subject: RE: cvs > commit:jakarta-commons/logging/src/java/org/apache/commons/logging/implLogFa > ctoryImpl.java > > > > What I can't imagine is a component that knows about multiple logging > > hierarchies. That smells an awful lot like the business of the > application, > > not the component. What it comes down to, is, what can a Digester pass > into > > the LogFactory.getInstance call to specify a domain or guard? > > > > What would make sense, is for Digester to have a setLogFactory() method. > The > > custom factory would be responsible for setting up the log in the correct, > > customer defined, hierarchy. > > > > Any logging during construction would have to go to the system default > > logger. Whatever that is. > > > > > -----Original Message----- > > > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, February 13, 2002 9:11 PM > > > To: Jakarta Commons Developers List > > > Subject: RE: cvs > > > commit:jakarta-commons/logging/src/java/org/apache/commons/log > > > ging/implL > > > ogFactoryImpl.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:[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/log > > > ging/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]> > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > -- > 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]>
