Bug? Unable to add ActionListener using Anonymous class.

Question

Hi,
I come accross one strange behaviour while adding ActionListener to RCF component.
I am trying to add the ActionListener in the managed bean using the Anonymous.
We can add the actionListener to a button using following methods. I am talking about the the first case. Only this case is not working. Rest other 2 cases are working properly.
Case 1:
class MyClass {
     RichCommmandButton btnTest = new RichCommmandButton();
     public MyClass(){
          btnTest.addActionListener(new ActionListener(){
               public void processAction(ActionEvent event){
Case 2:
class MyClass implements ActionListener {
     RichCommmandButton btnTest = new RichCommmandButton();
     public void processAction(ActionEvent event){
<af:button binding="#{myClassBean.btnTest}" actionListener="#{myClassBean.processAction}"/>
Case 3:
class MyClass implements ActionListener {
     RichCommmandButton btnTest = new RichCommmandButton();
     public void addActionLister(){
          //Use EL to add processAction(). Create MethodBinding
          FacesContext facesContext = FacesContext.getCurrentInstance();
ELContext elContext = facesContext.getELContext();
ExpressionFactory exprfactory = facesContext.getApplication().getExpressionFactory();
          MethodExpression actionListener =
exprfactory.createMethodExpression(elContext, "#{myClassBean.processAction}", null, new Class[] { ActionEvent.class });
          btnTest.setActionListener(actionListener);
     public void processAction(ActionEvent event){
Java has provided good way to use the Anonymous classes while adding the listeners. It should work with the RCF also.
Some how i found the case 1 usefull, as i can have as many buttons in my screen and i can add the actionListener in one method. Also it is easy to read. I dont have to see the JSPX page to find the associated actionListener method.
Is it a bug or i am wrong at some point?
Any sujjestions are welcome.
- Sujay.

Answer 1

Hello Sujay,
As I said in my previous reply, you can try with request scope. In JSF you shouldn't use the binding attribute very often. I agree that anonymous class is nice, but don't forget that you might be dealing with client state saving here so it cannot be perfectly compared with Swing that maintains everything in RAM. What I think happens with you currently is the following:
1. Bean is created and the button instance as well. The ActionListener is added to the button;
2. The view is rendered and while it is, the binding attribute is evaluated, resulting in the get method of your bean being called;
3. Since the method returns something different than null, the button instance created in 1. get used in the component tree;
4. The tree's state is saved on the client, since your class isn't a StateHolder, nor Serializable, the StateManager doesn't know how to deal with it so it gets discarded from the saved state and maybe from the component itself (would have to debug the render view phase to be sure);
5. The postback request arrives, the tree is restored. When the handler reaches the button, it call the bean that returns the same instance that was used in the previous tree (since not request scoped), which is BAD because the remaining of the tree is not made of the same object instances, but rather new deserialized ones. The component then gets updated from the client state saved in 4, this might also be where the listener get removed (again debugging would tell you this, but I would tend more with the previous possibility). Note that with a request scoped bean you would have to add the listener during the first get method call (by checking if the component is null) or in the constructor as you're doing right now. It would be a very clean way and you could give the request bean (and thus the listener) access to the conversation scoped bean through injection which is very nice as well.
6. The invoke application phase occurs and the listener is no longer there.
Btw, this isn't a rich client issue, more a specification one. I'm curious if it works in a simple JSF RI application, if it does then I guess it would be a bug in Trinidad and/or rich client state handling architecture (using FacesBean).
Regards,
~ Simon