These are chat archives for fiji/fiji

3rd
Sep 2016
Florian Jug
@fjug
Sep 03 2016 17:32
Hi! I’m looking for the ‘official’ way to use logging in ImageJ/Fiji. For that matter I studied http://imagej.net/Logging but I have a question to to still open and wonder if someone could help me.
I would like to replace ALL System.out.* lines in my code and use the LogService instead.
Just getting the log-service via @Parameter and using it makes Fiji open the console every time I log something. I think to have understood, taht I can prevent this by changing the log-level for my project (as explained in http://imagej.net/Logging).
System.setProperty(“scijava.log.level:my.package", "debug”);
Florian Jug
@fjug
Sep 03 2016 17:37
From within Eclipse I instantiate my own log service and some magic makes messages also appear on stderr.
Now the questions:
1) is anything about what I am doing silly or at least clearly improvable?
2) how could I change the magic strerr thing to e.g. write all infos out on stdout??? (At least for the log service I created myself…)
Thanks a lot for your replies (and case there will be some)! ;)
Florian Jug
@fjug
Sep 03 2016 17:49
PS: coolest would be, could I tell the log service to forward messages I log to (or also to) a stream I provide (so my plugin could collect all log messages itself in the already existing log panel).
Florian Jug
@fjug
Sep 03 2016 17:58

PPS: whereever I put the line

System.setProperty( "scijava.log.level", "none" );

from within Fiji and started standalone from Eclipse, I always see ALL log messages coming over stderr… something I seem not to get...

Curtis Rueden
@ctrueden
Sep 03 2016 21:15
@fjug Firstly, note that all log messages currently go to stderr, unfortunately. This is a flaw in SJC v2.
It is fixed in SJC v3 (scijava/scijava-common@2145a5e), which is not yet released.
The Logging page is correct that anything on stdout does not pop up the Console (though the output will appear there). And anything on stderr does pop it up.
So, once SJC v3 is released, WARN and ERROR level messages will pop the Console, while INFO and DEBUG will no longer do so.
You should get your LogService via an @Parameter. Do not create your own.
What is your logging goal? You want your messages to go to stdout, and not stderr?
If so, I suggest using log.info(...) and log.debug(...). Unfortunately, the SJC v2 behavior of sending those to stderr is the current situation right now. Actually, by default, those messages will probably go nowhere, since I think the log level is set to warn by default.
Curtis Rueden
@ctrueden
Sep 03 2016 21:20
There was some reason the change of those to stdout was a breaking API change, which couldn't be done in SJC v2. I'm checking now.
Curtis Rueden
@ctrueden
Sep 03 2016 21:25
@fjug I think the behavior can be easily fixed in SJC v2, without breaking backwards compatibility. Testing now.
Curtis Rueden
@ctrueden
Sep 03 2016 21:32
@fjug Just for you: scijava/scijava-common@e3453f2

coolest would be, could I tell the log service to forward messages I log to (or also to) a stream I provide (so my plugin could collect all log messages itself in the already existing log panel).

Yes, you can do all of that. You just need to use the SLF4JLogService instead, as described on the Logging page.

If you use that LogService instead of the default SJC one, you can make SLF4J backed by logback, and configure logback in all the usual ways. The configuration capabilities are extensive: you can log to files, streams, combinations thereof, whatever you want basically, and set up the log messages in whatever format you want, with prefixes, datestamps, etc.
The whole point of these logging frameworks is to let you have fine-grained control over logging for complex systems where recompilation would be a big headache.
What you should not do is hardcode that stuff into your project's code. Just use log.info, log.warn, log.error and log.debug to classify your log messages. And leave the configuration of where the messages go to the application downstream.
Curtis Rueden
@ctrueden
Sep 03 2016 21:38
And again, you should not instantiate and use your own LogService—that defeats the entire purpose of SciJava dependency injection.
P.S. I was wrong about the default level being WARN. It is INFO. This is a good thing I think.

whereever I put the line

System.setProperty( "scijava.log.level", "none" );

from within Fiji and started standalone from Eclipse, I always see ALL log messages coming over stderr… something I seem not to get...

This is because that system property is only respected when the SciJava context is first created. When the LogService is initialized, it uses the current value of that property to set its level. It does not poll the property later.

To change the level after Fiji starts up, use the setLevel methods of LogService.
At the moment, there is no package- or class-specific API for changing the level after SciJava spins up.
Oh, I lied. There is: setLevel(String classOrPackageName, int level). Enjoy.