atom feed53 messages in org.apache.commons.devRe: [logging] Need interface... VOTE
FromSent OnAttachments
Richard SitzeApr 4, 2002 2:15 pm 
cost...@covalent.netApr 4, 2002 2:26 pm 
Paulo GasparApr 4, 2002 3:25 pm 
Geir Magnusson Jr.Apr 5, 2002 2:45 am 
Richard SitzeApr 5, 2002 6:07 am 
Geir Magnusson Jr.Apr 5, 2002 6:16 am 
Nicola Ken BarozziApr 5, 2002 6:26 am 
Andrew C. OliverApr 5, 2002 6:38 am 
cost...@covalent.netApr 5, 2002 6:46 am 
Geir Magnusson Jr.Apr 5, 2002 7:03 am 
cost...@covalent.netApr 5, 2002 7:17 am 
Geir Magnusson Jr.Apr 5, 2002 7:53 am 
Christoph ReckApr 5, 2002 8:25 am 
Geir Magnusson Jr.Apr 5, 2002 8:37 am 
Craig R. McClanahanApr 5, 2002 8:57 am 
Geir Magnusson Jr.Apr 5, 2002 9:10 am 
Richard SitzeApr 5, 2002 9:18 am 
Morgan DelagrangeApr 5, 2002 9:24 am 
Geir Magnusson Jr.Apr 5, 2002 9:58 am 
Craig R. McClanahanApr 5, 2002 10:06 am 
Nicola Ken BarozziApr 5, 2002 10:09 am 
Michael A. SmithApr 5, 2002 10:14 am 
Morgan DelagrangeApr 5, 2002 10:18 am 
cost...@covalent.netApr 5, 2002 10:24 am 
Michael A. SmithApr 5, 2002 10:36 am 
Geir Magnusson Jr.Apr 5, 2002 10:44 am 
cost...@covalent.netApr 5, 2002 10:45 am 
Michael A. SmithApr 5, 2002 10:50 am 
Morgan DelagrangeApr 5, 2002 10:53 am 
Andrew C. OliverApr 5, 2002 10:56 am 
Richard SitzeApr 5, 2002 11:10 am 
Scott SandersApr 5, 2002 11:11 am 
Geir Magnusson Jr.Apr 5, 2002 11:33 am 
cost...@covalent.netApr 5, 2002 11:41 am 
cost...@covalent.netApr 5, 2002 12:27 pm 
Geir Magnusson Jr.Apr 5, 2002 1:03 pm 
Craig R. McClanahanApr 5, 2002 1:14 pm 
Geir Magnusson Jr.Apr 5, 2002 1:35 pm 
cost...@covalent.netApr 5, 2002 1:45 pm 
cost...@covalent.netApr 5, 2002 1:47 pm 
Geir Magnusson Jr.Apr 5, 2002 2:23 pm 
Geir Magnusson Jr.Apr 5, 2002 2:36 pm 
cost...@covalent.netApr 5, 2002 2:58 pm 
Craig R. McClanahanApr 5, 2002 3:08 pm 
Geir Magnusson Jr.Apr 5, 2002 3:37 pm 
Geir Magnusson Jr.Apr 5, 2002 3:45 pm 
Geir Magnusson Jr.Apr 5, 2002 3:50 pm 
Geir Magnusson Jr.Apr 5, 2002 3:51 pm 
Craig R. McClanahanApr 5, 2002 4:00 pm 
Geir Magnusson Jr.Apr 5, 2002 6:07 pm 
Craig R. McClanahanApr 5, 2002 7:30 pm 
Geir Magnusson Jr.Apr 6, 2002 4:11 am 
Craig R. McClanahanApr 6, 2002 9:14 am 
Subject:Re: [logging] Need interface... VOTE
From:Christoph Reck (Chri@dlr.de)
Date:Apr 5, 2002 8:25:03 am
List:org.apache.commons.dev

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 o.a.c.gl 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, "cost@covalent.net" <cost@covalent.net> wrote:

On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:

[snip]

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 o.a.c.gl 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 o.a.c.gl, o.a.c.gl could be used w/o knowing about o.a.c.l, and things that support o.a.c.gl 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 o.a.c.gl, 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 o.a.c.gl.LogUser, 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 o.a.c.gl

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 o.a.c.gl.Log. 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 o.a.c.gl