IceClientBehaviorHolder is the interface that our ACE components implement when they have behavior events. Their Meta classes have a ClientBehaviorHolder annotation, with ClientEvent annotations per event. The ACE generator generates Base classes that implement IceClientBehaviorHolder with all the annotated events.

When ace:ajax is nested within an ACE component, it needs to wire up its listener property so that it can invoke a MethodExpression in the bean that takes the appropriate event type. This requires knowing the appropriate javax.faces.event.AjaxBehaviorEvent sub-class that the ACE component will queue and broadcast. Or it might just be a plain AjaxBehaviorEvent itself, and not a sub-class.

In AjaxBehaviorHandler.deriveEventClass(-) we attempt to derive which Class of event that the IceClientBehaviorHolder will use, by taking advantage of the fact that we happen to name our events after the event name, and that we can use reflection to test if that guess happens to be true, or if we should fall back to assuming it's a plain AjaxBehaviorEvent. This has the downside of using the hard-coded ACE component package that our events are in, and relies on our conventions, which won't necessarily work well for third parties making use of ACEnvironment for their own components.

It would be better to augment the ClientEvent annotation, ACE generator, and IceClientBehaviorHolder interface, to allow for explicit declaration of the event type. It would also be more declarative and clearer, since if it's not mentioned in the TLDDOC, then auditing the component code is currently the only way of knowing the relevant event type that a bean should use as the argument type in its MethodExpression.