LoggingFeature not logging correctly based on configuration on constructor

[glassfishrobot]

Running dropwizard 1.0.5 with jersey 2.23.2. In my application when I register my LoggingFeature in the jersey environment as shown below:

**ApiApplication.java**@Override
public void run(ApiConfiguration apiConfiguration, Environment environment) throws Exception {

        final HelloWorldResource helloWorldResource = new HelloWorldResource();
        final JerseyEnvironment jerseyEnvironment = environment.jersey();
        jerseyEnvironment.register(helloWorldResource);
        jerseyEnvironment.getResourceConfig().register(MyCustomRequestFilter.class);

        jerseyEnvironment.register(new LoggingFeature(Logger.getLogger(LoggingFeature.DEFAULT_LOGGER_NAME), Level.ALL, LoggingFeature.Verbosity.PAYLOAD_TEXT, Integer.MAX_VALUE));
    }

No logs are produced at all but if I register it as below:

**ApiApplication.java**jerseyEnvironment.register(new LoggingFeature(Logger.getLogger(LoggingFeature.DEFAULT_LOGGER_NAME), Level.OFF, LoggingFeature.Verbosity.PAYLOAD_ANY, Integer.MAX_VALUE));

I am getting the follwoing logs produced:

ERROR [2017-03-30 08:14:15,580] org.glassfish.jersey.logging.LoggingFeature: 1 * Server has received a request on thread dw-46 - GET /helloworld
1 > GET http://localhost:8080/helloworld 1 > Accept: */*
1 > Accept-Encoding: gzip, deflate
1 > Cache-Control: no-cache
1 > Connection: keep-alive
1 > Host: localhost:8080
1 > Postman-Token: 2f882fdc-f7cc-46ca-9dcc-e456e64d962d
1 > User-Agent: PostmanRuntime/3.0.11-hotfix.2

Hello and welcome to the logging!
Hello World
ERROR [2017-03-30 08:14:15,591] org.glassfish.jersey.logging.LoggingFeature: 1 * Server responded with a response on thread dw-46 - GET /helloworld
1 < 200

Now should it not be the other way around, that when I set Level.ALL then I should get logs, and when Level.OFF i set then no logs should be produced? And another thing is that the requests/responses are logged as [ERROR].

Affected Versions

[2.23.2]

[glassfishrobot]

Reported by NedimCokljat

[glassfishrobot]

nedimcokljat said: My work around to make it work properly is to set

jerseyEnvironment.register(new LoggingFeature(Logger.getLogger(LoggingFeature.DEFAULT_LOGGER_NAME), Level.INFO, LoggingFeature.Verbosity.PAYLOAD_ANY, Integer.MAX_VALUE));

is to set the logger level to INFO then it works fine and it logs with level INFO and not ERROR. So perhaps the Level.OFF and Level.ALL are over- and underflowed in java.util.logging.Level so the meaning of the levels are flipped? Now I do not know if that is something that should be fixed in java.util.logging.Level or in org.glassfish.jersey.logging.LoggingFeature.

[glassfishrobot]

ajdergute said: We ran into the exact same issue. This is not a bug. I assume you're using some logging Framework other than JUL. Because all logging inside LoggingFeature is directly done with JUL and not via commons-logging (or similar) you must adjust the logging manager.

This could be done by providing a system property. In case of Log4J2 a system property could be given as follows: -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager. As an alternative you could System.setProperty("java.util.logging.manager", "org.apache.logging.log4j.jul.LogManager"); BEFORE any logging. Please be aware that the referenced class differs if you're not using Log4J2.

remark: In your case no LogManager class for JUL was set. In case log level is OFF, all logging will be passed to stderr which is then picked up by e.g. Log4J2. This is also the reason why this occurs as "ERROR" on console output.

[glassfishrobot]

nedimcokljat said: Thanks ajdergute

I see it makes sense what you are telling me. I am using slf4j with LogBack and as what I can figure out it seems like pain in the *** to make that work. So far I have only tried this solution:

LogManager.getLogManager().reset();
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();

But could not make it work. Cannot find anything that resembles your suggestion of log4j2 for slf4j. I have had a pretty good experince using log4j2 before, so I will consider changing my logging framework if I do not find any good solution for slf4j. It also seems that bridging from jul to slf4j can be costly for the performance. But thanks for enlightening me that it was not a bug as i first thought.

[glassfishrobot]

ajdergute said: You're welcome. I've no experience with sfl4j. So far what I can see from the documentation is: at least jul-to-slf4j.jar must be on the classpath. But if performance is bad anyway, maybe this is not an ideal solution.

I feel not happy that Jersey doesn't use commons logging, but I see no chance to change this.

[glassfishrobot]

nedimcokljat said: It's fine and I have jul-to-slf4j.jar on my classpath but it does not work . Well I am currently working on changing to Log4J2. Again thanks, you may close this issue .

[glassfishrobot]

This issue was imported from java.net JIRA JERSEY-3255

[pa314159]

The issue is in jul-to-slf4j, I have filled in a ticket for this https://jira.qos.ch/browse/SLF4J-429

[FelixJongleur42]

And they resolved it as "Not a bug" on Feb 4th...

[pa314159]

Yeap, they asked me to check the JDK code, but they didn't bother to do the same :)

I removed any dependency to jul-to-slf4j and I'm happy with this gist https://gist.github.com/pa314159/8420b2ad60f4db740c3d3765ed2ab285