Hi,
On Wed, Nov 28, 2012 at 3:49 AM, Felix Meschberger <[email protected]>wrote: > 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. > Indeed, but if you look at http://logback.qos.ch/manual/appenders.html#logback-sizeAndTime (which is what I meant to post as the second link), you'll see that the configurations are in fact arbitrarily deep object graphs. Which leads to configuration dictionaries like this: name=FILE class=ch.qos.logback.core.rolling.RollingFileAppender file=logFile.log rollingPolicy.class=ch.qos.logback.core.rolling.TimeBasedRollingPolicy rollingPolicy.fileNamePattern=logFile.%d{yyyy-MM-dd}.log rollingPolicy.maxHistory=30 encoder.pattern=%-4relative [%thread] %-5level %logger{35} - %msg%n name=ROLLING class=ch.qos.logback.core.rolling.RollingFileAppender file=mylog.txt rollingPolicy.class=ch.qos.logback.core.rolling.TimeBasedRollingPolicy rollingPolicy.fileNamePattern=mylog-%d{yyyy-MM-dd}.%i.txt rollingPolicy.timeBasedFileNamingAndTriggeringPolicy.class=ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP rollingPolicy.timeBasedFileNamingAndTriggeringPolicy.maxFileSize=100MB encoder.pattern=%msg%n At which point two things have happened: (1) you've thrown out any possibility of using Metatype (right?) and (2) you're essentially reproducing the XML structure in name-value pairs. Look, I don't love XML configuration files either, but it seems that without one in this case we're going to do a lot of wheel-reinventing which I love less. > 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. Yes, but IMHO it's more important to support the generic use case first. > > 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. > Yes... through XML files (i.e. Blueprint, DS) ;) Regards, Justin > > Regards > Felix
