Thanks, Curtis, I'll take a look at the different strategies. Picking
and choosing .jars is probably not so bad. Hopefully I can exclude a
couple key ones and everything will work.
On 12/14/2012 4:25 PM, Curtis Rueden wrote:
Hi Lee,
> how should I start ImageJ headless
It sounds like you want a full-featured ImageJ context with all
available services except for maybe a couple of them (the ones that
touch AWT).
The easiest way to ensure your ImageJ context is headless is to
exclude problematic JARs from your distribution completely.
Specifically: do not include ij-legacy or any of the ij-ui-* UI
implementations (e.g., ij-ui-swing).
Then you can create an ImageJ context simply with "new
imagej.ImageJ()" (note that this invocation changed a couple of days
ago from the previous static "imagej.ImageJ.createContext()" but it is
otherwise the same).
If for some reason you need or want to include those problematic JARs
in your classpath, you can still avoid the ImageJ context including
them by passing an explicit list of services to the ImageJ
constructor. Or, if you would rather approach it from an "exclusion"
rather than "inclusion" standpoint, you could do something like:
final PluginIndex pluginIndex = new PluginIndex();
pluginIndex.discover();
final List<PluginInfo<Service>> services
= pluginIndex.getPlugins(Service.class);
And then cherry-picking everything from the list that doesn't violate
your exclusion rules.
For that latter approach though, we should probably provide some
helper routine somewhere to make this easier; if you take a look at
ServiceHelper#findServiceClasses, you'll see the code, but it's
currently private. We could make that a public static utility method
for you instead. Or provide something even higher level.
> how headless is headless?
Ideally, we want headless to truly mean no usage of AWT whatsoever.
That said, we do violate that rule in one big place right now: the
ThreadService. The DefaultThreadService uses java.awt.EventQueue to
queue and invoke operations. With a normal JVM with
java.awt.headless=true, this is unlikely to cause problems. But if it
does for some reason, you could provide your own ThreadService
implementation with a higher priority than that of
DefaultThreadService, and the ImageJ service loader will automagically
use it instead.
Regards,
Curtis
On Fri, Dec 14, 2012 at 3:09 PM, Lee Kamentsky
<[email protected] <mailto:[email protected]>> wrote:
Hi all,
I'm getting pretty far along with the CellProfiler integration and I'm
at the point where I'd like to get a headless ImageJ context. My first
guess was that I should call imagej.ImageJ.createContext() with a list
containing only the ConsoleService. The list (see below) has most of
what I want (module service, command service, dataset service, display
service), but is missing a few others (overlay service and scripting
service). I've been running ImageJ with the DefaultUIService while
running CellProfiler with a UI and it seems to operate pretty
smoothly -
some error messages when it can't find viewers for displays, but
otherwise without any apparent UI interaction.
So my first question is how should I start ImageJ headless and my
second
question is "how headless is headless?" (will it ever touch AWT?
Will it
exclude the legacy layer?).
Created service: imagej.thread.DefaultThreadService
Created service: imagej.event.DefaultEventService
Created service: imagej.plugin.DefaultPluginService
Created service: imagej.module.DefaultModuleService
Created service: imagej.command.DefaultCommandService
Created service: imagej.options.DefaultOptionsService
Created service: imagej.event.DefaultStatusService
Created service: imagej.object.DefaultObjectService
Created service: imagej.data.DefaultDatasetService
Created service: imagej.io.DefaultIOService
Created service: imagej.display.DefaultDisplayService
_______________________________________________
ImageJ-devel mailing list
[email protected] <mailto:[email protected]>
http://imagej.net/mailman/listinfo/imagej-devel
_______________________________________________
ImageJ-devel mailing list
[email protected]
http://imagej.net/mailman/listinfo/imagej-devel
