Ldap Synchronization Connector

The first (and I hope the last) issue, is that there is no FATAL level in sfl4j.
There is a FATAL level but only for backward compatibility for log4j & co.
The new interface does not define one (http://www.slf4j.org/apidocs/org/slf4j/Logger.html)

How should we migrate this level ?

Should we migrate it to a standard ERROR level ? Or do we keep log4j ?

A little more about that:
http://www.slf4j.org/faq.html#fatal

Rémy-Christophe Schermesser wrote:

The first (and I hope the last) issue, is that there is no FATAL level in sfl4j. There is a FATAL level but only for backward compatibility for log4j & co. The new interface does not define one (http://www.slf4j.org/apidocs/org/slf4j/Logger.html)

How should we migrate this level ?

Should we migrate it to a standard ERROR level ? Or do we keep log4j ?

As far as I know, there have never been any explicit conventions about log levels in LSC.

I agree with SFL4J authors' opinion: FATAL is just an ERROR message that then causes the program to halt. So if there are any FATAL logs in LSC, you can make them ERROR, in my opinion.

I have changed the package org.lsc.utils.log4j.csv to org.lsc.utils.output.csv

Rémy-Christophe Schermesser wrote:

I have changed the package org.lsc.utils.log4j.csv to org.lsc.utils.output.csv

OK, but we need to document any changes that aren't compatible with 1.1, so that existing setups on 1.1 can migrate easily. Please update http://lsc-project.org/wiki/documentation/upgrade/1.1-1.2.

LogBack is not configurable with properties files, only xml files.

So I don't know if we accept this (big) change. What do you think ?

There is an online service which takes a log4j property file and translate it into LogBack XML file (http://logback.qos.ch/translator/)

Rémy-Christophe Schermesser wrote:

LogBack is not configurable with properties files, only xml files.

sigh
What is with XML configuration files?

So I don't know if we accept this (big) change. What do you think ?

There is an online service which takes a log4j property file and translate it into LogBack XML file (http://logback.qos.ch/translator/)

Well, we already have some XML configuration files for iBatis (db2ldap syncs). All that matters to me is that configuring LSC is simple. Writing an XML file is not simple, however, editing a well commented XML file can be...

But maybe we can configure logging with our own properties, and inject the appropriate values into the XML file on launch? If I recall correctly we already load lsc.properties before initializing the logger, in org.lsc.Launcher, no?

It is possible to inject properties in the xml file, but it is very limited. You can only inject values inside existing xml tags.

<configuration>

  <property name="USER_HOME" value="/home/sebastien" />

  <appender name="FILE" 
    class="ch.qos.logback.core.FileAppender">
    <file>${USER_HOME}/myApp.log</file>
    <layout class="ch.qos.logback.classic.PatternLayout">
      <Pattern>%msg%n</Pattern>
    </layout>
  </appender>

  <root level="debug">
    <appender-ref ref="FILE" />
  </root>

Here is an example of a log4j.property file :

log4j.rootLogger = WARN, CONSOLE

log4j.logger.communicationLogger = WARN, CONSOLE
log4j.logger.org.apache = WARN, CONSOLE
log4j.logger.poolLogger = ERROR, CONSOLE
log4j.logger.lsc = INFO, LSC
log4j.logger.org.lsc = INFO, LSC

log4j.appender.CONSOLE = org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout = org.lsc.utils.LocalizedJndiModificationsLayout
log4j.appender.CONSOLE.layout.ConversionPattern = %-4r - %-5p - %m%n

log4j.appender.LSC = org.apache.log4j.RollingFileAppender
log4j.appender.LSC.File=/tmp/synchro.log
log4j.appender.LSC.Append = false
log4j.appender.LSC.Threshold = DEBUG
log4j.appender.LSC.MaxFileSize = 10000KB
log4j.appender.LSC.layout = org.lsc.utils.LocalizedJndiModificationsLayout
log4j.appender.LSC.layout.ConversionPattern = %m%n

And here is the xml version of the file for logback :

<?xml version="1.0" encoding="UTF-8"?>

<configuration>
  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <layout class="org.lsc.utils.LocalizedJndiModificationsLayout">
      <ConversionPattern>%-4r - %-5p - %m%n</ConversionPattern>
    </layout>
  </appender>
  <appender name="LSC" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <!--See also http://logback.qos.ch/manual/appenders.html#RollingFileAppender-->
    <Append>false</Append>
    <File>/tmp/synchro.log</File>
    <layout class="org.lsc.utils.LocalizedJndiModificationsLayout">
      <ConversionPattern>%m%n</ConversionPattern>
    </layout>
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>DEBUG</level>
    </filter>
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"/>
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
      <MaxFileSize>10000KB</MaxFileSize>
    </triggeringPolicy>
  </appender>
  <logger name="communicationLogger" level="WARN">
    <appender-ref ref="CONSOLE"/>
  </logger>
  <logger name="org.lsc" level="INFO">
    <appender-ref ref="LSC"/>
  </logger>
  <logger name="org.apache" level="WARN">
    <appender-ref ref="CONSOLE"/>
  </logger>
  <logger name="lsc" level="INFO">
    <appender-ref ref="LSC"/>
  </logger>
  <logger name="poolLogger" level="ERROR">
    <appender-ref ref="CONSOLE"/>
  </logger>
  <root level="WARN">
    <appender-ref ref="CONSOLE"/>
  </root>
</configuration>

Here my idea :

We use properties for a default logger with a default configuration.

And if some user wants to change the behavior of the loggers (Csv, JndiModifications, etc.) he goes and dig in the xml file

What do you think ?

ps : the migration is almost done for lsc-core

Rémy-Christophe Schermesser wrote:

Here my idea :

We use properties for a default logger with a default configuration.

And if some user wants to change the behavior of the loggers (Csv, JndiModifications, etc.) he goes and dig in the xml file

What do you think ?

Well, that's the same as current behaviour. But that sucks, because it's a different config file from everything else, and it's obscure... so XML just makes it more obscure. It'll work for a first version though.

Is it possible to inject parameters programattically to logback (via something.setConfiguration or addAppender, for example, like in log4j) ?

ps : the migration is almost done for lsc-core

Great! Looking forward to trying it :)

Jonathan Clarke wrote:

Well, that's the same as current behaviour. But that sucks, because it's a different config file from everything else, and it's obscure... so XML just makes it more obscure. It'll work for a first version though.

Is it possible to inject parameters programattically to logback (via something.setConfiguration or addAppender, for example, like in log4j) ?

Yes, we CAN !! But is it really a good idea ? It will be a lot of code, and not a very useful feature

Great! Looking forward to trying it :)

Don't look to much for it, I will push A lot of revisions ;)

Rémy-Christophe Schermesser wrote:

Is it possible to inject parameters programattically to logback (via something.setConfiguration or addAppender, for example, like in log4j) ?

Yes, we CAN !! But is it really a good idea ? It will be a lot of code, and not a very useful feature

I was thinking of a simple parameter in LSC properties, that specifies for example:

lsc.tasks.<taskname>.LdifLog = /tmp/updates.ldif

That, when parsed, runs some Java code to add an appender to logback with the filename, using the LDIF layout configured for the appropriate taskName. The idea is to make simple shorthand to avoid copying out the same lengthy configuration used all the time, to the XML file.

I think you should talk about this face to face or at least irc to irc.

Rémy-Christophe Schermesser wrote:

I think you should talk about this face to face or at least irc to irc.

OK. Don't worry about it. I'm just thinking out loud about ways to improve the configuration all together.

We should get together to discuss LSC soon!

(BTW, assigning this feature to you, Rémy-Christophe)

It is done !

I will really need some feedback and additional testing from people.

I did not migrate some files, which are using log4j.properties, from lsc-sample because I don't know what they do (make-lsc-archive.sh, build-generator.xml, build-install.xml).

Rémy-Christophe Schermesser wrote:

It is done !

I will really need some feedback and additional testing from people.

I've given it a try, and it looks OK so far - apart from some issues I mentioned on IRC (like logs during tests don't seem to use the LDIF formatter)

I did not migrate some files, which are using log4j.properties, from lsc-sample because I don't know what they do (make-lsc-archive.sh, build-generator.xml, build-install.xml).

make-lsc-archive.sh is a shell script to create an tar.gz archive ready to install on a production server. It builds a JAR from lsc-sample, and copies all Maven dependencies into a lib dir. A shell script build a classpath from all these JARs, and runs LSC. Thus, maven and ant aren't necessary on servers.

build-generator and build-install.xml are the build files for the generator wizard and the install wizard (unused AFAIK).

The make-lsc-archive.sh is now obsolete and #103 can generate a new tarball.

I think this issue is finished, so I close it.