Hi Lindsay, This is a good question, because as simple in-concept as logging is, somehow unwanted complexity can creep in if it's not well thought out. I think an important consideration is regarding the intended usage of the bundles that are being written. If on one hand the application code is, and is to be all controlled by you, the OSGi Log Service is just one of many possible approaches. If on the other hand downstream users and developers may be using your bundles along with other external bundles, using the OSGi Log Service API means the runtime context can have a cohesive logging view of the whole system. In this case IMHO the polite thing to do is use the OSGi log service API.
In my experience, I'm either writing a bundle that I want to be free of dependencies, or something at exists as part of a greater whole. In the former I typically import the Log API code (as opposed to a package dependency) and use a helper method to get an existing service existence or return a simple one that prints the log data to System.out. In the latter case I use the same helper method but explicitly import the Log API. Internally, Apache Felix uses an interesting hybrid of this in which via reflection the Log API is called, removing the requirement that the log service API be present at all. hth, ken On Wed, Oct 5, 2011 at 9:22 AM, Lindsay Smith <lin...@coretech.co.nz> 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**** > > +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 > -- thx ken
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
