Community
Participate
Working Groups
The icons added to the registry view for bug 210971 don't refresh after the user has triggered the disable/enable event. This leaves the UI displaying stale information to the users.
I believe we may be limited by the runtime here? I don't remember, may Tom can answer. I do agree the UI can be cleaner here.
It would be nice to listen to the runtime for changes. But if we can't, we should be refreshing the icons when the user runs our disable/enable action.
You could be a BundleListener and listen to UNRESOLVED events. If the bundle becomes unresolved and it has a DisabledInfo object associated with it then you could trigger the disabled icon. Similarly you could listen for RESOLVED events to know that a bundle got enabled.
I was looking into this and just to clarify: what's described by Tom is already implemented. if there's any BundleListener event from bundle that has changed its Enabled state, icon will be refreshed. But simple Disable/Enable (or console "disableBundle"/"enableBundle") doesn't trigger BundleListener.
Disabling a bundle does not force the bundle to become UNRESOLVED synchronously. You must perform a refresh operation on the bundle (using PackageAdmin.refreshPackages method or the "refresh" command at the console). Only then will the UNRESOLVED event be fired. At that point PDE can determine why the bundle became unresolved. Chris's comment 1 is correct in that we do not actually fire any event on each individual enable/disable call. We want to avoid adding another event bus for that. Currently the best thing you can do is listen to the BundleEvents RESOLVED/UNRESOLVED to update the results of being enabled/disabled when refreshPackages is called.
100% agree with you Tom, it just took me 1h to figure out earlier what's the status of this bug, so I added clarification. so what could we do to fix this bug? What about Registry polling from time to time with refresh call? (yes, nobody likes polling:P) Or maybe Equinox should provide higher verbosity for advanced clients like PDE? Not sure if it's worth it. But assuming disable/enable mechanism is used in security, how security concerned components are notified that something has just got disabled?
I don't think a poll is needed. Maybe an explicit refreshPackages call when we go ahead and disable/enable bundles... that should trigger things properly I think.
(In reply to comment #7) > I don't think a poll is needed. Maybe an explicit refreshPackages call when we > go ahead and disable/enable bundles... that should trigger things properly I > think. that would assume we're only client. If someone else does disable/enable then we're dead :P
I agree with Chris, if we handle the case where we enable/disable bundles then we cover 95% of the scenarios. It would be great to make it work when the user disabled something from the command line, but this is not required and if it takes a lot of time, is not worth it.
cool, I like simple patches :P
Created attachment 87315 [details] patch patch
Danke!!!
nice and simple, thanks Jacek :)
Verified on I20080204-0010
