UIComponent event-listening APIs are inconsistent #997
Comments
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented This is due to the fact that we call SystemEvent.processListener() from ComponentSystemEvent.processListenerwhich is now trying to cast to a SystemEventListener(). The issue is that ComponentSystemEventLIstener and SystemEventListener are peers. This is unlike ComponentSystemEvent which is a SystemEvent in the hierarchy. |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
UIComponent defines the pair of:
void subscribeToEvent(Class<? extends SystemEvent>, ComponentSystemEventListener)
void unsubscribeFromEvent(Class<? extends SystemEvent>, ComponentSystemEventListener)
The rationale given for ComponentSystemEventListener is that, being installed on a specific component, there is no need for an instance to implement the full-blown SystemEventListener interface. It was not desired that ComponentSystemEventListener be an abstract class itself implementing SystemEventListener presumably because (a) that would force a listener into a particular inheritance hierarchy and (b) in order to narrow the argument accepted for .processEvent(), would most likely have necessitated the introduction of generics into the SystemEventListener taxonomy. The point at which the inconsistency arises is when UIComponent defines:
List getListenersForEventClass(Class<? extends SystemEvent>)
Ignoring the contrived possibility that all ComponentSystemEventListeners installed on a given UIComponent also implement SystemEventListener, the getListeners... method is meaningless and cannot return the objects registered via subscribeToEvent().
Affected Versions
[2.2 Sprint 8]
The text was updated successfully, but these errors were encountered: