[jira] [Commented] (PORTLETBRIDGE-231) Request Threads can get stuck when Bridge removes a scope
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13589627#comment-13589627 ] Michael Freedman commented on PORTLETBRIDGE-231: Fixed in Trunk for 2.0. Still need to migrate to 3.0. Request Threads can get stuck when Bridge removes a scope - Key: PORTLETBRIDGE-231 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-231 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 1.0.0, 2.0.0, 3.0.0 Reporter: Michael Freedman Assignee: Michael Freedman During the process of removing the scopes associated with a given session when a session is invalidated/released, request threads can become stuck waiting on the scope manager lock because action of iterating over all the objects (and their methods) in the scope to find and then call managed bean predestroy methods occurs while the lock is held. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-233) Add ability to create a dummy ExternalContext
Michael Freedman created PORTLETBRIDGE-233: -- Summary: Add ability to create a dummy ExternalContext Key: PORTLETBRIDGE-233 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-233 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.1, 2.0.1, 3.0.0 Reporter: Michael Freedman Assignee: Michael Freedman Some Faces extensions (Trinidad/ADF) have an initialization scheme that requires they crete a dummy ExternalContext (i.e. a valid ExternalContext that isn't bound to a FacesContext) prior to acquiring/activating a FacesContext. Update our impl to remove dependencies within ExternalContext to a FacesContext in order to support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-233) Add ability to create a dummy ExternalContext
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13589633#comment-13589633 ] Michael Freedman commented on PORTLETBRIDGE-233: Fixed in 2.0.1 (Trunk) code. Need to migrate to 3.0. Add ability to create a dummy ExternalContext - Key: PORTLETBRIDGE-233 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-233 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.1, 2.0.1, 3.0.0 Reporter: Michael Freedman Assignee: Michael Freedman Some Faces extensions (Trinidad/ADF) have an initialization scheme that requires they crete a dummy ExternalContext (i.e. a valid ExternalContext that isn't bound to a FacesContext) prior to acquiring/activating a FacesContext. Update our impl to remove dependencies within ExternalContext to a FacesContext in order to support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-231) Request Threads can get stuck when Bridge removes a scope
Michael Freedman created PORTLETBRIDGE-231: -- Summary: Request Threads can get stuck when Bridge removes a scope Key: PORTLETBRIDGE-231 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-231 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 2.0.0, 1.0.0, 3.0.0 Reporter: Michael Freedman Assignee: Michael Freedman During the process of removing the scopes associated with a given session when a session is invalidated/released, request threads can become stuck waiting on the scope manager lock because action of iterating over all the objects (and their methods) in the scope to find and then call managed bean predestroy methods occurs while the lock is held. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-231) Request Threads can get stuck when Bridge removes a scope
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468125#comment-13468125 ] Michael Freedman commented on PORTLETBRIDGE-231: Fixed in the Oracle branch by having the thread holding the lock merely push the scope being removed onto a queue and then notifies waiting threads. A single (app wide) thread listens/waits to be notified this queue has entries and when its woken up, takes the scope object from the queue and executes the predestroy logic. Request Threads can get stuck when Bridge removes a scope - Key: PORTLETBRIDGE-231 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-231 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 1.0.0, 2.0.0, 3.0.0 Reporter: Michael Freedman Assignee: Michael Freedman During the process of removing the scopes associated with a given session when a session is invalidated/released, request threads can become stuck waiting on the scope manager lock because action of iterating over all the objects (and their methods) in the scope to find and then call managed bean predestroy methods occurs while the lock is held. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-232) Add ability for portlet to clear current request scope.
Michael Freedman created PORTLETBRIDGE-232: -- Summary: Add ability for portlet to clear current request scope. Key: PORTLETBRIDGE-232 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-232 Project: MyFaces Portlet Bridge Issue Type: New Feature Affects Versions: 2.0.1-oracle-PS6 Reporter: Michael Freedman Assignee: Michael Freedman We want to provide an ability for the portlet to tell the bridge to clear the current scope. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-232) Add ability for portlet to clear current request scope.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-232. Resolution: Fixed Bridge now recognizes the attribute org.apache.myfaces.portlet.faces.clearRequestScope. If the value is a Boolean and true then the bridge clears the current scope at the beginning of an event, render, or resource request. Add ability for portlet to clear current request scope. --- Key: PORTLETBRIDGE-232 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-232 Project: MyFaces Portlet Bridge Issue Type: New Feature Affects Versions: 2.0.1-oracle-PS6 Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.1-oracle-PS6 We want to provide an ability for the portlet to tell the bridge to clear the current scope. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-231) Request Threads can get stuck when Bridge removes a scope
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468161#comment-13468161 ] Michael Freedman commented on PORTLETBRIDGE-231: Fixed in Oracle's PS6 branch -- consider migrating to all other branches. Request Threads can get stuck when Bridge removes a scope - Key: PORTLETBRIDGE-231 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-231 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 1.0.0, 2.0.0, 3.0.0 Reporter: Michael Freedman Assignee: Michael Freedman During the process of removing the scopes associated with a given session when a session is invalidated/released, request threads can become stuck waiting on the scope manager lock because action of iterating over all the objects (and their methods) in the scope to find and then call managed bean predestroy methods occurs while the lock is held. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-228) supported-publishing-event and supported-processing-event ordering is incorrect according to portlet-app_2_0.xsd
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-228.
Resolution: Fixed
Fix Version/s: 3.0.0
2.0.1
Updated portlet.xml to switch order of the tags to give correct XML syntax
supported-publishing-event and supported-processing-event ordering is
incorrect according to portlet-app_2_0.xsd
Key: PORTLETBRIDGE-228
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-228
Project: MyFaces Portlet Bridge
Issue Type: TCK Challenge
Components: TCK
Affects Versions: 2.0.0
Environment: N/A
Reporter: Neil Griffin
Assignee: Michael Freedman
Fix For: 2.0.1, 3.0.0
[Test Challenger Name and Company]
Neil Griffin, Liferay, Inc.
[Specification Name(s) and Version(s)]
Portlet 2.0 Bridge for JavaServer™ Faces 1.2
[Test Suite Name and Version]
portlet-bridge-tck-main, v1.0.0
[Exclude List Version]
N/A
[Test Name]
All portlets that invoke Events based IPC.
[Complaint (argument for why test is invalid)]
The portlet-bridge-tck-main/src/main/webapp/portlet.xml descriptor has the
following specified multiple times:
{code}
supported-publishing-event
qname
xmlns:bridge=http://myfaces.apache.org/portlet-bridge/event_ns;bridge:myfaces.apache.org.tck.testEvent/qname
/supported-publishing-event
supported-processing-event
qname
xmlns:bridge=http://myfaces.apache.org/portlet-bridge/event_ns;bridge:myfaces.apache.org.tck.testEvent/qname
/supported-processing-event
{code}
But this is invalid according to the portlet-app_2_0.xsd XML Schema, and it
is causing Liferay Portal to refuse to deploy the portlet.
The fix is to swap the order of each occurrence, so that
supported-processing-event appears before supported-publishing-event.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-227) Bridge Spec and TCK assume that the portlet container implements the post-redirect-get design pattern
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-227.
Resolution: Fixed
Fix Version/s: 3.0.0
2.0.1
Updated portlet.xml to put event tags in correct (syntax) order.
Bridge Spec and TCK assume that the portlet container implements the
post-redirect-get design pattern
-
Key: PORTLETBRIDGE-227
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-227
Project: MyFaces Portlet Bridge
Issue Type: TCK Challenge
Components: TCK
Affects Versions: 2.0.0
Environment: Liferay Portal 6.1.x + Liferay Faces Bridge 3.1.x
Reporter: Neil Griffin
Assignee: Michael Freedman
Fix For: 2.0.1, 3.0.0
[Test Challenger Name and Company]
Neil Griffin, Liferay, Inc.
[Specification Name(s) and Version(s)]
Portlet 2.0 Bridge for JavaServer™ Faces 1.2
[Test Suite Name and Version]
portlet-bridge-tck-main, v1.0.0
[Exclude List Version]
N/A
[Test Name]
TCK TestPage151 (requestMapRequestScopeTest)
[Complaint (argument for why test is invalid)]
Portlet containers like Pluto implement the post-redirect-get design pattern
by having the the ACTION_PHASE and RENDER_PHASE of the portlet lifecycle
execute in two separate user-agent requests. The first request is a POST
(ActionRequest), and the second request is a GET (RenderRequest). As a
natural by-product of this design, request attributes that were set during
the ACTION_PHASE do not survive into the RENDER_PHASE. On a related note, one
of the requirements of the bridge-request-scope is to ensure that
non-excluded attributes do indeed survive into the RENDER_PHASE.
The Liferay portlet container does not implement the post-redirect-get design
pattern. Instead, it executes the ACTION_PHASE and RENDER_PHASE of the
portlet lifecycle all within a single user-agent POST request. Because of
this, the Liferay portlet container maintains request attributes that were
originally set on the {@link ActionRequest} such that they automatically
survive into the {@link RenderRequest}.
Problem Description: The TCK TestPage151 (requestMapRequestScopeTest)
performs some checks to make sure that certain non-excluded request
attributes don't survive into the RENDER_PHASE. One of these attributes is
named verifyPreBridgeExclusion with value avalue. Since the Liferay
portlet container does not implement post-redirect-get, it is not possible
for the bridge to programatically determine if the verifyPreBridgeExclusion
attribute should be removed.
Since the Bridge Spec assumes that the portlet container implements
post-redirect-get, it would be necessary for the bridge to pro-actively
remove non-excluded request attributes when running under Liferay Portal.
Details of problem: The following is an example list of String-based
attributes that are present in the Liferay Portal RenderRequest prior to the
FacesContext being constructed by the requestMapRequestScopeTest:
*
INVOKER_FILTER_URI=/chapter6_1_3_1TestsrequestMapRequestScopeTestportlet/invoke
*
PORTLET_ID=chapter6_1_3_1TestsrequestMapRequestScopeTestportlet_WAR_bridgetckmainportlet
* verifyPreBridgeExclusion=avalue
In this example, the INVOKER_FILTER_URI and PORTLET_ID attributes (added by
the Liferay portlet container) need to be maintained, but the
verifyPreBridgeExclusion attribute needs to be removed. But to restate the
problem, it is not possible for the bridge to programatically determine which
one of these should be maintained and which should be removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-226) requestProcessingNonFacesTest specifies charset in JSP
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-226.
Resolution: Fixed
Fix Version/s: 3.0.0
2.0.1
Changed test in the jsp to only test that the content type starts with the
expected content type name -- this allows charset to also be reflected in the
result.
requestProcessingNonFacesTest specifies charset in JSP
--
Key: PORTLETBRIDGE-226
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-226
Project: MyFaces Portlet Bridge
Issue Type: TCK Challenge
Components: TCK
Affects Versions: 2.0.0
Environment: Liferay Portal + Liferay Faces Bridge
Reporter: Neil Griffin
Assignee: Michael Freedman
Fix For: 2.0.1, 3.0.0
[Test Challenger Name and Company]
Neil Griffin, Liferay, Inc.
[Specification Name(s) and Version(s)]
Portlet 2.0 Bridge for JavaServer™ Faces 1.2
[Test Suite Name and Version]
portlet-bridge-tck-main, v1.0.0
[Exclude List Version]
N/A
[Test Name]
requestProcessingNonFacesTest
[Complaint (argument for why test is invalid)]
If the TestPage017 (requestProcessingNonFacesTest) is successful, the output
text should be the following:
{code}Detail: Expected response content type is text/html, actual value is
text/html.{code}
However, under Liferay Portal the test fails with the following:
{code}Detail: Expected response content type is text/html, actual value is
text/html; charset=UTF-8.{code}
The reason why is because the test contains a JSP file named
chapter4_2_5Result.jsp that starts with the following directive:
%@ page contentType = text/html; charset=UTF-8 ... %
... and Liferay Portal has a feature that respects the contentType attribute
of the page directive, which ultimately calls back into the Liferay
implementation of
[MimeResponse.setContentType(String)|http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/MimeResponse.html#setContentType(java.lang.String)].
That's why Liferay returns an actual value of text/html; charset=UTF-8
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-223) Bridge mishandles encodings of urls with targets containing same prefix as contextpath
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-223. Resolution: Fixed Fix Version/s: 3.0.0 2.0.1 Code in ExternalContext now explicitly checks to make sure that string matches aren't inadvertently finding the name elsewhere in the path/target. Bridge mishandles encodings of urls with targets containing same prefix as contextpath -- Key: PORTLETBRIDGE-223 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-223 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0, 2.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.1, 3.0.0 If a target is prefixed with the same name/string as the context path, the bridge mishandles encoding/decoding the URLs as portlet urls. For example if the contextpath is /simple and the path is /simple.jspx code in the bridge's ExternalContext will break as there are several locations where the bridge either needs to adds the ContextPath during encoding or strip the ContextPath during decoding. In both cases the bridge incorrectly recognizes the CP in the above example (/simple.jspx) when its not there. All tests for context path must therefore not only check that string startwith the CP but in fact ends with a /. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-223) Bridge mishandles encodings of urls with targets containing same prefix as contextpath
Michael Freedman created PORTLETBRIDGE-223: -- Summary: Bridge mishandles encodings of urls with targets containing same prefix as contextpath Key: PORTLETBRIDGE-223 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-223 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0, 1.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman If a target is prefixed with the same name/string as the context path, the bridge mishandles encoding/decoding the URLs as portlet urls. For example if the contextpath is /simple and the path is /simple.jspx code in the bridge's ExternalContext will break as there are several locations where the bridge either needs to adds the ContextPath during encoding or strip the ContextPath during decoding. In both cases the bridge incorrectly recognizes the CP in the above example (/simple.jspx) when its not there. All tests for context path must therefore not only check that string startwith the CP but in fact ends with a /. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-219) NonFaces in protocol resource request fails after and action
NonFaces in protocol resource request fails after and action Key: PORTLETBRIDGE-219 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-219 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Impl relies on the same render parameter to hold the viewId at the end of an action or in a resourceURL that references a Faces resource. Hence the check in Bridge during a resource request on whether the request is for a Faces or NonFaces resource depends on whether this render parameter exists or not. The problem is in that in a resource URL this isn't really a render parameter but rather a resource parameter. The resource receives the current portlet render parameters + its url encoded resource parameters. This means that if an action occurs it will set the VIEWID render parameter. If in the render following this action we create and render a resource url to a nonFaces resource request then when this resource request is sent we will still receive the VIEWID parameter and incorrectly think this is Faces resource request when its a nonFaces one. Fix is to have a distinct resource param to hold the viewId for Faces resource URL. Then the check looks for existence/nonexistence of this param and ignores whether the render param VIEWID is there. Note: when making this fix will also need to update the code that resolves the view to execute as we will need to test if we are in a resource request and pull from the right param. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-220) 329 TCK: change TCK NonFacesResourceTest to test/verify conditions that explained in PORTLETBRIDGE-219
329 TCK: change TCK NonFacesResourceTest to test/verify conditions that explained in PORTLETBRIDGE-219 --- Key: PORTLETBRIDGE-220 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-220 Project: MyFaces Portlet Bridge Issue Type: Bug Components: TCK Reporter: Michael Freedman Assignee: Michael Freedman Modify the TCKs NonFacesResourceTest to start with a page that requires you to run an action to get to the actual test page. This duplicates the situation where the encoderesourceURL is called in the render following an action -- and hence the resource request itself falls into this same context. This is the situation that caused PB-219 to be raised. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-217) Test URL should be resources/myImage.jpg?javax.portlet.faces.BackLink=myBackLinkParam
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060037#comment-13060037 ] Michael Freedman commented on PORTLETBRIDGE-217: Wesley, is this a patch file created from the changes I made/checked into trunk? I need to know if there are further updates I need to make to the TCK or whether this patch is here for others who prefer to pick up the released version? Test URL should be resources/myImage.jpg?javax.portlet.faces.BackLink=myBackLinkParam --- Key: PORTLETBRIDGE-217 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-217 Project: MyFaces Portlet Bridge Issue Type: TCK Challenge Components: TCK Affects Versions: 2.0.0 Reporter: Wesley Hales Assignee: Michael Freedman Attachments: pbr-tck.patch [Alexander Smirnov Wesley Hales: Red Hat] [jsr329-1.0.0] [portlet_2_bridge-1_0-final-spec] [chapter_6/section_6_5_1/Tests#testImplicitObject, chapter_6/section_6_1_3_1/Tests#illegalRedirectRenderTest, chapter_4/section_4_2_1/InitMethodTestPortlet#init, /testsuite/beans/NonJSFViewBean#getUrl] [https://issues.jboss.org/browse/PBR-254?focusedCommentId=12611867page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12611867 Many tests failed because of possible TCK issue, that threats URLs not started with application context as internals. Following this logic (and given Oracle's use of encodeActionURL to encode its equivalent of the OutputLink) then encodeAction should do a return portletResponse.encodeURL(target) if the url begins with a / and isn't (this application) context-path prefixed. I.e. we need the bridge code to give the portlet container a chance to encode the server/port (construct and absolute url) - typically when the portlet container is remote. Sound about right? I know the spec doesn't say anything about this but it seems to fall out from this decision/interpretation. Does your code already do this? If not should it? Mike On 6/14/2011 1:29 PM, Michael Freedman wrote: So what you are saying is that because ViewHandler.getResourceURL() is defined and it will always append the ContextPath then the spec/impl should assume that urls starting with '/' that don't contain a ContextPath must be out of the application (because all in application urls would have been channeled through getResourceURL? I.e. just using /xxx as a resource url without a context path doesn't work in servlet based JSF. Interesting - okay I see your logic. Please file a JIRA against the TCK indicating the test url it should use ought to be resources/myImage.jpg?javax.portlet.faces.BackLink=myBackLinkParam. If possible please make the needed changes yourself and verify (and then submit the jira with either the details of the code change or a patch file). I will file a bug against the RI concerning its not treating / as an external url - and since we are changing the test/fixing a bug will just include in the 2.0.1 release. Mike ] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-215) EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-215. Resolution: Fixed Fix Version/s: 3.0.0 2.0.1 1.0.1 Both encodeActionURL and encodeResourceURL have been modified so they now assume any URL beginning with a / is contextpath encoded and hence any that do not can't be an external URL. Primary change from this: anything starting with a / must be CP encoded or else will fail (before we would add the current CP). EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url - Key: PORTLETBRIDGE-215 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-215 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 1.0.1, 2.0.1, 3.0.0 If you have an url that is passed to encodeResourceUrl which begins /foo/bar.jpg where /foo isn't this applications context-path, the bridge recognizes this url as a internal app url and prefixs it with the context-path. However, because JSF doesn't do auto-context path appending the above url is invalid in regular (serlvet) JSF as its neither relative to the current page nor the current server. Hence all resource urls that begin with / should be seen as external urls -- i.e. assumed to be urls that are full path (including the context-path) to another application in this server. As ADF's GoLink uses encodeActionUrl for its targets -- we should also review and consider correct behavior there as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-211) Trinidad doesn't work with the 3.0.0 Portlet Bridge
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-211. Resolution: Fixed Fix Version/s: 3.0.0 With the release Trinidad 2.0.0 these problems have gone away -- so marking bug as resolved. Trinidad doesn't work with the 3.0.0 Portlet Bridge --- Key: PORTLETBRIDGE-211 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-211 Project: MyFaces Portlet Bridge Issue Type: Bug Components: TCK Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Scott O'Bryan Fix For: 3.0.0 I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2 (which fixed the problem I needed to patch) the bridge completely breaks as long as the app includes the trinidad libs. There seems to be some incompatibilities between the Trinidad extensions and the bridge's. Did get a chance to track down the specific details but wanted to get the issue logged as its likely to be identified much faster by someone in the Trinidad team. To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to the 3.0.0 TCK. Follow the instructions in the TCK User Manual for building it, configuring it on Apache, and then running it. With the Trinidad jars in the deployment you will find that almost all the test fail (170) -- the few that pass don't actually execute Faces. If you remove the jars (and I think drop the other Trinidad refs in the web.xml) things run fine except for those few tests that depend on Trindiad (failed tests shoudl be something like 37). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-214) BridgeImpl incorrectly cleans up after exceptions; retains contexts
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-214.
Resolution: Fixed
Fix Version/s: 2.0.1
The NPE is likley caused because of failure during the acquisition of the
FacesContext -- hence its not established/remains null. Changed code to use
PortletConfig to log which is always around. In addition I noticed this and
some other conditional logging checks were logging only if logging was
disabled. Switched this to ensure they get logged only if logging is enabled.
BridgeImpl incorrectly cleans up after exceptions; retains contexts
---
Key: PORTLETBRIDGE-214
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-214
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0
Reporter: Scott Oaks
Assignee: Michael Freedman
Fix For: 2.0.1
Attachments: stack.txt
The exception handling of BridgeImpl.doFacesRequest() is incorrect, which
leads to contexts not being released after an exception.
When an exception is thrown to the doFacesRequest() method, it ends up in
this code:
try {
...
} catch (Exception e) {
...
context.getExternalContext().log(Exception thrown in
doFacesRequest:resource, e); // line 1168
...
} finally {
...
context.release();
...
}
The first problem is that whatever error is getting thrown to us is lost
because line 1168 is generated a NullPointerException from
context.getExternalContext().log(). So that NPE gets thrown from the
exception block and the original, actual root-cause, exception is lost.
The reason that this code fails is that context.getExternalContext() returns
null -- the processing has been redirected, and this context has already been
released in redirectRender(). Which leads to the much more serious issue --
the new context established by redirectRender() is never released in the
exception handling: the context.release() call in the finally block of
doFacesRequest() is the original, already released context.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-215) EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url
EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url - Key: PORTLETBRIDGE-215 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-215 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman If you have an url that is passed to encodeResourceUrl which begins /foo/bar.jpg where /foo isn't this applications context-path, the bridge recognizes this url as a internal app url and prefixs it with the context-path. However, because JSF doesn't do auto-context path appending the above url is invalid in regular (serlvet) JSF as its neither relative to the current page nor the current server. Hence all resource urls that begin with / should be seen as external urls -- i.e. assumed to be urls that are full path (including the context-path) to another application in this server. As ADF's GoLink uses encodeActionUrl for its targets -- we should also review and consider correct behavior there as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-215) EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13049414#comment-13049414 ] Michael Freedman commented on PORTLETBRIDGE-215: Looks like ADF does the right thing and ensures anything starting with a / is transformed to a context path relative url via Viewhandler.getResourceURL(). I.e. GoLink impls that by the time encodeActionURL is called anything starting with a / is context path encoded -- whether this context path or another on the server. So logically the bridge's encodeActionURL should check any url that begins with / and make sure its in this apps context path, if it is not then it should turn the url into an absolute url and return it. Fix this as well. EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url - Key: PORTLETBRIDGE-215 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-215 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman If you have an url that is passed to encodeResourceUrl which begins /foo/bar.jpg where /foo isn't this applications context-path, the bridge recognizes this url as a internal app url and prefixs it with the context-path. However, because JSF doesn't do auto-context path appending the above url is invalid in regular (serlvet) JSF as its neither relative to the current page nor the current server. Hence all resource urls that begin with / should be seen as external urls -- i.e. assumed to be urls that are full path (including the context-path) to another application in this server. As ADF's GoLink uses encodeActionUrl for its targets -- we should also review and consider correct behavior there as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-214) BridgeImpl incorrectly cleans up after exceptions; retains contexts
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13047344#comment-13047344
]
Michael Freedman commented on PORTLETBRIDGE-214:
Okay -- looked at the code. I understand what you have said but don't
understand how we got in this situation as a redirect during a resource request
is a noop (in a portlet/bridge environment). Is there any chance you can set a
breakpoint in the bridge's FacesContext.release() and send me the stack so I
can understand/work backwards in terms of why the context has been prematurely
released ... Note: if you look at the corresponding doFacesRequest code for
render requests -- you will see it does reacquire the FacesContext in the
exception clause as it does expect a render redirect to occur.
I.e. the issue here seems to be an unexpected premature release of the
facesContext in a resource request. Can you help me dig/determine why this is
happening?
BridgeImpl incorrectly cleans up after exceptions; retains contexts
---
Key: PORTLETBRIDGE-214
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-214
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0
Reporter: Scott Oaks
Assignee: Michael Freedman
Attachments: stack.txt
The exception handling of BridgeImpl.doFacesRequest() is incorrect, which
leads to contexts not being released after an exception.
When an exception is thrown to the doFacesRequest() method, it ends up in
this code:
try {
...
} catch (Exception e) {
...
context.getExternalContext().log(Exception thrown in
doFacesRequest:resource, e); // line 1168
...
} finally {
...
context.release();
...
}
The first problem is that whatever error is getting thrown to us is lost
because line 1168 is generated a NullPointerException from
context.getExternalContext().log(). So that NPE gets thrown from the
exception block and the original, actual root-cause, exception is lost.
The reason that this code fails is that context.getExternalContext() returns
null -- the processing has been redirected, and this context has already been
released in redirectRender(). Which leads to the much more serious issue --
the new context established by redirectRender() is never released in the
exception handling: the context.release() call in the finally block of
doFacesRequest() is the original, already released context.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-99) RequestScopeListener not Serializable
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-99. --- Resolution: Fixed Fix was to make the RequestScopeListener a non inner class -- thus when its serialized itsw outer class isn't. RequestScopeListener not Serializable - Key: PORTLETBRIDGE-99 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0-beta Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces 1.2.7 and JBoss embebed Mojarra Reporter: Fernando Silva Lozano Assignee: Michael Freedman Fix For: 1.0.1, 2.0.1, 3.0.0-alpha I get lots of erros on JBoss AS log such as: 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException: java.io.NotSerializableException: org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.setObject(Message.java:281) 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.init(Message.java:141) 13:51:03,110 ERROR [STDERR] at org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103) 13:51:03,110 ERROR [STDERR] at org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114) 13:51:03,110 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) 13:51:03,112 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 13:51:03,112 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) 13:51:03,112 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) 13:51:03,112 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) 13:51:03,112 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) 13:51:03,112 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595) I think it is self-explanatory: every object stored on the user HTTP session should be serializable, and one of the objects put there by the bridge (an inner class of BridgeImpl) isn't. I rated as Major because I suppose this will prevent my JSF portlet to work correctly in a clustered container. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-213) Portlet 2.0 Bridge: FacesMessages not updated in bridge scope if empty
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-213. Resolution: Fixed Fix Version/s: 3.0.0-alpha 2.0.1 cached messages no longer saved if current request didn't generate any. Portlet 2.0 Bridge: FacesMessages not updated in bridge scope if empty --- Key: PORTLETBRIDGE-213 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-213 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.1, 3.0.0-alpha The Bridge manages FacesMessages in its scope (so Messages generated during an action are carried forward to the render). Unfortunately its impl of saveFacesMessageState only writes the FacesMessages data structure into the scope if there are messages in the current FacesContext. Because the resource code copies forward (merges) all scope attributes that aren't there at the end of the resource request, we are inadvertently copying forward the old set of FacesMessages (rather then the new empty set). Fix is to always put the FacesMessages data structure into the scope even if its empty. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-204) Bridge doesn't work with Mojarra 2.0.4b09
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-204. Resolution: Fixed Fix Version/s: 3.0.0-alpha Bridge no longer caches the UIViewRoot between and action and render. Rather it saves and restores across the requests. Bridge doesn't work with Mojarra 2.0.4b09 - Key: PORTLETBRIDGE-204 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-204 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha Bridge doesn't work with the latest released Mojarra. Problem again is related to us slamming the UIViewRoot across the action/render without a full save/restore -- this time the UIViewRoot has old listeners hanging off its atts. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PORTLETBRIDGE-190) New Bridge 3.0 files missing Apache License headers
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-190. Resolution: Fixed Fix Version/s: 3.0.0-alpha Added headers New Bridge 3.0 files missing Apache License headers --- Key: PORTLETBRIDGE-190 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-190 Project: MyFaces Portlet Bridge Issue Type: Bug Components: General Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha Most of the new files added to the Bridge as part of upgrading for JSF 2.0 support are missing their requires Apache license/copyright statements. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-213) Portlet 2.0 Bridge: FacesMessages not updated in bridge scope if empty
Portlet 2.0 Bridge: FacesMessages not updated in bridge scope if empty --- Key: PORTLETBRIDGE-213 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-213 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman The Bridge manages FacesMessages in its scope (so Messages generated during an action are carried forward to the render). Unfortunately its impl of saveFacesMessageState only writes the FacesMessages data structure into the scope if there are messages in the current FacesContext. Because the resource code copies forward (merges) all scope attributes that aren't there at the end of the resource request, we are inadvertently copying forward the old set of FacesMessages (rather then the new empty set). Fix is to always put the FacesMessages data structure into the scope even if its empty. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2105) DocumentRenderer.encodeAll must not assume root StateManager is Trinidad's
DocumentRenderer.encodeAll must not assume root StateManager is Trinidad's
--
Key: TRINIDAD-2105
URL: https://issues.apache.org/jira/browse/TRINIDAD-2105
Project: MyFaces Trinidad
Issue Type: Bug
Components: Portlet
Affects Versions: 2.0.0
Reporter: Michael Freedman
DocumentRenderer.encodeAll has the following code:
StateManager sm = context.getApplication().getStateManager();
if (sm instanceof StateManagerImpl)
{
// do real work
}
else
{
// log error and return
}
This means Trinidad fails in an environment in which its wrapped -- such as the
Portlet Bridge -- even though its StateManager is in use. Instead the code
should test for whether its StateManagerImpl and if not recursively test to see
if its a StateManagerWrapper. For each wrapper it finds it calls .getWrapped
and runs the test again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-192) Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030805#comment-13030805 ] Michael Freedman commented on PORTLETBRIDGE-192: Alexandr -- it looks like you are commenting on Neil's APIs as the above doesn't fully describe the set of APIs I have proposed/started to put into use. Could you repost comments pertaining to the APIs that are in the refactored code? As to your points: 1) PortletContext, Request/Response are included in the API because there is a short period of time between when the controller is invoked (with a BridgeContext) and when it acquires a FacesContext (and if a nonFaces resource it never acquires one). These APIs allow the controller access to these portlet objects before they are exposed in Faces. 2) Do we really need another threadlocal (and what do we gain by having one)? 95%+ of the time we will need to acquire the BridgeContext we will either have or also need to acquire the FacesContext. I had been planning on adding the BridgeContext to the FacesContext scope and let extensions/etc. access it there as needed. The only real thing running outside the FacesContext is the controller which is passed the BridgeContext explicitly. 3) default viewId's and PortletConfig are in the BridgeConfig 4) Whether or not we have setter methods to allow for object initialization (somewhat) depends on the APIs you come up with for the factories. If the factories cleanly allow for this type of object initialization and allows us to easily extend add new initialization 'attributes in the future then you are right there is no need to have the set methods. I included them so as we have to support new features in Faces that require additional config/context -- it is easy to add a get/set method and have the code using the factory updated to do the additional initialization call. Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory --- Key: PORTLETBRIDGE-192 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-192 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman This class contains contextual information related to the bridge. It is inherently request scoped, and is useful for sharing data between implementations of Bridge.java and ExternalContext.java Please refer to the following classes for this proposal: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContext.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContextFactory.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (PORTLETBRIDGE-99) RequestScopeListener not Serializable
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman reopened PORTLETBRIDGE-99: --- Turns out my fix doesn't work because the RequestScopeListener isn't a static inner class and hence auto-causes the containing class to be serialized along with it and the BridgeImpl (which is the containing class contains objects that can't be serialized. Easiest/best short term solution is to make the RequestScopeListener a static inner class and to pass the BridgeImpl object to it. RequestScopeListener not Serializable - Key: PORTLETBRIDGE-99 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0-beta Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces 1.2.7 and JBoss embebed Mojarra Reporter: Fernando Silva Lozano Assignee: Michael Freedman Fix For: 1.0.1, 2.0.1, 3.0.0-alpha I get lots of erros on JBoss AS log such as: 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException: java.io.NotSerializableException: org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.setObject(Message.java:281) 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.init(Message.java:141) 13:51:03,110 ERROR [STDERR] at org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103) 13:51:03,110 ERROR [STDERR] at org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114) 13:51:03,110 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) 13:51:03,112 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 13:51:03,112 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) 13:51:03,112 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) 13:51:03,112 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) 13:51:03,112 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) 13:51:03,112 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595) I think it is self-explanatory: every object stored on the user HTTP session should be serializable, and one of the objects put there by the bridge (an inner class of BridgeImpl) isn't. I rated as Major because I suppose this will prevent my JSF portlet to work correctly in a clustered container. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-206) Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016452#comment-13016452 ] Michael Freedman commented on PORTLETBRIDGE-206: For the time being this can't/won't go in Bridge.java. Rather it will be part of the org.apache.myfaces.portlet.faces.bridge package. Probably in Constants.java. Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE -- Key: PORTLETBRIDGE-206 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-206 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Proposal is to add the following constant to Bridge.java: public static final String BRIDGE_CONTEXT_ATTRIBUTE = javax.portlet.faces.bridgeContext; And to require implementations of the Bridge interface to set this attribute in each of the doFacesRequest(...) methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-203) Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016463#comment-13016463 ] Michael Freedman commented on PORTLETBRIDGE-203: I have found that the 329/301 bridge methodology of caching the UIViewRoot and releasing the FacesContext at the end of the action and then getting the render to use the cached UIViewRoot in a new FacesContext will not work consistently in JSF 3.0. Each release of Mojarra or Myfaces I get changes the issue I ran into -- yes first it was just the need to carry some of the FacesContext attributes forward -- but now there are issues with attributes stored on the UiViewRoot itself that have been released underneath these references in the prior facesContext.release. So I think the bridge is going to have to change to explicitly save and restore the view across the action/render -- at which point we won't need to preserve/restore the JSF2 FacesContext attrs anymore. Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope -- Key: PORTLETBRIDGE-203 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-203 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman The JSF 2.0 API introduced a getAttributes() method on FacesContext: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/FacesContext.html#getAttributes() These values need to be preserved in the BridgeRequestScope. For more information on implementation details, search for BRIDGE_REQ_SCOPE_ATTR_FACES_CONTEXT_ATTRIBUTES in the following Java class: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-impl/trunk/src/main/java/org/portletfaces/bridge/scope/BridgeRequestScopeImpl.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2083) Trinidad doesn't work with the 3.0.0 Portlet Bridge
Trinidad doesn't work with the 3.0.0 Portlet Bridge --- Key: TRINIDAD-2083 URL: https://issues.apache.org/jira/browse/TRINIDAD-2083 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 2.0.0-beta-2 Reporter: Michael Freedman I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2 (which fixed the problem I needed to patch) the bridge completely breaks as long as the app includes the trinidad libs. There seems to be some incompatibilities between the Trinidad extensions and the bridge's. Did get a chance to track down the specific details but wanted to get the issue logged as its likely to be identified much faster by someone in the Trinidad team. To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to the 3.0.0 TCK. Follow the instructions in the TCK User Manual for building it, configuring it on Apache, and then running it. With the Trinidad jars in the deployment you will find that almost all the test fail (170) -- the few that pass don't actually execute Faces. If you remove the jars (and I think drop the other Trinidad refs in the web.xml) things run fine except for those few tests that depend on Trindiad (failed tests shoudl be something like 37). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-206) Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013012#comment-13013012 ] Michael Freedman commented on PORTLETBRIDGE-206: Yes, we will need to add such a new constant -- and I was thinking we will have the Bridge set this on the FacesContext prior to executing the lifecycle. Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE -- Key: PORTLETBRIDGE-206 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-206 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Proposal is to add the following constant to Bridge.java: public static final String BRIDGE_CONTEXT_ATTRIBUTE = javax.portlet.faces.bridgeContext; And to require implementations of the Bridge interface to set this attribute in each of the doFacesRequest(...) methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-206) Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013529#comment-13013529 ] Michael Freedman commented on PORTLETBRIDGE-206: Yep. Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE -- Key: PORTLETBRIDGE-206 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-206 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Proposal is to add the following constant to Bridge.java: public static final String BRIDGE_CONTEXT_ATTRIBUTE = javax.portlet.faces.bridgeContext; And to require implementations of the Bridge interface to set this attribute in each of the doFacesRequest(...) methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-202) Proposal for 3.0 IMPL: Support mode changes via StateAwareResponse#setPortletMode(PortletMode)
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013627#comment-13013627
]
Michael Freedman commented on PORTLETBRIDGE-202:
1) On your spec comment -- I don't see why the spec would need to say anything
about this specific use case. I think (hope) the spec is clear as to the
bridge behavior when it encounters a mode change in any request -- i.e. don't
restore the scope.
2) On managing this info in the requestScope itself. Maybe -- right now the RI
handles this by encoding the info in the target viewId itself. This ensures
that whenever we are processing an incoming request that the target can check
what mode it was saved in and the bridge controller only restores if that
mode is the same as the current request. Seems to me this is a logical place
to handle things (i.e. in the controller itself) as why should the bridge
restore the scope so it can read the mode and then decide to undo the restore
beacuse the mode has changed?
Proposal for 3.0 IMPL: Support mode changes via
StateAwareResponse#setPortletMode(PortletMode)
--
Key: PORTLETBRIDGE-202
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-202
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
To the best of my knowledge, the Bridge 2.0 spec does not address usage of
StateAwareResponse#setPortletMode(PortletMode) within a JSF backing bean
action.
This proposal would require the BridgeRequestScope to remember the
PortletMode so that mode changes can be detected:
public interface BridgeRequestScope {
...
PortletMode getPortletMode();
void setPortletMode(PortletMode portletMode);
...
}
Note that the Bridge implementation would be required to call
bridgeRequestScope.setPortletMode() during an ActionRequest and EventRequest.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-202) Proposal for 3.0 IMPL: Support mode changes via StateAwareResponse#setPortletMode(PortletMode)
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013640#comment-13013640
]
Michael Freedman commented on PORTLETBRIDGE-202:
PortletExternalContextImpl.encodeFacesActionTarget does the encoding of the
target (admittedly now that you have pointed it out it would be better if it
also checked response.getPortletMode()). This is called when encodeActionURL
is called with an URL that resolves to a Faces view.
doFacesRequest (renderRequest/whatever) in BridgeImpl calls hasModeChanged() to
detect whether the mode of the request is different than the one of the target
viewId.
Proposal for 3.0 IMPL: Support mode changes via
StateAwareResponse#setPortletMode(PortletMode)
--
Key: PORTLETBRIDGE-202
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-202
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
To the best of my knowledge, the Bridge 2.0 spec does not address usage of
StateAwareResponse#setPortletMode(PortletMode) within a JSF backing bean
action.
This proposal would require the BridgeRequestScope to remember the
PortletMode so that mode changes can be detected:
public interface BridgeRequestScope {
...
PortletMode getPortletMode();
void setPortletMode(PortletMode portletMode);
...
}
Note that the Bridge implementation would be required to call
bridgeRequestScope.setPortletMode() during an ActionRequest and EventRequest.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-203) Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012588#comment-13012588 ] Michael Freedman commented on PORTLETBRIDGE-203: We will have to discuss/debate this one. Turns out there are some Faces internal FacesContext attributes that can't be preserved across FacesContext releases and there are others that must. In addition we need to discuss/understand to what degree application developers are using this scope and expect/require that it last until the entire action/render occurs. Basically -- this scope is a mess for the bridge as its normal behavior is to release the FacesContext at the end of the action and start a new one in render. I really want to avoid having to support a similar include/exclude mechanism as the request scope for any new scope. Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope -- Key: PORTLETBRIDGE-203 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-203 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman The JSF 2.0 API introduced a getAttributes() method on FacesContext: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/FacesContext.html#getAttributes() These values need to be preserved in the BridgeRequestScope. For more information on implementation details, search for BRIDGE_REQ_SCOPE_ATTR_FACES_CONTEXT_ATTRIBUTES in the following Java class: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-impl/trunk/src/main/java/org/portletfaces/bridge/scope/BridgeRequestScopeImpl.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-204) Bridge doesn't work with Mojarra 2.0.4b09
Bridge doesn't work with Mojarra 2.0.4b09 - Key: PORTLETBRIDGE-204 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-204 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Bridge doesn't work with the latest released Mojarra. Problem again is related to us slamming the UIViewRoot across the action/render without a full save/restore -- this time the UIViewRoot has old listeners hanging off its atts. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3081) javax.faces.Application addBehaviors() throws UnsupportedOperationException when it shouldn't
javax.faces.Application addBehaviors() throws UnsupportedOperationException when it shouldn't - Key: MYFACES-3081 URL: https://issues.apache.org/jira/browse/MYFACES-3081 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.5-SNAPSHOT Reporter: Michael Freedman Line 140 of javax.faces.Application is currently: application.addBehavior(behaviorId, behaviorClass); when it should be: return application.addBehavior(behaviorId, behaviorClass); without the return we fall through and throw the UnsupportedOperationException when we shouldn't. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3081) javax.faces.Application addBehaviors() throws UnsupportedOperationException when it shouldn't
[ https://issues.apache.org/jira/browse/MYFACES-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010509#comment-13010509 ] Michael Freedman commented on MYFACES-3081: --- Oops -- meant the fix is: application.addBehavior(behaviorId, behaviorClass); return; See patch file. javax.faces.Application addBehaviors() throws UnsupportedOperationException when it shouldn't - Key: MYFACES-3081 URL: https://issues.apache.org/jira/browse/MYFACES-3081 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.5-SNAPSHOT Reporter: Michael Freedman Assignee: Leonardo Uribe Fix For: 2.0.5-SNAPSHOT Line 140 of javax.faces.Application is currently: application.addBehavior(behaviorId, behaviorClass); when it should be: return application.addBehavior(behaviorId, behaviorClass); without the return we fall through and throw the UnsupportedOperationException when we shouldn't. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-190) New Bridge 3.0 files missing Apache License headers
New Bridge 3.0 files missing Apache License headers --- Key: PORTLETBRIDGE-190 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-190 Project: MyFaces Portlet Bridge Issue Type: Bug Components: General Reporter: Michael Freedman Assignee: Michael Freedman Most of the new files added to the Bridge as part of upgrading for JSF 2.0 support are missing their requires Apache license/copyright statements. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PORTLETBRIDGE-187) Why does the 3.0.0 implementation of PortletFacesContextFactoryImpl differ from the one in 2.0?
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007302#comment-13007302
]
Michael Freedman commented on PORTLETBRIDGE-187:
Yep, in JSF 2.0 the ExternalContext creation has been separated from the
FacesContext creation. Turns out that the generic FacesContext impl is 95%+ (I
think its actually 100%) platform independent -- so the bridge now can grab and
wrap the base one and only override those methods where it extends the
behavior. Pretty much all the platform dependent code is safely inside the
ExternalContext which now has its own factory and hence isn't something tied
explicitly to a given FacesContext.
Why does the 3.0.0 implementation of PortletFacesContextFactoryImpl differ
from the one in 2.0?
---
Key: PORTLETBRIDGE-187
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-187
Project: MyFaces Portlet Bridge
Issue Type: Question
Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Hampus Wingren
Assignee: Michael Freedman
This seems like an impossible thing to do if there is no other
PortletFacesContext implementations available. Is it really correct to try
and lookup another FacesContext if we are in a portlet environment?
// if in portlet environment -- do a portlet container neutral test
// first in case we are packaged in a web app that isn't deployed
// on a portlet container/as a portlet. Note: can't use the BridgeUtil
// method as that call requires the facesContext to exist.
FacesContext fc = getWrapped().getFacesContext(context, request,
response, lifecycle);
if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
{
fc = new FacesContextImpl(fc);
}
return fc;
regards,
Hampus
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PORTLETBRIDGE-188) HEAD resources added to the viewroot by portlets
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007303#comment-13007303 ] Michael Freedman commented on PORTLETBRIDGE-188: Yes, this code/support is coming. I didn't place it in the first batch of function to support as I upgrades the JSF 1.2 bridge as I thought it was more important to focus on the facelets support, Ajax/Partial rendering support and ensuring composite components ran properly (as well as ensuring the bridge continued to provide all the JSR 329 behaviors one would expect for those bringing forward 1.2 apps into this env.) HEAD resources added to the viewroot by portlets Key: PORTLETBRIDGE-188 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-188 Project: MyFaces Portlet Bridge Issue Type: Question Components: Impl Affects Versions: 3.0.0 Reporter: Hampus Wingren Assignee: Michael Freedman Hi, Are there any plans on supporting some way of extracting the HEAD resources that a portlet may add through JSF so that the portal can handle them in some manner? Regards, Hampus -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3064) UIView.createUniqueId shouldn't call encodeNameSpace to build the id.
UIView.createUniqueId shouldn't call encodeNameSpace to build the id. - Key: MYFACES-3064 URL: https://issues.apache.org/jira/browse/MYFACES-3064 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.4, 1.2.10 Reporter: Michael Freedman Submitting a new bug based on one I recently reopened as it pertains to 1.2 and 2.0 impls as well: Referer bug: https://issues.apache.org/jira/browse/MYFACES-702 Problem reported in the above bug is related to the component's id being prefixed with the portletNamespace which is caused by calling encodeNamespace. Why is this api called in generating the component id. encodeNamespace was added to external context by and large for the portlet environment to allow it to prefix client ids to be unique on the page they are being incorporated into. Is there a reason for needing this when generating the component id? FYI ... Mojarra doesn't make this call from createUniqureId. Hopefully, this is something that can be fixed by just removing the call -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-702) outputText generates wrapped span element in a portal
[ https://issues.apache.org/jira/browse/MYFACES-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman reopened MYFACES-702: -- Reopening because PORTLETBRIDGE-186 was filed. (https://issues.apache.org/jira/browse/PORTLETBRIDGE-186) I.e. The problem reported in MYFaces-702 was reopened against the bridge indicating that the 1.1 Bridge change/patch to work around this should be applied to the 1.2 bridge. I am not so sure. It appears that the real bug is that UIViewRoot.createUniqueId calls ExternalContext.encodeNamespace on the id before returning. It shouldn't make this call. Rather it should just return the uniqueId it generates. My guess is this was very old code that was added to deal with portlet/portal namespacing issues. However, the bridge now handles this more correctly by not impacting the component id -- rather it introduces its own UIViewRoot that provides a NamingContainer which ensures all clientIds are namespaced via this externalcontext call. Is this correct, or is there some valid reason that createUniqueId calls encodeNamesapce? outputText generates wrapped span element in a portal - Key: MYFACES-702 URL: https://issues.apache.org/jira/browse/MYFACES-702 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.0 Reporter: Gavin Cornwell Assignee: Martin Marinschek Fix For: 1.1.2 Attachments: myfaces702.patch We have a JSF app that runs as a portlet and normal webapp. In the webapp the h:outputText value=some text/ appears as I would expect (i.e. just the text) however the same thing in the portlet gets rendered as: span id=form-id:handleMetaDataEvent_id36some text/span This becomes a problem when you are trying to use outputText to render part of a URL or to become a JavaScript string as the output includes the span element! Looking at the renderer code for outputText it appears the span gets generated when the id does not start with _id, so the question is where has the handleMetaDataEvent prefix for the id come from? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PORTLETBRIDGE-186) Unnecesarry Id and span's generated in a portal
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003472#comment-13003472 ] Michael Freedman commented on PORTLETBRIDGE-186: I have reopened https://issues.apache.org/jira/browse/MYFACES-702 as it looks to me that the real bug here is that UIViewRoot.createUniqueId calls encodeNamespace(). I don't see a valid reason for it doing so and would prefer comment/fix by the MyFaces core folks before introducing any hacks to workaround the issue.In the meantime if you need to workaround the issue you can always introduce your own ExternalContext and subclass encodeNameSpace to add the additional prefix. Unnecesarry Id and span's generated in a portal --- Key: PORTLETBRIDGE-186 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-186 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Krashan Brahmanjara Assignee: Michael Freedman Html generated via bridge has dot a'lot of unnecesary code :id's, span's and span's unwanted by programmers (like h:outputText without styleClass) Full description of this problem and easy patch is here https://issues.apache.org/jira/browse/MYFACES-702. BTW. It looks like very old bug. Old patch pplied to file: myfaces_1_1_8\impl\src\main\java\org\apache\myfaces\context\portlet\PortletExternalContextImpl.java still exist but was not moved and applied to file: myfaces-portlet-bridge-2.0.0\src\impl\src\main\java\org\apache\myfaces\portlet\faces\context\PortletFacesContextImpl.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-183) Potential NPE in FacesContext.release
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-183. Resolution: Fixed Fix Version/s: 3.0.0-alpha 2.0.1 1.0.1 Updated all versions with the simple fix in release() that first makes sure the attr Map returned from looking up on the request attrs is non-null. Potential NPE in FacesContext.release - Key: PORTLETBRIDGE-183 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-183 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 1.0.0, 2.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 1.0.1, 2.0.1, 3.0.0-alpha The Bridge's FacesContext.release dereferences the return from request.getAttribute(BridgeImpl.PREEXISTING_ATTRIBUTE_NAMES) without checking to see if its null. Now it would only be null if the bridge didn't create/release FC but there seems to be at least one situation in which this has occurred and in any case the code should be written correctly to avoid the potential problem/NPE. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-99) RequestScopeListener not Serializable
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-99. --- Resolution: Fixed Fix Version/s: 3.0.0-alpha 2.0.1 1.0.1 Finally got around to making this object serializable to avoid the exception. RequestScopeListener not Serializable - Key: PORTLETBRIDGE-99 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0-beta Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces 1.2.7 and JBoss embebed Mojarra Reporter: Fernando Silva Lozano Fix For: 1.0.1, 2.0.1, 3.0.0-alpha I get lots of erros on JBoss AS log such as: 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException: java.io.NotSerializableException: org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.setObject(Message.java:281) 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.init(Message.java:141) 13:51:03,110 ERROR [STDERR] at org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103) 13:51:03,110 ERROR [STDERR] at org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114) 13:51:03,110 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) 13:51:03,112 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 13:51:03,112 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) 13:51:03,112 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) 13:51:03,112 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) 13:51:03,112 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) 13:51:03,112 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595) I think it is self-explanatory: every object stored on the user HTTP session should be serializable, and one of the objects put there by the bridge (an inner class of BridgeImpl) isn't. I rated as Major because I suppose this will prevent my JSF portlet to work correctly in a clustered container. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-185) Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map
Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map Key: PORTLETBRIDGE-185 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-185 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0 Reporter: Michael Freedman Assignee: Michael Freedman In handling a resource request we reacquire the bridge request scope. If we find the scopeId to use but the scope has since been removed from the ScopeMap (or never put there in the first place) you get an NPE. This happen because the code (getResourceRequestScopeId() in BridgeImpl) dereferences the (Map) object pulled from the scopeMap using the scopeId key without checking first if this object is null (wasn't found). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-185) Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-185. Resolution: Fixed Fix Version/s: 2.0.1 Turns out the actual use case that caused this occurred because of a concurrency interaction inside a series of requests that occur after a renderredirect and include an concurrent render and resource request. The use case problem is the bridge was creating the scopeId early in the render but not actually giving it a representation in the ScopeMap until later. When a concurrent resource request is run -- it can hit this case where it picks up this new scopeId but doesn't find the entry. Fix was actually quite involved -- in that it also showed that in this use case the bridge was overally aggressively creating new scopes. So now the scope activation/resolution has been reworked to make this work/simpler. Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map Key: PORTLETBRIDGE-185 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-185 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0 Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.1 In handling a resource request we reacquire the bridge request scope. If we find the scopeId to use but the scope has since been removed from the ScopeMap (or never put there in the first place) you get an NPE. This happen because the code (getResourceRequestScopeId() in BridgeImpl) dereferences the (Map) object pulled from the scopeMap using the scopeId key without checking first if this object is null (wasn't found). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-184) Bridge NPE in resolving scope during resource request if scope has been removed from cache
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-184.
Resolution: Duplicate
Inadvertently opened duplicate second bug: PORTLETBRIDGE-185 and updated/marked
that one fixed.
Bridge NPE in resolving scope during resource request if scope has been
removed from cache
--
Key: PORTLETBRIDGE-184
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-184
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman
If the Bridge receives a scopeid in the incoming request during a resource
request and that scope isn't in the cache (it has been removed) then the
bridge throws a NPE as it doesn't include a check to ensure that the map
returned from looking up the scopeId isn't null.
Code currently reads like this:
private String getResourceRequestScopeId(ExternalContext extCtx,
PortletRequest request)
{
// get the render scope this resource request is contained in
String scopeId = getRequestScopeId(request);
if (scopeId == null)
{
// first request is a resource request
// create a scope and store in the session until an action occurs
// pass null as we aren't a StateAwareResponse
return initBridgeRequestScope(request, null);
}
// Check to see if this resource request is targeting the same view or a
different one
MapString, Object m = getScopeMap(scopeId);
MapString, String childResourceScopeMap = (MapString, String)
m.get(CHILD_RESOURCE_REQUEST_SCOPE_MAP);
String scopeIdKey = (String) m.get(SCOPE_VIEW_KEY);
String childIdKey = getScopeViewKey(extCtx);
Instead code should check for null return from geetScopeMap and if null init
a new bridge RequestScope.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-184) Bridge NPE in resolving scope during resource request if scope has been removed from cache
Bridge NPE in resolving scope during resource request if scope has been removed
from cache
--
Key: PORTLETBRIDGE-184
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-184
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman
If the Bridge receives a scopeid in the incoming request during a resource
request and that scope isn't in the cache (it has been removed) then the bridge
throws a NPE as it doesn't include a check to ensure that the map returned from
looking up the scopeId isn't null.
Code currently reads like this:
private String getResourceRequestScopeId(ExternalContext extCtx,
PortletRequest request)
{
// get the render scope this resource request is contained in
String scopeId = getRequestScopeId(request);
if (scopeId == null)
{
// first request is a resource request
// create a scope and store in the session until an action occurs
// pass null as we aren't a StateAwareResponse
return initBridgeRequestScope(request, null);
}
// Check to see if this resource request is targeting the same view or a
different one
MapString, Object m = getScopeMap(scopeId);
MapString, String childResourceScopeMap = (MapString, String)
m.get(CHILD_RESOURCE_REQUEST_SCOPE_MAP);
String scopeIdKey = (String) m.get(SCOPE_VIEW_KEY);
String childIdKey = getScopeViewKey(extCtx);
Instead code should check for null return from geetScopeMap and if null init a
new bridge RequestScope.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3045) jsf.js jsf.ajax.request doesn't resolve calling URL correctly -- ajax use in portlets broken
[
https://issues.apache.org/jira/browse/MYFACES-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999028#comment-12999028
]
Michael Freedman commented on MYFACES-3045:
---
A potential patch (this works for me): replace the line in
_AjaxRequest._startXHR:
this._xhr.open(this._ajaxType, this._sourceForm.action+
((this._ajaxType == GET)?
?+this._requestParameters.makeFinal():)
, true);
with the following lines:
var targetURL;
if (typeof this._sourceForm.elements[javax.faces.encodedURL] ==
'undefined') {
targetURL = this._sourceForm.action;
} else {
targetURL =
this._sourceForm.elements[javax.faces.encodedURL].value;
}
this._xhr.open(this._ajaxType, targetURL +
((this._ajaxType == GET)?
?+this._requestParameters.makeFinal():)
, true);
Sorry no patch file as the one that the Diff program used to generate the patch
seems to want to replace everything...And anyway I am not authorized to provide
includable patches.
jsf.js jsf.ajax.request doesn't resolve calling URL correctly -- ajax use in
portlets broken
Key: MYFACES-3045
URL: https://issues.apache.org/jira/browse/MYFACES-3045
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman
Javadoc for jsf.ajax.request says you determine the calling URL by:
Determine the posting URL as follows: If the hidden field
javax.faces.encodedURL is present in the submitting form, use its value as
the posting URL. Otherwise, use the action property of the form element as
the URL.
Looks like the MyFaces impl skips loking for/using the javax.faces.encodedURL
and only uses the form action. This means ajax is broken in portlets (when
using MyFaces). I.e. the javax.faces.encodedURL in the portlet case is
different than the action URL and the one that needs to be used.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PORTLETBRIDGE-99) RequestScopeListener not Serializable
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996122#comment-12996122 ] Michael Freedman commented on PORTLETBRIDGE-99: --- Two attributes need to support Serializable: RequestScopeListener and QueryString RequestScopeListener not Serializable - Key: PORTLETBRIDGE-99 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0-beta Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces 1.2.7 and JBoss embebed Mojarra Reporter: Fernando Silva Lozano I get lots of erros on JBoss AS log such as: 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException: java.io.NotSerializableException: org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.setObject(Message.java:281) 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.init(Message.java:141) 13:51:03,110 ERROR [STDERR] at org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103) 13:51:03,110 ERROR [STDERR] at org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114) 13:51:03,110 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 13:51:03,111 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 13:51:03,111 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) 13:51:03,112 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 13:51:03,112 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) 13:51:03,112 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) 13:51:03,112 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) 13:51:03,112 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) 13:51:03,112 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595) I think it is self-explanatory: every object stored on the user HTTP session should be serializable, and one of the objects put there by the bridge (an inner class of BridgeImpl) isn't. I rated as Major because I suppose this will prevent my JSF portlet to work correctly in a clustered container. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-3042) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java
[ https://issues.apache.org/jira/browse/MYFACES-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman updated MYFACES-3042: -- Status: Patch Available (was: Open) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java Key: MYFACES-3042 URL: https://issues.apache.org/jira/browse/MYFACES-3042 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 2.0.5-SNAPSHOT Reporter: Michael Freedman Attachments: jira-myfaces-3042.patch In FaceletViewDeclarationLanguage.java: createResponseWriter(), getResponseEncoding(), handleFaceletNotFound(), and sendSourceNotFound() each cast to Servlet object. This causes ClassCastExceptions when run in a portlet environment. Each of these calls/casts can be removed and ExternalContext APIs can be used instead to get/set the needed information from the request or response object. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3042) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java
[ https://issues.apache.org/jira/browse/MYFACES-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12994882#comment-12994882 ] Michael Freedman commented on MYFACES-3042: --- I have attached a potential patch -- Apologies for not just making the changes but (1) this change breaks an automated test that is part of the build as it seems the test environment doesn't provide its own stub impl of the new JSF 2.0 ExternalContext methods that these changes rely on -- and I have no clue how to address those and (2) the various paperwork Oracle made me sign to allow me to participate in Apache only allows me to submit work related to the Portlet Bridge project -- MyFaces work has to be submitted by those from Oracle signed up to do that. CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java Key: MYFACES-3042 URL: https://issues.apache.org/jira/browse/MYFACES-3042 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 2.0.5-SNAPSHOT Reporter: Michael Freedman Attachments: jira-myfaces-3042.patch In FaceletViewDeclarationLanguage.java: createResponseWriter(), getResponseEncoding(), handleFaceletNotFound(), and sendSourceNotFound() each cast to Servlet object. This causes ClassCastExceptions when run in a portlet environment. Each of these calls/casts can be removed and ExternalContext APIs can be used instead to get/set the needed information from the request or response object. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3045) jsf.js jsf.ajax.request doesn't resolve calling URL correctly -- ajax use in portlets broken
jsf.js jsf.ajax.request doesn't resolve calling URL correctly -- ajax use in portlets broken Key: MYFACES-3045 URL: https://issues.apache.org/jira/browse/MYFACES-3045 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5-SNAPSHOT Reporter: Michael Freedman Javadoc for jsf.ajax.request says you determine the calling URL by: Determine the posting URL as follows: If the hidden field javax.faces.encodedURL is present in the submitting form, use its value as the posting URL. Otherwise, use the action property of the form element as the URL. Looks like the MyFaces impl skips loking for/using the javax.faces.encodedURL and only uses the form action. This means ajax is broken in portlets (when using MyFaces). I.e. the javax.faces.encodedURL in the portlet case is different than the action URL and the one that needs to be used. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-183) Potential NPE in FacesContext.release
Potential NPE in FacesContext.release - Key: PORTLETBRIDGE-183 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-183 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 2.0.0, 1.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman The Bridge's FacesContext.release dereferences the return from request.getAttribute(BridgeImpl.PREEXISTING_ATTRIBUTE_NAMES) without checking to see if its null. Now it would only be null if the bridge didn't create/release FC but there seems to be at least one situation in which this has occurred and in any case the code should be written correctly to avoid the potential problem/NPE. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3042) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java
CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java Key: MYFACES-3042 URL: https://issues.apache.org/jira/browse/MYFACES-3042 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 2.0.5-SNAPSHOT Reporter: Michael Freedman In FaceletViewDeclarationLanguage.java: createResponseWriter(), getResponseEncoding(), handleFaceletNotFound(), and sendSourceNotFound() each cast to Servlet object. This causes ClassCastExceptions when run in a portlet environment. Each of these calls/casts can be removed and ExternalContext APIs can be used instead to get/set the needed information from the request or response object. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-3039) MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman reopened MYFACES-3039: --- Can you clarify what the defaultExternalContext is being used for? On portlet requests this seemingly won't be set/used as its the Bridge's ExternalContext that is in use not the core MyFaces one (which does the attribute put that causes this default stuff to be enabled). Basically, I am trying to ensure there isn't a problem in the portlet env in not participating in this mechanism. MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext Key: MYFACES-3039 URL: https://issues.apache.org/jira/browse/MYFACES-3039 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Michael Freedman Assignee: Leonardo Uribe Fix For: 2.0.5-SNAPSHOT JSF 2.0 improved the definition/handling of the instantiation of the FacesContext allowing non-servlet environments to wrap the base/core impl. This was done because most of the FacesContext apis are inherently runtime environment neutral -- allowing the portlet bridge to not have to duplicate/reimplement and maybe get wrong base core function. Unfortunately MyFaces doesn't conform to this change and hence the Portlet Bridge can't run in the MyFaces environment. Basically the bridge expects to be able to delegate from its FacesContextFactoryImpl.getFacesContext and then wrap the returned FacesContext with its own. This requires the underlying core impl to be runtime (servlet/portlet) neutral during the creation process. The bridge will wrap the FacesContext and supply its own ExternalContext such that any servlet dependent impl in the core FacesContext/ExternalContext will be hidden by overrides. FYI ... until this is addressed I can't begin any testing of the bridge on MyFaces. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3042) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java
[ https://issues.apache.org/jira/browse/MYFACES-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12994511#comment-12994511 ] Michael Freedman commented on MYFACES-3042: --- FYI ... when you make these changes it looks like you will also have to implement an ExternalContext (stub) to use in the test harness as one doesn't seem to exist at the moment -- and these new 2.0 methods through an exception (from the javax.faces.context impl) if not implemented. CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java Key: MYFACES-3042 URL: https://issues.apache.org/jira/browse/MYFACES-3042 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 2.0.5-SNAPSHOT Reporter: Michael Freedman In FaceletViewDeclarationLanguage.java: createResponseWriter(), getResponseEncoding(), handleFaceletNotFound(), and sendSourceNotFound() each cast to Servlet object. This causes ClassCastExceptions when run in a portlet environment. Each of these calls/casts can be removed and ExternalContext APIs can be used instead to get/set the needed information from the request or response object. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992575#comment-12992575 ] Michael Freedman commented on MYFACES-3039: --- I have to respectively disagree. The only servlet dependency I see in the MyFaces FacesContextImpl I see is in the special constructor code used to self create an external context. Isn't this a holdover from the JSF 1.2 pattern? In JSF 2.0 things were reorganized so the ExternalContext is constructed from a factory and passed to the FacesContext constructor -- ala: FacesContext ctx = new FacesContextImpl( externalContextFactory.getExternalContext(sc, request, response), lifecycle); This allows the FacesContext to be environment neutral (all environmental stuff is within the ExternalContext) -- and with the new FacesContext wrapper its now easy for the bridge to wrap the core context and only override the few method it changes. What is the rationale for the MyFaces model and runtime dependency? If some of that rationale needs to be maintained, can't it be isolated to the circumstance it pertains to and the more general pattern (runtime neutral) be utilized in other cases (like the bridge)? Basically, what I am arguing is that the model supported by the spec and implemented by Mojarra seems to be a general/broad model and should be supported by MyFaces -- and if improvements can be made for specific situations, so be it, but handle as such without penalizing the general. MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext Key: MYFACES-3039 URL: https://issues.apache.org/jira/browse/MYFACES-3039 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Michael Freedman JSF 2.0 improved the definition/handling of the instantiation of the FacesContext allowing non-servlet environments to wrap the base/core impl. This was done because most of the FacesContext apis are inherently runtime environment neutral -- allowing the portlet bridge to not have to duplicate/reimplement and maybe get wrong base core function. Unfortunately MyFaces doesn't conform to this change and hence the Portlet Bridge can't run in the MyFaces environment. Basically the bridge expects to be able to delegate from its FacesContextFactoryImpl.getFacesContext and then wrap the returned FacesContext with its own. This requires the underlying core impl to be runtime (servlet/portlet) neutral during the creation process. The bridge will wrap the FacesContext and supply its own ExternalContext such that any servlet dependent impl in the core FacesContext/ExternalContext will be hidden by overrides. FYI ... until this is addressed I can't begin any testing of the bridge on MyFaces. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-174) Portlet Bridge 3.0.0 -- PortletViewHandler.render needs to reference MimeResponse after the check for portlet request
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-174. Resolution: Fixed See comment above ... Portlet Bridge 3.0.0 -- PortletViewHandler.render needs to reference MimeResponse after the check for portlet request - Key: PORTLETBRIDGE-174 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-174 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha or else you get a ClassCastException when run as a servlet. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-175) Bridge phase listeners have portlet dependecy but can be executed in a servlet request yielding ClassCastException
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-175. Resolution: Fixed Fix Version/s: 3.0.0-alpha As suggested, modified code to ensure we are in a Portlet request before executing phase listener. Bridge phase listeners have portlet dependecy but can be executed in a servlet request yielding ClassCastException -- Key: PORTLETBRIDGE-175 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-175 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0, 2.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha The Bridge temporarily installs its own phase listeners to provide a variety of behaviors . As phase listeners are controlled by the lifecycle and there (can be) is only 1 lifecycle instance per application all listeners are called whenever the lifecycle is run. Because you can have distinct portlets in a application and the application can also run as a servlet care must be taken to only execute the phase listener if its truly the target of the execution. The bridge properly handles this for the multiple portlet case by checking that the event's FacesContext is the same as the thread's (current instances). Unfortunately this doesn't prevent the code from executing in the servlet case. I.e. if a portlet request comes in an is being processed by the bridge it will install the phase listener. If a second request happens concurrently but accesses this app as a servlet, we will execute the bridge's phase listener in this servlet request. This results in a ClassCastException as the code accesses the request object as a PortletRequest (but its not). Simple fix is to expand the test to only execute the phase listener is the FacesContext instance match and its a Portlet request. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-176) encodeActionURL must properly encode urls containing fragment references (#)
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-176. Resolution: Fixed Fix Version/s: 3.0.0-alpha partially fixed: code now at least can deal with incoming URLs containing # fragments. I.e. the utility code that parses this now recognizes the fragment portion separately from the parameter portion. The thing is that that fragments in URLs are essentially thrown away/ignored as the portlet spec provides no way to encode them into the generated URL. encodeActionURL must properly encode urls containing fragment references (#) Key: PORTLETBRIDGE-176 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-176 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0, 2.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha Currently encodeActionURL (and encodeResourceURL?) don't handle (deal with properly) urls that contain fragment references (#). What we should do is parse the # and for now just throw it away. The portlet spec doesn't deal with fragments -- though something might work with local portlets -- wsrp/remote portlets using consumer rewriting will not work. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-177) Portlet Bridge 3.0.0 -- Support Bookmarkable URLs
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-177. Resolution: Fixed Fix Version/s: 3.0.0-alpha Code modified so encodeBookmarkableURL adds a special QS marker indicating its a bookmark url. This param is generally set with a value of true. When set with a value of false, it still signals a renderURL but one which should include the request scope (i.e. a redisplay vs a bookmark url). Portlet Bridge 3.0.0 -- Support Bookmarkable URLs - Key: PORTLETBRIDGE-177 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-177 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha Faces 2.0 has support for bookmarkableURLs, and is implemented by first calling ExternalContext.encodeBookMarkableUrl followed by encodeActionURL. Birdge needs to a) provide an implementation for encodeBookmarkableUrl -- this impl needs to add a parameter to the query string that signals the Bridge's encodeActionUrl to use a renderURL b) modify encodeActionUrl to recognize/use the special parameter and create a renderUrl Note: to make this generic -- we should define a constant for this special parameter in javax.portlet.faces.Bridge -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-178) Portlet Bridge 3.0.0 -- Support Views using Ajax that reference component ids (in the execute or render id list)
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-178. Resolution: Fixed Fix Version/s: 3.0.0-alpha As suggested in original comment -- added the PartialViewContext Impl and do the extra resolution when needed. Portlet Bridge 3.0.0 -- Support Views using Ajax that reference component ids (in the execute or render id list) Key: PORTLETBRIDGE-178 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-178 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha The Faces 2.0 ajax javascript signature takes two parameters that allow you to identify the targets of the action and the render. Many samples, (and hence commonly) set these ids statically. This breaks when run in a portlet/bridge environment because the bridge wraps the entire tree with its own UIViewRoot which adds a NamingContainer to ensure are ids are unique in an overall portal page. I.e. its NC prefix is prepended to the component id. So the problem is the request sends ids x, y, z while the tree contains nc.x, nc,y, nc.z. hence the ids aren't found and nothing is executed/rendered. Fix is to write our own PartialViewContext which overrides getRenderIds() and getExecuteIds() and take all the ids that don't resolve and retry them with the nc id prepended. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-179) Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed that expect to be held for a full lifecycle
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-179. Resolution: Fixed Fix Version/s: 3.0.0-alpha Modfied code so you can configure the portlet via an init parameter with a specific set of FacesContext attributes that should be carried from the action to the render. For these samples I configure with the two attributes needed to get the Facelets (render) restore to work properly. Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed that expect to be held for a full lifecycle - Key: PORTLETBRIDGE-179 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-179 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha In the situation that a ViewRoot isn't being restored by Faces (i.e. the client/bridge pushes an existing ViewRoot into the FacesContext prior to calling restore), and the application has composite components (and hence using Facelets), the restore/subsequent save gets all screwed up because to work properly Faces expects a couple of FacesContext attributes to also be set at this time. I.e. in the bridge at the end of the action phase we release the FacesContext -- this causes attrs to be lost. However we hold onto the ViewRoot (because we can't Faces save it) in a in-memory cache. In the subsequent render we push this viewRoot back into the facesContext before we call restoreView. When the Faces view contains composite components things go off the rails (because it expects the FacesContext to contain two attributes (one keyed with the viewRoot object of the current view (value -- boolean = true) and another keyed with com.sun.faces.FACELET_FACTORY). FYI ... I have contacted the Mojarra team to determine whether they will consider this a bug on their side or not. However to workaround in existing versions I should add a new portlet initParam (maybe something that can be added to the faces-config as well -- but we will wait on the Mojarra guys first) that allows you to name a list of attributes that should be preserved. Then change the code to preserve and restore only those attributes that are requested in this config. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-180) Portlet Bridge 3.0.0 -- Update extension to view mapping to account for JSF 2.0 support of a list of mappable extensions
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-180. Resolution: Fixed Fix Version/s: 3.0.0-alpha Code now parses the list (vs assuming only one) and tries each to see if the resource exists when converting from .jsf (etc) to the actual valid suffix. Portlet Bridge 3.0.0 -- Update extension to view mapping to account for JSF 2.0 support of a list of mappable extensions Key: PORTLETBRIDGE-180 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-180 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha In JSF 2.0 an application can define multiple suffixes that are recognized as being processed by Faces (whereas in 1.2 you only had one). This means translating a viewId to an url requires walking this list and seeing if the underlying resource exists -- Also need vice-versa support. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-181) Portlet Bridge 3.0.0 -- Need to add impls for ExternalContext methods not currently implemented
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-181. Resolution: Fixed Added each of these methods. Portlet Bridge 3.0.0 -- Need to add impls for ExternalContext methods not currently implemented --- Key: PORTLETBRIDGE-181 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-181 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman These include: setResponseBufferSize setResponseContentLength getResponseBufferSize responseFlushBuffer responseSendError -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-182) Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default
Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default --- Key: PORTLETBRIDGE-182 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-182 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Late in the game the bridge impl changed (2.0) whereby a bridge scope is always created on any request that there isn't one (in the case you are in a render or resource request we cache this in a session attr). Because of this renderURLs created via encodeActionURL might retain their scopes across submissions. This doesn't seem like the reasonable default. With Portlet 3.0.0 they added a concept of a bookmarkable url -- which makes it more common for a faces app to create a render url (prior versions could only do it using the special portlet:render? syntax). So we need to fix the encodeActionURL to mark renderURLs as not preserving the scope. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PORTLETBRIDGE-182) Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-182. Resolution: Fixed Fix Version/s: 3.0.0-alpha I leveraged the special QS param that signals to encodeActionURL that its encoding a bookmarkable url. If the value of this QS param is true then the scope isn't preserved (we add a new different param to the url being generated that is recognized in the bridge's render) If the value is false we still create the render url but without this extra param -- hence the bridge will preserve the scope. This later is done/supported as TCK tests rely on this to do render redisplays (within the scope). Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default --- Key: PORTLETBRIDGE-182 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-182 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha Late in the game the bridge impl changed (2.0) whereby a bridge scope is always created on any request that there isn't one (in the case you are in a render or resource request we cache this in a session attr). Because of this renderURLs created via encodeActionURL might retain their scopes across submissions. This doesn't seem like the reasonable default. With Portlet 3.0.0 they added a concept of a bookmarkable url -- which makes it more common for a faces app to create a render url (prior versions could only do it using the special portlet:render? syntax). So we need to fix the encodeActionURL to mark renderURLs as not preserving the scope. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3038) MyFaces fails to recognize ViewDeclarationLanguageFactory when defined in META-INF/services -- throws IllegalStateException instead
MyFaces fails to recognize ViewDeclarationLanguageFactory when defined in META-INF/services -- throws IllegalStateException instead --- Key: MYFACES-3038 URL: https://issues.apache.org/jira/browse/MYFACES-3038 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.3 Reporter: Michael Freedman Spec says a factory can be declared by including a META-INF/services file with the name of the javax.faces factory class (in this case java.faces.view.ViewDeclarationLanguageFactory ) with its contents containing a single line containing the name of the class that implements this factory. The MyFaces startup/read config code throws an IllegalStateException however in this case. Looks like the code wasn't updated to reflect the new 2.0 Factory. Use case -- Portlet Bridge currently uses this methodology and hence doesn't run on MyFaces. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3039) MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext
MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext Key: MYFACES-3039 URL: https://issues.apache.org/jira/browse/MYFACES-3039 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Michael Freedman JSF 2.0 improved the definition/handling of the instantiation of the FacesContext allowing non-servlet environments to wrap the base/core impl. This was done because most of the FacesContext apis are inherently runtime environment neutral -- allowing the portlet bridge to not have to duplicate/reimplement and maybe get wrong base core function. Unfortunately MyFaces doesn't conform to this change and hence the Portlet Bridge can't run in the MyFaces environment. Basically the bridge expects to be able to delegate from its FacesContextFactoryImpl.getFacesContext and then wrap the returned FacesContext with its own. This requires the underlying core impl to be runtime (servlet/portlet) neutral during the creation process. The bridge will wrap the FacesContext and supply its own ExternalContext such that any servlet dependent impl in the core FacesContext/ExternalContext will be hidden by overrides. FYI ... until this is addressed I can't begin any testing of the bridge on MyFaces. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-177) Portlet Bridge 3.0.0 -- Support Bookmarkable URLs
Portlet Bridge 3.0.0 -- Support Bookmarkable URLs - Key: PORTLETBRIDGE-177 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-177 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Reporter: Michael Freedman Assignee: Michael Freedman Faces 2.0 has support for bookmarkableURLs, and is implemented by first calling ExternalContext.encodeBookMarkableUrl followed by encodeActionURL. Birdge needs to a) provide an implementation for encodeBookmarkableUrl -- this impl needs to add a parameter to the query string that signals the Bridge's encodeActionUrl to use a renderURL b) modify encodeActionUrl to recognize/use the special parameter and create a renderUrl Note: to make this generic -- we should define a constant for this special parameter in javax.portlet.faces.Bridge -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-178) Portlet Bridge 3.0.0 -- Support Views using Ajax that reference component ids (in the execute or render id list)
Portlet Bridge 3.0.0 -- Support Views using Ajax that reference component ids (in the execute or render id list) Key: PORTLETBRIDGE-178 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-178 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman The Faces 2.0 ajax javascript signature takes two parameters that allow you to identify the targets of the action and the render. Many samples, (and hence commonly) set these ids statically. This breaks when run in a portlet/bridge environment because the bridge wraps the entire tree with its own UIViewRoot which adds a NamingContainer to ensure are ids are unique in an overall portal page. I.e. its NC prefix is prepended to the component id. So the problem is the request sends ids x, y, z while the tree contains nc.x, nc,y, nc.z. hence the ids aren't found and nothing is executed/rendered. Fix is to write our own PartialViewContext which overrides getRenderIds() and getExecuteIds() and take all the ids that don't resolve and retry them with the nc id prepended. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-179) Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed that expect to be held for a full lifecycle
Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed that expect to be held for a full lifecycle - Key: PORTLETBRIDGE-179 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-179 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman In the situation that a ViewRoot isn't being restored by Faces (i.e. the client/bridge pushes an existing ViewRoot into the FacesContext prior to calling restore), and the application has composite components (and hence using Facelets), the restore/subsequent save gets all screwed up because to work properly Faces expects a couple of FacesContext attributes to also be set at this time. I.e. in the bridge at the end of the action phase we release the FacesContext -- this causes attrs to be lost. However we hold onto the ViewRoot (because we can't Faces save it) in a in-memory cache. In the subsequent render we push this viewRoot back into the facesContext before we call restoreView. When the Faces view contains composite components things go off the rails (because it expects the FacesContext to contain two attributes (one keyed with the viewRoot object of the current view (value -- boolean = true) and another keyed with com.sun.faces.FACELET_FACTORY). FYI ... I have contacted the Mojarra team to determine whether they will consider this a bug on their side or not. However to workaround in existing versions I should add a new portlet initParam (maybe something that can be added to the faces-config as well -- but we will wait on the Mojarra guys first) that allows you to name a list of attributes that should be preserved. Then change the code to preserve and restore only those attributes that are requested in this config. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-180) Portlet Bridge 3.0.0 -- Update extension to view mapping to account for JSF 2.0 support of a list of mappable extensions
Portlet Bridge 3.0.0 -- Update extension to view mapping to account for JSF 2.0 support of a list of mappable extensions Key: PORTLETBRIDGE-180 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-180 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman In JSF 2.0 an application can define multiple suffixes that are recognized as being processed by Faces (whereas in 1.2 you only had one). This means translating a viewId to an url requires walking this list and seeing if the underlying resource exists -- Also need vice-versa support. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-181) Portlet Bridge 3.0.0 -- Need to add impls for ExternalContext methods not currently implemented
Portlet Bridge 3.0.0 -- Need to add impls for ExternalContext methods not currently implemented --- Key: PORTLETBRIDGE-181 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-181 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman These include: setResponseBufferSize setResponseContentLength getResponseBufferSize responseFlushBuffer responseSendError -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-176) encodeActionURL must properly encode urls containing fragment references (#)
encodeActionURL must properly encode urls containing fragment references (#) Key: PORTLETBRIDGE-176 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-176 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0, 1.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Currently encodeActionURL (and encodeResourceURL?) don't handle (deal with properly) urls that contain fragment references (#). What we should do is parse the # and for now just throw it away. The portlet spec doesn't deal with fragments -- though something might work with local portlets -- wsrp/remote portlets using consumer rewriting will not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-175) Bridge phase listeners have portlet dependecy but can be executed in a servlet request yielding ClassCastException
Bridge phase listeners have portlet dependecy but can be executed in a servlet request yielding ClassCastException -- Key: PORTLETBRIDGE-175 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-175 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0, 1.0.0, 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman The Bridge temporarily installs its own phase listeners to provide a variety of behaviors . As phase listeners are controlled by the lifecycle and there (can be) is only 1 lifecycle instance per application all listeners are called whenever the lifecycle is run. Because you can have distinct portlets in a application and the application can also run as a servlet care must be taken to only execute the phase listener if its truly the target of the execution. The bridge properly handles this for the multiple portlet case by checking that the event's FacesContext is the same as the thread's (current instances). Unfortunately this doesn't prevent the code from executing in the servlet case. I.e. if a portlet request comes in an is being processed by the bridge it will install the phase listener. If a second request happens concurrently but accesses this app as a servlet, we will execute the bridge's phase listener in this servlet request. This results in a ClassCastException as the code accesses the request object as a PortletRequest (but its not). Simple fix is to expand the test to only execute the phase listener is the FacesContext instance match and its a Portlet request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-3017) MyFaces Shared (and Core) rework for portlet support
MyFaces Shared (and Core) rework for portlet support Key: MYFACES-3017 URL: https://issues.apache.org/jira/browse/MYFACES-3017 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.3 Reporter: Michael Freedman Assignee: Michael Freedman 1) The render method JspViewDeclarationLanguageBase.java in Shared currently only parses/replaces the VIEW_STATE token if its saving the state in the client -- this is presumably because MyFaces optimizes the server save state and writes the state key as part of render rather then needing to do the post process parse and replace. Because this code is now shared with the Portlet Bridge and the bridge is designed to run in either a MyFaces or Mojarra environment (and Mojarra doesn't have this optimization) the logic needs to be reworked to preserve the MyFaces behavior in its world yet always do the parsing in the Mojarra world. 2) The render method JspViewDeclarationLanguageBase.java currently calls a protected method actuallyRenderView to render the faces tree. Because the portlet bridge spec allows a redirect to occur during this render it must subclass. However for it to get the benefits of the shared code that kicks off the tree rendering the signature of this method should be modified to return a boolean so the portlet subclass can determine whether the render completed successfully or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-173) Upgrade Portlet 2.0 Bridge for JSF 1.2 to JSF 2.0
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-173. Resolution: Fixed Fix Version/s: 3.0.0-alpha Initial merge completed and valdiated on JSF 2.0 (this includes migrating the TCK) Upgrade Portlet 2.0 Bridge for JSF 1.2 to JSF 2.0 - Key: PORTLETBRIDGE-173 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-173 Project: MyFaces Portlet Bridge Issue Type: New Feature Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 3.0.0-alpha Vanilla bug/feature task to migrate Portlet Bridge 2.0.0 (release) to be the base for PortletBridge 3.0.0 (Portlet 2.0 bridge for JSF 2.0) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-173) Upgrade Portlet 2.0 Bridge for JSF 1.2 to JSF 2.0
Upgrade Portlet 2.0 Bridge for JSF 1.2 to JSF 2.0 - Key: PORTLETBRIDGE-173 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-173 Project: MyFaces Portlet Bridge Issue Type: New Feature Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Vanilla bug/feature task to migrate Portlet Bridge 2.0.0 (release) to be the base for PortletBridge 3.0.0 (Portlet 2.0 bridge for JSF 2.0) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-174) Portlet Bridge 3.0.0 -- PortletViewHandler.render needs to reference MimeResponse after the check for portlet request
Portlet Bridge 3.0.0 -- PortletViewHandler.render needs to reference MimeResponse after the check for portlet request - Key: PORTLETBRIDGE-174 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-174 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 3.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman or else you get a ClassCastException when run as a servlet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1996) FacesContextFactoryImpl's FacesContext (CacheRenderKit) needs to extend FacesContextWrapper not FacesContext
FacesContextFactoryImpl's FacesContext (CacheRenderKit) needs to extend FacesContextWrapper not FacesContext Key: TRINIDAD-1996 URL: https://issues.apache.org/jira/browse/TRINIDAD-1996 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Michael Freedman Currently Trinidad's FacesContextFactoryImpl creates a FacesContext of type CacheRenderKit (declared in same file). CacheRenderKit is declared as a class that extends FacesContext. Instead it should extend FacesContextWrapper. By not using the wrapper Trinidad breaks other instances in the hierarchy (lower than it) as it misses the wrapper delegation model. Note: When you make this change. also remove the now obsolete methods that merely delegate. Testcase: Portlet Bridge TCK tests don't run unless this code is changed to extend the Wrapper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-172) Portlet 2.0 Bridge: encodeActionUrl of nonFaces view isn't a renderURL
Portlet 2.0 Bridge: encodeActionUrl of nonFaces view isn't a renderURL --- Key: PORTLETBRIDGE-172 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-172 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman but it should be by spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-172) Portlet 2.0 Bridge: encodeActionUrl of nonFaces view isn't a renderURL
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-172. Resolution: Fixed Fix Version/s: 2.0.0-beta When I recognize that its a nonFaces view I set a fflag indicating its a renderURL which is honored at the time I create the url. Portlet 2.0 Bridge: encodeActionUrl of nonFaces view isn't a renderURL --- Key: PORTLETBRIDGE-172 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-172 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.0-beta but it should be by spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-170) Portlet 2.0 Bridge: Make routine/debug logging configurable.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-170. Fix Version/s: 2.0.0 Resolution: Fixed Done -- now there is a myFaces Bridge specific config parameter to turn on debug messages: initParam nameorg.apache.myfaces.portlet.faces.loggingEnabled/name valuetrue/value /initParam) Portlet 2.0 Bridge: Make routine/debug logging configurable. - Key: PORTLETBRIDGE-170 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-170 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.0 At some point in the future we need to implement a real logging mechanism (Apache logging?) but until them at least make the simplified logging that we do configurable on a per portlet basis so that its not on by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-171) Portlet 2.0 Bridge: update impl to support spec change for turing DIRECT_LINKs into absolute paths in encodeActionURL
Portlet 2.0 Bridge: update impl to support spec change for turing DIRECT_LINKs into absolute paths in encodeActionURL - Key: PORTLETBRIDGE-171 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-171 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Old version of the spec required developers only mark urls being action encoded with the DIRECT_LINK tag if an absolute url. Based on user feedback the spec changed to require encodeActionURL to turn any app relative DIRECT_LINKs into an absolute link before returning. Need to update the impl to reflect this change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-171) Portlet 2.0 Bridge: update impl to support spec change for turing DIRECT_LINKs into absolute paths in encodeActionURL
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-171. Fix Version/s: 2.0.0 Resolution: Fixed Code has been updated to do this. Portlet 2.0 Bridge: update impl to support spec change for turing DIRECT_LINKs into absolute paths in encodeActionURL - Key: PORTLETBRIDGE-171 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-171 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.0 Old version of the spec required developers only mark urls being action encoded with the DIRECT_LINK tag if an absolute url. Based on user feedback the spec changed to require encodeActionURL to turn any app relative DIRECT_LINKs into an absolute link before returning. Need to update the impl to reflect this change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-169) Portlet 2.0 Bridge: Deprecate getResponseContentType and getResponseCharacterSetEncoding in GenericFacesPortlet
Portlet 2.0 Bridge: Deprecate getResponseContentType and getResponseCharacterSetEncoding in GenericFacesPortlet --- Key: PORTLETBRIDGE-169 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-169 Project: MyFaces Portlet Bridge Issue Type: Bug Components: API Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman spec recently deprecated these methods as they are no longer needed for the bridge to run (since we now use forward instead of include). Update the API impl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-170) Portlet 2.0 Bridge: Make routine/debug logging configurable.
Portlet 2.0 Bridge: Make routine/debug logging configurable. - Key: PORTLETBRIDGE-170 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-170 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman At some point in the future we need to implement a real logging mechanism (Apache logging?) but until them at least make the simplified logging that we do configurable on a per portlet basis so that its not on by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (PORTLETBRIDGE-132) Websphere claims there are no private parameters in an action but we expect them
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman reopened PORTLETBRIDGE-132: Websphere claims there are no private parameters in an action but we expect them Key: PORTLETBRIDGE-132 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-132 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 2.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.0 The bridge restricts the view of parameters via the ExternalContext to the privateParameters. On websphere this is coming back null during an action causing the bridge to break. To work around this change the map code to get the full parameter set and remove the public parameters and return the difference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-132) Websphere claims there are no private parameters in an action but we expect them
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-132. Resolution: Fixed Adjusted code as mentioned -- not as efficient but should always work. Websphere claims there are no private parameters in an action but we expect them Key: PORTLETBRIDGE-132 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-132 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 2.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.0 The bridge restricts the view of parameters via the ExternalContext to the privateParameters. On websphere this is coming back null during an action causing the bridge to break. To work around this change the map code to get the full parameter set and remove the public parameters and return the difference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-169) Portlet 2.0 Bridge: Deprecate getResponseContentType and getResponseCharacterSetEncoding in GenericFacesPortlet
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-169. Resolution: Fixed Now marked/documented as deprecated. Portlet 2.0 Bridge: Deprecate getResponseContentType and getResponseCharacterSetEncoding in GenericFacesPortlet --- Key: PORTLETBRIDGE-169 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-169 Project: MyFaces Portlet Bridge Issue Type: Bug Components: API Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman spec recently deprecated these methods as they are no longer needed for the bridge to run (since we now use forward instead of include). Update the API impl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-167) Portlet 2.0 Bridge: update impl to support spec change for config of defaultRenderKitId
Portlet 2.0 Bridge: update impl to support spec change for config of defaultRenderKitId --- Key: PORTLETBRIDGE-167 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-167 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Spec was recently updated to define support for ability of GFP to read a portlet init parameter (javax.portlet.faces.defaultrenderKitId). And as a side effect add a new public method getDefaultRenderKitId(). The GFP init() calls this method (which by default reads from the portlet.xml init param) and sets a portlet context attribute (namespaced by the portlet) so the bridge will know to override any default in the faces-config.xml. The bridge is then supposed to recognize this context attribute and on every request (if it exists) to expose the ResposneStateManger.RENDER_KIT_ID_PARAM as a parameter in the ExternalContexts param maps with the provided value. This is only done if the request doesn't already contain this parameter. Anyway -- need to update the GFP/ExternalContextImpl/Bridge impl to support this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-167) Portlet 2.0 Bridge: update impl to support spec change for config of defaultRenderKitId
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-167. Fix Version/s: 2.0.0-beta Resolution: Fixed Added the implementation Portlet 2.0 Bridge: update impl to support spec change for config of defaultRenderKitId --- Key: PORTLETBRIDGE-167 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-167 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.0-beta Spec was recently updated to define support for ability of GFP to read a portlet init parameter (javax.portlet.faces.defaultrenderKitId). And as a side effect add a new public method getDefaultRenderKitId(). The GFP init() calls this method (which by default reads from the portlet.xml init param) and sets a portlet context attribute (namespaced by the portlet) so the bridge will know to override any default in the faces-config.xml. The bridge is then supposed to recognize this context attribute and on every request (if it exists) to expose the ResposneStateManger.RENDER_KIT_ID_PARAM as a parameter in the ExternalContexts param maps with the provided value. This is only done if the request doesn't already contain this parameter. Anyway -- need to update the GFP/ExternalContextImpl/Bridge impl to support this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-159) Race condition in GenericFacesPortlet: mFacesBridge
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-159.
Fix Version/s: 1.0.1
2.0.0
Resolution: Fixed
Removed lazy initialization
Race condition in GenericFacesPortlet: mFacesBridge
Key: PORTLETBRIDGE-159
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-159
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: API
Reporter: Karl Krukow
Assignee: Michael Freedman
Fix For: 1.0.1, 2.0.0
GenericFacesPortlet contains an instance variable of type Bridge
private Bridge mFacesBridge = null;
this is lazily initialized in initBridge called in called in
initBridge uses the broken double checked locking idiom
private void initBridge() throws PortletException
{
// Ensure te Bridge has been constrcuted and initialized
if (mFacesBridge == null)
{
try
{
// ensure we only ever create/init one bridge per portlet
synchronized(mLock)
{
if (mFacesBridge == null)
{
mFacesBridge = mFacesBridgeClass.newInstance();
mFacesBridge.init(getPortletConfig());
}
}
}
catch (Exception e)
{
throw new PortletException(doBridgeDisptach: error instantiating
the bridge class, e);
}
}
}
On Java 1.5+ this can be made safe by changing the declaration to:
private volatile Bridge mFacesBridge = null;
at a small synchronization cost. Alternatively consider if a version of Josh
Bloch's static initialization on demand could be used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
