Do not keep static references to log levels

I’m indeed finding many cases in which the level is statically cached w/o it seemingly being justified. I’ll fix them.

I’m not sure what we could do to make levels immutable really. The JBoss Log Manager is an extension of JUL so we’re tied to that.

I can see arguments for using debug/trace levels at runtime. For example if they are seeing an issue they can’t explain, likely happening at random times, it could be useful to enable trace logging at runtime as restarting the JVM may cause the issue to go away.

I’m aware that all Loggers work like this, yet I wonder if we could do better.

Regarding WildFly.. I don’t expect users to reboot, but I also don't expect them to need the lowest level (trace), which we use exclusively for complex debugging cases - as mentioned, the alternative is that we strip them out.

But yes this is just my general answer about “the pattern”, we certainly do want users to be able to log binding parameters - that shouldn’t be done in that case.

I’m not sure how we could support an immutable level in the JBoss Log Manager. That’s how, to my knowledge, all log managers work. They allow levels to be changed at runtime. By keeping a static final reference, that makes it a requirement to restart the JVM if you want to see messages at that level logged.

This would be an issue for any app that allows for log level changes, not just WildFly. However, this definitely affects WildFly as changing a log level shouldn’t really require restarting the server.

The alternative to this pattern being to fully remove such statements from the source code.

I personally think that we could remove quite a lot of the debug/trace-level logging that Hibernate does, but the logging in JdbcBindingLogging is actually super-useful and important. These are the log messages we really can’t remove.