Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should we keep ?

[Niklas Gustavsson <ni...@protocol7.com>]

On Sun, Jan 10, 2010 at 5:26 PM, Emmanuel LŽcharny <el...@gmail.com> wrote:
> At this point, regardless we need it or not, we should try to think about
> what we want to do when logging :
> - first, probably log only one single session, or at least a selected number
> of session versus blindly log every sessions
> - we would also like to be able to log at some specific point in the chain,
> or even better at different points in the chain
> - we may want to log only some specific events (Read, Session created, ...)
> - we may also like to define a log level for each of those  logs

All these sound reasonable?

> - we would probably prefer to be able to activate those logs dynamicaly

I presume you mean in runtime (using JMX or whatever)? If so, then
this sounds like something that should be delegated to the logging
framework the user chooses the use (log4j, logback, OSGi logging and
so on).

/niklas

Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should we keep ?

[Niklas Gustavsson <ni...@protocol7.com>]

On Sun, Jan 10, 2010 at 7:52 PM, Emmanuel LŽcharny <el...@gmail.com> wrote:
>> Yes, I agree that it is unfortunate that slf4j do not provide a
>> generic log(Level, String) method in the same way as log4j. Given
>> Ceki's great knowledge in this area, I presume it's for good reasons.
>> However, another solution would be to allow the user to inject his own
>> logger into the logging filter.
>>
>
> I think that CLog does not support level setting, it's probably why SLF4J
> does not allow such an operation.

slf4j could have done a switch statement to handle that. I suspect the
reason being Ceki's bad experience (as far as I understand) with
people expectations on making up their own custom levels in log4j.

> We can also provide a Log4jLoggingFilter and a LogBackLogging Filter too...

I think giving power users to option to inject a slf4j logger is the
best solution to the problem anyways.

/niklas

Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should we keep ?

[Emmanuel LŽcharny <el...@gmail.com>]

Niklas Gustavsson a écrit :
> On Sun, Jan 10, 2010 at 6:42 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>   
>> That raise a slight issue here : with slf4j, we have no way to tell the
>> underlying framework that it should switch to some specific level, for
>> instance. Quite a dead end, so far :/
>>     
>
> As mentioned, I don't think this is in scope for MINA. If the user,
> for example has chosen to use log4j, he would do this using the log4j
> API (in which slf4j will create a logger). We do not need to care.
>   
right.
>   
>> The way it was done in MINA was awfull : the log level ws always set to
>> debug, and we overriden this level with our own level :
>>
>> if ( requestedLevel == DEBUG ) {
>>  Log.debug( blah );
>> }
>>     
>
> Yes, I agree that it is unfortunate that slf4j do not provide a
> generic log(Level, String) method in the same way as log4j. Given
> Ceki's great knowledge in this area, I presume it's for good reasons.
> However, another solution would be to allow the user to inject his own
> logger into the logging filter.
>   
I think that CLog does not support level setting, it's probably why 
SLF4J does not allow such an operation.

We can also provide a Log4jLoggingFilter and a LogBackLogging Filter too...
> /niklas
>
>   

Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should we keep ?

[Niklas Gustavsson <ni...@protocol7.com>]

On Sun, Jan 10, 2010 at 6:42 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> That raise a slight issue here : with slf4j, we have no way to tell the
> underlying framework that it should switch to some specific level, for
> instance. Quite a dead end, so far :/

As mentioned, I don't think this is in scope for MINA. If the user,
for example has chosen to use log4j, he would do this using the log4j
API (in which slf4j will create a logger). We do not need to care.

> The way it was done in MINA was awfull : the log level ws always set to
> debug, and we overriden this level with our own level :
>
> if ( requestedLevel == DEBUG ) {
>  Log.debug( blah );
> }

Yes, I agree that it is unfortunate that slf4j do not provide a
generic log(Level, String) method in the same way as log4j. Given
Ceki's great knowledge in this area, I presume it's for good reasons.
However, another solution would be to allow the user to inject his own
logger into the logging filter.

/niklas

Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should we keep ?

[Emmanuel Lecharny <el...@gmail.com>]

Niklas Gustavsson a écrit :
>> - we would probably prefer to be able to activate those logs dynamicaly
>>     
>
> I presume you mean in runtime (using JMX or whatever)? 
yep.
> If so, then
> this sounds like something that should be delegated to the logging
> framework the user chooses the use (log4j, logback, OSGi logging and
> so on).
>   
That raise a slight issue here : with slf4j, we have no way to tell the 
underlying framework that it should switch to some specific level, for 
instance. Quite a dead end, so far :/

The way it was done in MINA was awfull : the log level ws always set to 
debug, and we overriden this level with our own level :

if ( requestedLevel == DEBUG ) {
  Log.debug( blah );
}

This make it very difficult to provide a LoggingFilter covering all the 
previous features, specifically the last two points (defining a log 
level for each event) (dynamically active logs).



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: [MINA 3.0] Logging filter was Re: [MINA 3.0] Which filters should we keep ?

[Niklas Gustavsson <ni...@protocol7.com>]

On Sun, Jan 10, 2010 at 6:17 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Sun, Jan 10, 2010 at 5:26 PM, Emmanuel LŽcharny <el...@gmail.com> wrote:
>> At this point, regardless we need it or not, we should try to think about
>> what we want to do when logging :
>> - first, probably log only one single session, or at least a selected number
>> of session versus blindly log every sessions
>> - we would also like to be able to log at some specific point in the chain,
>> or even better at different points in the chain
>> - we may want to log only some specific events (Read, Session created, ...)
>> - we may also like to define a log level for each of those  logs
>
> All these sound reasonable?

Should have been without the question mark :-)

/niklas