It might not fit too well with the felix/karaf idea of installing config admin pid configs through .cfg property files, but config admin has no problem dealing with a string property that is an entire xml document. So I'd go for a handy way to initialize such config admin properties rather than a whole new logback configurator. Maybe some kind of notation like
..file.key=filelocation which means the value for key is read from the filelocation. thanks david jencks On Oct 14, 2011, at 9:33 AM, Guillaume Nodet wrote: > > > On Fri, Oct 14, 2011 at 18:27, ceki <[email protected]> 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 >
