Limited Context tries to instantiate invalid plugins

[dietzc]

When loading TIFF files using the standard SCIFIO Context (which does not include ImageJ services), SCIFIO needs the list of Codec objects, which triggers a call to ObjectIndex.get(Codec.class), which attempts to resolve all pending objects. More specifically, in our setting this includes all net.imagej.tool.Tool plugins, many of which rely on ImageJ-specific services not present in a SCIFIO-only Context.

[ctrueden]

PR #91 addresses the too-zealous resolution of all the pending objects. With the changes there, known-incompatible pending objects will be skipped. So the problem with the Tool plugins all getting loaded should hopefully disappear in this case.

However, in general, there are still two problems. Suppose you want to use the ToolService with your Whizzbang application, and you write several Whizzbang tool plugins. Suppose further that you also have ImageJ on the classpath. Then you create a new Context with Whizzbang services but not ImageJ ones.

1. When the ToolService is first queried (i.e., getInstances() is called), you will still receive a bunch of log messages at ERROR level about invalid tool plugins from ImageJ. The ToolService should work, but these messages are annoying.
2. If you query ToolService#getPlugins() you'll get back a List<PluginInfo<Tool>> that includes tool plugins which cannot actually be successfully instantiated in that Context because they rely on missing services.

Both of these problems could be avoided if we were smarter about the metadata we cache for plugins. @dscho's idea is to make the SciJava plugin indexer also cache the list of parameters, so that we can interrogate each PluginInfo at runtime to determine which services it needs without needing to load its associated Java class. Then the PTService abstract class layers could filter the list of PluginInfo objects to include only those valid with respect to the current context.

However, we are not anxious to make such changes. It would be quite a lot of work for arguable gain, since PR #91 addresses the major use case right now. If we find ourselves in a situation where this becomes relevant again, we can pursue the work further then.

[dietzc]

Sounds great. Thank you very much for the quick help. Let me know if I can provide a test-case or help you somehow.

Christian