Community
Participate
Working Groups
As IU's are installed, uninstalled, or updated in a profile, should there be events that let interested parties know about it, akin to workspace change notification events? Right now I have to handle this within the UI code (for example, if an install action is chosen in a metadata repository view, the profile view needs to update to show that the new IU is there). Any other changes made outside of the UI won't be known without a manual refresh of the view. This may be "just fine" but alternate UI's might want some kind of notification that something was installed...for example, show an async bubble letting the user know that their profile was updated, etc. etc...
The agent has an event bus (ProvisioningEventBus) on which you should be able to find what you are interested in. For example you may be interested in the CommitOperationEvent that indicates the success of an operation (install/uninstall). Note that we may need additional events since you may want to be guaranteed to be notified once everyone has committed. There is also a ProfileEvent that notify about the addition and removal of profiles.
thanks for the pointer, not sure how I missed it. Changed title of bug so we can track comments on the API here. I think an untyped event mechanism is fine, but I'm used to there being a retrievable event type defined in the basic event class, rather than clients having to use instanceof checks to determine the type of event. I suggest a common provisioning event superclass that would contain a type (int) field with constants defined for type of event. The listener interface would be typed to the common superclass rather than EventObject (which makes it hard to go looking for which types of events are supported) Another performance consideration would be to register for only certain types of events rather than receive them all.
Also see bug 184021 we should consider reusing Event Admin instead of implementing a new event bus if possible.
It would be nice to have notification events for repository adding/removal. As it is now, I have to manufacture my own events based on the assumption that everyone goes through my wrapper util API to add and remove repos.
I have added temporary classes on the UI side so that the UI code can register for events it is interested in that are not supported by the underlying event bus. So if you want to see what kinds of events the UI needs that are not supported, see IProvisioningProperties.
remaining issues are covered in the duplicate bug *** This bug has been marked as a duplicate of bug 199806 ***
