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: [logging] Need interface... VOTE
Date Thu, 04 Apr 2002 23:25:53 GMT
-1

I see too much confusion for any voting.
What about letting the dust settle just a bit more?


Have fun,
Paulo

> -----Original Message-----
> From: Richard Sitze [mailto:rsitze@us.ibm.com]
> Sent: Friday, April 05, 2002 12:15 AM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] Need interface... VOTE
> Importance: High
>
>
> OK then, let's see what happens:
>
> I PROPOSE that the classes in commons logging be rearranged as follows:
>
> no change:
>    org.apache.commons.logging.Log
>    org.apache.commons.logging.impl.Jdk14Loger.java
>    org.apache.commons.logging.impl.Log4JCategoryLog.java
>    org.apache.commons.logging.impl.LogKitLogger.java
>    org.apache.commons.logging.impl.NoOpLog.java
>    org.apache.commons.logging.impl.SimpleLog.java
>
> rename package, and add JavaDoc to explain or confuse as appropriate:
>    org.apache.commons.logging.factory.LogFactory
>    org.apache.commons.logging.factory.LogSource  (deprecate?)
>    org.apache.commons.logging.factory.impl.LogFactoryImpl
>    org.apache.commons.logging.factory.impl.LogConfigurationException
>    org.apache.commons.logging.factory.impl.Log4jFactoryImpl
>
>
> Justification:
>
> 1. Provide a logging interface independent of (or
>    at least disassociated from) factory or other framework.
>
> 2. Make changes NOW before someone else invents yet another logging
>    interface to accomplish this "goal".
>
>
> Cons:
>
> 1.  Requires changes to user's code (minimal?).
>
>
>
> Alternatives:
>
> 1. Leave as-is
> 2. use o.a.c.logFactory.* instead of o.a.c.l.factory, to further
>    distinguish/confuse.
>
>
> <ras>
> [Dang, where IS that ring when you need it!?!?!]
>
> <ps>
> If this exchange were by paper-mail, I'd be investing in more than one
> logging enterprise...
> </ps>
>
>
> *******************************************
> Richard A. Sitze            rsitze@us.ibm.com
> CORBA Interoperability & WebServices
> IBM WebSphere Development
>
>
>
>
>                       "Geir Magnusson
>
>                       Jr."                     To:      Jakarta
> Commons Developers List <commons-dev@jakarta.apache.org>
>                       <geirm@optonline         cc:
>
>                       .net>                    Subject: Re:
> [logging]  Need interface...
>
>
>
>                       04/04/2002 03:09
>
>                       PM
>
>                       Please respond
>
>                       to "Jakarta
>
>                       Commons
>
>                       Developers List"
>
>
>
>
>
>
>
>
>
> On 4/4/02 11:30 AM, "Richard Sitze" <rsitze@us.ibm.com> wrote:
>
> > I think we are circling around the same point.
>
> Maybe.
>
> >
> > I don't see the value of the interface w/o framework as-per
> your comments
> > below.  You CANNOT use the interface for "totally generic code" without
> > forcing a framework into the code also... SOMETHING has to attach an
> > implementation to the logger, via pull (factory) or push (external
> > dependencies) model.  So, you are going to be subscribing to one or the
> > other.
>
> And SOMETHING has to be there anyway to use the
> component/class/package/module that uses o.a.c.l, right?  I just
> don't want
> to be told exactly what has to be there...
>
> >
> > On the other hand, we could do a bit of disassociation here:  move the
> > factory and other elements of the "framework" into a separate package,
> and
> > introduce a new package for the push model:
> >
> >     org.apache.commons.logging.pull
> >     org.apache.commons.logging.push
> >
> > (and no, I wouldn't vote for these for final names :-)
>
> Nor would I.
>
> I would hope though that in o.a.c.l lives the basic interfaces...
>
> --
> Geir Magnusson Jr.                                     geirm@optonline.net
> System and Software Consulting
> Be a giant.  Take giant steps.  Do giant things...
>
>
> --
> 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