You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Michael Lipp (JIRA)" <de...@myfaces.apache.org> on 2005/11/14 14:05:28 UTC
[jira] Created: (MYFACES-821) Usage of request attributes for caching
Usage of request attributes for caching
---------------------------------------
Key: MYFACES-821
URL: http://issues.apache.org/jira/browse/MYFACES-821
Project: MyFaces
Type: Bug
Versions: 1.1.0
Environment: liferay 3.6.1
Reporter: Michael Lipp
Priority: Blocker
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-821) Usage of request attributes for
caching
Posted by "Anonymous (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=all ]
updated MYFACES-821:
---------------------
Status: Patch Available (was: Open)
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> Project: MyFaces Core
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-821) Usage of request attributes for
caching
Posted by "Stan Silvert (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365479 ]
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 <st...@hursley.ibm.com>
To: Julien Viet <ju...@jboss.com>
References: <43...@jboss.com>
Hi Julien,
sure, I can clearify that attributes are only valid within one object and not shared across objects.
Stefan
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 https://issues.apache.org/jira/browse/MYFACES-1024
>
> 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: http://issues.apache.org/jira/browse/MYFACES-821
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-821) Usage of request attributes for
caching
Posted by "Stan Silvert (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365439 ]
Stan Silvert commented on MYFACES-821:
--------------------------------------
Hi Michael,
I understand what you are saying. You are correct that the spec does allow LifeRay some wiggle room in this regard. LifeRay complies with the letter of the spec, but not its spirit. As I stated before, a portlet should be a self-contained unit. The fact that LifeRay allows request attributes to "leak" into another portlet tells me that LifeRay is doing something wrong - even though they have technically followed the letter of the spec.
Even if we fixed this in MyFaces, there is no assurance that another portlet will not cause the same kind of name collision on its own. What you are saying is that if I put two portlets on a page then I have to know every request attribute that might be set in each portlet. Then I must manually check for name collisions. That doesn't make any sense at all. I might not even have the portlet source code.
I only know the behavior of three containers in regard to this issue. They are JBoss Portal, LifeRay, and Pluto. Of the three, LifeRay is the only one that exhibits the problem. The fact that Pluto does make sure that request attributes scoped, bolsters my argument because Pluto is the reference implementation.
The real solution to this problem is to get a ruling from the portlet expert group. I will try to get an official statement out of them.
Stan
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-821) Usage of request attributes for caching
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=all ]
Martin Marinschek updated MYFACES-821:
--------------------------------------
Priority: Major (was: Blocker)
I am reducing this to major as it only affects portal users - and in fact is rather something that should be solved for JSF in general and not only MyFaces.
regards,
Martin
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> Project: MyFaces
> Type: Bug
> Versions: 1.1.0
> Environment: liferay 3.6.1
> Reporter: Michael Lipp
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-821) Usage of request attributes for
caching
Posted by "Mike Kienenberger (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=all ]
Mike Kienenberger updated MYFACES-821:
--------------------------------------
Status: Open (was: Patch Available)
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> Project: MyFaces Core
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-821) Usage of request attributes for
caching
Posted by "Michael Lipp (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365405 ]
Michael Lipp commented on MYFACES-821:
--------------------------------------
On the contrary! English may not be my first language, but I tend to rely on my logical thinking. JSR-168, including the errata, states that an implementor may not rely on one portlet's request attributes being available in another portlet. But this does not imply that a container MUST do scoping of attributes. It MAY do, and obviously some do it, others don't.
I have pointed out a problem with MyFaces bridge running in Liferay. Like it or not, Liferay behaves according to specs (at least in this respect). If MyFaces bridge wants to be portable among all JSR-168 compliant portlet containers, this is a bug that needs to be fixed (the fix is easy and can be found in my sources, though as Martin has pointed out, the view-id is not a unique model instance, but surely there is such a thing). If MyFaces bridge is specified to support only a subset of JSR-168 compliant portlet containers, this is only a request for improvement. But then MyFaces should clearly state which JSR-168 compliant containers it is known not to support, so that others do not run into this problem. Believe me, while the fix was easy (and works well for me though it may be incomplete), it took me a long time to find the cause, so this is not a trivial issue.
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-821) Usage of request attributes for
caching
Posted by "Tanju Erinmez (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12373736 ]
Tanju Erinmez commented on MYFACES-821:
---------------------------------------
Greetings,
Just wanted to let you know that things have moved again and this particular problem (which has haunted me, too in MYFACES-660) is supposed to be resolved in the newest Liferay 4.0.0 version. (see also http://support.liferay.com/browse/LEP-287 ).
Resolution (though have not tried), is mention at http://www.theserverside.com/news/thread.tss?thread_id=39830#205741 and consists of setting the following parameters accordingly in your liferay-portlet.xml:
use-portal-class-loader
private-request-attributes
Enjoy,
Tanju
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> Project: MyFaces Core
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (MYFACES-821) Usage of request attributes for
caching
Posted by "Stan Silvert (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=all ]
Stan Silvert closed MYFACES-821:
--------------------------------
Resolution: Won't Fix
This is a problem in LifeRay. The latest version has a fix.
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> Project: MyFaces Core
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-821) Usage of request attributes for
caching
Posted by "Michael Lipp (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365442 ]
Michael Lipp commented on MYFACES-821:
--------------------------------------
The approach to get a ruling from the expert group is OK. It gives us (the users) something to show to Liferay support.
Pluto being the reference implementation and providing scoping does not really help. Even a reference implementation may go beyond the minimum requirements and provide features that MAY be implemented.
Of course, any portlet that does not observe the specs is a thread. But because the spec is as it is, I do program all my portlets in such a way that they can handle the situation that the spec implies -- though I don't like the burden imposed on me by the spec.
What I still do not really understand is why it should be so difficult to prevent the name collition in the MyFaces bridge. A simple unique id of the JSF model instance is sufficient. But this is only an issue if the expert group does not support your point of view.
I'm really curious about the expert group's statement.
Michael
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-821) Usage of request attributes for caching
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12361180 ]
Martin Marinschek commented on MYFACES-821:
-------------------------------------------
On the issue itself - how would prepending the viewid solve the issue?
What if you have two portlets of the same jsf-app on the same page, and they are on the same view-id in the moment?
Your solution sounds reasonable - but doesn't go far enough, cause the client won't know anything about this, and will send the request attributes in just as they were set originally?
regards,
Martin
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> Project: MyFaces
> Type: Bug
> Versions: 1.1.0
> Environment: liferay 3.6.1
> Reporter: Michael Lipp
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-821) Usage of request attributes for caching
Posted by "Michael Lipp (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12361210 ]
Michael Lipp commented on MYFACES-821:
--------------------------------------
Mmh, the problem is that I have looked into this more than a month ago, and as a lot has happened since, it is a bit hard to remember the details. I'm afraid, all I can do just now is point you to my code at http://cvs.sourceforge.net/viewcvs.py/wfmopen/wfmopen/src/de/danet/an/util/jsf/MyFacesAdaptedPortlet.java?rev=1.13&view=log
As far as the view-id is concerned: I have assumed that the view-id is a unique id for JSF model instances. If the view-id isn't, something else must be...
Regards,
Michael
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> Project: MyFaces
> Type: Bug
> Versions: 1.1.0
> Environment: liferay 3.6.1
> Reporter: Michael Lipp
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-821) Usage of request attributes for
caching
Posted by "Stan Silvert (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365358 ]
Stan Silvert commented on MYFACES-821:
--------------------------------------
I contend that the spec actually does at least imply that request attributes are scoped to a single portlet. To do otherwise breaks the whole idea that a portlet is a single application unit with its own environment. The relevant section of the spec is PLT 11.4. Also, this part of the spec has been clarified by the expert group here: http://www.jcp.org/aboutJava/communityprocess/maintenance/jsr168/Portlet1.0-ERRATA.html#issue10
Even this is not quite clear enough and it should be further clarified by the portlet EG.
As of now, I see no reason to change anything in MyFaces for this. I know of at least two Portlet containers that take care of the scoping already. Surely it would not be that hard for LifeRay to do so as well.
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira