Version 2

    Test logging

    All GateIn codebase and components use a wrapper of SLF4J logging framework. The unit test configuration leverages this and use the JDK logging via the SLF4J binding during the unit test executions. The component test module defines a few classes that are necessary to properly integrate the unit test logging with the maven environment. Most of the configuration is done in the main GateIn pom.

    Logging configuration

    The configuration of the logging is done via a bootstrap class org.exoplatform.component.test.logging.LogConfiguration that reads the file gatein-logging.properties that is in the same module.

    Configuration bootstrap

    This configuration is performed by a system property (java.util.logging.config.class) configured at the maven level that indicates to use this configurator. If ones requires to change that configuration for various reason, then the most appropriate way is to update the maven configuration to remove the system property java.util.logging.config.class and instead use the java.util.logging.config.file value to point directly to a valid configuration file.

    Default configuration

    The default configration setup two handlers

    • The ConsoleHandler outputs the log and is reduced to the info level
    • The FileHandler outputs the log in the target directory of maven under the name gateintest-0.log (usually) and it is configured with the fine level for GateIn and its components (including JCR), the rest is configured with the info level.

    Note that the default LogConfigurator class performs additional property replacement in the property file to reuse the basedir propery setup by the surefire plugin to put the log in the target directory.

     

    handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler
    
    # Console handler
    java.util.logging.ConsoleHandler.level = INFO
    java.util.logging.ConsoleHandler.formatter = org.exoplatform.component.test.logging.PatternFormatter
    
    # File handler
    java.util.logging.FileHandler.level = ALL
    java.util.logging.FileHandler.formatter = org.exoplatform.component.test.logging.PatternFormatter
    java.util.logging.FileHandler.pattern = ${basedir}/target/gateintest-%u.log
    
    # Default level is info
    .level = INFO
    
    # Configures GateIn logging as fine
    org.exoplatform.level = FINE
    org.gatein.level = FINE
    
    Handler output format

    The default output format of the JDK is not nice and the class org.exoplatform.component.test.logging.PatternFormatter has been developed to replace it during the unit test execution. It is configured in the gatein-logging.properties and contains a configurable pattern. Please read the javadoc of this class if you want to customize its output format.

    If you need to retain one thing

    Logging is performed on the console at the info level and at the fine level (for GateIn and its components) in the ${project.build.directory}/target/gateintest-0.log file. It has reasonable default but if you don't like it you can change it, you probably won't.

    Testing with various databases

    Test profiles

    The main pom file of GateIn defines two profiles for executing unit test with different databases:

    • hsqldb: run tests with HSQLDB, this profile is active by default
    • mysql5: run tests with Mysql5: note that this profile is experimental and it is hardcoded in it the URL of the local Mysql database. The URL contains the IP of Julien Viet's virtual machine running Mysql5 and you should respect that as he spent time starting this effort. If you want to have the freedom to specify a database, you should spend time making it easy and flexible to configure and understand the work behind it.

    The main affected backend is Java Content Repository as it uses now dialect autodetection which makes it only require a different database to run without additional configuration.

    Known limitations

    • mysql5 tests cannot be run at the aggregator level as it needs cleanup once tests have been executed
    • identity component always use hsqldb as it would require proper configuration of the hibernate service for autodetection of dialect