felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Walker <r...@ascert.com>
Subject Re: Resource Bundles and logs
Date Tue, 06 Jun 2006 17:40:39 GMT
I have to say - logging to most people is probably the dullest subject 
they can imagine - but it's also the best (and worst) part of a lot of 
frameworks I've worked with.

So for me, it's actually right up there with some of the most important 
components you can build - ok, so if that makes me dull, I'll take it ;)

I'm really looking forward to seeing how we can take these ideas forward 
into something really solid

Great input John, thanks

-- Rob

John E. Conlon wrote:
> On Tue, 2006-06-06 at 16:08 +0100, Rob Walker wrote:
>   
>>> So, until then there is no way to "hide" these errors. Perhaps there 
>>> is another approach too. One thing that we could do (in addition to 
>>> eventually using the log service) is to have a property that allows us 
>>> to disable diagnostic messages...otherwise, I don't know.
>>>       
>> In our app. this was our reasoning behind basing our logging on LOG4J - 
>> so we had very flexible "soft switches" to control and configured what 
>> got logged at runtime. I haven't looked at SLF4J yet - but I think it 
>> extends this concept further with a generic 'commons' style API that can 
>> also sit on top of other logging frameworks.
>>     
> Yes it's API is very nice and it sits on several logging stacks now. 
> http://www.slf4j.org/
>
>   
>> We did a not very good "hack" to enable us to wire LOG4J in as an Osgi 
>> service - so I can't really recommend the actual approach we took for 
>> general usage - but the outcome has been pretty good, and it's given us 
>> a degree of flexibility around the level of diagnostic and application 
>> message noise which gets logged.
>>     
>
> Like Rob, did a simple bundlizing of an existing logging framework, but
> one based on SLF4J. (Enrique has also done a similar logging bundle in
> ApacheDS.) I included the adapter that maps the apache commons logging
> to SLF4J. To this like Rob,  added an OSGi logging service (adapted to
> SLF4J). As mentioned SLF4J sits on top of a underlying logging stack,
> for this bundle used the NLOG4J native SLF4J logging stack which is
> configured similarly to log4j. One neat OSGi feature that was added was
> a simple activator that reread the configuration file on startup, thus
> allowing a rereading the config without shutting down the framework. 
>  
> OSGi, Apache-Commons, SLF4J logging and log4j configuration.
>   
>> In my mind, the model I envisaged that could be workable was:
>>
>>     * a "logger" bundle that whilst supporting the standard OSGi
>>       LogService API for the very basic case, also offered a fairly rich
>>       LOG4J (maybe SLF4J now) set of API functionality
>>     
>
> Just bundlizing the SLF4J jars would get us along way to having what we
> need. Then we could pick and choose what we need the OSGi way. The only
> other thing that I think would be helpful is to add a SLF4J to OSGi Log
> Reader service.
>
> Looking forward to the opening of a Felix commons area for consolidating
> these different implementations.
>
>   
>> Needless to say, time prevented me from creating this generalised "split 
>> brain" logging module, but I think it's feasible and has merit.
>>
>> And of course beyond this, there then opens up the possibility of remote 
>> log message or / logging access through things like JMX or simpler APIs  
>> (ours is actually a very simple XMLRPC based one that let's us pull back 
>> captured log messages for viewing on a client)
>>     
> If we use the SLF4J/log4j think we can plug into all the fine remote
> work that has already been done with log4j, JMS, Chainsaw, etc.
>
> cheers,
> John
>
>   

-- 


Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com


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