1 Reply Latest reply on Apr 17, 2008 1:05 AM by System Administrator

    PrePassivation cleanup best practices with Seam

    System Administrator Expert

      I've now converted my SFSB from conversation-scoped to session-scoped which has eliminated the sporadic conversation ended, timed out or was processing another request error (possibly due to incorrect conversation management with


      from a dataTable getter method).  I've eliminated the @Begin and @End annotations and now using session-scoped component.

      So now I'm having an exception when the ejb container attempts to passivate the SFSB.  There is thread about this in the ejb3 forum.

      My question is, from a Seam programming perspsective, what is the recommended cleanup activities for SFSB's generally speaking?  Do we need to worry about the @In injected objects/references and mark them as @Transient?

      Do we need to worry about adding a @PrePassivate interceptor callback method?  Is it possible the lack of cleanup is what's causing this problem?

      apparent root cause after passivation attempt by ejb container:

      Caused by: java.lang.NoClassDefFoundError: org/jaxen/VariableContext
           at java.lang.Class.getDeclaredMethods0(Native Method)
           at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
           at java.lang.Class.getDeclaredMethod(Unknown Source)
           at org.jboss.serial.classmetamodel.ClassMetaData.lookupMethodOnHierarchy(ClassMetaData.java:102)
           at org.jboss.serial.classmetamodel.ClassMetaData.lookupInternalMethods(ClassMetaData.java:432)
           at org.jboss.serial.classmetamodel.ClassMetaData.<init>(ClassMetaData.java:122)
           at org.jboss.serial.classmetamodel.ClassMetamodelFactory.getClassMetaData(ClassMetamodelFactory.java:350)
           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:168)
           at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:206)
           at org.jboss.serial.persister.ArrayPersister.saveObjectArray(ArrayPersister.java:110)
           at org.jboss.serial.persister.ArrayPersister.writeData(ArrayPersister.java:101)
           at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:276)
           at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:206)
           at org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
           at org.jboss.serial.persister.ObjectOutputStreamProxy.writeFields(ObjectOutputStreamProxy.java:79)
           at org.jboss.serial.persister.ObjectOutputStreamProxy.defaultWriteObject(ObjectOutputStreamProxy.java:68)
           at java.util.Vector.writeObject(Unknown Source)
           ... 169 more

        • 1. Re: PrePassivation cleanup best practices with Seam
          System Administrator Expert

          I have resolved this issue by adding the following code to my

          private void cleanUp() 
                         if (rs != null) 
                         if (preparedStmt != null) 
                         if (stmt != null) 
                         if (con != null) 
                    catch(SQLException e) {
          private void cleanupBeforePassivation() {
          con                = null;  
          stmt                = null;  
          preparedStmt          = null; 
          rs                = null;   
          //params = null;  //<-- root cause identified!  at least this variable not being set to null causes the 
          // javax.ejb.EJBException: Could not passivate; failed to save state error...

          I know with Seam/JSF/EJB3 apps we're not supposed to use JDBC but tell that to the contractor from whom I inherited this codebase.

          I searched the Seam2.0.0.GA ref doc and found only 1 hit on passivate and 0 hits on passivation.  There needs to be a white-paper or addition to the ref doc regarding how to handle clean up operations for non-serializable objects in SFSB's...

          The root-cause exception after the long stack trace is not only misleading, it seems to be false (4.2.1.GA default/lib has the jaxen.jar with the org.jaxen.VariableContext class in it as other posts have stated as well).

          If I have some time I will write-up a how-to example or white-paper regarding how to handle passivation scenarios with SFSB's and upload to the documents section of this board.  One may argue that that information belongs in a EJB forum but since Seam apps make heavy use of SFSB's, I argue it belongs here or in the Seam ref doc...