commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <mdela...@yahoo.com>
Subject Re: [logging] Need interface... VOTE
Date Fri, 05 Apr 2002 18:18:31 GMT

----- Original Message -----
From: "Geir Magnusson Jr." <geirm@optonline.net>
To: "Jakarta Commons Developers List" <commons-dev@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" <mdelagra@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.
>
> --
> Geir Magnusson Jr.                                     geirm@optonline.net

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


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message