Attached test case that shows issue.

Steps:

• Load welcomeICEfaces.jsf
• Select the row in the table, error is thrown.

I've discovered a workaround. I was also unable to reproduce this issue in the showcase.

I'm attempting to distill this issue into a pure JSF case as I believe the failure here is a scoping issue between ui:include and EL evaluation.

Converting the test case to use h:dataTable and h:commandButton with a 'backingBean' method expression actionListener causes the same error.

This is a framework JSF deficiency or bug depending on how you think EL scope in ui:includes should be handled.

Adding the ui:param to the global f:metadata region resolves this issue but with the same caveats as the existing workaround, that the parameter must be defined globally.

At first I thought it was a matter of syntax, so Arran tested using listener="#

" but that didn't work because I had confised rowSelectListener for another ui:param, but really is was the method name, so he tried listener="#

"
   listener="#

"
   listener="#

"

The direct bean references worked, but not the indirect ones.

I looked in the code and there's a bit where the exception is coming from, in AjaxBehavior.broadcast, where it first tries a no-arg method expression invocation, and then constructs a new one on the fly to take the argument. I distrusted the construction code, so changed it so that the AjaxBehaviorHandler would just wire up the one with an argument, and broadcast would just call it, and then we made that app take that argument, and it started working, with the indirect syntax.

So, the technical hurdle will be to find a way of supporting no argument and the event argument on the ace:ajax listener, without doing the method expression creation that doesn't seem to work.

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.