JUnit5

Intellij Idea wspiera pisanie testów w JUnit5. Większa modularność biblioteki minimalnie utrudniła wybór zależności do projektu. W wersji M4 są to odpowiednio:

ext.junitJupiterVersion  = '5.0.0-M4'
ext.junitPlatformVersion  = '1.0.0-M4'

dependencies {
    testCompile "org.junit.jupiter:junit-jupiter-api:${junitJupiterVersion}"
    testRuntime "org.junit.jupiter:junit-jupiter-engine:${junitJupiterVersion}"
    testRuntime "org.junit.platform:junit-platform-launcher:${junitPlatformVersion}"
}

Co ciekawe Idea nie wspiera wcześniejszych wersji JUnit5, czyli nie skorzystamy w niej np. z wersji M2.

SLF4J i Logback w WildFly10

Problem

Najprostszym sposobem skonfigurowania logowania w WildFly jest skorzystanie z podsystemu logging, który podczas deploymentu dostarcza niezbędne zależności opisane w dokumentacji. Niestety tak się składa, że pośród nich nie ma logbacka, którego chcielibyśmy użyć.

Założenia

Na serwerze będzie zarejestrowanych kilka earów, które nie zawierają pliku jboss-deployment-structure.xml, więc w miarę możliwości nie chcemy go dodawać. Aktualnie wszystkie aplikacje mają zależność compile od bibliotek slf4j-api, logback-core i logback-classic, które znajdują się po spakowaniu wewnątrz każdego eara. Konfiguracja logbacka jest gdzieś na dysku i dostarczamy ją do WildFly przez flagę -Dlogback.configurationFile. Byłoby fajnie gdyby dało się po prostu zdefiniować listę bibliotek, które chcemy dostarczyć do wszystkich deploymentów.

Rozwiązanie

Stworzyłem nowy moduł w $WILDFLY_HOME/modules/com/blogspot/..., zawierający biblioteki logback-core, logback-classic i slf4j-api. Wymagane było dodanie zależności od javax.api, ponieważ któraś z bibliotek potrzebuje org.xml.sax. Ostatecznie plik module.xml wygląda następująco:

 <module xmlns="urn:jboss:module:1.1" name="com.blogspot.julianrubin.logbacklogging">
    <resources>
        <resource-root path="logback-classic-1.1.7.jar"/>
        <resource-root path="logback-core-1.1.7.jar"/>
        <resource-root path="slf4j-api-1.7.21.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
    </dependencies>
</module>

Następnie okazało się, że jest możliwość zdefiniowania globalnych modułów, które powinny być widoczne dla wszystkich deploymentów.

 <subsystem xmlns="urn:jboss:domain:ee:4.0">
    <global-modules>
        <module name="com.blogspot.julianrubin.logbacklogging" slot="main"/>
    </global-modules>

Znaki zapytania

• Umieszczenie bibliotek w earze (np. poprzez zależność compile w build.gradle) sprawia, że wykrywany jest plik WEB-INF/classes/logback.xml. Nie udało mi się doprowadzić do sytuacji, w której logback dodawany przez nowy moduł wykryłby logback.xml umieszczony w powyższej lokalizacji. Czyli EAR ma w classpathie plik, którego w classpathie nie wykrywa logback.
• Próba uzależnienia nowego modułu od dostępnego w WildFly org.slf4j zakończyła się niepowodzeniem, czego następstwem było umieszczenie slf4j-api w nowym module. Problem polegał na tym, że SLF4J nie wiązał się z logbackiem tylko z implementacją dostępną w module WildFly org.slf4j.impl pomimo tego, że miał logbacka w classpathie (sprawdziłem to).