On Tue, Jan 11, 2011 at 12:28 PM, Marcel Offermans
<marcel.offermans at luminis.nl> wrote:
> On 10 Jan 2011, at 22:06 , Bram de Kruijff wrote:
>
>> working on the fabric I have some problems/concerns with regard to our
>> current convention of using the plain Felix OSGi spec LogService.
>>
>
> My first reaction is to address this question to OSGi to find out why they 
> did not include an "isLoggable" construct.

Define "address this question to OSGi" :) Look in the spec? Call
Peter? Start a thread over at Felix?

> My second reaction is that you seem to be using the LogService to trace and 
> debug your code, which is something that is definitely worth discussing. One 
> could argue that this is not what the LogService was meant for.

The spec says "A Log Service object can log any message, but it is
primarily intended for reporting events and error conditions" so I
quess that does not include trace or debug which can explain why they
did not an isLoggable optimizations. As a result we have a problem
domain AFAIK not coverred by OSGi spec which probably explains why
Equinox/PAX are comming up with custom solutions.

> Regarding named loggers and filtering. A log entry contains the bundle that 
> logged the message and (optionally) the service. Those can be used to filter 
> messages. That's what the LogListener is for.

But it is very limited /rudimentary still.

> I would be hesitant to just dismiss the current LogService and replace it 
> with a different one unless we can convince the OSGi alliance that this is a 
> good idea.

Did not mean to say the LogService service should be dismissed. It
should not for obvious reasons. Only suggesting we accompany /
decorate it with the optimization for massive debug/trace logging
allowing a developers to choose.

regards,
Bram

Reply via email to