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...
Date Wed, 03 Apr 2002 18:44:01 GMT
On 4/3/02 12:56 PM, "Fernandez Martinez, Alejandro"
<a.fernandez.martinez@ibermatica.com> wrote:

> So, if I understand you right, you just want the interface;

Yes - and a note saying why it's there.  We can do something in
velocity-tools - declare that the interface LogWantsTool implies that the
toolbox hands the tool an interface to log through.

But we figured that others could use this - it's more general.

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

Well, I don't think it inverts control - it just leaves it out of the
picture.  Or there is an implied lifecycle -  basically the component saying
- "after instantiation, you can call setCommonsLog(logger) if you understand
what I mean and if you want to - if not, I'll deal"

geir

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

-- 
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
View raw message