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: | ||
| Blocking: |
Description
If you do code like this:
FindEdges edgeFinder = new FindEdges();
edgeFinder.setDisplay(someOtherDIsplay);
pluginService.run(edgeFinder);
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
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.
This ticket was spawned from work on ticket #1443. To repeat my comment from there:
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.