Bugzilla – Full Text Bug Listing
| Summary: | BundleListener fails to fire any events when a plugin has stopped or uninstalled | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Dilton McGowan II <diltonm> | ||||||
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> | ||||||
| Status: | RESOLVED INVALID | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | tjwatson | ||||||
| Version: | 3.5.2 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 166650 [details]
Reports the events being monitored on PluginUnderControl
Created attachment 166651 [details]
This is the plugin that will be monitored and it can stop itself
The bug is identical on Red Hat 4 Linux. In the controller bundle you add a bundle listener using the controlled bundle's context ... getControlledBundle().getBundleContext().addBundleListener(mBL); The controller bundle should only use its own context to add listeners for. Adding your listener on another context will cause your listener to be automatically removed when the controlled bundle is stopped which will cause you to miss all bundle events after the controlled bundle is stopped. Change the lines to context.addBundleListener(mBL); in the Activator.start method and ... context.removeBundleListener(mBL); in the Activator.stop method, although removing the listener in the stop method is not strictly necessary since the framework will automatically remove the listener when the bundle is stopped anyway. (In reply to comment #4) That was it! I guess it seemed that if I wanted to listen to another plugin that it was logical to attach a listener to it. Thanks for that! |
Build Identifier: M20100211-1343 Hi, I have two plugins A and B. B is set to lazy start. A implements IStartup to guarantee that A moves to an Activated state so it can listen to BundleChange events for B. This works and is verifiable using the OSGi console command "ss". A now creates a BundleListener to listen for B bundle state changes. When I open a view in B, it moves to the Activated state and A gets the BundleEvent in its listener: <snippet> @Override public void bundleChanged(BundleEvent event) { </snippet> When I invoke bundle.stop() in B, A does not get the event. Why is that? I stepped through the stop() code in Eclipse and in this section of code in org.eclipse.osgi.framework.eventmgr.EventManager found that the listenerObject at one point is set to my A plugin. I stepped through for a while and mistakenly stepped out. <snippet> static void dispatchEvent(Set/*<Map.Entry<Object,Object>>*/ listeners, EventDispatcher dispatcher, int eventAction, Object eventObject) { for (Iterator iter = listeners.iterator(); iter.hasNext () { /* iterate over the list of listeners */ Map.Entry listener = (Map.Entry) iter.next(); Object eventListener = listener.getKey(); Object listenerObject = listener.getValue(); try { /* Call the EventDispatcher to complete the delivery of the event. */ dispatcher.dispatchEvent(eventListener, listenerObject, eventAction, eventObject); } catch (Throwable t) { </snippet> Dilton Reproducible: Always Steps to Reproduce: 1. Import the attached projects, PluginUnderControl and PluginController 2. Set up a Run Configuration for org.eclipse.sdk.ide for PluginUnderControl and make sure that PluginController is listed on the Plugins tab 3. Run the Eclipse Platform and both plugins should be available on the Window | Show View tab 4. In the view for PLuginUnderControl, click the StopThisPlugin button 5. Check the console output for the message: "got BundleEvent for the Controlled Plugin:" and see if the reported id's match any expected for a stopped plugin