commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernandez Martinez, Alejandro" <a.fernandez.marti...@ibermatica.com>
Subject RE: [logging] Need interface...
Date Wed, 03 Apr 2002 17:56:20 GMT
So, if I understand you right, you just want the interface; the use given to
it (i.e., the lifecycle) is left to you and your application? That makes
sense, even if it leaves inversion of control in your hands -- inversion of
inversion of control :)

Un saludo,

Alex.

> -----Mensaje original-----
> De: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Enviado el: miƩrcoles 3 de abril de 2002 19:21
> Para: Jakarta Commons Developers List
> Asunto: Re: [logging] Need interface...
> 
> 
> On 4/3/02 12:16 PM, "Fernandez Martinez, Alejandro"
> <a.fernandez.martinez@ibermatica.com> wrote:
> 
> > In order to implement a LogUser interface and have a 
> setLogger(Log) method
> > called, don't you need a full lifecycle for the components?
> 
> Not at all (well, maybe...).
> 
> The point of view here is that implementing LogUser means you want a
> configured log to use, and the lifecycle is up to the component and
> framework it works in...
> 
> > 
> > That is, to be sure setLogger(Log) will be called at a 
> certain point in all
> > LogUsers, LogUsers must register somewhere.
> 
> No - it's left up to the use - we just want a standard way of 
> doing it.
> 
> > Then, the logging package will
> > call setLogger(Log) for all components after it has read 
> the configuration.
> > That, in turn, means the components should tell the logging 
> package to
> > configure itself, or read the configuration from a given 
> location, or
> > whatever. This resembles even more a full-fledged 
> framework, and does not
> > seem proper for a simple logging package.
> 
> No - we are coming at it from the POV that we want to write 
> little tools
> that work with any app/framework/etc that knows about LogUser.  The
> component that implements the interface can make no demands - 
> it is just
> saying "I can log using Log, so give me one if you have it..."
> 
> 
> > 
> > Un saludo,
> > 
> > Alex.
> > 
> >> -----Mensaje original-----
> >> De: costinm@covalent.net [mailto:costinm@covalent.net]
> >> Enviado el: miƩrcoles 3 de abril de 2002 17:55
> >> Para: Jakarta Commons Developers List
> >> Asunto: Re: [logging] Need interface...
> >> 
> >> 
> >> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> >> 
> >>> What we need is a marker interface that indicates a tool
> >> wants a logger, and
> >>> of course a method to give it the logger...  I did a quick
> >> scan of the
> >>> public API, and there doesn't seem to be one.
> >>> 
> >>> So what I propose is to add an interface 'LogUser' or
> >> something like it (we
> >>> can quibble about the name...)
> >>> 
> >>>  public interface LogUser
> >>>  {
> >>>     public void setCommonsLogger(Log log)
> >>>  }
> >> 
> >> In other words, you also want a 'push' model for the logger.
> >> Curently each 
> >> component is supposed to 'pull' the logger.
> >> 
> >> Well, I can't say no. I prefer the current Log.getLog() 
> pattern, but
> >> the whole point of commons is to be open and accept multiple points
> >> of view, instead of forcing everyone to use a 'right' thing.
> >> 
> >> +1 on the idea - but maybe we can discuss a bit the 
> details. LogUser
> >> and setCommonLogger sounds a bit weird, and I'm not sure I
> >> understand who
> >> will call the method.
> >> 
> >> In JMX terms, you would have a method setLogger(
> >> o.a.commons.logger.Log )
> >> or setLoggerName( String ) and based on some config JMX 
> will set the
> >> logger. The Log???? interface will be extended by the component
> >> MBean interface ( if any ). Seems a valid use case, and a
> >> good idea to 
> >> 'standardise' the pattern used to set the logger in a component.
> >> 
> >> Maybe even a set logLevel() to tune the ammount of output the
> >> component 
> >> generates - i.e. a second filter pattern. I wouldn't say no,
> >> since the 
> >> pattern is in wide use in tomcat(3 at least, and other
> >> projects as well )
> >> and quite usefull.
> >> 
> >> 
> >>> As I personally believe that just being a commons committer
> >> doesn't give me
> >>> the 'spirit-of-the-law' right to commit to the logger, I'll
> >> ask for some
> >>> even vague hint of approval from the logger people before
> >> moving forward.
> >> 
> >> Good idea, given the amount of debate we had for each API change in
> >> commons-logger. I would do the same.
> >> 
> >> However feel free to commit anything in the impl :-).
> >> 
> >> Costin
> >> 
> >> 
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <mailto:commons-dev-help@jakarta.apache.org>
> >> 
> > 
> 
> -- 
> Geir Magnusson Jr.                                     
> geirm@optonline.net
> System and Software Consulting
> Be a giant.  Take giant steps.  Do giant things...
> 
> 
> --
> 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