This appears to be caused by an earlier revision 29289... committed by Mark with this comment: ICE-8180 : ace:ajax - PropertyNotFoundException thrown.

Also note that these issues can be reproduced with the showcase sample app., using the ace:panel Listener demo, or ace:dateTimeEntry Ajax submit demos.

The old code tried to make a MethodExpression that took the specific type of event that was currently in play, like DateSelectEvent, whereas I made it always look for the super-class AjaxBehaviorEvent. The matching code is likely exact and doesn't care about inheritance. I'll need to see if I can walk the options to find the applicable match.

Our eventing seems to fall into two categories:

1. FacesEvent sub-classes that have a static relationship to a component's method expression property. That is, for a given component, like TabSet, it will have a MethodExpression property called tabChangeListener that will always involve a ValueChangeEvent and no other type of event.

2. AjaxBehaviorEvent sub-classes that have a tenuously / indirectly static relationship. They are broadcast from ace:ajax's listener MethodExpression property, which could have to deal with one of four existing types: CloseEvent, DateSelectEvent, DateTextChangeEvent, ToggleEvent. But, when the ace:ajax component is within a certain parent UIComponent, and with a certain event name, then the event type is known. For example, when the parent is DateTimeEntry, then DateTimeMeta gives us:

@ClientBehaviorHolder(events =

, defaultEvent="dateSelect")
public class DateTimeEntryMeta extends UIInputMeta {

From knowing the parent component, there exists the information that there are two event names: dateSelect and dateTextChange, and without a name the default is dateSelect. Since DateTimeEntryBase is a ClientBehaviorHolder, we can get that info from: Collection<String> getEventNames() and String getDefaultEventName().

What is missing from this is any explicit mapping of: "dateSelect" -> DateSelectEvent, "dateTextChange" -> DateTextChangeEvent.

To be confusing this example is with ace:dataTable and not ace:dateTimeEntry as above. Here's the flow of execution, showing that in AjaxBehaviorHandler.apply we get access to the parent component DataTable, and so can query all that event information off of it before the MethodExpression setting code is run:

AjaxBehaviorHandler.ctor() BehaviorConfig.getBehaviorId: org.icefaces.ace.component.AjaxBehavior
AjaxBehaviorHandler.apply() BEFORE super parent: org.icefaces.ace.component.datatable.DataTable@2c10d16b
AjaxBehaviorHandler.setAttributes() BEFORE super instance: org.icefaces.ace.component.ajax.AjaxBehavior@424de67
AjaxBehaviorHandler.createMetaRuleset() type: class org.icefaces.ace.component.ajax.AjaxBehavior
MethodExpressionMetadata.setMethodExpressionIntoMethod() instance: org.icefaces.ace.component.ajax.AjaxBehavior@424de67
MethodExpressionMetadata.setMethodExpressionIntoMethod() instance.class: org.icefaces.ace.component.ajax.AjaxBehavior
MethodExpressionMetadata.setMethodExpressionIntoMethod() instance: org.icefaces.ace.component.ajax.AjaxBehavior@424de67
MethodExpressionMetadata.setMethodExpressionIntoMethod() instance.class: org.icefaces.ace.component.ajax.AjaxBehavior
AjaxBehaviorHandler.setAttributes() AFTER super instance: org.icefaces.ace.component.ajax.AjaxBehavior@424de67
AjaxBehaviorHandler.apply() AFTER super parent: org.icefaces.ace.component.datatable.DataTable@2c10d16b

So, here are the three fixes, with the best and most involved first, progressing to more temporary hacks for the deadline:

1. Make the generator and Meta changes so that @ClientEvent will declare what event it uses. Remember, the ace:ajax listener doesn't always get a custom event, it typically just gets a raw AjaxBehaviorEvent, so that would make a sane default value when the new annotation field is not specified. Modify AjaxBehaviorHandler.apply to get the event type using the newly augmented facilities.

2. Without any generator or Meta changes, we can extrapolate a rule in AjaxBehaviorHandler.apply where we derive the event class name from the event name, and if it exists, and is a sub-class of AjaxBehaviorEvent, then use that. This would enable third party components to maybe work too, if their event names follow the convention. Although it would had-code the package as being: org.icefaces.ace.event

3. There are only four special cases, so we can just hard-code them, and forget any third party components for this release, since we'll do the generator fix anyway. Why introduce a convention that we won't keep anyway.

Regression tests show a single remaining failure:

Icefaces3.0 trunk revision# 29399
Server: tomcat6
Browser: FF3.6, IE8, GoogleChrome19

New failures: All browsers: notificationPanel (When trying to close a notificationPanel that's using the ace:ajax event 'close' there is a an exception in the server log)

WARNING: /notificationPanelAjax.xhtml @55,77 listener="$

": Method not found: org.icefaces.notificationPanel.AjaxTestBean@13f5a2f.ajaxEventListener()
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:109)
at org.icefaces.ace.component.ajax.AjaxBehavior.broadcast(AjaxBehavior.java:178)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:760)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
at java.lang.Thread.run(Thread.java:619)

To reproduce:
1. Build / deploy test app located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/notificationPanel
2. Navigate to /notificationPanelAjax.jsf
3. Follow the instructions on the page for the 'close' event test
Exception is seen in the logs.

NotificationPanel uses event names: close, display. Unlike Dialog, which also has a close event, NotificationPanel does not substitute the AjaxBehaviorEvent with a CloseEvent, but rather just uses the original AjaxBehaviorEvent. The original #2 algorithm didn't cover that possibility, it assumed that if there existed the event object corresponding to the event name, that it would be the event object in use.

Note that it is interesting that the failure doesn't occur on tomcat7, where the newer EL library is included, but does on tomcat 6 where we deploy our own.
Newer EL might be smart enough to know that if we're trying to pass a sub-class object into a method with a super-class arg, that it can coerce it

Adjusted the code to add yet another fallback MethodExpression, so that it will try first to use the calculated event object as the parameter, then try the no-arg MethodExpression, and then, if the calculated event object was not AjaxBehaviorEvent, try a MethodExpression with an AjaxBehaviorEvent as the parameter. The last method expression that throws a MethodNotFoundException, will end up continuing to throw it.

trunk
Subversion 29405

Need to state save the new field added in the last commit.

This jira was intended for solving the regressions caused by ICE-8180, and so was a fine tuning of that approach. 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.