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 13:55:42 GMT
Answer inline:

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Thursday, February 14, 2002 5:09 AM
>
> ...
>
> On Thu, 14 Feb 2002, Paulo Gaspar wrote:
>
> > ...
> >
> > 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 find it quite amusing to note that all three of the logging
> implementations we have defined wrappers for include *exactly* this
> technique.  That's what we call in the wrappers, so we're using them in
> exactly the same way an application would use them if programmed directly
> to these APIs.

And I am questioning if that is the best way.


> LogKit does have the notion of hierarchies, but the others don't.  Our
> wrapper uses the default hierarchy -- if you want to support different
> ones, you are now free to implement it in your own LogFactory.  It doesn't
> require any changes to the APIs, though.

And maybe that is enough.


> > I hope I will come back with something more constructive later but
> > my CPU is too busy right now.
> >
>
> Until someone comes up with patches instead of words :-), I'm going to
> consider this issue closed.

Until I have the time for patches I have to agree.
=:o/

>
> Craig


Have fun,
Paulo Gaspar


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