Ticket #1641 (closed defect: wontfix)

Note that I discovered this issue by converting NewImage plugin to a DynamicCommand from a ContextCommand. The code in InvokeCommandTest had to be recompiled and after the change running the plugin would cause a NPE. I hacked the initialization code in NewImage to avoid this case (and documented well what was being done). If we fix this bug in a general way we should cleanup NewImage a little and make sure to test that InvokeCommandTest works.

The real difficulty is that InitPreprocessor is not the only desirable preprocessor that someone may want to execute on their command, prior to running it. In particular, many initialization methods require other parameters to have been populated earlier in the chain: Services in particular, but also Datasets, DatasetViews and ImageDisplays, via the ActiveDisplayPreprocessor and ActiveImagePreprocessor. There is also a UIPreprocessor that populates UserInterface inputs, and other similar preprocessors could exist for other sorts of inputs—ImageJ2's extensibility makes this very possible.

Intuitively, it seems to me that a suitable subset of the preprocessors need to be flagged somehow for execution in the programmatic context. In other words, we should get rid of the hack in ContextCommand#setContext(ImageJ) which calls CommandService#populateServices(ContextCommand), and instead have a CommandService#selectivePreprocess or some such, that applies only those preprocessors matching the suitability criteria. This could be as simple as a boolean flag of the @Plugin annotation, or we could have some other way of deciding.

Another issue is whether such preprocessing should fire any events. Our current approach with populating the services is not to do so, but it seems strange to apply an extensible set of suitable preprocessors without telling anyone about it.

Thoughts?

Note that InvokeCommandTest has been removed in favor of an ImageJ tutorial showing how to execute commands (which now uses OpenFile for simplicity and to avoid this issue). However, this issue still needs to be fixed.

A  recent thread on imagej-devel touched on many related issues, including the initialization of modules. We concluded that for use cases where the pre- and post-processing steps are omitted, it is the responsibility of the caller to call initialize manually before executing the module. This greatly simplifies matters, because I see no general way of ensuring that initialize gets called by the module framework when the framework itself is being largely bypassed.