For what it's worth, my feeling is that you shouldn't re-invent the wheel when there appears to be a good solution maintained by those whose primary objective is logging. Not to mention, the thought of switching to logback over time is very intriguing.
+1 for replacing the single bundle with SLF4J (non-binding) -- mike moulton | meltmedia [email protected] w | 602.648.6810 c | 602.432.2568 @mmoulton On Jan 10, 2011, at 3:08 PM, Felix Meschberger wrote: > Hi all, > > Over the last few week I have been thinking about our logging bundle and > what we do and include. > > Basically, the logging bundle is/does... > > - Implements OSGi LogService on top of SLF4J > - Implements SLF4J > - Provides Configuration Admin driven configuration > - Exports SLF4J API > - Exports Commons Logging API > - Exports Log4J API > - Exports OSGi LogService API > > Now, many of these things can be ripped apart into separate bundles. > Actually the SLF4J project libraries SLF4J API, Log4J-over-SLF4J, and > Commons-Logging-over-SLF4J already come as bundles. > > Likewise we could separate the implementation of the OSGi LogService > over SLF4J into its own small bundle. > > Finally remains the actual SLF4J implementation: This can be its own > bundle again (SLF4J API actually imports the SLF4J impl package) and > provide the well-known and beloved Configuration Admin support while > internally (over time) change the implementation to, say, logback for > even more logging options. > > The drawback is, that we are talking about 5 bundles instead of just a > single one. > > WDYT ? > > Regards > Felix > -- > [email protected] > +41 61 226 98 44 >
