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:Morgan Delagrange (mdel@yahoo.com)
Date:Apr 5, 2002 10:18:09 am
List:org.apache.commons.dev

----- Original Message ----- From: "Geir Magnusson Jr." <gei@optonline.net> To: "Jakarta Commons Developers List" <comm@jakarta.apache.org> Sent: Friday, April 05, 2002 11:58 AM Subject: Re: [logging] Need interface... VOTE

On 4/5/02 12:24 PM, "Morgan Delagrange" <mdel@yahoo.com> wrote:

Now, if we can't meet somewhere in o.a.c.l, I am happy to do an interface package o.a.c.gl, which I hope wouldn't be -1'd when proposed to commons proper because of the existance of o.a.c.l...

geir

I'm -0 on a backwards-compatible change that does not affect performance.

That's fair. Not sure why '-', but ok.

I am -1 on integrating this with existing commons components because of the performance impact of non-static Log objects in the classes.

At no time have I suggested that any component, existing or in the future, be required to change.

Great!

It wouldn't make any sense unless you wanted that component to have the option of getting a log pushed to it. (And you can do both if you want...)

And what's the performance impact of implementing an interface?

The problem is that you can't just implement the interface. You would also have to remove any static references to the Log object.

For example, this class

public class Foo {

private static Log log = LogFactory.getLog(Foo.class);

}

becomes:

public class Foo implements SetsLog {

// Logs now have to be assignable per instance, no longer static // need a reasonable default too private Log log = LogFactory.getLog(Foo.class);

public void SetLog(Log log) { this.log = log; }

}

This is particularly important since we are already guaranteed a level of indirection. Also I'm decidedly -1 on changes to existing components that do not provide backward-compatible default Log objects.

Again, I have never, ever suggested changing any existing components. At worst, o.a.c.l interfaces would implement o.a.c.gl interfaces,

Which I would -1.

but the change there would be one import statement and the addition of 'implements XXX' - no other changes as the interfaces are identical,

And the method that implements that interface, and you would have to make all the Logs instance variables if they were static variables.

and again, only in the o.a.c.l package. Components wouldn't care - they would go on happily using o.a.c.l as they do now...

That's a real kicker for me wrt. integration in other Commons components. You would have to instantiate a default Log for each instance of a class, and then if you utilize that interface you would instantiate _another_ Log.

Why? Remember :

there are no requirements to use the marker interface

That's quite a bit of potential overhead. The proposed interface might work acceptably in an environment that does not require default Log implementations.

Repeat :

For users of o.a.c.l, *nothing* changes.

I assumed that this interface would make it possible to set Log objects on a per-instance basis. Would the setter method be called once on a particular instance, which would assign to a static variable? That doesn't make sense to me. It seems like a prerequisite of implementing that interface would be to change all Log objects to instance variables.

- Morgan