-1. The registration/discovery mechansims are essential for Logging functionality.
Not to mention backward compatibility. Costin On Thu, 4 Apr 2002, Richard Sitze wrote: > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
