Eclipse Community Forums: Equinox » Issue Related To IExtensionRegistry addContribution

Help

Home

Home » Eclipse Projects » Equinox » Issue Related To IExtensionRegistry addContribution

Show: Today's Messages :: Show Polls :: Message Navigator

Fri, 13 April 2012 02:31

Rob Hatcherson

Messages: 33
Registered: July 2009
Location: Fort Worth, TX, USA

Member

I'm working on a RCP app and have bumped into a problem related to IExtensionRegistry.addContribution(...args...). I originally posted to the RCP forum, but I think the folks here might also have some insight into this problem. I apologize if this violates a policy of the forums since it's a multi-post.

The IDE version I'm using is Indigo on Fedora 12, and says:

Version: 3.7.2.v20120207-1839-9gF7UHPDFxGjd-PqDr2jX_4yKaumkoHTz04_q-q
Build id: M20120208-0800

As far as I know everything in Eclipse proper is up to date.

The issues are (I'll get to the addContribution part shortly):

1) I have at least one plugin.xml file that makes coolbar contributions, but after the workbench window initially pops up the coolbar remains hidden until the main window is resized horizontally. At that point the coolbar pops in, looks like I expect, and functions normally. This behavior is similar to message www.eclipse.org/forums/index.php/mv/msg/140033/ (sorry, it wouldn't let me make a real link here).

2) That same plugin.xml attempts to make a contribution to the status bar but the contribution never shows up. I set a breakpoint on the contribution's createControl method but it never got hit. So... in this case the contribution seems to be totally ignored.

I'm loading contributions from various plugin.xml files via "interim" public API:

RegistryFactory.getRegistry().addContribution(...args...)

The plugin.xml files being loaded make typical contributions, e.g. views, perspectives, menus/toolbars/etc. Other than the technique being used to load them nothing unusual is going on.

I have an IRegistryEventListener in the loop and it shows the contributions being processed from the plugin.xml, including the status bar contribution that is never realized.

I have at least one other app that loads contributions via the RegistryFactory.getRegistry().addContribution(...args...) method, and its coolbar shows up as soon as the workbench window springs to life though it also exhibits Problem 2) noted above. I'm still looking for what the working app is doing that the broken app might not be doing regarding the coolbar, but so far no revelations.

I've spent a good chunk of the last few days snooping around in TrimContributionManager trying to figure out what's going on, but I am a relative noob on workbench internals and don't yet know what to expect to see at various points as the workbench springs to life. Guidance about what to look for is welcome.

I later discovered that if I made the following call significantly after the workbench window is up (e.g. from a command tied to some menu item) then the status bar contribution is finally created:

someWorkbenchWindow.setPerspectiveBarLocation("topLeft")

I assume this happens because this call triggers a re-layout of the window.

Point being, the contributions are in there somewhere, which we already knew because the IRegistryEventListener showed them being loaded. They just aren't springing to life all the way.

Anybody have any theories about what might be going wrong with contributions loaded through this interim API that would cause either of the problems mentioned above? Limitations, calls I should be making after addContribution() that might be missing, call ordering, etc.?

Report message to a moderator

Mon, 16 April 2012 15:25

Pascal Rapicault

Messages: 333
Registered: July 2009
Location: Ottawa

Senior Member

I'm not quite sure what the root cause of this could be, but from your description I would bet on either a timing issue or a problem in the workbench code that would not listen properly to the extension registry (e.g. it gets all the elements from the registry, and then add the listener, so if your entry is processed between those two events then it could cause the issue).

Report message to a moderator

Thu, 19 April 2012 02:52

Rob Hatcherson

Messages: 33
Registered: July 2009
Location: Fort Worth, TX, USA

Member

Thanks for the feedback Pascal. I had the same thought, though the behavior was so regular that it seemed more like a something-called-at-the-wrong-time thing.

I have since fiddled with this some more and discovered that if I push the RegistryFactory.getRegistry().addContribution(...args...) call closer to the application start rather than further away from it then the problem disappears. I was motivated to do this by noting in the debugger that the /plugin.xml of the app was loaded very early.

The first thing I tried was calling ...addContribution... in the workbench advisor's initialize(IWorkbenchConfigurer) method, but that still didn't work.

However, if I moved the call to the workbench advisor's constructor then the problem cleared up.

So... there appears to be a period of time somewhere between the workbench advisor's constructor and the point where the workbench and associated windows are all the way up where calling ...addContribution... may do unexpected things.

Note that ...addContribution... calls made once the workbench was up all the way also worked as expected.

I don't know if this is a bug or a feature. The naive reaction is that if the workbench has gotten itself together enough that very early contributions work, then any contributions made downstream of that should work too.

Report message to a moderator

Thu, 19 April 2012 15:20

Pascal Rapicault

Messages: 333
Registered: July 2009
Location: Ottawa

Senior Member

You may want to open a bug against the platform UI with a simple app reproducing the problem. Also this may have been fixed in e4.

=-=-=
Pascal
Consulting, training, bug fixing - pascal at rapicault dot net

Report message to a moderator