|AdapterManager with multiple adapters for the same adapter type [message #539228]
||Thu, 10 June 2010 00:56
| Greg Babcock
Registered: July 2009
My application performs multiple types of analysis for which I need to |
provide a common charting service. Each of the analysis types being
performed have their own data model, so I created an adapter factory for
each data model (each analysis type resides in a different plug-in), and
registered them with the platform adapter manager. The problem is that the
first adaptor factory retrieved is being used instead of chaining the
adapter factories to find one that will produce an adapter for the input
This seems like it would be a common problem, is there a recommended way to
|Re: AdapterManager with multiple adapters for the same adapter type [message #539591 is a reply to message #539419]
||Fri, 11 June 2010 09:13
| Paul Webster
Registered: July 2009
Greg Babcock wrote:|
> Thanks for your reply confirming what I was experiencing.
> I think this is a major flaw in the platform adapter manager design which
> makes it useless for me because it enables a situation where one pluging can
> break another plugin. Hopefully E4 with dependency injection will provide a
> better (safer) solution.
I think it'll just be the same. The e4 solution will still be based on
the standard eclipse pattern:
1) instanceof TargetType -> return obj
2) instanceof IAdaptable -> return ((IAdaptable)obj).getAdapter(TargetType)
3) return adapterManager.getAdapter(TargetType)
(the core expression pattern is light #1 followed by #3)
If the object implements IAdaptable, it gets to decide the priority of
solutions (as it were).
But in an open-ended contribution based system, one entry can always
clobber another. There isn't a general solution, although different
ones are used in parts of Eclipse based on complexity vs predictability.
By default, Extensions are return from the IExtensionRegistry in a
non-determanistic order. Kind of a "let the system decide" option.
This is not generally a good option.
Different Example: actions tend to sort contributions by plugin id.
Then first one in wins. good: predictability. bad: priority based on
bundle ID collation :-)
Different Example: a comparator extension was recently added, to allow
the product to decide how to sort the preference nodes in the
preferences dialog tray. Delegating to the product provides it with
control ... and significant complexity.
In general, the product can exclude plugins that clobber important stuff
.... except that doesn't always work, as the plugins (like JDT) probably
need to work in Eclipse and work in a product, and if you need JDT in
your product you're stuck with it.
I'm not sure how the adapter manager decides which factory is the winner
for MyType -> TargetType, but it obviously picks one.
Powered by FUDForum
. Page generated in 0.01831 seconds