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:16:57 GMT
In order to implement a LogUser interface and have a setLogger(Log) method
called, don't you need a full lifecycle for the components?

That is, to be sure setLogger(Log) will be called at a certain point in all
LogUsers, LogUsers must register somewhere. 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.

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

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