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
