First of all, the word "static" is and should be dead. As for log4j, we did write an appender that will forward those events to the log service (at which point, in felix and more than likely equinox, you will be bombarded with framework events).
After that, it's a mere matter of implementing the log service however you please (streaming if your streaming, to a cloud/hbase table if you're throwing things that way, and so forth). I did rip the log service API to it's own API bundle - why it's "bundled", so to speak, elsewhere is beyond me. The pax logging never really panned out for me due to memory leaks. Why they buffer log events is beyond me - that's what metrics are for. Speaking of metrics, that should have been in the standard as well. I whipped up my own corollary metric service to the log service. I really don't bother wading in to sophisticated diatribes on logging and metrics - keep it simple. Regards ________________________________ From: osgi-dev-boun...@mail.osgi.org [osgi-dev-boun...@mail.osgi.org] on behalf of Lindsay Smith [lin...@coretech.co.nz] Sent: Tuesday, October 04, 2011 8:22 PM To: osgi-dev@mail.osgi.org Subject: [osgi-dev] Logging Patterns 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
