NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #1444 (closed defect: wontfix)

Opened 2012-08-28T16:06:11-05:00

Last modified 2012-08-28T17:07:46-05:00

Plugin field values do not always resolve correctly

Reported by: bdezonia Owned by: curtis
Priority: minor Milestone: imagej-2.0.0
Component: Core Version:
Severity: serious Keywords:
Cc: Blocked By:


If you do code like this:

FindEdges edgeFinder = new FindEdges();

the edges are enhanced in the current display and not in someOtherDisplay. This is because the resolved status of the input variable is not marked as so when using setDisplay(). Thus the plugin preprocessors run and think the display variable is unresolved and sets it to the current display.

We need to detect a way to determine that resolved is true for an instance variable. Perhaps each setter implementation could handle it. Or else maybe instance fields that are null are considered unresolved but others are not. Curtis has ideas here.

Change History

comment:1 Changed 2012-08-28T16:15:40-05:00 by curtis

  • Priority changed from major to minor
  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0

This ticket was spawned from work on ticket #1443. To repeat my comment from there:

Setting the Display parameter manually will not flag the parameter as "resolved" so the preprocessors will still try to populate it. I'm not sure of the best way around this. One option might be to skip certain plugin preprocessing when running plugins this way, but that would require further thought to get right.

It will not work to look for null fields. Some plugins will initialize the field with a default value, but still expect it to get overridden in many cases.

Really, I do not have any good ideas on how to make this approach work. One mediocre idea might be to do *no* pre- or post-processing whatsoever, but that comes with its own lack of convenience.

There are already so many ways to run a plugin that *do* work, so I am not sure this ticket is worth worrying about.

comment:2 Changed 2012-08-28T17:07:46-05:00 by curtis

  • Status changed from new to closed
  • Resolution set to wontfix

After a discussion between bdezonia, dscho and myself, we decided not to bend over backwards to support a fully compile-time-safe approach to "mixing and matching" plugin execution. We will remove the ability for PluginService to execute an existing plugin instance. If you want to execute a plugin instance directly, you can use the "pure Java" approach of instantiating it yourself, populating all its fields by calling setters, then calling run() yourself too. Of course, this assumes the plugin has been written to have setters and/or constructor arguments for all its parameters.