mixed java logging with slf4j, log4j and java.util.logging

Question

I'm running a web application in a Weblogic server (Im not realy familiar with ).
Via JVM args a log4j config is passed with log level DEBUG to the application. In the log file I can also find some log entries of DEBUG level.

So far so good.
During debugging I found some calls to logger.debug() that are not in the log file.

private static final org.slf4j.Logger logger = LoggerFactory.getLogger(ActionCtr.class);

The method call is definitely hit but nothing is written to a file.

If I do a step into during debugging I see in the logger: org.slf4j.impl.JDK14LoggerAdapter(com.example.application.ActionCtr) "java.util.logging.FileHandler.pattern" -> "%h/java%u.log"

And this leads to some questions for me (as I can not change the running application):
1) how could it bee that it uses the application is using a mixed up log4j and java.util.logging
2) How could I determine what is used in what classes?
3) There is no %h/java%u.log (~/java*.log) so I've tried to provide a java.util.logging conform properties file, but this changed nothing - how an I determine where the running logger got its config from to configure it right?

Answer 1

1) how could it be that it uses the application is using a mixed up log4j and java.util.logging

Any of those logging frameworks could be used by the application directly or a dependent library that the application is using. It doesn't take too many dependencies to end up with a bunch of logging framework hitchhikers.

The SLF4J manual explains how that logging framework wrangles all of these other frameworks. This why you are seeing the org.slf4j.impl.JDK14LoggerAdapter.

How could I determine what is used in what classes?

Assuming you mean direct usages you can use Jdeps or Javap.

how an I determine where the running logger got its config from to configure it right?

The JConsole tool can access the JUL loggers at runtime. It will also show you all of the system properties which may include paths to logging.properties files.

If the application is pragmatically configuring the logging in an non-standard way then one option would be to use the java.security.debug using the access option. Run the application under a security manager will all or all required permissions but then enable access tracing.