commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Reck <>
Subject Re: [logging] Need interface... VOTE
Date Fri, 05 Apr 2002 16:25:25 GMT
Geir, could you agree in having the o.a.c.l build file pop out an
logifc.jar with what you want instead of creating another 
package with practically the same interfaces as in o.a.c.l ?

Just my 0.02c: If you look at the commons(-sandbox) its hard to
identify what you need - "you don't see the forest because of the
many trees".

"Geir Magnusson Jr." wrote:
> On 4/5/02 10:17 AM, "" <> wrote:
> > On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> >> I do to, but it seems to me that the underlying implementation assumptions
> >> of o.a.c.l are somewhat at odds with the notion of implementation-free
> >> generic interface...
> >
> > Can you give any arguments for that ( besides 'it seems' ) ?
> Because if I use o.a.c.l, it's assumed that there exists a singleton
> somewhere such that
>    LogFactory.getFactory()
> Will work.  That SEEMS like a huge assumption and requires an implementation
> to be part of o.a.c.l
> I want to just define the interfaces separately in that o.a.c.l
> builds upon with the current implementation strategy.  People could still
> use o.a.c.l as is w/o even knowing about, could be used
> w/o knowing about o.a.c.l, and things that support could also be
> used in a o.a.c.l environment, as the Logs and Factorys are compatible.
> (I believe the above - will need to try out with actual code... :)
> >
> > Is there anything in Log that is not implementation-free ? Is there any
> > requirement to use Log with a named-based pull system or force ?
> > ( or even to force it's use with LogFactory ).
> No - the problem as I see it, and I maybe hugely mistaken, is in the
> expectation - that if I am in an o.a.c.l environment, I can assume that I
> can do a pull to get the Log or factory.   This makes me worry that if I
> have a system that claims that logging is done via o.a.c.l, then I have to
> provide the ability to pull.
> With the idea of, there are no implementation expectations on the
> part of the component, or requirements placed on the containing environment.
> >
> > LogFactory is a helper for people who want a one-line init code
> > for logging. It does some magic to guess what logger is in the classpath,
> > and that's it. I wouldn't use anything more complex - if using
> > commons-logging requires implementing an interface or creating setters,
> > then I prefer to use println.
> >
> Like I have been trying to say - there are no implementation requirements on
> the part of the component.
> The component can *choose* to implement, or not.   Keeping
> it out of o.a.c.l means that the problem goes away for the o.a.c.l mavens.
> If you want to pull all the time, use o.a.c.l.  Don't even worry about
> If you want to pull in some other environment, you can do that, as it is
> assumed that the component and environment have an agreed-upon scheme, and
> that the thing the component logs to looks like  I know you
> can do this now in o.a.c.l, but there is this trend for o.a.c.l components
> to *expect* the LogFactory pull model, as the impl is in the o.a.c.l jar.
> If you have some other implementation idea or lifecycle, use

:) Christoph Reck

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message