[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603472#action_12603472
]
Scott O'Bryan commented on PORTLETBRIDGE-35:
--------------------------------------------
Angel, JSR-301 clearly dictates the behavior of the parameters on the
ActionRequest and as far as I know, the MyFaces Portlet Bridge implements this
correctly. I noticed in the environment that you stated that you are using
MyFaces 1.1.6. The MyFaces Portlet Bridge referenced by this JIRA project is
being developed as the R.I. for JSR-301 and it has a minimum Technical
Requirement of JSF 1.2, it will not work with JSF 1.1...
If you are using the bridge built into MyFaces 1.1.6 (which predates JSR-301),
bugs are logged against the MyFaces Core project under the portal component.
If this is the environment your running under, then you'll want to re-log this
ticket under that project but understand the following comments. Some portals
do preserve request scope between action requests and subsequent render
requests. The JSR-168 doesn't say either way and it's been interpreted both
ways. IMO, not preserving request attributes from action to render makes these
attributes utterly pointless. Nonetheless, because of differences in
containers JSR-301 attempts to clarify this behavior from a bridge standpoint.
Within the 301 EG, this subject was a manner of much debate and what we came up
with was, what I consider to be, the only viable way of handling this for the
majority of applications. In either case, people using the MyFaces 1.1 bridge
already count on this behavior as-is and we've rejected this type of
enhancement to the old bridge code as a result of this change in behavior.
Nonetheless, if you want to file this bug against the 1.1 bridge, I suggest
reading the JSR-301 specification and suggest a solution much like the JSR-301
bridge defines. There may even be an open bug out there. But doing session
management in this fashion is probably your best bet and will allow you to more
easily move to a JSR-301 bridge in the future.
I'm going to close this bug right now, but if you are using JSF 1.2 (either the
R.I. or MyFaces 1.2.x) and the Portlet Bridge then please reopen this bug and
we'll evaluate why it's not working as intended. If this is indeed using the
MyFaces 1.1.6 Bridge, refile this bug under the MyFaces core..
> request parameters are not preserved and persisted from the action to the
> render request
> ----------------------------------------------------------------------------------------
>
> Key: PORTLETBRIDGE-35
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-35
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-alpha, 1.0.0-alpha-2, 1.0.0, 2.0.0
> Environment: Myfaces 1.1.6 , WebLogic Portal 10.0 , Windows 2003
> Server
> Reporter: Angel Todorov
> Priority: Critical
> Fix For: 1.0.0-alpha, 1.0.0-alpha-2, 1.0.0, 2.0.0
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> When the Myfaces portlet bridge is used , and parameters are stored in the
> initial request, they are not preserved, and the backend cannot reliably
> obtain these parameters. This happens because normally in a portlet (JSR-168)
> environment there are two requests - the action request, and the render
> request. The problem is that the myfaces portlet bridge does not "transfer"
> all of these request parameters from the action to the render request.
> For example if I would like to use any AJAX framework that saves the ajax
> components that need to be re-rendered, in the request, this won't work in a
> portlet environment.
> The solution is to get all request params in the action request, store them
> in an object with a bigger scope than request scope, and then retrieve these
> parameters in the render request, so that they are available to any entity on
> the "backend" that can access the PortletContext / Servlet context.
> What about storing these in the PortletSession object?
> Thanks,
> Angel
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
