4 Replies Latest reply on Jan 16, 2009 9:56 PM by Norman Richards

    Migrating pure-JSF app to Seam

    Joseph Marques Newbie
      I have a fairly sizable application written using pure JSF.  However, new requirements for multi-page flows have necessitated the use of a conversational context to ease the burden of state management on those new pages.

      I added the necessary dependency elements to the appropriate POMs in our multi-module maven-based app as well as the required elements in the web.xml.  NO Seam annotations were added at this point.  The goal of this first step was to smoke test the app for regression caused by the integration of the Seam libraries.

      From the literature I've read, I expected this testing to go smoothly.  I am under the impression that as long as I do not use Seam annotations on any managed beans that Seam will not interfere with the "classic" JSF lifecycle for those beans, essentially acting as a pass-through for existing parts of the application that haven't yet been migrated to Seam.  However, I very quickly found several results that appear to contradict this assumption:

      1) On some - but not all - of my existing page flows, I see a conversationId URL param being passed around.
      2) On pages that attempt to load data on postbacks (as opposed to initial page loads), I'm seeing the "cannot open connection...transaction not active" error message (similar to what you see in the first post on this thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097777#4097777 )
      3) When I open seam.debug page to see what's going on, I see several of my JSF managed beans in the application context.

      Our app stack is as follows:

      Seam 2.1.0.SP1
      Richfaces 3.2.2.SR1
      Facelets 1.1.14 + JSF 1.2_06
      JBossAS 4.2.1.GA w/Hibernate 3.2.r14201-2

      The code convention used on every page in the UI is to have our Facelets layer call into a managed bean layer which calls into our JPA-based SLSB layer.

      My questions / concerns have a 1-to-1 mapping to the 3 issues I see above:

      1) Considering our code convention above and considering we're not using any Seam annotations yet, why do some of my pages appear to operate in the conversational context? 
      2) I've been able to workaround this issue by either loading all required data during the initial page load, or by using the @RequiresNew annotation on the SLSB methods that my managed beans call in to on the postbacks.  However, I was expecting the EJB3 container's default @Requires annotation on SLSB methods to suffice.  I presume this has to do with the fact that my page is operating in the conversational context (and thus using extended persistence context?), so any responses / suggested fixes for #1 may indirectly fix this too?
      3) Our managed beans are declared (in *-beans.xml files) as being in request or session scope, but I see some of these now in the application scope.  I'm wondering what could cause this considering again that we're not using any Seam annotations yet.

      On a final note, one workaround I tried to alleviate these issues was to modify the configuration for which URLs Seam intercepts.  I changed the Seam Filter declaration to ONLY have url-mappings for the URL prefixes where the new multi-page flows will reside, i.e. I changed "/*" to "/some/multi/page/flow/context/*".  Oddly, that seemed to have no affect and I still see all 3 issues above.  I figured that if the Seam filter wasn't mapped to the existing URLs in the rest of the application, it wouldn't have changed the traditional JSF lifecycle on those existing, non-Seam-intercepted pages.

      Has anyone else tried migrating an existing JSF application to Seam and had any of these issues before?  If so, what were your workarounds and/or proper fixes?  I'm perfectly willing to believe I'm missing something big, but it's just not obvious to me at the this point.  Any help is greatly appreciated.

      -joseph
        • 1. Re: Migrating pure-JSF app to Seam
          Norman Richards Expert

          1) On some - but not all - of my existing page flows, I see a conversationId URL param being passed around.

          On redirects?  This is normal seam behavior.




          2) On pages that attempt to load data on postbacks (as opposed to initial page loads), I'm seeing the "cannot open connection...transaction not active" error message

          Not enough information to know what you are describing.




          3) When I open seam.debug page to see what's going on, I see several of my JSF managed beans in the application context.


          The debug page shows everything in the application scope.  This doesn't imply that seam is managing them.


          • 2. Re: Migrating pure-JSF app to Seam
            Norman Richards Expert

            1) Considering our code convention above and considering we're not using any Seam annotations yet, why do some of my pages appear to operate in the conversational context?

            The conversation context will be active for all requests.



            2) I've been able to workaround this issue by either loading all required data during the initial page load, or by using the @RequiresNew annotation on the SLSB methods that my managed beans call in to on the postbacks.  However, I was expecting the EJB3 container's default @Requires annotation on SLSB methods to suffice.  I presume this has to do with the fact that my page is operating in the conversational context (and thus using extended persistence context?), so any responses / suggested fixes for #1 may indirectly fix this too?


            Are you you using a seam-managed transaction and or seam-managed persistence context?



            3) Our managed beans are declared (in *-beans.xml files) as being in request or session scope, but I see some of these now in the application scope.  I'm wondering what could cause this considering again that we're not using any Seam annotations yet.

            I don't think this is seam-related.

            • 3. Re: Migrating pure-JSF app to Seam
              Joseph Marques Newbie

              OK, let me ask in a different way.  If someone wants to start injecting/using Seam a little bit at a time in an existing application, what are the proper procedures.  I basically don't want Seam to touch anything about the existing application, and allow me to add Seam to ONLY the pages that need to leverage Seam functionality.  I tried mucking with the Seam Filter (as described in my first post), but did not have success.

              • 4. Re: Migrating pure-JSF app to Seam
                Norman Richards Expert

                Seam definitely isn't designed with that goal in mind. That's not to say it isn't possible or that it should be difficult, but new Seam applications have always been our primary target with Seam with an eye towards c


                It sounds to me like the only real issue you are having is possibly some confusion over transaction management.  Everything else sounds like a non-issue/misunderstanding or a quirk of the application that is only being exposed now that the app is being deployed in a slightly different environment. It's hard to say without any more information.