Hi, Am 27.11.2012 um 15:24 schrieb Justin Edelson:
> 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. Maybe it is really simple: This really looks like beany configs. The most important property would be the class name to use. This can be a plain string. The rest of the properties could just be used as bean properties to the actual class -- ignoring all properties which cannot be mapped. For main-stream configuration types (like rolling files) we might provide mor concise configuration types (and even support the existing ones in this case). In fact, IMHO our existing configurations can cope with both TimeBased and SizeBased policies of the RollingFileAppender. On the other hand we can also turn this around: Instead of configuring Log Back directly through the configuration manager, we use services: For example, the RollingFileAppender may take a RollingPolicy or some pre-defined configuration. It looks like the configuration files just are somewhat like dependency injection and OSGi can do that formidably. Regards Felix
