Investigation of the two types of MethodExpression objects, the original and the copy, showed that the original was a com.sun.faces.facelets.el.TagMethodExpression, and the copy was a org.apache.el.MethodExpressionImpl. There wasn't anything in TagMethodExpression to explain a difference of EL evaluation. But, searching though the Mojarra source code found that the entire MethodExpression construction chain was full of composite component handling code and retargeting code, mostly in com.sun.* classes. I investigated all throughout the chain, but there didn't seem to be a way to replicate the handling within AjaxBehavior.

The next approach taken was to use our AjaxBehaviorHandler as a hook into the process where the listener TagAttribute is processed and eventually results in the TagMethodExpression being set into the listener property on AjaxBehavior. There seemed to be a very 1:1 mapping between the two, but eventually I untangled that MetaRule objects are used to create Metadata objects, which can do arbitrary tasks on the UIComponent, and that our MethodRule code contains both, and in altering it, I could create a 1:2 mapping between the one TagAttribute and two properties for the MethodExpressions, so that instead of trying to carbon copy the MethodExpression later, we could instead have two originals, one for the argument and one for the no-argument, and all the regular Facelets/JSF processing would happen on both, so they would both be setup for working with composite components.

Now ace:ajax will try to invoke the bean method that takes the event, and if it can't find it, then it will fall back to invoking a no-argument version of that method.

In theory, we could alter other components, or the generator, to allow for our other listeners to use this one or no argument signature, to allow for applications to be more POJO.

trunk
Subversion 29289

The test application should be able to have javax.faces.event.AjaxBehaviorEvent or no argument to its row selection method.

Issue is now seen again when a composite component is on the page. This is a similar situation as what is found in ICE-8221

Attached new test case that shows the latest issue with the composite component.

This caused regressions, which were addressed in ICE-8223. But ultimately this type of solution was superseded by ICE-8258, since when the full application scenario from ICE-8221 was tested against, this solution was insufficient, and ICE-8258 was needed.