Page Parameter not working

[stephen.friedrich]

It seems I am caught in the heel that is framework integration once more: Seam 1.2.1, Trinidad 1.0.2, MyFaces 1.1.5

A page parameter set like this never makes it into the model:

<s:link view="/departments.xhtml" value="#{department.id}">
 <f:param name="departmentId" value="#{department.id}"/>
</s:link>

It works in the seampay example (which does not use Trinidad). It also worked when in my prototype I developed on 2.0.0. (CVS), JBoss 4.2.1, JSF RI and Trinidad 1.0.2.

Now that I had to port my app to Seam 1.2.1, Tomcat 5.5.17 and MyFaces 1.1.5 it stopped working.

I might have traced it down to a difference in Seam 1.2.1 / Seam 2.0.0 (I don't understand the code good enough to be sure, though).
Seam 2.0.0 seems to apply request values unconditionally :

SeamPhaseListener.afterRestoreView
 -> Pages.instance().postRestore(facesContext);
 -> Pages.storeRequestParameterValuesInViewRoot(facesContext)
 -> Contexts.getPageContext().set( pageParameter.getName(), value );

Seam 1.2.1 only sets the parameter conditionally:

AbstractSeamPhaseListener.afterRestoreView
 ->
 if ( facesContext.getRenderResponse() )
 {
 Pages.instance().applyRequestParameterValues(facesContext);
 }
 else
 {
 Pages.instance().applyViewRootValues(facesContext);
 }

That condition never ever evaluates to true when I click the s:link.

Of course Trinidad 1.0.2 also must have something to do with it, since it works with seampay.


Please, some expert, help me out of my misery.
There's a deadline approaching and I have spent a whole day on this issue.

[milli]

When you hover over the link do you see departmentId and its value in the URL?

Are you injecting request parameter or using page parameter to get the value in your model?

[stephen.friedrich]

I do see the request parameter in the URL and after clicking on a link the correct URL is even displayed in the browser's address bar.

I do (try to) use a page parameter:

<page view-id="/departments.xhtml" action="#{entryAction.enter()}">
 <param name="departmentId" value="#{departmentHome.id}" converterId="javax.faces.Long"/>
 </page>

I put the action there only for testing and it sure is called.

However request parameters never are used. As I previously said: This setup was working on Seam 2.0.0, Trinidad 1.2.2, Sun JSF RI 1.2 and JBoss 4.2. Of course it may be that I forgot to change some descriptors to the older format, but I triple (quadruple, and lots more) checked them against the seampay example in 1.2.1.

It really seems to me like a bug in the integration of Seam and Trinidad.

In my scenario Seam never calls it's own applyRequestParameterValues() which sure seems like a bug to me. Of course it probably has a deeper cause somewhere.
It seems that for this request Seam figures out there won't be a JSF response, so the applyRequestParameterValues() is not needed (I have no clue why facesContext.getRenderResponse() always returns false nor why that should disable request parameter processing).

[stephen.friedrich]

Another midnight is through, but stupid me has found the culprit:
As part of the backport from Seam 2.0.0 to 1.2.1 I changed from JSF RI to MyFaces, but I still tried to use server side state saving, which seems to be known to be buggy:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=108488

Currently I am working with client side state saving and it works fine. Unfortunately I probably have to get server side state saving to work, because my client's web development guidelines forbid hidden input field.

Even more unfortunately there were issues with Trinidad and JSF RI last time I tried, so that's not an easy way either. I'll check again, maybe now with Trinidad 1.0.2 and JSF RI 1.1 I'll have more luck. However right now I am totally fed up with trying to get different frameworks to work together.

[piotr.walczyszyn]

Did you manage to solve this problem? I have a same issue with my application. I even tried to upgrade myfaces to 1.1.5 but it didn't help.

[stephen.friedrich]

Nope, currently I am still using client-side state saving which is working fine.
I posted a question on the myfaces mailing list, but nobody seemed to care.

[piotr.walczyszyn]

The strange thing about this problem is that its completely not deterministic. I have a few pages that are using same construct and are working fine.