Hi, I've also been over this. I like the idea of OSGi logging as a DS service because it nicely decouples and partitions the responsibilities of the log emitter, receiver and consumer; however the boilerplate required to track the service was a bit muh for me. For our production code, we actually inject a custom logger into the bundle using a whiteboard pattern, because we need the logging to interface with legacy code (our production system uses OSGi as a hosted felix framework).
For my own little test project (things we do for fun of an evening eh?) I've gone the ops4j pax logging way, which enables me to use the standard log4j static pattern, and have pax handle the backend 'correctly'. Like Craig, I also don't want to spend much time on the finer points of logging. I can't speak to memory leaks in pax - this strikes me as a serious issue, perhaps it's more bloat than actually leaking? My test project is really just a place for me to try out things (currently bundled Vaadin, JPA/Gemini etc. It's not production grade, so it hasn't been load tested for leaks etc. One thing I might add is that if I was developing open-source bundles, I would restrict myself to OSGi logging to avoid imposing a constraint on the clients of the bundle. HtH (though I guess not :) -John -- John Hawksley john.hawks...@gmail.com On Mon, Oct 10, 2011 at 14:41, Peter Kriens <peter.kri...@aqute.biz> wrote: > I always use the Log Service as it is instance based and highly flexible. > Yes, statics and class names might be more convenient but I rarely find it > cumbersome when working with µServices and DS. But I also think logging is > highly overrated in many cases. > > Kind regards, > > Peter Kriens > > > On 5 okt. 2011, at 02:22, Lindsay Smith wrote: > > > Hi all, > > > > I'm interested to hear opinions on logging patterns within bundles. > > > > The prevailing pattern in vanilla Java code is to use static class > methods to allow logging from anywhere in your code. The logging dispatcher > then allows control over logging output depending on the classname of the > logger. There's a few alarm bells in that description for the OSGi > situation - accessing static classes, and using class names. > > > > OSGi has a logging service, which nicely decouples the emission of > logging messages with their recording or output. However to use it, you > obviously need to have a reference to the logging service. While this is > straightforward to do, having to have a reference to the logging service > everywhere that you need to log is cumbersome. Using static class methods > is far preferable in terms of code cleanliness. > > > > So is there a middle ground? Could a bundle-private class retrieve a > reference to the logging service, then provide static loggin methods to all > classes within that bundle? This way you get to use the logging service, and > still make static method calls from your code for logging. Does anyone have > an example of doing this? I suspect managing the bundle lifecycle may need > some care. > > > > Pax-logging is one approach for bridging the two approaches, which works > very well when you have existing code you need to port to OSGI. However > their approach I think does not allow any control of logging output > per-bundle, as it still uses the underlying classname based mechanism of the > logging providers it supports. > > > > What patterns are people using for this? Thoughts appreciated... > > > > Lindsay > > > > > > > > > > > > Lindsay Smith > > Lead Aviarc Architect > > lind...@coretech.co.nz<mailto:lind...@coretech.co.nz> > > +64 4 801 2250 > > +64 21 025 14411 > > > > _______________________________________________ > > OSGi Developer Mail List > > osgi-dev@mail.osgi.org > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
