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
[EMAIL PROTECTED]
+44 (0)20 7488 3470
www.ascert.com
