Added trivial test for every basic variant of execution

[dmatej]

No description provided.

[dmatej]

It is not, take a look to SLF4J website. It is the artifact name just to keep continuity. JUL was added to JDK at the time of Java 1.4, since then it has nearly the same api, but internally it changed over time. And it is also a default backend behind System Logger facade, which came in Java 11.

SLF4J can bind to both as an api or as an implementation. With all those platforms you basically have to choose your backend and sink all other to it. SLF4J is very capable in this discipline, so it this case:

• TestContainers use slf4j-api
• GlassFish uses JUL as the impl backend extended by own logmanager.
• GlassFish and its dependencies use JUL, System. Logger and JBoss-Logging + some additonal custom apis as an api facade.

[chabala]

Ah I see, this is the JUL implementation binding; I have avoided using JUL and was not familiar with that artifact. Your explanation makes sense. In the context of most elements of the stack using it, it makes sense to make it the target. I've avoided it due to it being the only implementation with a performance penalty for bridging away from it.

[OndroMih]

The penalty is only when an app logs using JUL and you want to translate that to slf4j and then log with something else, e.g. log4j. It’s the opposite case here. In this case, test containers use slf4j for logging and we want that to be logged via JUL, in the same way as our logs in tests. This doesn’t incur much performance penalty because JUL is called only when log messages are really logged and not always, as in the first case. Note that the slf4j-jdk14 artfact means slf4j logged via JUL, while jul-to-slf4j means JUL logged via slf4j and subsequently via some slf4j adapter (log4j, logback, etc)