Migrating pure-JSF app to Seam
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
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
