On Fri, Oct 14, 2011 at 18:27, ceki <c...@qos.ch> wrote: > On 14/10/2011 5:48 PM, Guillaume Nodet wrote: > > Thank you for your quick response. > > > I do care a lot about logback being configure with properties to be able >> to leverage ConfigAdmin. It should be *the* way to configure things in >> OSGi. That way, you can distribute the configuration remotely or store >> it in a DB or in any other mean without having to rewrite all the >> bundles to leverage that. That's the benefit of using a standard service. >> > > How does any of the above change for properties format. For log4j which > supports properties format, you still need to invoke PropertyConfigurator on > the properties (or some URL containing the properties). It would be no > different with logback, except that you would invoke a different > configurator.
Yeah, I agree. I just don't want to write that configurator. > > > You just said the configuration file needs to be xml or groovy, which is >> different from a properties file. For config admin, the input data >> needs to be a map of key/value pairs. I haven't said it was not >> possible with logback, just that it does not exist, and I don't have the >> time and will to start writing a new configuration mechanism for logback >> without having any real need to switch to it. >> > > But if you want to try that, it could be nice. Though I still haven't >> heard the reasons why you want logback instead of pax-logging. >> > > I am not a Karaf user, at least not yet. I am the founder of both log4j and > logback projects although I now work mostly on logback. I am just trying to > understand your use case for properties configuration. My apologies if the > use case is obvious for Karaf users. > The use case is to provide the configuration through the standard OSGi ConfigAdmin service. The main benefit is that the data storage can be abstracted. We use files by default as the primary source, but Cellar can push configuration changes between instances, Fuse Fabric stores them in Zookeeper, I've also seen people using a JDBC storage for the configuration. All the things are mostly interesting when dealing with large deployments, not for a single instance, I agree. > > Best regards, > -- > Ceki > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
