0

We are using JSF 2.0.3 version with WebSpehere 8.5 as the application Server. We have a requirement to have two selectmanylistboxes with ability to move data between two boxes.Please note due to restrictions in our company I cannot use Rich faces,Ice faces etc. Hence I tried using Ajax calls and listener like below code to move data

    <h:commandButton id="lefttoright"  value="Left to Right"  >
 <f:ajax execute="listbox" render="sellistbox listbox" onevent="checkData"  listener="#{bean.leftToRight}" />
</h:commandButton> 

Please note I am using Viewscoped bean . Now the funtionality i.e. moving data around boxes works perfectly fine on my Local RAD set up with single node single server WebSphere.

When I deploy the same code on our WeSphere server which has 1 cell , 2 nodes with 2 servers each which are in cluster , the "left to Right" button only invokes the constructor but does not invoke the method i.e. "leftToRight" . There are no errors/exceptions reported in the logs directly on invoking "lefttoright" button. But there is a continuous exception being thrown regarding serialization. Not sure if this has any direct impact on Ajax calls.

 E SessionContextMBeanAdapter findAttCausingNotSerializableException Miscellaneous data: Attribute "com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap" is declared to be serializable but is found to generate exception "java.io.NotSerializableException" with message "com.sun.faces.context.FacesContextImpl".  Fix the application so that the attribute "com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap" is correctly serializable at runtime.

Any feedback is much appreciated. Please let me know if I need to provide additional information.

Kukeltje
  • 12,223
  • 4
  • 24
  • 47
ShaikR
  • 3
  • 4

2 Answers2

1

"java.io.NotSerializableException" with message "com.sun.faces.context.FacesContextImpl"
Fix the application so that the attribute "com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap" is correctly serializable at runtime

So, you have something like this:

@ViewScoped
public class Bean implements Serializable {

    private FacesContext context = FacesContext.getCurrentInstance();

    // ...
}

This is very definitely not right. You should never assign FacesContext as an instance variable of some class which lives longer than the FacesContext instance itself.

Grab it in the method local scope instead and don't assign it to any instance variable.

@ViewScoped
public class Bean implements Serializable {

    public void someMethod() {
        FacesContext context = FacesContext.getCurrentInstance();
        // ...
    }

    // ...
}

This way the LogicalViewMap, which represents the JSF view state itself, will become serializable again and anything depending on JSF view state will start to work again, such as ajax requests which depend on view scoped variables.

Only in the upcoming JSF 2.3 it will be legit to have it as an instance variable provided that it's injected via CDI (CDI will as usual just inject a serializable proxy which delegates further to the currently available instance).

@ViewScoped
public class Bean implements Serializable {

    @Inject
    private FacesContext context;

    // ...
}

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thanks BalusC. You have been terrific help to this forum. Based on further analysis the root cause of this issue was that common logging jar got added to the lib folder and after removing the jar file all the ajax calls started working with out any issues. Based on my painful experience I would recommend to check jar files especially "common logging" if you encounter any weird problems :) . Check below link for reference http://articles.qos.ch/thinkAgain.html – ShaikR Apr 13 '16 at 15:25
0

Based on further analysis the root cause of this issue was that common logging jar got added to the lib folder and after removing the jar file all the ajax calls started working with out any issues. Based on my painful experience I would recommend to check jar files especially "common logging" if you encounter any weird problems :) . Check below link for reference http://articles.qos.ch/thinkAgain.html

ShaikR
  • 3
  • 4