2 Replies Latest reply on Oct 7, 2008 4:59 PM by cs224

    Check for serializability in a distributable webapp

    cs224

      Hello,


      in our old style web application we've implemented a serialization check that verifies that all objects in the session are serializable. This check is executed after every request before a result is returned to the browser if the application is running in debug mode. It is vital to detect any serialization issues early in the development phase to ensure proper functioning later in production in a clustered set-up with session replication.


      I was wondering if seam provides a component or a configuration setting that would check for serialization and write error messages to the log if problems are detected?


      What would be the recommended best practice to check for serializability in seam?


      If no solution exists yet, where would be the best place in the seam framework to plug a serialization test into the framework?


      Many thanks,


      Christian Schuhegger

        • 1. Re: Check for serializability in a distributable webapp
          pmuir

          Seam will check if a bean is serializable for some certain types of components which must be. But this is better done at development time - I would suggest either an ant task or a Eclipse tool. You could file a feature request for an ant task with a patch in the Seam JIRA.

          • 2. Re: Check for serializability in a distributable webapp
            cs224
            Hello,

            thanks for your answer. I don't think that a static offline tool can do the job. For example if you put a collection into the session then only at runtime you know which objects are added to the collection.

            I've created a prototype of a servlet filter that does roughly what I have in mind. It follows the approach of XStream to serialize data to XML. It is located at:
            svn co https://jclusterjobs.svn.sourceforge.net/svnroot/jclusterjobs/prototypes/p20080705/jces

            And can be configured like:
                <filter>
                    <filter-name>Serialization Check Filter</filter-name>
                    <filter-class>net.sourceforge.jclusterjobs.jces.util.serialization.SerializationCheckServletFilter</filter-class>
                      <init-param>
                           <param-name>SERIALIZATION_CHECK_SHOULD_REPLACE_OBJECTS_WITH_SERDESERCLONE</param-name>
                           <param-value>false</param-value>
                      </init-param>       
                </filter>

                <filter-mapping>
                    <filter-name>Serialization Check Filter</filter-name>
                    <url-pattern>/*</url-pattern>
                </filter-mapping>

            I have one final problem, though. The parameter SERIALIZATION_CHECK_SHOULD_REPLACE_OBJECTS_WITH_SERDESERCLONE should be used to force the replacement of every element in the session with a clone that was created via serialization / deserialization. I guess this would be the final proof that the session is serializable as expected and a user could continue to work on another cluster node after a fail-over.

            The problem is, as soon as I switch this feature on I get in my sample project exceptions like this here:
            16:54:50,972 ERROR [STDERR] [ERROR][16:54:50.972][n.s.j.j.u.s.SerializationUtils                    ] : Failed to serialize/deserialize the object!
            java.lang.ClassNotFoundException: No ClassLoaders found for: net.sourceforge.jclusterjobs.jces.p20080705.collectionmanager.usermanagement.webapp.sessionbeans.UserManagementAction
                 at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
                 at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:521)
                 at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415)
                 at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
                 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
                 at java.lang.Class.forName0(Native Method)
                 at java.lang.Class.forName(Class.java:247)
                 at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604)
                 at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
                 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
                 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
                 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.readObject(ObjectInputStream.java:351)
                 at net.sourceforge.jclusterjobs.jces.util.serialization.SerializationUtils.deserializeObject(SerializationUtils.java:55)
                 at net.sourceforge.jclusterjobs.jces.util.serialization.SerializationUtils.cloneObjectViaSerialization(SerializationUtils.java:70)
                 at net.sourceforge.jclusterjobs.jces.util.serialization.SerializationCheckServletFilter.doFilter(SerializationCheckServletFilter.java:82)


            I am working with seam in the war deployment mode. May this have something to do with the seam classloader that allows for hot deployment?

            I think such a general serialization check would be really useful to have it as a standard component in seam. Especially for mission critical applications that need to support a fail-over it is vital to detect serialization issues early in the development process.

            Many thanks for any additional info,
            Christian Schuhegger