ICEfaces
  1. ICEfaces
  2. ICE-9266

Exception when deploying tabSet application (Mojarra 2.2)

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Invalid
          • Affects Version/s: 4.0.BETA
          • Fix Version/s: EE-3.3.0.GA, 4.0.BETA
          • Component/s: ACE-Components
          • Labels:
            None
          • Environment:
            ICEfaces3 trunk revision# 34968
            Mojarra 2.2 library
            Tomcat7
          • Affects:
            Compatibility/Configuration

            Description

            There is an exception when deploying tabSet application to the server (however, no issues found when testing). In automation the application is unable to be un-deployed (causes another exception), but when testing manually I had no issues undeploying the application. This issue does not occur with Mojarra 2.1.21.

            SEVERE: IOException while loading persisted sessions: java.io.EOFException
            java.io.EOFException
            at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
            at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
            .......

            To reproduce:
            1) Build / deploy test app (with Mojarra 2.2 library) located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/tabSet
            Exception will be seen upon deployment.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Deryk Sinotte added a comment -

              I think I need more information on how exactly to reproduce this. I've deployed and undeployed that test app several times on Tomcat 7, switching between 2.1.12 and 2.2m15 several times without any exceptions.

              If there is a problem, I suspect it may not be that serious. The message "while loading persisted sessions" indicates that the session was serialized between deployments. If you change a serialized class between deployments, it would likely report this issue. So in our case, any Mojarra classes that might have been serialized in the session (Views for instance) that get changed between deployments - the 2.1 version of the View class and the 2.2 version of the same class - may cause this problem.

              To verify there are a couple of things to try:

              • Rebuild and redeploy the app using the same version of Mojarra multiple times before switching to the other version. If the error only occurs when the Mojarra version is changed (and not between redeploys using the same version), the it's the problem I've noted above and can likely be ignored.
              • If you shut down Tomcat, it will serialize the sessions. You can see the file under apache-tomcat-7.0.33/work/Catalina/localhost/tabSet/SESSIONS.ser. Removing this file between redeploys would also get rid of the problem.
              <Context>
    <Manager pathname="" />
</Context>

              It might be a useful thing to do with certain tests where you may not want the session data re-animated between test runs.

              Show
              Deryk Sinotte added a comment - I think I need more information on how exactly to reproduce this. I've deployed and undeployed that test app several times on Tomcat 7, switching between 2.1.12 and 2.2m15 several times without any exceptions. If there is a problem, I suspect it may not be that serious. The message "while loading persisted sessions" indicates that the session was serialized between deployments. If you change a serialized class between deployments, it would likely report this issue. So in our case, any Mojarra classes that might have been serialized in the session (Views for instance) that get changed between deployments - the 2.1 version of the View class and the 2.2 version of the same class - may cause this problem. To verify there are a couple of things to try: Rebuild and redeploy the app using the same version of Mojarra multiple times before switching to the other version. If the error only occurs when the Mojarra version is changed (and not between redeploys using the same version), the it's the problem I've noted above and can likely be ignored. If you shut down Tomcat, it will serialize the sessions. You can see the file under apache-tomcat-7.0.33/work/Catalina/localhost/tabSet/SESSIONS.ser. Removing this file between redeploys would also get rid of the problem. You can also turn off session serialization altogether ( http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html ). This can be done server-wide in the conf/server.xml file or per application by including a context.xml file that disables the session persistence manager: <Context> <Manager pathname="" /> </Context> It might be a useful thing to do with certain tests where you may not want the session data re-animated between test runs.
              Hide
              Permalink
              Cruz Miraback added a comment - - edited

              When I created this JIRA I was able to reproduce this issue manually and when running the tests in automation (deployment is controlled via ant using tomcat manager). However, when testing now I cannot reproduce this issue upon deployment but can reproduce it upon undeployment. This occurs every time when testing through automation, and intermittently when testing manually. Additionally, I reproduced this exception during undeployment using Mojarra 2.1.21, so it appears to be unrelated to Mojarra 2.2 after all.

              That being said, when I disable session persistence in the Tomcat config I am unable to reproduce this exception in any scenario.

              Show
              Cruz Miraback added a comment - - edited When I created this JIRA I was able to reproduce this issue manually and when running the tests in automation (deployment is controlled via ant using tomcat manager). However, when testing now I cannot reproduce this issue upon deployment but can reproduce it upon undeployment. This occurs every time when testing through automation, and intermittently when testing manually. Additionally, I reproduced this exception during undeployment using Mojarra 2.1.21, so it appears to be unrelated to Mojarra 2.2 after all. That being said, when I disable session persistence in the Tomcat config I am unable to reproduce this exception in any scenario.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              I would suspect you could get it to happen when switching Mojarra in either direction (2.1 -> 2.2 or 2.2 -> 2.1) when an active session is serialized and the library changes. The mechanism for deploying and undeploying (Tomcat Manager vs manual copying) may also have some sort of impact depending on how the classloaders are handled. I don't believe we need to devote to much more time to this if we have a good understanding of what is happening and why.

              Show
              Deryk Sinotte added a comment - I would suspect you could get it to happen when switching Mojarra in either direction (2.1 -> 2.2 or 2.2 -> 2.1) when an active session is serialized and the library changes. The mechanism for deploying and undeploying (Tomcat Manager vs manual copying) may also have some sort of impact depending on how the classloaders are handled. I don't believe we need to devote to much more time to this if we have a good understanding of what is happening and why.
              Hide
              Permalink
              Ken Fyten added a comment -

              Marking Invalid as this issue only occurs when moving between JSF 2.1 and 2.2 on the same application, same tomcat instance.

              Show
              Ken Fyten added a comment - Marking Invalid as this issue only occurs when moving between JSF 2.1 and 2.2 on the same application, same tomcat instance.

                People

                • Assignee:
                  Cruz Miraback
                  Reporter:
                  Cruz Miraback
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: