These are chat archives for fiji/fiji

Sep 2016
Florian Jug
Sep 04 2016 09:22

And again, you should not instantiate and use your own LogService—that defeats the entire purpose of SciJava dependency injection.

@ctrueden Sure, if my command runs from within Fiji I do not do that — only in case I run standalone (e.g. from Fiji or from an Uber-Jar) I have to create a context and instantiate my own op and log services.

Florian Jug
Sep 04 2016 09:28

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.

So how would I use log back with the SLF4JLogService? Is there a place I could see this being done?

(Just some plugin or so that you know about doing it so I can just look into their code…)
Curtis Rueden
Sep 04 2016 13:30
Even running standalone, yes you create your own context, but no you do not instantiate services manually.
Regarding logback, put scijava-log-slf4j in your deps. Put logback-classic and slf4j-logback in your runtime deps. And put a file in src/main/resources. Or you can skip that file and use scijava-config which ships a sensible default file. The OMERO-5.x update sites do this, as an example.
We do not do this in core Fiji because it was thought to be overly complex (four jars + deps for logging, ugh) but perhaps we should, I don't know.
Curtis Rueden
Sep 04 2016 14:12
@fjug Oh, I guess the SLF4J/logback binding is actually org.slf4j:slf4j-log4j12 or org.slf4j:slf4j-log4j13 depending on the needed version. But otherwise I think what I wrote above is generally accurate.
Here you can see the scijava-config log4j and logback configuration files.
I'm not necessarily suggesting you do things that way—just telling you because you asked. ;-) I hope the standard LogService of SJC is enough for you, actually.
@fjug And just to stress one more time: do not ever write e.g. new YadaYadaService(...) and use it. Defeats the point of the application context's plugin model. Just ask the context for the service in question, e.g. context.service(LogService.class). If you need a custom LogService implementation, write @Plugin(type = Service.class, priority = Priority.HIGH_PRIORITY) on top of yours and include it on the classpath. If there is some reason doing that is not good enough for your use case, I am very interested in hearing more about it.