Static anything and everything should be avoided as a general practice. The danger of statics have been documented for decades and, unfortunately, the industry at large still doesn't get it. As for OSGi, it gets even worse because each bundle gets it's own class loader (hence, static is only static within the class loader).
Class.forName() is static. Log4J and other things use this and are very problematic. Trying to get cots into OSGi is problematic. Try using xml beams from OSGi. You'll eventually realize statics are very bad. The best thing for any client code is to simply use the LogService API and then provide an implementation for that API. I ripped the LogService API into it's own bundle and I provide a "service" (reference Declarative Services) implementation. We do this for everything and it has been "set it and forget it"; On the other end of the service, you log events can be formatted and dealt with as you see fit. If you're streaming, you can throw analytics on the lot stream. If you're sending log events to cloud/Hbase table, you can sift through them. I created a swing gui that does the equivalent of a "tail -f | grep" on an hbase table and we can monitor our "system" at a glance - one pane for log events and one pane for metrics. I could have also done the same with a log stream flowing a la ActiveMQ or equiv. Log4J is problematic. SLF4J was an attempt to deal with log4j's issues. LogService is better - we even run OSGi code inside of map-reduce (of course, we have to do declarative service type stuff overtly, but we reuse our bundle code). Cheers, regards ________________________________________ From: osgi-dev-boun...@mail.osgi.org [osgi-dev-boun...@mail.osgi.org] on behalf of Lindsay Smith [lin...@coretech.co.nz] Sent: Thursday, October 06, 2011 4:27 PM To: osgi-dev@mail.osgi.org Subject: [osgi-dev] RE: osgi-dev Digest, Vol 60, Issue 4 Thanks for your reply, some questions I have: > First of all, the word "static" is and should be dead. Can you elaborate on what you mean here? Are you saying that static methods shouldn't be called in hygienic OSGi code? Or just that the word is no good? Can somebody please provide the technicalities of static methods within OSGi - in particular I'd like to know how the lifecycle of classes corresponds to the bundle lifecycle? > 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). So you're calling the log4j static methods then I assume? The thing about using log4j and similar libraries is that you lose any control over logging at the bundle level - you have to configure it using class names. If I want to, say, turn on debug logging for some bundle, I should be able to set that at the bundle level - I shouldn't have to know anything about the names of the classes in the bundle to do that. All these log4j or commons logging bridges lose that fidelity from the logging config. Does anyone else have patterns for organizing and configuring logging in an OSGi system? Lindsay > -----Original Message----- > From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev- > boun...@mail.osgi.org] On Behalf Of osgi-dev-requ...@mail.osgi.org > Sent: Friday, 7 October 2011 5:00 a.m. > To: osgi-dev@mail.osgi.org > Subject: osgi-dev Digest, Vol 60, Issue 4 > > Send osgi-dev mailing list submissions to > osgi-dev@mail.osgi.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.osgi.org/mailman/listinfo/osgi-dev > or, via email, send a message with subject or body 'help' to > osgi-dev-requ...@mail.osgi.org > > You can reach the person managing the list at > osgi-dev-ow...@mail.osgi.org > > When replying, please edit your Subject line so it is more specific than "Re: > Contents of osgi-dev digest..." > > > Today's Topics: > > 1. RE: Logging Patterns (Craig Phillips) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 5 Oct 2011 20:19:53 +0000 > From: Craig Phillips <lcphill...@praxiseng.com> > Subject: [osgi-dev] RE: Logging Patterns > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Message-ID: <331C3DF5BBF5B34B95144FAA5EAAF3FF67D5E8@exch02> > Content-Type: text/plain; charset="windows-1252" > > > 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 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://mail.osgi.org/pipermail/osgi- > dev/attachments/20111005/74adec62/attachment-0001.html > > ------------------------------ > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > End of osgi-dev Digest, Vol 60, Issue 4 > *************************************** _______________________________________________ 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
