commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: [logging] Need interface... VOTE
Date Fri, 05 Apr 2002 15:54:19 GMT
On 4/5/02 10:17 AM, "costinm@covalent.net" <costinm@covalent.net> wrote:

> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> 
>>>>   o.a.c.genericlog.Log
>>>>   o.a.c.genericlog.LogUser
>>>>   o.a.c.genericlog.LogFactory
>>> 
>>> You already have 2 of them ( Log and LogFactory).
>> 
>> In o.a.c.l with some implicit assumptions (which I am trying to dodge...)
> 
> It's quite explicit, and your proposal seem to hava a LogFactory too.

The assumptions are *not* explicit - the assumption I am talking about is
that you must get the log via a pull from a singleton in o.a.c.l.  Again,
nothing wrong with that, but wanted to be clear.

Yes, I have a LogFactory as well - same interface as o.a.c.l -
implementation free - the o.a.c.gl package contains no impl of anything so
you can have the gl.jar in your classpath and all is well if you do your own
impl...

> 
> BTW, are you going to also propose a o.a.c.genericxmlparser,
> o.a.c.genericjdbc, etc ? After all, there are few dozen APIs using the
> same pattern with common-logging, do you feel confused when using them
> too ? 

Nope.  JDBC doesn't come with an impl, does it?  Don't I go and use the
mm.sql MySQL driver package throuh which getConnection() will return an
object that implements Connection?  That's what I am trying to get to here -
an implementation free interface spec.

Then the basic implementation is commons-logging for the pull crowd, (and
maybe push) and anyone who has another idea can do what they want.
 
You guys say you don't want this interface in the Logging package, and then
make fun of me when I propose a generic interface package that fully
supports the existing and includes it?

> 
>>> What about 
>>> o.a.c.logmanager.LogUser - define the interface to be implemented by
>>> components who want to support setLog()
>>> o.a.c.logmanager.LogManager - define interface for setting the
>>> properties if a Log, like level, appenders - the minimal stuff that is
>>> common to all loggers.
>>> (maybe few others ).
>> 
>> That would be cool - but setLog() sets the factory, so you can recover the
>> pull model as well w/o giving anything up.
> 
> Fine with me.
> 
> BTW, since static LogFactory.getFactory() uses per ClassLoader data ( so
> each application can use a different factory ), we should also add a
> static setFactory() method in LogFactory itself. This way you can change
> explicitely the default factory for the whole application with a single
> call ( instead of calling each compoent's setLog()).

I agree with the principle - you just modify your logFactory rather than
have to call anything on the components...

However, I would think you would want to separate the interfaces, to prevent
a *component* from calling setFactory()

> 
> Again, I'm perfectly fine and +1 if you want to set the factory on each
> component, maybe you want to use multiple loggers in your app.

Right.

What I am thinking about here is that you could write a component that does
both the static factory pull (catching any exceptions) well as support
container push at the same time.  Maybe I'm wrong...

> 
> 
>>> I would be +0 on this ( I think the push and management APIs should be
>>> part of c-l itself, not a separate package ).
>> 
>> 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

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
The obvious solutions are challenging


--
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