I am still +1 on adding the interface. Scott
> -----Original Message----- > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 04, 2002 3:26 PM > To: Jakarta Commons Developers List > Subject: RE: [logging] Need interface... VOTE > > > -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:[EMAIL PROTECTED]] > > 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 [EMAIL PROTECTED] > > CORBA Interoperability & WebServices > > IBM WebSphere Development > > > > > > > > > > "Geir Magnusson > > > > Jr." To: Jakarta > > Commons Developers List <[EMAIL PROTECTED]> > > <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" <[EMAIL PROTECTED]> 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. > [EMAIL PROTECTED] > > System and Software Consulting > > Be a giant. Take giant steps. Do giant things... > > > > > > -- > > 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: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]>