System Properties bei Tomcat setzen

Java-Forum Jakarta EE (Java EE)
1

Hi,

kein echtes EE Thema, aber hier passt es wohl am besten rein.

Ich benutze Tomcat 7 und möchte Hibernate 4 verwenden. Hibernate 4 verwendet jboss-logging fürs Logging. Ich verwende in meiner Anwendung aber log4j 2. Um das gesamte Logging über log4j zu konfigurieren, muss auch das jboss-logging so konfiguriert werden, dass es dahin umgeleitet wird.
Das realisiere ich so, dass ich jboss-logging mit slf4j benutze und log4j so konfiguriere, dass es als Implementierung von slf4j eingesetzt wird.

Meine Dependencies sehen so aus:


dependencies {
    compile('org.springframework:spring-core:4.0.0.RC1') {
        exclude group: 'commons-logging'
    }

    runtime 'org.slf4j:jcl-over-slf4j:1.7.+'
    runtime 'org.slf4j:slf4j-api:1.7.+'
    runtime 'org.apache.logging.log4j:log4j-slf4j-impl:2.+'
    runtime 'org.apache.logging.log4j:log4j-api:2.+'
    runtime 'org.apache.logging.log4j:log4j-core:2.+'
    ....
}

Um jboss-logging dazu zu bewegen, dass es slf4j benutzt, muss ich die System Property org.jboss.logging.provider auf slf4j setzen.

Was ist nun der geschickteste Weg, die Systemproperty zu setzen?

Ich möchte möglichst wenig harte Abhängigkeiten produzieren. Am liebsten wäre mir eine Lösung, bei der ich unabhängig vom Webcontainer bleibe und die Property standardkonform setzen kann.

2

Containerunabhängig wird das nicht. Schau Dir die Startscripte des Tomcat an. Dort werden die Sysprops gesetzt. Damit man nicht dort direkt editieren muss, legt man sich eine setenv.sh/bat an und schreibt das da rein. Diese wird von den Startscripten gecallt.

3

Das ist natürlich bescheiden. Solch eine Abhängigkeit von der Laufzeitumgebung ist nicht schön.
Ich habe noch eine Lösung mit einem ContextListener gefunden, die ist aber auch nicht viel schöner: http://stackoverflow.com/a/2335332

Kann ich nur hoffen, dass jboss-logging vielleicht noch log4j 2 autodetection oder eine elegantere Konfigurationsmethode lernt, bis das Projekt produktiv gehen soll.

"
[spoiler]Ist noch ein bisschen Zeit, daher habe ich bei den verwendeten Frameworks Betaversionen / Releasecandidates gewählt: log4j 2, Spring 4 (daher auch Java 8)
Das hakt auch noch ein bisschen, unter anderem mag gradle unter Java 8 meine TestNG-Tests nicht und man muss umständlich Java 7 als JVM für gradle und Java 8 für den Buildprozess konfigurieren.
Solch eine komplizierte Konfiguration macht die CI dann wieder komplizierter…[/spoiler]