Adding OSGi support is on my todo list. However, my current knowledge
of OSGi is only theoretical, so I'd need to experiment with an OSGi
container to test any logging service implementation SLF4J might offer.
I know that is quite non-committal, but does it sound acceptable to
you? How urgent/important is OSGi logging service to you?
A long time back we did a quick and dirty LogService impl which I think
is probably still in OBR.
The problem we had here was that the OSGi service is so minimal as to be
almost useless in a real application context - except perhaps just as a
bootstrapping layer for really basic startup/framework related logging.
Haven't looked at SLF4J - we're still just a basic LOG4J user on what is
probably quite an old version by now. Even with very very basic wiring,
that turned out way better than the standard LogService though - all we
really created was create:
- a way for bundles to register their own log hierarchies, which they
could even then configure or have a default set of application-wide
config settings applied
- provide a Listener registration approach to allow local bundles to
register to receive LOG4J events (using pretty standard approach as I
recall, although it's a long time ago)
- provide an XMLRPC method for clients to register and pull back
"categories" of message they are interested in (categories being used in
the standard LOG4J sense)
The point I'm sort of driving to here is that without some extra
thougt/plumbing - I don't think you can really build a real app's loging
on top of just the OSGi standard service alone. It doesn't offer enough
features like config granularity of what gets logged, partitioning of
bundles to either use common or separated logging configs/hierarchies,
facilties for local and remote logging clients to pull log events (or
have them pushed)
-- Rob
