I'm not sure finding the right bit of an xml configuration and editing it is harder than finding the right property and editing it..... dunno, seems like a config admin interface issue.
thanks david jencks On Oct 14, 2011, at 10:32 AM, Guillaume Nodet wrote: > Yeah, but you loose the ability to easily configure one logger level or such. > Fine grained configuration is much easier imho, but you're right, it would > work too. > > On Fri, Oct 14, 2011 at 19:28, David Jencks <[email protected]> wrote: > 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 >> > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
