LibLogging

Logging in the external Components

Tangram uses a broad range of libraries which of course do some logging if appropriate. The experiences and notes reflecting this are collected in this document.

Especially a mapping of libraries to their used logging framework is usefull for the setup of the application using all these libraries together.

java.util.logging (jul)

Google Guice and DataNucleus Accessplattform use this facility. Unfortunately it is not possible to redirect the DataNucleus log output to slf4j using the jul-to-slf4j bridge.

Simple Logging Facade for Java (slf4j)

Hibernate and EBean directly use this API like Tangram does.

Log 4j

If a log4j API is present on the classpath, DataNucleus switches to this facility. You can redirect the DataNucleus output using "DataNucleus" as the logging prefix using the log4j-over-slf4j bridge.

apache commons logging (jcl)

Once a favoured API it is now on the "don't use" list for most external components. But there is one candidate which still uses it and you will have to work around that: The Springframework.

Special Cases

For EclipseLink there is a special logging adaptor to get slf4j logging.

https://github.com/PE-INTERNATIONAL/org.eclipse.persistence.logging.slf4j

Also OpenJPA is a special case with a custom logging which can be switched to some output options. Using slf4j just means setting one option

openjpa.Log=slf4j

Or in the more wordy syntax of persistence.xml

<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">

  <persistence-unit name="tangram" transaction-type="RESOURCE_LOCAL">
    <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
    <properties>
      <property name="openjpa.Log" value="slf4j"/>
    </properties>
  </persistence-unit>

</persistence>

Caveats

Some of the libraries used in Tangram use the java.util.logging facility while most of the used components use slf4j. Despite this, it is not a good idea to include the jul-to-slf4j bridge in the respective modules hard wired in the dependencies for two reasons:

• The use of the bridge is relatively expensive
• It cannot be used in conjunction with the slf4j-jul adapter, which might be necessary in certain environments

As a result it is app to the application so select the bridge/adaptor which fits best for the situation of the very application.

Still to be investigates

• Groovy?
• Guava?