commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sale, Doug" <ds...@us.britannica.com>
Subject RE: [logging] Need interface...
Date Thu, 04 Apr 2002 16:15:28 GMT


> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Thursday, April 04, 2002 5:14 AM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] Need interface...
> 
> 
> On 4/4/02 2:09 AM, "costinm@covalent.net" 
> <costinm@covalent.net> wrote:
> 
> > On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> > 
> >> Are you saying that any component/class/tool that 
> implements the generic
> >> commons logger Log interface is only usable in an 
> application environment
> >> where a special class with a static method getLogger() is 
> in the classpath?
> >> [Modulo the real name of the class and method... You get 
> what I mean, I
> >> hope...]
> > 
> > The same pattern that is used with JDBC, JNDI, JAXP and 
> about a dozen
> > other APIs. 
> > 
> > I'm not sure what do you mean by 'framework' in this 
> context - of course
> > every API and package has a set of contracts and APIs. You 
> want a database
> > connection - you call the DriverManager or look up in JNDI.
> 
> I don't think it's a fair comparison necessarily, although I 
> am having a
> tough time explaining why.
> 
> But you pointed out an interesting thing.  With a db connection, I can
> legitimately 'pull' it via DriverManager, specifying exactly 
> what I want in
> terms of configuration, or it can be preconfigured by 
> 'someone else' and (in
> a broad sense) pushed to me via JNDI - I can go get it if I 

the broadest ;)

both architectural approaches are valid (push/pull).  it seems to me that
the major *valid* hangup most folks are having w/your proposal is the effect
this might have on commons components.  one notable effect (desired, i
suppose) is that commons-logging clients could be configured at run-time.
perhaps if someone with a larger brain than i could focus on the pros and
cons of the proposed interface, instead of flaming the 'opposing'
architecture, this thread might be productive...

> want, ready to
> go.
> 
> In the case of commons, there seems to be an almost required 
> implementation.
> I think that's ok - it just needs to be stated (or y'all need 
> to tell me to
> go RTFM :)
> 
> 
> > There is a LogFactory class that will find you the Log 
> implementation,
> > and if a logger is to be useable with the commons-logging it must
> > implement the Log interface ( that's the big one ) and follow the
> > discovery rules if it wants to be found using the LogFactory.
> 
> Ok - cool.  I understand.  If that isn't documented, it should be.
> 
> My only problem is that there is a huge assumption about how to get
> LogFactory - unlike the db example, where I can use driver 
> manager *or* JNDI
> if I want to keep the knowledge outside of the app, I seem to 
> have to utter
> the right prayers and pull from some singleton.
> 
> I think there should be valid alternatives.
> 
> So there seems to be an opportunity for a generic logging interface in
> commons that has no implementation or lifecycle requirements, 
> because then I
> can do what I want to do in Velocity and elsewhere - offer a logging
> contract while leaving the push/pull & lifecycle issues in 
> the hands of the
> framework/app/container builder, where it belongs (IMO).
> 
> If I can find some time, I'll scratch something together - it will be
> trivially usable with the existing commons logging - it will 
> use the same
> interface Log in fact - so it won't be a competitor but rather augment
> o.a.c.l  I think a nice name is 'NaturalLog' (math joke...)
>  
> > 
> >> I hope the answer is 'no' also, because otherwise, you are defining
> >> framework-like requirements on any app using commons-logging-using
> >> components.
> > 
> > If a component wants to use commons-logging, it must obviously
> > call it's API in the way commons-logging is designed.
> 
> Of course.  Just like log4j or logkit.  In a sense then, 
> commons-logging is
> yet another logger that didn't bother to write the guts, but just used
> others.  Log4j or logkit could be the same thing.  For 
> example, if you had a
> logkit or jdk1.4 appender for log4j...  (I wonder how fast 
> I'd get run out
> of town if I submitted *that* patch :)
> 
> LOL
> 
> > 
> > It doesn't impose any other requirement on your component. I'm not
> > sure I understand what's your problem here.
> 
> I guess the mismatch is that I thought o.a.c.l was a 
> policy-free logger
> abstraction allowing components and apps to have a common 
> interface for
> logging w/o any implementation requirements, and that the project also
> offered impls for log4j, logkit and jdk1.4.   As is, its 
> clearly a good
> thing because people find it useful, but I think there are 
> other needs.
> 
> > 
> > If you need an aditional interface to allow a standard way for
> > components to get a different logger - I'm ok. With the
> > current model the underlying logger is in control over what
> > and how is logged - commons-logging is just a wrapper ( and
> > the associated discovery method ).
> 
> I guess its the dictation of the discovery method that I have 
> a problem
> with.  But it's fixable...
> 
> > 
> > It is curently assumed that each logger will have a name -
> > so it can be found by the component on one side, and configured
> > in the logger on the other side. In a JMX perspective, it
> > makes sense - all objects that are manageable need some name.
> 
> It makes sense indeed.  But I may not care always about 
> having my own named
> logger - as a component, I might just want to spooge out 
> debug info and
> think it nicer if it doesn't have to go to stdout.
> 
> > 
> > It is also a common pattern to separate between the actual
> > channel ( where the log output goes ) and the 'facade' that
> > is viewed by the component. And the pattern is to have
> > each component use a logger with a name based on it's class
> > ( with the classloader acting as namespace ).
> > 
> > How do you fit the setter in this and what do you actually
> > want - I don't know.
> 
> You can fit the setter in this - because with the factory alternative
> offered by Michael
> 
>   public interface LogUser
>   {
>     public void setLogFactory(LogFactory);
>   }
> 
>  you can retain the pull pattern.  But you get the benefit of 
> the marker.
> 
> This of course shouldn't be the *only* way -  because then you have to
> specifically manage any logging component, which is a royal 
> pain.  Being
> able to arbitrarily grab the logger out of thing air is 
> clearly useful....
> 
> To summarize : yes, there is clear value in the pull model - makes
> integration easy.  I think that a generalized interface contract w/o
> implementation requirements would be useful too.
> 
> 
> > 
> > My feeling is that an interface to allow some tunning of the
> > logging at runtime, in a logger-independent manner is extremenly
> > usefull. 
> 
> Does commons do that?  I didn't think so.
>  
> > I think some portable way to set the level on a logger would
> > be the most important. Since the logging is 2-layered it is possible
> > to change the channel without any action in the component, but
> > it is not possible to change the actual Log - do you think
> > this is that important ?
> 
> To be able to change the actual Log?  No - because the 
> container/app/etc
> implementing the Log interface can do that...  Right?
> 
> > 
> > 
> >> I am not trying to be combative - I just think that this 
> discussion showed
> >> me that the commons logger is not as general-purpose as I 
> thought it was -
> > 
> > Yes, it's not general-purpose. It's just an API to allow 
> your components
> > to log. Nothing else.
> 
> I think that is a little short of the description, because 
> log4j and logkit
> did that already.  I thought that being 'implementation 
> agnostic' was one of
> the goals, and it seem to be in one aspect - the Log 
> interface is used for
> any underlying impl (which is good).  But in another sense, 
> the pull pattern
> requirement (or 'pseudo requirement') seems to exhibit some 
> of the problems
> I thought o.a.c.l was trying to solve.
> 
> -- 
> Geir Magnusson Jr.                                     
> geirm@optonline.net
> System and Software Consulting
> The question is : What is a Mahnamahna?
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message