LU> To be more explicit, this is the example that should fail: LU> <ez:loginPanel id="loginPanel" model="#{bean}"> LU> <f:actionListener for="loginEvent" LU> binding="#{bean.loginEventListener}" /> LU> <f:actionListener for="loginEvent" LU> binding="#{bean.loginEventListener2}" /> LU> <f:actionListener for="cancelEvent" LU> binding="#{bean.cancelEventListener}" /> LU> </ez:loginPanel> LU> <composite:interface name="loginPanel"> LU> <composite:actionSource name="loginEvent" /> LU> <composite:actionSource name="cancelEvent" /> LU> </composite:interface> LU> <composite:implementation> LU> <h:commandButton name="button1"> LU> <f:actionListener LU> binding="#{cc.actionSource.loginEvent}"/> LU> </h:commandButton> LU> <x:mycompositecomponent name="button2"> LU> <f:actionListener LU> binding="#{cc.actionSource.cancelEvent}" for="someOtherEvent"/> LU> </x:mycompositecomponent> LU> </composite:implementation> LU> In this case, the binding #{cc.actionSource.loginEvent} does not LU> point to just one actionListener. GP> Leo, IMO your example wouldn't need to fail: the nested GP> actionListener with binding="#{cc.actionSource.loginEvent}" would GP> need to execute *all* actionListeners that have been bound to GP> "loginEvent". In this case "#{bean.loginEventListener}" and GP> "#{bean.loginEventListener2}" would reside in a Map named GP> cc.actionSource.loginEvent and could both be executed. Wouldn't this GP> work? EB> The type of the binding attribute is specified thus. EB> Value binding expression that evaluates to an object that implements EB> javax.faces.event.ActionListener EB> How would you make that handle a list? EB> Sure, we could go and add a raft of new "bindingList" attributes to all EB> of the attached object handlers in f:, but is it worth the complexity? MM> Hi Gentlemen, MM> I am leaning toward Jakob's approach, but if it is not possible due to MM> the constraints Leonardo mentioned, then why not add the necessary MM> tags? MM> @Leonardo, Jakob: can you put your heads together and come up with a MM> combined proposal? Please do so on this new issue I've created [1]. We will not be able to put this into 2.1. I'm afraid we'll have to live with only targets for 2.1. This will have to go into 2.2. Ed [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=901 -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 8 work days until German Oracle User's Group Conference