myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stan Silvert (JIRA)" <>
Subject [jira] Commented: (MYFACES-821) Usage of request attributes for caching
Date Tue, 07 Feb 2006 20:03:58 GMT
    [ ] 

Stan Silvert commented on MYFACES-821:

I asked the JBoss Portal lead to contact the Expert Group.  The portlet spec lead, Stefan
Hepper, indicated that my reading of the spec is correct.

I don't know if they will be making a formal change or not.  However, you can at least tell
LifeRay that Stefan says that attributes should not be shared.  Here is the email exchange:

-------- Original Message --------
Subject: Re: portlet clatification
Date: Tue, 07 Feb 2006 17:50:47 +0100
From: Stefan Hepper <>
To: Julien Viet <>
References: <>

Hi Julien,
sure, I can clearify that attributes are only valid within one object and not shared across


Julien Viet wrote:
> Hello Stephan,
> I have been pinged by one of our developer that is also a developer of 
> myfaces. I understand and agree with his point that is that they need 
> a clarification about request attributes : all request attributes 
> setup by the portlet during its lifecycle should be cleared when the 
> portlet exit the invocation of render or processAction.
> see
> can I rethrow the same subject on the JSR 286 list or should I wait a 
> more appropriate time to raise the hand about it ?

Julien Viet
JBoss Portal Project Lead

> Usage of request attributes for caching
> ---------------------------------------
>          Key: MYFACES-821
>          URL:
>      Project: MyFaces
>         Type: Bug
>     Versions: 1.1.0
>  Environment: liferay 3.6.1
>     Reporter: Michael Lipp
>     Assignee: Stan Silvert

> JspStateManagerImpl (and maybe other classes) uses request attributes for caching state.
This causes a wrong view to be used if there is more than one JSF-based portlet on a single
page. MyFaces saves the serialized view of the first portlet on the page as a request attribute.
To avoid re-serialization, MyFaces subsequently checks if there already is a request attribute
with a serialized view. As request attributes are not scoped to a single portlet (the portlet
specification does not require this), the serialized view of the first portlet will be found
and used by the second portlet.
> This usage of request attributes may also be the cause of MYFACES-549.
> As JSF, of course, does not need to know about the portlet environment, it cannot be
required that MyFaces saves such information "per view", e.g. by prepending the viewId to
the key for the request attribute (although this would solve the problem). IMHO any request
attributes added during lifecycle.render() should be removed after lifecycle() render by the
portlet bridge. (The same applies to request attributes added during lifecycle.execute(),
but these should also be re-added before lifecycle.render().) I have implemented this in my
portlet bridge as a workaround.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message