Community
Participate
Working Groups
Currently IExtensionDelta indicates which IExtension and IExtensionPoint are being affected by the modification and whether the modification is an addition or removal. It would be very convenient to know specifically which of the two (IExtension vs IExtensionPoint) are actually being modified. Consider a registry with one extension point and one contributing extension. Removing either the extension or the extension point will fire an event with some IExtensionDelta. Looking at the delta there is no way of telling if its the extension or the extension point which is being removed.
Moving out of NEW inbox. Thoughts on this? Is it needed? Are there scenarios where the extension needs to know that its extension point is going away? I think the typical case is the extension point needing to listen for when extensions come and go. In this case an extension point does not care if it has gone away because it no longer exists. On a side note, what does the registry do to listeners from a bundle that becomes unresolved? I think it must flush such listeners from the listener list.
cc'ing Pascal for comment.
(In reply to comment #1) > On a side note, what does the registry do to listeners from a bundle that > becomes unresolved? I think it must flush such listeners from the listener > list. > You should look at the org.eclipse.osgi.framework.eventmgr package. It is design to manage listener list in the face of bundle removal.
>On a side note, what does the registry do to listeners from a bundle that >becomes unresolved? I think it must flush such listeners from the listener >list. What you are suggesting here is that non active bundles can have registered some listeners. This is not something we usually encounter in eclipse since most bundles are automatically starting and stopping and doing listener registration on those operations. That said it is still interesting. BJ could you please detail more on how this package would help? Maybe even provide a patch.
Janek, Sorry for highjacking this bug. I opened bug 135863 to discuss handling proper listener cleanup. Anyone have thoughts on my other comments in comment 1? Do we need more information on IExtensionDelta?
Yes, I agree with Janek that such functionality is needed. It is not very interesting in the traditional scenario where lifecycle of extension/extension points is determined by the contributing bundle, but it makes a lot of sense for dynamic contributions. I think that this is something we should adress in 3.3.
marking for 3.3
Hi again and thanks for your feedback, the reason I opened up this defect is because of recent cleanup/migration of the Registry View. We planned on having a fully dynamic view that would update to any changes detected in the registry. This specific piece of information is required for the view to be correctly updated when an extension / extension-point is removed.
Hello again, PDE has no problem leaving this for 3.3 (especially since we are so late in the development cycle). Unblocking - we will workaround on our end. Thanks
Any plans for this to be addressed in 3.4?
Yes, the intent is to have this fixed in 3.4.
Good to hear. Additionally, I have a quick question: My IRegistryChangeListener gets notified upon Extension addition/removal, is it possible to also receive notifications for any changes to Extension Points. (If I have an extenion point with no extensions and I add it/remove it during runtime, no notifications get fired).
If that is still the case, yes, most certainly. There is a fix for a similar problem (in that case for extensions with no configuration elements) done in the bug 178028.
The original listener mechanism was not designed to propagate changes to extension points. As a part of more generic solution in the bug 206936 an IRegistryEventListener has been added to track modifications to extensions and extension points. *** This bug has been marked as a duplicate of bug 206936 ***
