You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Bernd Winterstein <be...@winterstein-web.de> on 2008/03/28 12:11:14 UTC
orchestra conversation closed by stylesheet
Hi
I have a one page conversation with access-scope. The page contains
several tabs which are switched by Ajax calls.
The first time the page is loaded the last request is a css download,
upon which orchestra closes the conversation. The following requests
for other tabs works perfect, the conversations stays open.
Mrz 28 11:37:21 DEBUG
org
.apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
invalidateAccessScopedConversations Clearing access-scoped
conversation contactSearchController after rendering view /pages/
doctor_details.jsp
<-- THIS IS OKAY(old page)
Mrz 28 11:37:21 DEBUG
org
.apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
invalidateAccessScopedConversations Not clearing accessed
conversation doctorDetailsController after rendering view /pages/
doctor_details.jsp
<-- THIS IS OKAY(NEW PAGE, CONVERSATION SHOULD STAY OPEN)
Mrz 28 11:37:21 DEBUG
org
.apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
invalidateAccessScopedConversations Clearing access-scoped
conversation doctorDetailsController after rendering view /org/
richfaces/renderkit/html/css/basic_classes.xcss
<-- THIS IS WHAT I DON'T understand
Regards
Bernd
Re: orchestra conversation closed by stylesheet
Posted by Werner Punz <we...@gmail.com>.
simon schrieb:
> On Sun, 2008-03-30 at 20:04 +0200, Werner Punz wrote:
>> Mario Ivankovits schrieb:
>>> Hi!
>>>> Weblets for instance allows a zeroconf resource loading
>>>> via phase listeners which trigger, usually this triggering
>>>> is done before phase1, but there are portlet cases where
>>>> it happens later.
>>> What are the JSF phases executed by weblets then? Probably we find a
>>> pattern which allows us to decide if it was a resource serving.
>>>
>> Hi Mario
>> Weblets usually triggers before the Restore View Phase for non portlet
>> cases and otherwise before the apply request values phase for portlets.
>> There also is a trigger for before render Response to trigger as early
>> as possible for other cases which even suppress those phases.
>>
>> (This seems a little bit unecessry to me probably the last one checking
>> the before render response is needed only I have to recheck that)
>> It simply means trigger asap before even doing any jsf related word.
>>
>> What you probably could do is to ignore requests in your garbage
>> collection of the page context, which trigger the lifecycle but do not
>> go through the phase properly, aka terminate early, that way you
>> probably could cover at least 95% of all use cases.
>
> Werner, Orchestra already does ignore requests that "terminate early".
>
> All the orchestra cleanup of access-scoped conversations is handled by a
> phase listener that runs only in post-render. That's enough to work
> correctly with Tomahawk PPR requests for example; they use a pre-render
> phase-listener that stops the lifecycle at that point, meaning that no
> access conversations get discarded.
>
> If weblets doesn't run the post-render phase, then Orchestra will have
> no problems with it either.
>
> The problem with richfaces is that it appears from the original post
> that it runs a completely normal JSF lifecycle, including all the
> post-render phase listeners when rendering its custom resources (the
> ".xcss" file in this case).
>
> I wonder what "viewId" it uses when processing the stylesheet request.
> Does the server see a request for viewId "foo.jsf", then suddenly a
> request for viewId "foo.xcss", then later the postback for "foo.jsf"
> again? I presume so; seems odd to me though. Wouldn't that stuff up a
> number of different backbutton/breadcrumb type systems? And what about
> things like Spring WebFlow that have a strict state-machine of allowed
> navigation flows?
>
Not sure if this is really orchestras problem, best guess probably is to
contact Sergeij from Exadel if this is a richfaces bug.
Cheers
Werner
Re: orchestra conversation closed by stylesheet
Posted by simon <si...@chello.at>.
On Sun, 2008-03-30 at 20:04 +0200, Werner Punz wrote:
> Mario Ivankovits schrieb:
> > Hi!
> >> Weblets for instance allows a zeroconf resource loading
> >> via phase listeners which trigger, usually this triggering
> >> is done before phase1, but there are portlet cases where
> >> it happens later.
> > What are the JSF phases executed by weblets then? Probably we find a
> > pattern which allows us to decide if it was a resource serving.
> >
> Hi Mario
> Weblets usually triggers before the Restore View Phase for non portlet
> cases and otherwise before the apply request values phase for portlets.
> There also is a trigger for before render Response to trigger as early
> as possible for other cases which even suppress those phases.
>
> (This seems a little bit unecessry to me probably the last one checking
> the before render response is needed only I have to recheck that)
> It simply means trigger asap before even doing any jsf related word.
>
> What you probably could do is to ignore requests in your garbage
> collection of the page context, which trigger the lifecycle but do not
> go through the phase properly, aka terminate early, that way you
> probably could cover at least 95% of all use cases.
Werner, Orchestra already does ignore requests that "terminate early".
All the orchestra cleanup of access-scoped conversations is handled by a
phase listener that runs only in post-render. That's enough to work
correctly with Tomahawk PPR requests for example; they use a pre-render
phase-listener that stops the lifecycle at that point, meaning that no
access conversations get discarded.
If weblets doesn't run the post-render phase, then Orchestra will have
no problems with it either.
The problem with richfaces is that it appears from the original post
that it runs a completely normal JSF lifecycle, including all the
post-render phase listeners when rendering its custom resources (the
".xcss" file in this case).
I wonder what "viewId" it uses when processing the stylesheet request.
Does the server see a request for viewId "foo.jsf", then suddenly a
request for viewId "foo.xcss", then later the postback for "foo.jsf"
again? I presume so; seems odd to me though. Wouldn't that stuff up a
number of different backbutton/breadcrumb type systems? And what about
things like Spring WebFlow that have a strict state-machine of allowed
navigation flows?
Regards,
Simon
Re: orchestra conversation closed by stylesheet
Posted by Werner Punz <we...@gmail.com>.
Mario Ivankovits schrieb:
> Hi!
>> Weblets for instance allows a zeroconf resource loading
>> via phase listeners which trigger, usually this triggering
>> is done before phase1, but there are portlet cases where
>> it happens later.
> What are the JSF phases executed by weblets then? Probably we find a
> pattern which allows us to decide if it was a resource serving.
>
Hi Mario
Weblets usually triggers before the Restore View Phase for non portlet
cases and otherwise before the apply request values phase for portlets.
There also is a trigger for before render Response to trigger as early
as possible for other cases which even suppress those phases.
(This seems a little bit unecessry to me probably the last one checking
the before render response is needed only I have to recheck that)
It simply means trigger asap before even doing any jsf related word.
What you probably could do is to ignore requests in your garbage
collection of the page context, which trigger the lifecycle but do not
go through the phase properly, aka terminate early, that way you
probably could cover at least 95% of all use cases.
Werner
Re: orchestra conversation closed by stylesheet
Posted by Martin Marinschek <ma...@gmail.com>.
> @Mario: your comment makes sense, we all should certainly try to work
> around bugs in other libraries!
.... cause else, our users will have to do it, and this we will want to prevent.
regards,
Martin
Re: orchestra conversation closed by stylesheet
Posted by Martin Marinschek <ma...@gmail.com>.
To sum it up: Orchestra is certainly not to blame here, this is a
RichFaces bug.
@Mario: your comment makes sense, we all should certainly try to work
around bugs in other libraries!
regards,
Martin
On Tue, Apr 1, 2008 at 12:38 AM, Scott O'Bryan <da...@gmail.com> wrote:
> Configurators work off of a custom FacesContext. It works very well.
>
>
>
> Mario Ivankovits wrote:
>
> > Hi!
> >
> >
> > > Weblets for instance allows a zeroconf resource loading
> > > via phase listeners which trigger, usually this triggering
> > > is done before phase1, but there are portlet cases where
> > > it happens later.
> > >
> > >
> > What are the JSF phases executed by weblets then? Probably we find a
> > pattern which allows us to decide if it was a resource serving.
> >
> > Ciao,
> > Mario
> >
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: orchestra conversation closed by stylesheet
Posted by Scott O'Bryan <da...@gmail.com>.
Configurators work off of a custom FacesContext. It works very well.
Mario Ivankovits wrote:
> Hi!
>
>> Weblets for instance allows a zeroconf resource loading
>> via phase listeners which trigger, usually this triggering
>> is done before phase1, but there are portlet cases where
>> it happens later.
>>
> What are the JSF phases executed by weblets then? Probably we find a
> pattern which allows us to decide if it was a resource serving.
>
> Ciao,
> Mario
>
>
Re: orchestra conversation closed by stylesheet
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Weblets for instance allows a zeroconf resource loading
> via phase listeners which trigger, usually this triggering
> is done before phase1, but there are portlet cases where
> it happens later.
What are the JSF phases executed by weblets then? Probably we find a
pattern which allows us to decide if it was a resource serving.
Ciao,
Mario
Re: orchestra conversation closed by stylesheet
Posted by Werner Punz <we...@gmail.com>.
Hi Mario this is not weird at all,
usually this technique is used
by resource loading frameworks if they want to provide
some automatisms.
Weblets for instance allows a zeroconf resource loading
via phase listeners which trigger, usually this triggering
is done before phase1, but there are portlet cases where
it happens later.
Weblets has a servlet fallback to bypass eventual problems.
But we might have a similar case here, the resource
loading of richfaces also might use a phase listener or view handler hence
being triggered by the faces servlet.
Werner
Mario Ivankovits schrieb:
> Hi!
>> many thanks for your tips. I checked the phase-listener solution, but
>> it's a little dirty.
>> The resource request skips phases 2-5. And the after RESTORE_VIEW
>> callback is not called.
>> In the before callback I do not know how to get the view id. As a
>> solution i check the source component of the phase event.
>> If it starts with org.ajax4jsf.resource.ResourceLifecycle I tell
>> orchestra to ignore the request.
> It is really weird that serving a resource kicks in the jsf lifecycle.
> However, I think the first thing to do is to allow using regexp to match
> the request one would like to ignore.
> The second thing we (probably) should do is to ignore "well known"
> requests. Even if it is weird, I'd like to see Orchestra dealing with
> these requests out of the box. Nothing is more depressive than a library
> you would like to use which just do not (easily) work in you
> environment. JSF 2.0 might make things easier as then serving a resource
> is more standardized ... lets hope everyone is following that spec then.
>
>> It's not beautiful but it seems to work.
> Yepp ... and it would not be any more beautiful if Orchestra do it that
> way, but if there is no other way ... well ... what the heck ... letz
> check for that thing.
> Would be great if you could post your final solution so that we could
> consider using it in Orchestra.
>
> Ciao,
> Mario
>
>
Re: orchestra conversation closed by stylesheet
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> many thanks for your tips. I checked the phase-listener solution, but
> it's a little dirty.
> The resource request skips phases 2-5. And the after RESTORE_VIEW
> callback is not called.
> In the before callback I do not know how to get the view id. As a
> solution i check the source component of the phase event.
> If it starts with org.ajax4jsf.resource.ResourceLifecycle I tell
> orchestra to ignore the request.
It is really weird that serving a resource kicks in the jsf lifecycle.
However, I think the first thing to do is to allow using regexp to match
the request one would like to ignore.
The second thing we (probably) should do is to ignore "well known"
requests. Even if it is weird, I'd like to see Orchestra dealing with
these requests out of the box. Nothing is more depressive than a library
you would like to use which just do not (easily) work in you
environment. JSF 2.0 might make things easier as then serving a resource
is more standardized ... lets hope everyone is following that spec then.
> It's not beautiful but it seems to work.
Yepp ... and it would not be any more beautiful if Orchestra do it that
way, but if there is no other way ... well ... what the heck ... letz
check for that thing.
Would be great if you could post your final solution so that we could
consider using it in Orchestra.
Ciao,
Mario
Re: orchestra conversation closed by stylesheet
Posted by Bernd Winterstein <be...@winterstein-web.de>.
Hi Simon,
many thanks for your tips. I checked the phase-listener solution, but
it's a little dirty.
The resource request skips phases 2-5. And the after RESTORE_VIEW
callback is not called.
In the before callback I do not know how to get the view id. As a
solution i check the source component of the phase event.
If it starts with org.ajax4jsf.resource.ResourceLifecycle I tell
orchestra to ignore the request.
It's not beautiful but it seems to work.
Bernd
Am 28.03.2008 um 14:11 schrieb simon:
> Hi Bernd,
>
> On Fri, 2008-03-28 at 12:11 +0100, Bernd Winterstein wrote:
>> Hi
>> I have a one page conversation with access-scope. The page contains
>> several tabs which are switched by Ajax calls.
>> The first time the page is loaded the last request is a css download,
>> upon which orchestra closes the conversation. The following requests
>> for other tabs works perfect, the conversations stays open.
>>
>>
>> Mrz 28 11:37:21 DEBUG
>> org
>> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
>> invalidateAccessScopedConversations Clearing access-scoped
>> conversation contactSearchController after rendering view /pages/
>> doctor_details.jsp
>> <-- THIS IS OKAY(old page)
>>
>> Mrz 28 11:37:21 DEBUG
>> org
>> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
>> invalidateAccessScopedConversations Not clearing accessed
>> conversation doctorDetailsController after rendering view /pages/
>> doctor_details.jsp
>> <-- THIS IS OKAY(NEW PAGE, CONVERSATION SHOULD STAY OPEN)
>>
>>
>> Mrz 28 11:37:21 DEBUG
>> org
>> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
>> invalidateAccessScopedConversations Clearing access-scoped
>> conversation doctorDetailsController after rendering view /org/
>> richfaces/renderkit/html/css/basic_classes.xcss
>> <-- THIS IS WHAT I DON'T understand
>
> You appear to have the suffix ".xcss" mapped to the FacesServlet, ie
> that full facelets lifecycle (including phase listeners) is being run
> when serving up that css file.
>
> That's not usual; normally a css is a static resource, and is not
> served by the FacesServlet. Therefore the jsf phase-listeners do not
> run and this will not occur. I suppose it's some odd RichFaces
> feature that requires a JSF lifecycle to serve a css file.
>
> Orchestra's AccessScopeManagerConfiguration class can be configured
> in spring to ignore specific view names:
>
> <bean
>
> name
> =
> "org
> .apache
> .myfaces.orchestra.conversation.AccessScopeManagerConfiguration"
>
> class
> =
> "org
> .apache
> .myfaces.orchestra.conversation.AccessScopeManagerConfiguration"
> scope="singleton">
> ... define set of views to ignore here ...
> </bean>
>
> However currently this supports only fixed view names, not patterns
> like "*.xcss", so this doesn't help in your case.
>
> The AccessScopePhaseListener does also ignore requests, however, if
> AccessScopeManager.getInstance().setIgnoreRequest()
> has been called. So I suggest that you add a phase-listener which
> just checks the current view-id, and if it ends with ".xcss" then
> set the ignoreRequest state on the AccessScopeManager. Note that
> this is just a request-scoped object, so there is no need to "reset"
> the state.
>
> Regards,
> Simon
>
>
> See file spring-orchestra-init.xml within the orchestra jar for some
> further details.
>
> The AccessScopePhaseLinstener.
>
> Hmm..
> So for now, you probably need to subclass the AccessScopeManager
> class itself,
>
>
Re: orchestra conversation closed by stylesheet
Posted by simon <si...@chello.at>.
Hi Bernd,
On Fri, 2008-03-28 at 12:11 +0100, Bernd Winterstein wrote:
> Hi
> I have a one page conversation with access-scope. The page contains
> several tabs which are switched by Ajax calls.
> The first time the page is loaded the last request is a css download,
> upon which orchestra closes the conversation. The following requests
> for other tabs works perfect, the conversations stays open.
>
>
> Mrz 28 11:37:21 DEBUG
> org
> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
> invalidateAccessScopedConversations Clearing access-scoped
> conversation contactSearchController after rendering view /pages/
> doctor_details.jsp
> <-- THIS IS OKAY(old page)
>
> Mrz 28 11:37:21 DEBUG
> org
> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
> invalidateAccessScopedConversations Not clearing accessed
> conversation doctorDetailsController after rendering view /pages/
> doctor_details.jsp
> <-- THIS IS OKAY(NEW PAGE, CONVERSATION SHOULD STAY OPEN)
>
>
> Mrz 28 11:37:21 DEBUG
> org
> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
> invalidateAccessScopedConversations Clearing access-scoped
> conversation doctorDetailsController after rendering view /org/
> richfaces/renderkit/html/css/basic_classes.xcss
> <-- THIS IS WHAT I DON'T understand
You appear to have the suffix ".xcss" mapped to the FacesServlet, ie
that full facelets lifecycle (including phase listeners) is being run
when serving up that css file.
That's not usual; normally a css is a static resource, and is not served by the FacesServlet. Therefore the jsf phase-listeners do not run and this will not occur. I suppose it's some odd RichFaces feature that requires a JSF lifecycle to serve a css file.
Orchestra's AccessScopeManagerConfiguration class can be configured in spring to ignore specific view names:
<bean
name="org.apache.myfaces.orchestra.conversation.AccessScopeManagerConfiguration"
class="org.apache.myfaces.orchestra.conversation.AccessScopeManagerConfiguration"
scope="singleton">
... define set of views to ignore here ...
</bean>
However currently this supports only fixed view names, not patterns like "*.xcss", so this doesn't help in your case.
The AccessScopePhaseListener does also ignore requests, however, if
AccessScopeManager.getInstance().setIgnoreRequest()
has been called. So I suggest that you add a phase-listener which just checks the current view-id, and if it ends with ".xcss" then set the ignoreRequest state on the AccessScopeManager. Note that this is just a request-scoped object, so there is no need to "reset" the state.
Regards,
Simon
See file spring-orchestra-init.xml within the orchestra jar for some further details.
The AccessScopePhaseLinstener.
Hmm..
So for now, you probably need to subclass the AccessScopeManager class itself,