You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by "Sertic Mirko, Bedag" <Mi...@bedag.ch> on 2010/03/17 16:37:03 UTC
MyFaces 1.2.6, JBoss PortletBridge 1.0.0CR3 & Postback with LifeRay 5.2.3
Hi@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
Re: Tutorial for MyFaces PortletBridge with Facelets
Posted by Michael Freedman <mi...@oracle.com>.
Sounds liek your plan is to try and isolate which system is contributing
to the problem. That is a good plan. I will contact you directly with
some information to help you proceed. FYI ... if you think its a
Liferay/JBoss specific issue you might also try their forum (if you
haven't already) to see if you get a direct response.
-Mike-
On 3/18/2010 9:20 AM, Sertic Mirko, Bedag wrote:
> Hi
>
> I'd like to know if there is a kind of reference documentation available for running the MyFaces Portlet Bridge with MyFaces 1.2.6, Facelets on LifeRay 5.2.3.
>
> Thanks in advance
> Mirko
>
Tutorial for MyFaces PortletBridge with Facelets
Posted by "Sertic Mirko, Bedag" <Mi...@bedag.ch>.
Hi
I'd like to know if there is a kind of reference documentation available for running the MyFaces Portlet Bridge with MyFaces 1.2.6, Facelets on LifeRay 5.2.3.
Thanks in advance
Mirko
AW: MyFaces 1.2.6, JBoss PortletBridge 1.0.0CR3 & Postback with LifeRay 5.2.3
Posted by "Sertic Mirko, Bedag" <Mi...@bedag.ch>.
Hi
I checked this with FireBug. The right form is submitted, and there is a javax.faces.ViewState parameter. But for some reason, it doesn't get to the JSF implementation...
Regards
Mirko
-----Ursprüngliche Nachricht-----
Von: sethfromaustria@gmail.com [mailto:sethfromaustria@gmail.com] Im Auftrag von Jakob Korherr
Gesendet: Mittwoch, 17. März 2010 16:44
An: MyFaces Discussion
Betreff: Re: MyFaces 1.2.6, JBoss PortletBridge 1.0.0CR3 & Postback with LifeRay 5.2.3
Hi,
It has to be something like that, yes. But why are there two different forms
in the HTML anyway?
Regards,
Jakob
2010/3/17 Sertic Mirko, Bedag <Mi...@bedag.ch>
> Hi@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
>
>
>
>
Re: MyFaces 1.2.6, JBoss PortletBridge 1.0.0CR3 & Postback with
LifeRay 5.2.3
Posted by Jakob Korherr <ja...@gmail.com>.
Hi,
It has to be something like that, yes. But why are there two different forms
in the HTML anyway?
Regards,
Jakob
2010/3/17 Sertic Mirko, Bedag <Mi...@bedag.ch>
> Hi@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
>
>
>
>
Re: MyFaces 1.2.6, JBoss PortletBridge 1.0.0CR3 & Postback with LifeRay
5.2.3
Posted by Michael Freedman <mi...@oracle.com>.
You will need to do a little digging to see if your intuition is right.
Double check the html source in the browser of the page that contains
the commandLink. Does is look like the reference tries to submit the
form that the commandLink is contained within (via javascript)? If so,
can you verify this is actually occuring over the wire by using
javascript debugging in the browser or a tunneler? If its the correct
form what parameters are being sent? Is this only a problem if you use
MyFaces (vs. Mojarra)
FYI its not unusual for the portal page containing the portlet to output
its own markup (within forms) -- and hence the likely cause of having
multiple forms in the client page -- it should not be impacting your usage.
-Mike-
On 3/17/2010 8:37 AM, Sertic Mirko, Bedag wrote:
> Hi@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
>
>
>
>
>
Re: MyFaces 1.2.6, JBoss PortletBridge 1.0.0CR3 & Postback with
LifeRay 5.2.3
Posted by Michael Freedman <mi...@oracle.com>.
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 <Mi...@bedag.ch>
>
>
>> Hi@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
>>
>>
>>
>>
>>
>
>
Re: MyFaces 1.2.6, JBoss PortletBridge 1.0.0CR3 & Postback with
LifeRay 5.2.3
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <Mi...@bedag.ch>
> Hi@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
>
>
>
>