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
