2 Replies Latest reply on Sep 26, 2006 5:03 PM by Andrew

    Seam remoting -- any plans for FacesContext support?

    Andrew Apprentice

      I just tried a little demo of using seam remoting in my JSF app using Seam, and found that I can't use it for my needs. We have a lot of code that uses the FacesContext and its internal classes for our beans & methods. It looks like Seam doesn't create a FacesContext inside of the remoting servlet.

      Is there any plans to use the JSF factories from within the Seam remoting servlet to reconstruct the faces context so that code that is used to running inside of the faces servlet will still be able to execute from within remoting as well?

      Thanks,
      Andrew

        • 1. Re: Seam remoting -- any plans for FacesContext support?
          Gavin King Master

          No, Seam remoting is independent of JSF.

          • 2. Re: Seam remoting -- any plans for FacesContext support?
            Andrew Apprentice

            Okay, I got this to work. I just needed to do a bit of simple OO programming.

            1) Extend your servlet and overwrite the "Execute" path handler:

            public class SeamRemotingServletEx
             extends SeamRemotingServlet
            {
             private static final String REQUEST_PATH_EXECUTE = "/execute";
            
             /**
             * @see org.jboss.seam.remoting.SeamRemotingServlet#init(javax.servlet.ServletConfig)
             */
             @Override
             public void init(ServletConfig config)
             throws ServletException
             {
             super.init(config);
             RequestHandlerFactory.getInstance().registerHandler(REQUEST_PATH_EXECUTE,
             new FacesExecutionHandler());
             }
            }


            2) Write the new handler with faces context support:
            public class FacesExecutionHandler
             extends ExecutionHandler
            {
             private ServletContext servletContext;
            
             /**
             * @see org.jboss.seam.remoting.InterfaceGenerator#setServletContext(javax.servlet.ServletContext)
             */
             @Override
             public void setServletContext(ServletContext ctx)
             {
             this.servletContext = ctx;
             super.setServletContext(ctx);
             }
            
             /**
             * @see org.jboss.seam.remoting.InterfaceGenerator#handle(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
             */
             @Override
             public void handle(HttpServletRequest request, HttpServletResponse response)
             throws Exception
             {
             getFacesContext(request, response);
             super.handle(request, response);
             }
            
             protected FacesContext getFacesContext(HttpServletRequest request,
             HttpServletResponse response)
             {
             FacesContext facesContext = FacesContext.getCurrentInstance();
            
             if (facesContext == null)
             {
             FacesContextFactory contextFactory = (FacesContextFactory)FactoryFinder
             .getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
             LifecycleFactory lifecycleFactory = (LifecycleFactory)FactoryFinder
             .getFactory(FactoryFinder.LIFECYCLE_FACTORY);
             Lifecycle lifecycle = lifecycleFactory
             .getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
            
             facesContext = contextFactory.getFacesContext(servletContext, request,
             response, lifecycle);
             }
             return facesContext;
             }
            }


            3) register the extended servlet instead of the Seam servlet. Follow all other configuration instruction verbatim.

            And that is all she wrote. Now Seam remoting works perfectly fine with JSF. Remoting methods can have full access to JSF scoped beans, access the session through the external context, have "facesContext" be injectable, etc.

            Perhaps a flag in some configuration file, or in the JavaScript to enable this? (or on the @WebRemote annotation?)

            Thanks,
            Andrew