I don't think this is related. FYI ... there are two types of state
(potentially) being managed/preserved by the bridge:
1) action parameters saved and reexposed during the render
this is off by default -- there is a portlet init parameter you
set to enable this
2) request scope attributes saved until the next action
this is always on and by default the bridge preserves all
attributes in the request scope. One can exclude specific attributes
from this cache using the
syntax Leonardo described in his message.
Note: in both of these cases the state management has nothing to do
with the View State -- once a render occurs that state is managed by
Faces in whatever manner the app defines (client/server, etc.)
-Mike-
On 3/17/2010 8:46 AM, Leonardo Uribe wrote:
Hi
I remember this one. In apache myfaces portlet bridge there is an special
configuration to allow some params to be preserved between action request
and render request, so the state is not lost when it is used server side
state saving. The hack there looks like this:
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee";
xmlns:bridge="
http://www.apache.org/myfaces/xml/ns/bridge/bridge-extension";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd";>
<application>
<view-handler>org.apache.myfaces.portlet.faces.application.PortletViewHandlerImpl</view-handler>
<state-manager>org.apache.myfaces.portlet.faces.application.PortletStateManagerImpl</state-manager>
<el-resolver>org.apache.myfaces.portlet.faces.el.PortletELResolver</el-resolver>
<application-extension>
<bridge:excluded-attributes>
<bridge:excluded-attribute>com.sun.faces.*</bridge:excluded-attribute>
<bridge:excluded-attribute>com.sun.faces.util.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.application.jsp.JspStateManagerImpl.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.el.unified.resolver.managedbean.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.shared_impl.renderkit.RendererUtils.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.application.DefaultViewHandlerSupport.*</bridge:excluded-attribute>
<bridge:excluded-attribute>jsf_sequence</bridge:excluded-attribute>
</bridge:excluded-attributes>
</application-extension>
</application>
</faces-config>
to check if this is what is happening, change your jsf state saving to
client. If so, there should be something in jboss portlet bridge that allows
do something similar. I have never tried it before (but good to know that
this bridge exists).
regards,
Leonardo Uribe
2010/3/17 Sertic Mirko, Bedag <mirko.ser...@bedag.ch>
h...@all
We are running into a strange problem with MyFaces, Facelets, the JBoss
PortletBridge running on LifeRay.
It seems that normal h:commandLinks are no longer working. After some
debugging, it seems that HtmlResponseStateManager.isPostback() always
returns false, and the Lifecycle jumps to the RENDER_RESPONSE phase. No
action is invoked. In fact there is no VIEW_STATE_PARAM request
parameter.
What is going wrong here? I noticed that there are two <form> elements
in the resulting HTML of the page. Is the MyFaces JavaScript just
submitting the wrong form?
Thanks in advance
Mirko
