Granular control of logging levels in a Java operator?

So: Streams itself logs, and we have several Java operators which log, and those operators use third-party libraries which also log. What we want is to be able to log only WARN or above from Streams and libraries. From our own operators we'd also like to be able to log high-level, relatively infrequent INFO in production, and possibly DEBUG in dev. (Streams INFO is pretty spammy - lots of entries like JavaOp: after calling JNIBridge.(), which look more like DEBUG or even TRACE to me. Some of the third-party library INFO is extremely spammy, to the extent that interesting stuff is getting drowned in the noise.)

The problem is that Streams (3.1.0) only seems to offer the global output levels in the SPL Application launch config, plus config tracing at the operator level in SPL. Logging config looks to be buried in /opt/ibm/InfoSphereStreams/toolkits/spl/impl/lib/com.ibm.streams.operator.internal.javaop.jar!/log4j.properties, which is systemwide rather than per-app and so not really something we should be hacking about. I've tried setting the global level high and selectively overriding with e.g. Logger.getLogger("com.example.nonspammy").setLevel(Level.INFO); in operator initialize() methods, but that appears to have zero effect on anything.

We've been banging our heads against this almost from the start and are getting desperate. Any suggestions gratefully received. Note that I think we're all new to Log4J and may well be missing something basic.

People who like this

Thanks for the reply. This helps insofar as it allows third-party library logging to be dialed down, but it doesn't seem to help for Streams itself. Even with a really draconian log4j.properties file in data e.g.

I'm still seeing large amounts of INFO logspam coming from Streams. It's hard to know how to turn this off without knowing the category it's being logged under; category isn't shown, and changing layout in log4j.properties to show it doesn't have any effect.

Accepting as partial answer, but I'd still be very interested in any tricks to suppress the Streams logspam. This actually isn't too bad at INFO - lots of noise at startup but seems OK thereafter - but is still pretty dire at DEBUG.

On reflection, given that most of this is coming from C++ code, I suspect the problem isn't that it's logging under an unexpected Category, but rather that it's bypassing Log4J completely and is therefore unaffected by any Log4J configuration.