Print

[dbwiddis]

There is now a dent on my desk from banging my head against it so often today. 

I am trying to suppress unwanted output from my Console in Eclipse.  Specifically, the JMX Exceptions mentioned in this thread. 

I have my own implementation of org.apache.log4j.Logger with a utility class that explicitly identifies a "log.properties" file. This is working just fine for me, and produces "black text" in my console output for everything that I configure to be output.  However, there is aso a lot of "red text" produced by various JPPF processes, including the initial printout of version numbers, client/driver connections, and the like, as well as output of other external classes that I call. 

I've got the config/log4j.properties file that I *think* is supposed to handle all these other logging issues, but nothing I try to suppress the output seems to be working.  I've confirmed that the file is on my classpath; I've tried adding "-Dlog4j.configuration=log4j.properties" as a VM argument in my Eclipse run configuration, and various other attempts at various paths/arguments based on what I've read in these forums and elsewhere on the internet.  I've officially given up!

It's possible that I've got it in the right place, but configured only for logfile output vs. console output (but I've uncommented the console lines in the stock log4j.properties file with no change in results.)

What obviously simple step am I missing here?

[lolo]

I am very sorry for the headaches this has caused you.

The explanation is simple: the JMX exceptions you mentioned are logged by the JMXMP remote connector, which uses only java.util.logging loggers. Basically, it doesn't use SLF4J with Log4j bindings as the JPPF code does. This means that you need to use a different logging configuration file for j.u.l logging and specify this file's location with -Djava.util.logging.config.file=/path/to/config/file.

You can notice that such a configuration file is present in the driver, node, admin console and application template distributions (in their respective config folders), side by side with the log4j configuration file: logging-driver.properties, logging-node.properties, logging-gui.properties and logging.properties, respectively. In the case of  the driver and node, the -Djava.util.logging.config.file is specified in their jppf configuration file (look for jppf.jvm.options), whereas in the other two it is specified in the shell script that launches them.

I hope this clarifies and keeps you away from aspirin 

-Laurent

[lolo]

An update on this: I registered an enhancement, targeted for JPPF 4.2: JPPF-268 JMXMP connector: replace j.u.l logging with slf4j logging. Since we have forked the code of the OpenDMK project, we can make any change deemed necessary, and I believe switching to Slf4j logging is a desirable improvement.

For the context and rationale, please have a look at JPPF-269.

-Laurent

[dbwiddis]

The explanation is simple: the JMX exceptions you mentioned are logged by the JMXMP remote connector, which uses only java.util.logging loggers. Basically, it doesn't use SLF4J with Log4j bindings as the JPPF code does. This means that you need to use a different logging configuration file for j.u.l logging and specify this file's location with -Djava.util.logging.config.file=/path/to/config/file.

You can notice that such a configuration file is present in the driver, node, admin console and application template distributions (in their respective config folders), side by side with the log4j configuration file: logging-driver.properties, logging-node.properties, logging-gui.properties and logging.properties, respectively. In the case of  the driver and node, the -Djava.util.logging.config.file is specified in their jppf configuration file (look for jppf.jvm.options), whereas in the other two it is specified in the shell script that launches them.

Thank you for that succinct and detailed explanation. Hours of research on Google did not make it as clear as those two paragraphs!

I'm afraid that my own setup may be stomping on one or both of the two, because I did try the -Djava.util.logging.config.file pointing to the logging.properties file, containing the same statements which worked on the driver... and that didn't work.  I did, after some time, realize that there was a ".level" in the java.util.logging syntax, which I had not seen and had been omitting in my earlier experiments.  I did finally manage to suppress the JMX alerts by placing com.sun.jmx.remote.level=ERROR in my own log.properties file, which is called from inside my code.

I'm still trying to get rid of another source of logspam (sshj package used in jclouds) that doesn't seem to play by either the log4j or java.util.logging syntax, but that's a questio for another forum!

[lolo]

Well, looking at sshj's pom.xml, they have a dependency on slf4j and logback (which is probably the slf4j binding they use by default), and I've seen it used in at least one of their source files ...

They actually state the dependency on slf4j in their Github home page.

[dbwiddis]

Laurent,

Thanks for going above and beyond the call of duty to try to help outside JPPF. 

Unfortunatey, while knowing sshj uses logback didn't help much, I did learn a lot more about slf4j in the process of investigating, and realized it was just a front-end to everything else.  Turns out I have a slf4j-simple jar in my classpath, and that is what is intercepting (and formatting) the messages coming from external programs like sshj.  I was easily able to get rid of the messages by switching to slf4j-log4j12.  I'm back to -simple, since it's in the imported project I'm porting over, but I think at some point I'll try to switch everything over to a consistent platform, possibly logback...

Anyway, sticking a fork in this for now.

Dan