9 Replies Latest reply on Oct 13, 2006 1:56 PM by gavin.king

    SFSB - NotSerializableException

      Hello,

      I am using the 2006.1011 nightly build of Seam. I am getting the following exception in the server:

      SEVERE: Error Rendering View[/user_access_request.xhtml]
      javax.faces.FacesException: java.io.NotSerializableException: com.evergreen.accesscontrol.AccessRequestManager$$EnhancerByCGLIB$$1703dda3
       at org.apache.myfaces.shared_impl.util.StateUtils.getAsByteArray(StateUtils.java:190)
       at org.apache.myfaces.shared_impl.util.StateUtils.construct(StateUtils.java:150)
       at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.writeState(HtmlResponseStateManager.java:102)
       at org.apache.myfaces.application.jsp.JspStateManagerImpl.writeState(JspStateManagerImpl.java:430)
       at org.jboss.seam.jsf.SeamStateManager.writeState(SeamStateManager.java:53)
       at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:606)
       at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
       at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:97)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at com.evergreen.filter.RequestDumper.doFilter(RequestDumper.java:72)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.jboss.seam.servlet.SeamExceptionFilter.doFilter(SeamExceptionFilter.java:45)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.jboss.seam.servlet.SeamRedirectFilter.doFilter(SeamRedirectFilter.java:33)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
       at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
       at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
       at com.evergreen.fastpass.catalina.CASSSOAuthenticatorValve.invoke(CASSSOAuthenticatorValve.java:371)
       at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
       at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
       at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
       at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
       at java.lang.Thread.run(Thread.java:595)
      Caused by: java.io.NotSerializableException: com.evergreen.accesscontrol.AccessRequestManager$$EnhancerByCGLIB$$1703dda3
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
       at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
       at java.util.HashMap.writeObject(HashMap.java:1039)
       at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
       at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
       at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
       at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
       at java.util.HashMap.writeObject(HashMap.java:1039)
       at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
       at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
       at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
       at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251)
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
       at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251)
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
       at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251)
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
       at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
       at org.apache.myfaces.shared_impl.util.StateUtils.getAsByteArray(StateUtils.java:180)
       ... 41 more
      


      Here is my SFSB code (not a lot there yet):

      @Stateful
      @Name("accessRequestManager")
      @Conversational(ifNotBegunOutcome = "home")
      public class AccessRequestManagerBean implements AccessRequestManager {
      
       @Logger
       private Log log;
      
       @In(create=true) @Out
       private AccessRequest accessRequest;
      
       @PersistenceContext(unitName = "accessControlDatabase")
       private EntityManager em;
      
       // This is another stateful EJB
       @In
       private ApplicationManager applicationManager;
      
       @Begin(join=true)
       public String create() {
      
       log.info("create() : accessRequest -> " + this.accessRequest);
       log.info("create() : applicationManager -> "+this.applicationManager);
       log.info("create() : selectedApplications -> "+this.applicationManager.getSelectedApplications());
       return "success";
       }
      
       /**
       * End conversation and return user to home page (often index.seam).
       *
       * @return "home"
       */
       @End
       public String cancel() {
       return "home";
       }
      
       /**
       * If the destroy method is not declared in the interface, Seam will throw an exception
       * when the bean is destroyed.
       */
       @Destroy @Remove
       public void destroy() {
       // NO OP
       }
      }
      


      I am using the CVS build because in the released version of Seam 1.0.1, @RequestParameter does not correctly handle req. param values from non-JSF widgets (e.g. a SelectManyList manually rendered). The version in CVS does correctly handle multiple parameter values for a single req. param.

      Does this seem familiar to anyone?

      Thanks.

        • 1. Re: SFSB - NotSerializableException
          gavin.king

          So the problem here is that for some reason one of the myfaces widgets is holding a hard reference to the SFSB. I'm really not sure why it is doing that. Are you using some funny myfaces widgets, or just the standard JSF controls? Did you put your SFSB in PAGE scope?

          Anyway, the relevant change b/w 1.0.1 and 1.1 is that we introduced client-side interceptors by using CGLIB proxies for all session beans (this is a nice feature). But as this bug reports:

          http://jira.jboss.com/jira/browse/JBSEAM-332

          the CGLIB proxies are not serializable.

          Now, I actually happen to know how to make CGLIB proxies serialize correctly, since I have done it before in Hibernate. So I just need to get around to fixing this :-)

          • 2. Re: SFSB - NotSerializableException
            gavin.king

            But it would still be worth figuring out my the MyFaces component tree is trying to hold a hard ref to your Seam component!

            • 3. Re: SFSB - NotSerializableException

              We are using the tomahawk (1.1.3) components in this application (with myfaces 1.1.4), however, there are no explicit usages of a tomahawk component on the page associated with this problem.

              Another note, there are a couple of <h:commandButton>'s on the page that are bound to methods in the AccessRequestManager(Bean).

              I am still stumped....

              • 4. Re: SFSB - NotSerializableException
                gavin.king

                I bet the exceptions would go away if you removed the tomahak filter from web.xml.

                • 5. Re: SFSB - NotSerializableException
                  gavin.king

                  I just "fixed" the serialization issue in CVS. But note that I mean "fixed" in the very broad sense of the word where I have not actually tested it to see if it works ;-)


                  Please try out a new CVS build and see what happens ;-)

                  • 6. Re: SFSB - NotSerializableException

                    I'll need to wait for the nightly build to be available on

                    http://cruisecontrol.jboss.com/cc/artifacts/jboss-seam-builds

                    to try your changes. Anyway, I did try removing the tomahawk filter and that didn't help.

                    Thanks,
                    Brad Smith

                    • 7. Re: SFSB - NotSerializableException
                      gavin.king

                      MyFaces *really* shouldn't be holding hard refs to your components in the JSF tree. That's broken.

                      • 8. Re: SFSB - NotSerializableException

                        I think part of the problem was in how I was using MyFaces.

                        First, there is the version of MyFaces that's shipped with JBoss' tomcat sar; in my application, I am using MyFaces 1.1.4 and I believe that's a higher version than what is supplied with JBoss (4.0.4 EJBRC8 - from JEMs). I was initially bundling MyFaces 1.1.4 in my .ear file. This worked fine for several weeks of development on my application. After I tried the latest nightly build of Seam, and ran into some other issues (which started this thread), I tried to back out my changes and my app/build just went haywire.

                        At some point in trying to get things working again off Seam 1.0.1 GA, I became suspicious of MyFaces (via exceptions/stack traces) - I tried removing the MyFaces 1.1.4 from my .ear, and instead, installing it in JBoss' tomcat sar. This made my application 'work' again.

                        For now, I've learned that it's not clear to me what the 'proper' way is to build an application using the latest MyFaces + Tomahawk + Facelets and deploy in JBoss (er..tomcat). I would appreciate any pointers on where particular jars should be developing .ear-style apps using these frameworks/components. Currently, I have Facelets + Tomahawk in my .ear / MyFaces 1.1.4 has been installed in the JBoss-tomcat sar (in jsf-libs).

                        I am looking forward to trying the nightly build that has your changes addressing the serialization issue as well. I would prefer to have @RequestParameter inject the array of values instead of verbose FacesContext approach.

                        Thanks,
                        Brad

                        • 9. Re: SFSB - NotSerializableException
                          gavin.king

                           

                          For now, I've learned that it's not clear to me what the 'proper' way is to build an application using the latest MyFaces + Tomahawk + Facelets and deploy in JBoss (er..tomcat). I would appreciate any pointers on where particular jars should be developing .ear-style apps using these frameworks/components. Currently, I have Facelets + Tomahawk in my .ear / MyFaces 1.1.4 has been installed in the JBoss-tomcat sar (in jsf-libs).


                          This is the correct way to do it.

                          The only thing you might need to do differently is either:

                          (a) put Tomahawk in jsf-libs or
                          (b) make sure you hack the tomahawk jar to remove any classes that are duplicated between myfaces-impl.jar and tomahawk.jar

                          But perhaps they already fixed the problem of duplicated classes in their latest releases. But you had better check.

                          Or you could just not use Tomahawk, and find a different JSF component library.