Hi, >From the peanout gallery of an interested observer ....
On 16.02.2010 11:01, Guillaume Nodet wrote: > It seems we use different mechanism for logging in various parts. > Blueprint uses slf4j api, jmx-core uses a facade on the osgi logging > service (but which won't work if the logging service package isn't > available at all), jmx-blueprint-core uses System.out. > I'd like us to choose one way and stick with it. > > The slf4j api is a nice api to use, but it brings an additional > dependency. If the goal is really to reduce the amount of > dependencies, we can use either java.util.logging or a cleaner facade > on top of the osgi logging service (were we can actually not require > the logging pacakge). If we want to use a facade, i'd suggest moving > it into its own maven module and including it in various osgi bundles > (to keep standalone bundles). The size of this facade should be small > enough so that it does not really matter to duplicate it. I would suggest to go for SLF4J since it has a really nice API for lazy-formatting messages and is simple to implement. As for the OSGi LogService, I suggest to integrate this with the logging implementation used. Finally, I suggest to not reinvent the wheel but to draw on existing open-source (and ASL2 licensed) stuff, like Apache Felix log bundle, the Apache Sling log bundle (providing SLF4J API, a LogService implementation as well as support for Log4J and Commons Logging API) or the OPS4J logging bundle(s) (which provide a similar level of integration as provided by the Sling log bundle). Regards Felix
