Hi, Am 27.11.2012 um 02:36 schrieb Justin Edelson:
> I'm taking a run at replacing the internals of the Sling Logging bundle > with Logback. I'm having some trouble mapping our existing configuration > structure to Logback. And I'm wondering how useful an exercise it is in the > first place as one of the reasons (at least for me) in moving to Logback is > the ability to be get more flexibility in terms of different appenders, > file rollover triggering policies, etc. I agree and I agree that our current configuration structure may not fully adequate. But I am pretty sure, we can and should continue to employ the Configuration Factory technique. > > So... WDYT about a much simpler structure where: > 1) On startup, a config file in a location relative to sling.home is > consulted. If it does not exist, some default configuration is used. > 2) Once a resource resolver factory is located, the configuration file is > reloaded from a configurable location. > 2a) Alternatively, rather than storing the configuration as an XML file in > the repository, store it as a resource structure. The advantage of using Configuration Admin is to not have to care about persistence and file formats and file updates etc. Therefore, I would really prefer to continue leveraging configuration admin (and a small handfull of framework properties for basic setup) over having to manage (observe, read, parse) configuration files. And I am much less inclined to even add a JCR dependency (and no Commons Config is not an option, either ;-) ) > > We could also have some script which converts existing sling:OsgiConfig > nodes into the Logback config file, but I have a feeling that's going to be > more trouble than it is worth. sling:OsgiConfig is part of JCR Install to ingest Configuration Admin configuration. We should not tamper with these nodes and try to have yet another parser. If we have to convert (and we may have to), we should do this based on regular Configuration Admin configuration. Regards Felix
