You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Steve Downey <st...@netfolio.com> on 2002/02/14 04:19:46 UTC
RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common
s/logging/implLogFactoryImpl.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:paulo.gaspar@krankikom.de]
> 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: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/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: 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"
> <jo...@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:
> > > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > For
> > > additional commands,
> > > e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <ma...@jakarta.apache.org>
> > >
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:jakarta-commons/logging/src/java/org/apache/commons/logging/implLogFactoryImpl.java
Posted by James Strachan <ja...@yahoo.co.uk>.
----- Original Message -----
From: <co...@covalent.net>
> 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' ?
Just calling the current getInstance() method.
> 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 ).
What do you mean by 2 applications? 2 seperate web applications?
> If 2 apps use the same library, their
> logs will get mixed up - that's unacceptable IMHO.
It depends on what the end user wants. If we're talking 2 web apps then I
agree folks often want to keep them seperate. Though shouldn't one of the
big
3 be used to solve this issue? i.e. commons-logging doesn't need to support
this kinda stuff does it?
> The current model works only if the commons-logging is strictly
> local to each application - but that prevents the container to
> plug in.
So either commons-logger gets deployed with each web application then
everything stays local & seperate or one of the big 3 loggers could be used
underneath commons-logging to allow more complex logging to be done, sharing
things across web apps if required or whatever. Or we can use the proposed
ServletLog implementation in web applications, then its the servlet
container's job of dealing with logging.
> > * 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.
OK this isn't a good idea to solve the multi-web-app container situation -
but we can use one of the big 3 for this. I was really talking about
application
developers wishing to introduce funky dual hierarchies that was all.
The commons-logging is an API for component developers to include logging in
their components - the door is open to deploy with any implemention
whatsoever.
Costin do you think there's something missing from the API itself or is it
implementation stuff in a web container that you're considering? Do you
think we maybe need a derived SimpleLog - SimpleWebLog that handles the
multi-web-app situation?
James
>
>
> 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" <st...@netfolio.com>
> > To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
> > 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:paulo.gaspar@krankikom.de]
> > > > 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: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/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: 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"
> > > > <jo...@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:
> > > > > > > > <ma...@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > > > > <ma...@jakarta.apache.org>
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > > > > For
> > > > > > additional commands,
> > > > > > e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > > > For
> > > > > > additional commands,
> > > > > > e-mail: <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:jakarta-commons/logging/src/java/org/apache/commons/logging/implLogFactoryImpl.java
Posted by co...@covalent.net.
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" <st...@netfolio.com>
> To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
> 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:paulo.gaspar@krankikom.de]
> > > 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: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/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: 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"
> > > <jo...@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:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > > > For
> > > > > additional commands,
> > > > > e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > > For
> > > > > additional commands,
> > > > > e-mail: <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:jakarta-commons/logging/src/java/org/apache/commons/logging/implLogFactoryImpl.java
Posted by James Strachan <ja...@yahoo.co.uk>.
How about we do the following
* each component by default initializes itself from the default hierarchy
(as we're all doing now anyways).
* 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.
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" <st...@netfolio.com>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
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:paulo.gaspar@krankikom.de]
> > 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: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/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: 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"
> > <jo...@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:
> > > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > > For
> > > > additional commands,
> > > > e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > For
> > > > additional commands,
> > > > e-mail: <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common
s/logging/implLogFactoryImpl.java
Posted by co...@covalent.net.
On Wed, 13 Feb 2002, Steve Downey wrote:
> 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?
Nothing, most of the times. Each application can have it's own favorite
logger ( in lib ), and it'll be automatically picked up and used.
However in some cases the container may want to provide a 'default'
logger - maybe you are in a sandbox and the webapp is not allowed
to create files or initiate net connections, while the logger
provided by container has the permissions ( and uses 'doPriviledged').
In this case the app has no rights and any attempt to configure a logger
will probably fail.
A third case is when you have a set of webapps and you want to share the
same logger. The default should definitely be 'don't allow application
1 to get the same logger as application 2, even if they use the same
name', so loggers must be qualified by a domain. If you want to use
a common logger, you'll need API support.
> 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.
Not if you want the components to be useable in a secure ( sandboxed )
environment.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>