Hi,
On Tue, Nov 27, 2012 at 4:47 AM, Felix Meschberger <[email protected]>wrote: > 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. > I'll try to get something committed to a whiteboard soon as this is probably best illustrated in code, but I don't think we can use Configuration Factories this without making some significant functional sacrifices (compared with what you can do with logback, not compared with what Sling has now). As two simple examples: http://logback.qos.ch/manual/appenders.html#logback-RollingTimeBased http://logback.qos.ch/manual/appenders.html#logback-RollingSizeBased Storing both of those configuration structures in ConfigAdmin without locking the administrator into these particular implementation classes doesn't seem feasible to me. At this is just a file example... it gets worse as you look at JDBC and JMS cases. > > > > > 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 ;-) ) > I would love to be able to use ConfigAdmin for all those reasons. But I don't think it's worth crippling logback for. I'm not contemplating a JCR dependency, just a sling.api dependency. And this would most likely be a separate bundle. > > > > > 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. > Makes sense. It sounds like we are at least agreed that directly supporting the existing configuration schemata is a non-goal. Justin > > Regards > Felix
