I've noticed that in the project it is the java.util.logging service that is used directly for, well, logging. It would be better to just use SLF4J, so that it is easier to handle the log for example with logback.
At the moment, this is a viable workaround for users like me:
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
<!-- reset all previous level configurations of all j.u.l. loggers -->
<resetJUL>true</resetJUL>
</contextListener>
put this code somewhere, I've put it in a static box:
static {
// Optionally remove existing handlers attached to j.u.l root logger
SLF4JBridgeHandler.removeHandlersForRootLogger(); // (since SLF4J 1.6.5)
// add SLF4JBridgeHandler to j.u.l's root logger, should be done once during
// the initialization phase of your application
SLF4JBridgeHandler.install();
}
This workaround works perfectly, but it could worsen the performances of the application (it adds a starting delay for sure).
I've noticed that in the project it is the java.util.logging service that is used directly for, well, logging. It would be better to just use SLF4J, so that it is easier to handle the log for example with logback.
At the moment, this is a viable workaround for users like me:
This workaround works perfectly, but it could worsen the performances of the application (it adds a starting delay for sure).