Turning off Atmosphere logging to stderr

Hello,

We have a vaadin 7 application that is using the lunifera Vaddin OSGI bridge with push enabled. Every time we start our server application we see the following get printed out to stderr.

Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework addAtmosphereHandler
INFO: Installed AtmosphereHandler com.vaadin.server.communication.PushHandler mapped to context-path: /*
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.DefaultBroadcaster <init>
INFO: /* support Out Of Order Broadcast: false
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework autoDetectWebSocketHandler
INFO: Auto detecting WebSocketHandler in /WEB-INF/classes/
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework initWebSocket
INFO: Installed WebSocketProtocol org.atmosphere.websocket.protocol.SimpleHttpProtocol 
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework autoDetectContainer
INFO: Atmosphere is using async support: org.atmosphere.container.JettyAsyncSupportWithWebSocket running under container: jetty/8.y.z-SNAPSHOT with WebSocket enabled.
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework configureAtmosphereInterceptor
INFO: Installed Default AtmosphereInterceptor [Android Interceptor Support, SSE Interceptor Support, JSONP Interceptor Support, Atmosphere JavaScript Protocol, Browser disconnection detection]
. Set org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults in your xml to disable them.
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework init
WARNING: No BroadcasterCache configured. Broadcasted message between client reconnection will be LOST. It is recommended to configure the org.atmosphere.cache.UUIDBroadcasterCache
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework init
INFO: Shared ExecutorService supported: true
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework init
INFO: HttpSession supported: true
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework init
INFO: Using BroadcasterFactory: org.atmosphere.cpr.DefaultBroadcasterFactory
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework init
INFO: Using WebSocketProcessor: org.atmosphere.websocket.DefaultWebSocketProcessor
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework init
INFO: Using Broadcaster: org.atmosphere.cpr.DefaultBroadcaster
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework init
INFO: Atmosphere Framework 1.0.14.vaadin4 started.
Mar 6, 2014 12:25:15 PM org.atmosphere.cpr.AtmosphereFramework interceptor
INFO: Installed AtmosphereInterceptor  Track Message Size Interceptor using |. 

I am trying to get rid of these log messages on startup but I am having issues doing so. We re currently using SLF4J implemented with Logback. All other logging in the application seems to be following the rules of our log configuration with the exception of the above messages. I can even turn on and off Vaadin server side logging via my slf4j config via the SLF4J Bridge.

An odd thing is that if I add the following tag to my log configuration I will see the above log messages twice. Once on stderr and once in my log.

<logger name="org.atmosphere" level="DEBUG" />

I took a look at the Atmosphere soruce and I do see that it is utilizing SLF4J. If anyone can shed some light on the issue I would greatly appreciate it.

Yes, there’s a catch. The Atmosphere version used by Vaadin does not use SLF4J but an adapter delegating to standard java.util.logging instead. Thus, you should use a logging.properties file to configure the logging. Depending on SLF4J would’ve been tricky because many servers already contain some (potentially conflicting) SLF4J version on the classpath, and others don’t. This is not acceptable, as Vaadin should be deployable in any supported server without needing extra “compatibility” modules.

Johannes,

Thank you for the quick response. I will try this out.

I take it that the SLF4J bridge will not resolve this issue as it is already implemented in my code and I am still having the same issue?

I was able to get the SLF4J JUL bridge working in this scenario.

The trick is to use the following code when setting up the bridge.

LogManager.getLogManager().reset();
SLF4JBridgeHandler.install();
java.util.logging.Logger.getLogger("global").setLevel(Level.FINEST);

I believe the reset() is needed to remove the default console appender. The setLevel() is needed so that all the JUL logging is pushed to SLF4J. The last line can decrease efficiency of the JUL logger as it is now pushing out all log messages to SLF4J and SLF4J is filtering them from its perspective. If efficiency is a concern you may want to just use two separate log files one for SLF4J and one for JUL.

It’s totaly stupid to bridge SLF4J to JUL, than from JUL to SLF4J (with performance penalty) and than to logback/log4j. You are using maven, so why don’t you let developers to deside, what logging framework use ???

Programicly redirecting JUL to SLF4J via SLF4JBridgeHandler / LevelChangePropagator don’t work for me in this case. I must use logging.properties to do the trick.

It is mucht easier to solve SLF4J dependancy problem than problems with JUL logging in application servers.

Life is much easier for application developers who know at least a part of the deployment environment than for framework developers.

As far as I can recall, there was a conflict on some versions of some servlet containers when SLF4J was included in the WAR, and other application servers didn’t include SLF4J so it had to be deployed with the application. While in theory the conflict shouldn’t happen with SLF4J, in practice it did - perhaps due to the classloaders used by those servers to load SLF4J. Other applications using SLF4J also faced similar problems on those servers, and they did prevent using the same WAR file on different servlet containers, so there was little choice but to eliminate the forced dependency on SLF4J.

If you know your environment, in theory you could build a custom version of the Vaadin Atmosphere package with some of the build time pre-processing (transforming the log statements) disabled. See
this thread
about the pre-processor.

Johannes and Henri,

I disagree with the approach that Vaadin is taking with this matter. Logging in Java is already a nightmare as it is. With the way that the Vaadin atmosphere framework forces JUL and offers no configuration to change this behavior, it has become a real horrortrip for me.

At first I thought I could just exlude the atmosphere-runtime JAR from Vaadin and add the original atmoshpere-runtime JAR to my dependencies. Butn then I was greeted with a warning message upon startup of the Vaadin servlet, informing me that my version of the atmosphere-runtime JAR may be missing patches from the Vaadin-based version. Great.

I now use LogManager.getLogManager().reset(); at the start of my application as a quite dirty hack to stop atmosphere from blasting log messages on stderr, but in the long run I might actually fork a version without the JUL/JDK14 binding for slf4j.

Are there plans to provide the patches that are in the Vaadin-based version of atmospohere-runtime to the atmosphere project?

LogManager.getLogManager().reset();

This line seems to do a big mess on Tomcat 7 for me. After having that set up, I was having some exceptions in my ServletContextListener#contextInitialized() (for other reasons, of course) and the stacktraces stopped going to “localhost” log file. I suspected that it happened because tomcat configure its own log mechanism to use JUL and this reset() call miscofigured it.