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 15:08:33 GMT

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

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.

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

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)

Just some thoughts ....

-- Rob

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