Previously we have had a fully working aplication which consist of JSR-168 portlets implemented with Seam 1.2, Facelets. The portal we're using is Liferay.
Now, we're planning to move with the flow and upgrade versions of different things. As with most cases you just cannot upgrade one component to a new version but you'll have to upgrade the depencies also.
Currently, we're using Seam 1.2-custom (for portlets,see below), JBoss 4.0.5.GA (patched almost to a breaking point), Liferay 4.2.2 (2 patches). And now we see Seam 2 coming out of the oven we'll be upgrading everything in one big effort. So Seam for 2.0, JBoss AS for 4.2.1, Liferay to 4.3.3. Every major component is more or less different than their previous version.
We've identified couple of critical changes, one is the change JSF implementation from MyFaces to Sun's RI (this is where some of the black magic happens ;).
Previously we had a heavily customized MyFacesGenericPortlet with all sorts of tricks for various bugs/things/ related to MyFaces, Facelets. Now this portlet is empty and simply extending com.sun.faces.portlet.FacesPortlet.
For facelets we've (always had) custom FaceletPortletViewHandler which used to extend SeamFaceletViewHandler. Now it just extends com.sun.facelets.FaceletViewHandler. So, we managed to get rid some of the hacks, but it seems we need some new ones ;)
Also, we had a customized org.jboss.seam.portlet.PortletSessionImpl which used PortletSession.APPLICATION_SCOPE rather than PortletSession.PORTLET_SCOPE to access the portlet session.
Now PortletSessionImpl has been removed from Seam and I'm trying to figure it ouf if this hack is still needed.
So can you point me what structure replaced the servlet/portal/SessionImpl way of doing things?
Is org.jboss.seam.contexts.SessionContext part of this new way?
So, what we currently have is a JBoss 4.2.1, Liferay 4.3.3, Seam2 and our applocation which is deploying just nicely! So we've managed to fix some of the integration issues.
However, when actually using the portlet you get an exception ( http://pastebin.com/f6da360a9 ) telling there's no active application context (one was created on deploy), and from debugger I can tell that's true, there's no active application context.
15:42:13,954 ERROR [STDERR] 18.10.2007 15:42:13 com.sun.faces.portlet.LifecycleImpl phase
java.lang.IllegalStateException: No active application scope
So, my reasoning is that somehow Seam is not being "kicked in" because of the different lifecycle you've on portlets. Not even the JSF phase listener has a change to do it's magic and active seam for the current request.
So maybe we still need some magic in the Portlet class or either in the FaceletViewHandler. I found couple of nice candicates for kickstarting Seam request, one from ServletLifecycle and the other from FacesLifecycle. I guess the FacesLifecycle should be called from SeamPhaseListener but it's doesn't get called early(?) enough for things to work.
SeamPhaseListener has some support for portlets because there're methods like afterPortletRequest but simply having your portlet class (extending) FacesPortlet doesn't seem to be enough to get it up and running.
Let's see if we can get this any further.