You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by JS Portal Support <su...@jsportal.com> on 2007/05/22 11:57:06 UTC
Remoting changes with viewState
Hi,
I'm using remoting and it works great! But unfortunately if I have a page
load partial content though remoting, the request seems to change the
underlying viewState of the JSF view.
I'm using the :
<context-param>
<param-name>org.apache.shale.remoting.FACES_SERVLET_MAPPING_INDEX</param-nam
e>
<param-value>1</param-value>
</context-param>
To point to the *.resources mapping:
<servlet-mapping>
<servlet-name>faces</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>faces</servlet-name>
<url-pattern>*.resources</url-pattern>
</servlet-mapping>
When a call to my resource
/dynamic/runableEntityHandler/getTaskExtraInfo.resources is made my log
shows:
exiting from lifecycle.execute in RESTORE_VIEW(1) because
getResponseComplete is true from one of the after listeners
exiting from lifecycle.execute in RENDER_RESPONSE(6) because
getResponseComplete is true from one of the before listeners
When then I use my page navigation which points to a simple JSF navigation
rule, it reloads the current view in stead of navigating to the new page.
When tried a second time (without using the remoting) the navigation
succeeds.
I have this need-to-click-twice-to-navigate in more situations and it must
have something to do with the underlying JSF viewState. I think there is a
concept here I'm missing, but I don't know what. Can anyone give me some
pointers as to where my problem lies?
Thank you,
joost
Re: Remoting changes with viewState
Posted by Craig McClanahan <cr...@apache.org>.
On 5/22/07, JS Portal Support <su...@jsportal.com> wrote:
> >Why not just try:
> >
> >/dynamic/runableEntityHandler/getTaskExtraInfo.jsf
>
> I tried this initially and since that caused problems, I thought I'd follow
> the example from the shale-usecases. I changed it back and the problem
> persists. So I guess the problem must lie somewheer else than.
>
> Would you suggest raising this issue in the myfaces list?
>
It might be advisable to first figure out what is causing your "double
submit" issues. The most common scenario I have seen for that is if
you have validators on some of your input components, but have not
provided a message component to display the errors -- the page will
just redisplay in that case.
Also, does the usecases app work for you? Using MyFaces? Without
double submits? (It does for me.) If it does for you as well, then
there is something else in your code that is triggering issues, and
can be investigated from there.
Craig
> Thanks,
> Joost
>
>
> -----Original Message-----
> From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of Craig
> McClanahan
> Sent: Wednesday, May 23, 2007 8:27 AM
> To: user@shale.apache.org
> Subject: Re: Remoting changes with viewState
>
> I haven't heavily tested multiple JSF servlet mappings, but it seems
> likely that there might be issues in the JSF implementation itself
> with that. Since you are using prefix mapping for your resources, why
> not just try:
>
> /dynamic/runableEntityHandler/getTaskExtraInfo.jsf
>
> instead?
>
> Craig
>
>
>
> On 5/22/07, JS Portal Support <su...@jsportal.com> wrote:
> > Hi,
> >
> > I'm using remoting and it works great! But unfortunately if I have a page
> > load partial content though remoting, the request seems to change the
> > underlying viewState of the JSF view.
> >
> > I'm using the :
> >
> > <context-param>
> >
> >
> <param-name>org.apache.shale.remoting.FACES_SERVLET_MAPPING_INDEX</param-nam
> > e>
> > <param-value>1</param-value>
> > </context-param>
> >
> > To point to the *.resources mapping:
> >
> > <servlet-mapping>
> > <servlet-name>faces</servlet-name>
> > <url-pattern>*.jsf</url-pattern>
> > </servlet-mapping>
> > <servlet-mapping>
> > <servlet-name>faces</servlet-name>
> > <url-pattern>*.resources</url-pattern>
> > </servlet-mapping>
> >
> > When a call to my resource
> > /dynamic/runableEntityHandler/getTaskExtraInfo.resources is made my log
> > shows:
> >
> > exiting from lifecycle.execute in RESTORE_VIEW(1) because
> > getResponseComplete is true from one of the after listeners
> > exiting from lifecycle.execute in RENDER_RESPONSE(6) because
> > getResponseComplete is true from one of the before listeners
> >
> > When then I use my page navigation which points to a simple JSF navigation
> > rule, it reloads the current view in stead of navigating to the new page.
> > When tried a second time (without using the remoting) the navigation
> > succeeds.
> >
> > I have this need-to-click-twice-to-navigate in more situations and it must
> > have something to do with the underlying JSF viewState. I think there is a
> > concept here I'm missing, but I don't know what. Can anyone give me some
> > pointers as to where my problem lies?
> >
> > Thank you,
> > joost
> >
> >
>
>
>
RE: Remoting changes with viewState
Posted by JS Portal Support <su...@jsportal.com>.
>Why not just try:
>
>/dynamic/runableEntityHandler/getTaskExtraInfo.jsf
I tried this initially and since that caused problems, I thought I'd follow
the example from the shale-usecases. I changed it back and the problem
persists. So I guess the problem must lie somewheer else than.
Would you suggest raising this issue in the myfaces list?
Thanks,
Joost
-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of Craig
McClanahan
Sent: Wednesday, May 23, 2007 8:27 AM
To: user@shale.apache.org
Subject: Re: Remoting changes with viewState
I haven't heavily tested multiple JSF servlet mappings, but it seems
likely that there might be issues in the JSF implementation itself
with that. Since you are using prefix mapping for your resources, why
not just try:
/dynamic/runableEntityHandler/getTaskExtraInfo.jsf
instead?
Craig
On 5/22/07, JS Portal Support <su...@jsportal.com> wrote:
> Hi,
>
> I'm using remoting and it works great! But unfortunately if I have a page
> load partial content though remoting, the request seems to change the
> underlying viewState of the JSF view.
>
> I'm using the :
>
> <context-param>
>
>
<param-name>org.apache.shale.remoting.FACES_SERVLET_MAPPING_INDEX</param-nam
> e>
> <param-value>1</param-value>
> </context-param>
>
> To point to the *.resources mapping:
>
> <servlet-mapping>
> <servlet-name>faces</servlet-name>
> <url-pattern>*.jsf</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>faces</servlet-name>
> <url-pattern>*.resources</url-pattern>
> </servlet-mapping>
>
> When a call to my resource
> /dynamic/runableEntityHandler/getTaskExtraInfo.resources is made my log
> shows:
>
> exiting from lifecycle.execute in RESTORE_VIEW(1) because
> getResponseComplete is true from one of the after listeners
> exiting from lifecycle.execute in RENDER_RESPONSE(6) because
> getResponseComplete is true from one of the before listeners
>
> When then I use my page navigation which points to a simple JSF navigation
> rule, it reloads the current view in stead of navigating to the new page.
> When tried a second time (without using the remoting) the navigation
> succeeds.
>
> I have this need-to-click-twice-to-navigate in more situations and it must
> have something to do with the underlying JSF viewState. I think there is a
> concept here I'm missing, but I don't know what. Can anyone give me some
> pointers as to where my problem lies?
>
> Thank you,
> joost
>
>
Re: Remoting changes with viewState
Posted by Craig McClanahan <cr...@apache.org>.
I haven't heavily tested multiple JSF servlet mappings, but it seems
likely that there might be issues in the JSF implementation itself
with that. Since you are using prefix mapping for your resources, why
not just try:
/dynamic/runableEntityHandler/getTaskExtraInfo.jsf
instead?
Craig
On 5/22/07, JS Portal Support <su...@jsportal.com> wrote:
> Hi,
>
> I'm using remoting and it works great! But unfortunately if I have a page
> load partial content though remoting, the request seems to change the
> underlying viewState of the JSF view.
>
> I'm using the :
>
> <context-param>
>
> <param-name>org.apache.shale.remoting.FACES_SERVLET_MAPPING_INDEX</param-nam
> e>
> <param-value>1</param-value>
> </context-param>
>
> To point to the *.resources mapping:
>
> <servlet-mapping>
> <servlet-name>faces</servlet-name>
> <url-pattern>*.jsf</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>faces</servlet-name>
> <url-pattern>*.resources</url-pattern>
> </servlet-mapping>
>
> When a call to my resource
> /dynamic/runableEntityHandler/getTaskExtraInfo.resources is made my log
> shows:
>
> exiting from lifecycle.execute in RESTORE_VIEW(1) because
> getResponseComplete is true from one of the after listeners
> exiting from lifecycle.execute in RENDER_RESPONSE(6) because
> getResponseComplete is true from one of the before listeners
>
> When then I use my page navigation which points to a simple JSF navigation
> rule, it reloads the current view in stead of navigating to the new page.
> When tried a second time (without using the remoting) the navigation
> succeeds.
>
> I have this need-to-click-twice-to-navigate in more situations and it must
> have something to do with the underlying JSF viewState. I think there is a
> concept here I'm missing, but I don't know what. Can anyone give me some
> pointers as to where my problem lies?
>
> Thank you,
> joost
>
>