I filed it as an enhancement a long time ago. Ill try to find it if it matters. Lincoln Baxter III http://ocpsoft.com http://scrumshark.com Keep it simple. On Nov 17, 2009 3:29 PM, "Jim Driscoll" <Jim.Driscoll(a)sun.com&gt; wrote: Sorry be be hard-nosed about this, but... This isn't really the place to discuss implementation bugs. Rather, if you have specific concerns about the specification, they should be discussed here. That would typically imply that you would refer to an area of the spec when reporting such bugs. We're going to have to start enforcing this rule vigorously if we open this list up more to the public, or else we're going to end up getting swamped in "my component doesn't work" emails, and we'll be unable to get anything else done. That said, your mail brings up a few gaps in the specification, though you don't refer explicitly to the spec. Spec bug 1: There is no defined way to specify an arbitrary method to be called server-side on the execution of a jsf.ajax.request function call. This is an oversight in the spec, and it should be addressed for 2.1. In the meantime, you can get *almost* equivalent functionality by using a valueChange listener or an action listener in most cases. I've filed spec bug 672 to track this issue. This isn't the first time it's come up, but no one bothered to file it last time, apparently - I thought they had. https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=672 The workaround you tried, adding the listener then calling the request manually, is just that, a workaround, that had never (that I know of) been tried before we released - so it's not surprising to me that it ran into trouble of various sorts. The behavior you found is probably a bug (but possibly not, I'll have to code trace and look at the spec to be sure), please file it against the implementation, and I'll take a look when I have time. Setting the javax.faces.behavior.event parameter to action should happen automatically for buttons - but that's an implementation specific detail at this point - it's not in the spec. And as such, you *really* shouldn't be talking about it in a book about standard JSF practice. I'd much rather you encourage end users to use action listeners and valuechange listeners, for which I have a number of demos. The functionality is roughly equivalent, though they'll still function if JavaScript is also disabled in the page - which I'd regard as a feature, rather than a drawback (and which is why it's probably better practice to do it that way for most uses). Where this turns a little silly, of course, is in the case that you're trying - a disconnected request that attempts to run an arbitrary method. But even that has a simple (if inelegant) workaround - a hidden button. I wrote a demo that does poll, and is in the Mojarra samples - did you look at it? It uses that hidden button mechanism to get around the same problem you're encountering. It doesn't cancel, but that's trivial to add. Doing it your proposed way, by registering an ajax listener, is also fraught for another reason that I don't think you've yet considered: event names. The javax.faces.behavior.event parameter is not part of the spec. So, if you want to trigger it for something besides "action", you can't. Even when (if) I do fix the above bug. And, as I said, allowing arbitrary method calls from jsf.ajax.request is something that really should be in 2.1. And it will probably mean setting the "unintuitive" javax.faces.behavior.event parameter, unless someone can come up with a more elegant way. Hopefully, someone will. Your second reported bug is almost certainly an implementation bug. Please file it - as I said, this isn't the place to discuss implementation bugs. We often discuss implementation bugs on webtier(a)glassfish.dev.java.net, if you'd like to subscribe. I'm running a little behind on there (we're doing a release right now), but we have a pretty good answer rate. Again, I'm sorry to come off as not caring about this - I care very much about every bug we find. But I know from past experience that if we let the discussion deviate from the charter of this list, It Won't End Well. Jim P.S. Ken - the suggestion to cancel an in process request is one that I used to favor as well, but that brings up data integrity and consistency issues that are better handled server side. So I'm now reluctantly against allowing that (at least the simple case - though canceling a request that hasn't yet begun would be something that I'd like to support). But still, if you would like to see this in 2.1, please file a spec feature request. On 11/17/09 8:21 AM, David Geary wrote: