[jira] [Commented] (MYFACES-4472) Remove Portlet Support from 4.0?
[ https://issues.apache.org/jira/browse/MYFACES-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644824#comment-17644824 ] Neil Griffin commented on MYFACES-4472: --- [~tandraschko] At this time, there are no plans for the Portlet Spec or for the JSF Portlet Bridge Spec to migrate from javax to jakarta. Those specs will continue to be updated as necessary with the existing javax namespace. > Remove Portlet Support from 4.0? > - > > Key: MYFACES-4472 > URL: https://issues.apache.org/jira/browse/MYFACES-4472 > Project: MyFaces Core > Issue Type: Wish >Reporter: Volodymyr Siedlecki >Priority: Minor > > To be follow up on later as portlet is still under the javax namespace and > hasn't been moved over to EE9 or EE10. > 4.0 Spec still mentions portlets, however. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4472) Remove Portlet Support from 4.0?
[ https://issues.apache.org/jira/browse/MYFACES-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644816#comment-17644816 ] Neil Griffin commented on MYFACES-4472: --- [~tandraschko] Removing portlet support should be fine for 4.0. > Remove Portlet Support from 4.0? > - > > Key: MYFACES-4472 > URL: https://issues.apache.org/jira/browse/MYFACES-4472 > Project: MyFaces Core > Issue Type: Wish >Reporter: Volodymyr Siedlecki >Priority: Minor > > To be follow up on later as portlet is still under the javax namespace and > hasn't been moved over to EE9 or EE10. > 4.0 Spec still mentions portlets, however. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=15981654#comment-15981654
]
Neil Griffin commented on PORTLETBRIDGE-178:
This doesn't seem to be a problem with Mojarra 2.2.13 as
[AjaxBehaviorRenderer.java|https://github.com/javaserverfaces/mojarra/blob/2.2.13/jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/AjaxBehaviorRenderer.java#L341]
finds the corresponding component in the tree and then calls
UIComponent.getClientId() in order to render the value of the
{{javax.faces.partial.execute}} and/or {{javax.faces.partial.render}} XHR
parameter values.
> 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 was sent by Atlassian JIRA
(v6.3.15#6346)
[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-tabpanel=15977788#comment-15977788 ] Neil Griffin commented on PORTLETBRIDGE-188: This is being implemented in JSR 378 with [FACES-2696|https://issues.liferay.com/browse/FACES-2696]. > 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 was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (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-tabpanel=1597#comment-1597 ] Neil Griffin edited comment on PORTLETBRIDGE-192 at 4/20/17 11:23 PM: -- Closing this issue as "Won't Fix" since the FacesBridge is being done under JSR 378 now. In addition, the BridgeContext concept has been removed from the new RI. For more information, see [FACES-2611|https://issues.liferay.com/browse/FACES-2611]. was (Author: ngriffin7a): Closing this issue as "Won't Fix" since the FacesBridge is being done under JSR 378 now. In addition, the BridgeRequestScope concept has been removed from the new RI. For more information, see [FACES-2611|https://issues.liferay.com/browse/FACES-2611]. > 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 was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYFACES-4053) PartialViewContextImpl does not fully implement the requirements outlined in section 2.2.6.1 of the JSF 2.2 Spec
Neil Griffin created MYFACES-4053: - Summary: PartialViewContextImpl does not fully implement the requirements outlined in section 2.2.6.1 of the JSF 2.2 Spec Key: MYFACES-4053 URL: https://issues.apache.org/jira/browse/MYFACES-4053 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.10 Reporter: Neil Griffin [JAVASERVERFACES_SPEC_PUBLIC-1069|https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069] introduced new requirements for compatibility with portlet environments. This resulted in an update to section 2.2.6.1 of the Spec titled "Render Response Partial Processing". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-3675) Session scoped beans are not cleaned up when PortletSession expires or is invalidated
Neil Griffin created MYFACES-3675: - Summary: Session scoped beans are not cleaned up when PortletSession expires or is invalidated Key: MYFACES-3675 URL: https://issues.apache.org/jira/browse/MYFACES-3675 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.10 Environment: Portlets Reporter: Neil Griffin When running in the context of a request, MyFaces calls FacesContext.getCurrentInstance().getExternalContext.getSessionMap() in order to get/set session attributes. This provides the portlet bridge with the ability to get/set attributes using the PortletSession, which is a layer of abstraction on top of the HttpSession. But when a session expires, the org.apache.myfaces.config.ManagedBeanDestroyer.isManagedBean(String) method does not check the attribute name for a portlet environment. This causes a memory leak when running in a portlet environment, because the portlet bridge is not consulted. Specifically, @SessionScoped managed-beans are not cleaned up. The good news is that Section PLT.18.3 of the Portlet 2.0 Specification titled Binding Attributes into a Session requires that PortletSession attribute names be namespaced/prefixed with the javax.portlet.p.ID? pattern when they are stored in the underlying HttpSession. This would enable MyFaces to find the session attributes, so that cleanup can take place correctly during session expiration/invalidation. Here is the parallel issue in Mojarra: http://java.net/jira/browse/JAVASERVERFACES-2691 -- 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] (MYFACES-3675) Session scoped beans are not cleaned up when PortletSession expires or is invalidated
[
https://issues.apache.org/jira/browse/MYFACES-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13554303#comment-13554303
]
Neil Griffin commented on MYFACES-3675:
---
Here is a patched ManagedBeanDestroyer.isManagedBean(String) method:
{code}
public boolean isManagedBean(String name)
{
boolean managed = false;
if (_runtimeConfig.getManagedBean(name) == null)
{
// Section PLT.18.3 of the Portlet 2.0 Specification titled
// Binding Attributes into a Session requires that
// PortletSession attribute names be namespaced/prefixed with
// the javax.portlet.p.ID? pattern. In order to determine
// if the specified name is a SessionScoped managed-bean, it
// is necessary to first strip the pattern from it.
if ((name != null) name.startsWith(javax.portlet.p.))
{
int pos = name.indexOf(?);
if (pos 0)
{
String attributeName = name.substring(pos+1);
managed = (_runtimeConfig.getManagedBean(attributeName) !=
null);
}
}
}
else
{
managed = true;
}
return managed;
}
{code}
Session scoped beans are not cleaned up when PortletSession expires or is
invalidated
-
Key: MYFACES-3675
URL: https://issues.apache.org/jira/browse/MYFACES-3675
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.10
Environment: Portlets
Reporter: Neil Griffin
When running in the context of a request, MyFaces calls
FacesContext.getCurrentInstance().getExternalContext.getSessionMap() in order
to get/set session attributes. This provides the portlet bridge with the
ability to get/set attributes using the PortletSession, which is a layer of
abstraction on top of the HttpSession. But when a session expires, the
org.apache.myfaces.config.ManagedBeanDestroyer.isManagedBean(String) method
does not check the attribute name for a portlet environment. This causes a
memory leak when running in a portlet environment, because the portlet bridge
is not consulted. Specifically, @SessionScoped managed-beans are not cleaned
up.
The good news is that Section PLT.18.3 of the Portlet 2.0 Specification
titled Binding Attributes into a Session requires that PortletSession
attribute names be namespaced/prefixed with the javax.portlet.p.ID?
pattern when they are stored in the underlying HttpSession. This would enable
MyFaces to find the session attributes, so that cleanup can take place
correctly during session expiration/invalidation.
Here is the parallel issue in Mojarra:
http://java.net/jira/browse/JAVASERVERFACES-2691
--
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] (TRINIDAD-2284) Trinidad CoreForm does not render standard javax.faces.encodedURL hidden field
[
https://issues.apache.org/jira/browse/TRINIDAD-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13440277#comment-13440277
]
Neil Griffin commented on TRINIDAD-2284:
Thanks for providing a patch. It would be nice to see this fixed soon.
FWIW, this is the temporary workaround that I came up with:
[ViewDeclarationLanguageJspTCKImpl.java|https://github.com/liferay/liferay-faces/blob/master/test/bridge-tck-compat/src/main/java/com/liferay/faces/bridge/tck/application/view/ViewDeclarationLanguageJspTCKImpl.java]
and
[ViewDeclarationLanguageFactoryTCKImpl.java|https://github.com/liferay/liferay-faces/blob/master/test/bridge-tck-compat/src/main/java/com/liferay/faces/bridge/tck/application/view/ViewDeclarationLanguageFactoryTCKImpl.java]
Also, this requires registration in faces-config.xml:
{code}
factory
view-declaration-language-factorycom.liferay.faces.bridge.tck.application.view.ViewDeclarationLanguageFactoryTCKImpl/view-declaration-language-factory
/factory
{code}
Trinidad CoreForm does not render standard javax.faces.encodedURL hidden field
--
Key: TRINIDAD-2284
URL: https://issues.apache.org/jira/browse/TRINIDAD-2284
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Reporter: Neil Griffin
Attachments: patch.zip
Trinidad PPR Ajax does not work in JSF 2 portlet bridges (like Liferay Faces
Bridge) because the renderer for tr:form does not render the standard hidden
field:
input type=hidden name=javax.faces.encodedURL value=... /
http://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/renderkitdocs/HTML_BASIC/javax.faces.Formjavax.faces.Form.html
Since the field is not rendered, jsf.js uses the action attribute of the
form, which invokes the ACTION_PHASE of the portlet lifecycle. If the hidden
field is rendered properly, then the value of the hidden field is a portlet
ResourceURL which invokes the RESOURCE_PHASE of the portlet lifecycle.
--
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] [Comment Edited] (TRINIDAD-2284) Trinidad CoreForm does not render standard javax.faces.encodedURL hidden field
[
https://issues.apache.org/jira/browse/TRINIDAD-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13440277#comment-13440277
]
Neil Griffin edited comment on TRINIDAD-2284 at 8/24/12 12:30 AM:
--
Thanks for providing a patch. It would be nice to see this fixed soon.
FWIW, this is the temporary workaround that I came up with:
[ViewDeclarationLanguageJspTCKImpl.java|https://github.com/liferay/liferay-faces/blob/master/test/bridge-tck-compat/src/main/java/com/liferay/faces/bridge/tck/application/view/ViewDeclarationLanguageJspTCKImpl.java]
and
[ViewDeclarationLanguageFactoryTCKImpl.java|https://github.com/liferay/liferay-faces/blob/master/test/bridge-tck-compat/src/main/java/com/liferay/faces/bridge/tck/application/view/ViewDeclarationLanguageFactoryTCKImpl.java]
Also, this requires registration in faces-config.xml:
{code}
factory
view-declaration-language-factorycom.liferay.faces.bridge.tck.application.view.ViewDeclarationLanguageFactoryTCKImpl/view-declaration-language-factory
/factory
{code}
BTW, you can ignore the JSP part of the class names. The workaround was
implemented for making Liferay Faces Bridge compatible with the JSR 329 TCK
which uses JSP (not Facelets), but it should work for Facelets too.
was (Author: ngriffin7a):
Thanks for providing a patch. It would be nice to see this fixed soon.
FWIW, this is the temporary workaround that I came up with:
[ViewDeclarationLanguageJspTCKImpl.java|https://github.com/liferay/liferay-faces/blob/master/test/bridge-tck-compat/src/main/java/com/liferay/faces/bridge/tck/application/view/ViewDeclarationLanguageJspTCKImpl.java]
and
[ViewDeclarationLanguageFactoryTCKImpl.java|https://github.com/liferay/liferay-faces/blob/master/test/bridge-tck-compat/src/main/java/com/liferay/faces/bridge/tck/application/view/ViewDeclarationLanguageFactoryTCKImpl.java]
Also, this requires registration in faces-config.xml:
{code}
factory
view-declaration-language-factorycom.liferay.faces.bridge.tck.application.view.ViewDeclarationLanguageFactoryTCKImpl/view-declaration-language-factory
/factory
{code}
Trinidad CoreForm does not render standard javax.faces.encodedURL hidden field
--
Key: TRINIDAD-2284
URL: https://issues.apache.org/jira/browse/TRINIDAD-2284
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Reporter: Neil Griffin
Attachments: patch.zip
Trinidad PPR Ajax does not work in JSF 2 portlet bridges (like Liferay Faces
Bridge) because the renderer for tr:form does not render the standard hidden
field:
input type=hidden name=javax.faces.encodedURL value=... /
http://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/renderkitdocs/HTML_BASIC/javax.faces.Formjavax.faces.Form.html
Since the field is not rendered, jsf.js uses the action attribute of the
form, which invokes the ACTION_PHASE of the portlet lifecycle. If the hidden
field is rendered properly, then the value of the hidden field is a portlet
ResourceURL which invokes the RESOURCE_PHASE of the portlet lifecycle.
--
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-229) portlet-bridge-tck-section3-2-lifecycle-set portlet specifies incorrect web.xml context-param for lifecycle
Neil Griffin created PORTLETBRIDGE-229:
--
Summary: portlet-bridge-tck-section3-2-lifecycle-set portlet
specifies incorrect web.xml context-param for lifecycle
Key: PORTLETBRIDGE-229
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-229
Project: MyFaces Portlet Bridge
Issue Type: TCK Challenge
Components: TCK
Affects Versions: 2.0.0
Environment: N/A
Reporter: Neil Griffin
Assignee: Michael Freedman
[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-section3-2-lifecycle-set, v1.0.0
[Exclude List Version]
N/A
[Test Name]
lifecycleTest
[Complaint (argument for why test is invalid)]
The src/main/webapp/WEB-INF/web.xml descriptor contains the following markup:
{code}
context-param
param-namejavax.portlet.faces.LIFECYCLE_ID/param-name
param-valueTCKLifecycle/param-value
/context-param
{code}
But according to Sections 3.2 and 5.2.1 of the JSR 329 Spec, the param name
should be {{javax.faces.LIFECYCLE_ID}} rather than
{{javax.portlet.faces.LIFECYCLE_ID}}
--
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-230) web.xml specifies Servlet 2.3 instead of Servlet 2.5
Neil Griffin created PORTLETBRIDGE-230:
--
Summary: web.xml specifies Servlet 2.3 instead of Servlet 2.5
Key: PORTLETBRIDGE-230
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-230
Project: MyFaces Portlet Bridge
Issue Type: TCK Challenge
Components: TCK
Affects Versions: 2.0.0
Environment: Tomcat 6
Reporter: Neil Griffin
Assignee: Michael Freedman
[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-jsr329, v1.0.0
[Exclude List Version]
N/A
[Test Name]
portlet-bridge-tck-section3-2-lifecycle-set
portlet-bridge-tck-section3-2-render-policy-always-delegate
portlet-bridge-tck-section3-2-render-policy-default
portlet-bridge-tck-section3-2-render-policy-never-delegate
portlet-bridge-tck-section6-2-configured-response-wrapper
[Complaint (argument for why test is invalid)]
The src/main/webapp/WEB-INF/web.xml descriptor specifies the following DTD:
{code}
!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application
2.3//EN' 'http://java.sun.com/dtd/web-app_2_3.dtd'
web-app
{code}
But JSF 1.2 has a dependency on Servlet 2.5, and the EL-expressions will not
evaluate in Tomcat 6 unless the following XML Schema is specified instead:
{code}
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
version=2.5
{code}
--
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] [Commented] (PORTLETBRIDGE-226) requestProcessingNonFacesTest specifies charset in JSP
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13423264#comment-13423264
]
Neil Griffin commented on PORTLETBRIDGE-226:
Here is the patch by Mike Freedman:
Change the following line (line 51) in chapter4_2_5Result.jsp:
Existing:
if (contentType.equals(renderRequest.getResponseContentType())
dispatcherPass)
New:
if (contentType.startsWith(renderRequest.getResponseContentType())
dispatcherPass)
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
[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] [Commented] (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:comment-tabpanelfocusedCommentId=13423267#comment-13423267
]
Neil Griffin commented on PORTLETBRIDGE-227:
Patch from Mike Freedman:
add after line 73 in GenericFacesTestSuitePortlet.java:
(removeAttribute statement is new line following code at line 72/73.
actionRequest.setAttribute(verifyPreBridgeExclusion, avalue);
super.processAction(actionRequest, actionResponse);
+actionRequest.removeAttribute(verifyPreBridgeExclusion);
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
[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-224) Mojarra version dependency in JSF_ELTest for facesContext implicit object
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin resolved PORTLETBRIDGE-224. Resolution: Not A Problem MyFaces Portlet Bridge 2.0 has the following code in PortletFacesContextImpl.java: // Use one set as current instance in case we are wrapped mElContext.putContext(FacesContext.class, FacesContext.getCurrentInstance()); So I hereby retract this TCK Challenge since it's an issue that can be fixed in Liferay Faces Bridge. Mojarra version dependency in JSF_ELTest for facesContext implicit object - Key: PORTLETBRIDGE-224 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-224 Project: MyFaces Portlet Bridge Issue Type: TCK Challenge Components: TCK Affects Versions: 2.0.0 Reporter: Neil Griffin Assignee: Michael Freedman [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] TestPage203 (JSF_ELTest) [Complaint (argument for why test is invalid)] The JSF_ELTest verifies facesContext implicit object is equal to the value returned by FacesContext.getCurrentInstance(). This works fine with Mojarra 1.2_03, but newer versions of Mojarra have different behavior possibly due to http://java.net/jira/browse/JAVASERVERFACES-565. In newer versions of Mojarra, the com.sun.faces.el.ImplicitObjectELResolver.getValue(ELContext context, Object base, Object property) method returns an instance of com.sun.faces.context.FacesContextImpl, which does not match the value returned by FacesContext.getCurrentInstance(). I'm filing this as a TCK Challenge because Liferay Faces Bridge requires Mojarra 1.2_13-b01 (or newer) due to the following issue: http://java.net/jira/browse/JAVASERVERFACES-977 -- 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-228) supported-publishing-event and supported-processing-event ordering is incorrect according to portlet-app_2_0.xsd
Neil Griffin created PORTLETBRIDGE-228:
--
Summary: 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
[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] [Created] (PORTLETBRIDGE-227) Bridge Spec and TCK assume that the portlet container implements the post-redirect-get design pattern
Neil Griffin created PORTLETBRIDGE-227:
--
Summary: 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
[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)
TCK TestPage203 (JSF_ELTest)
[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 #1: 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.
Problem #2: The TCK TestPage203 (JSF_ELTest) performs some checks to make sure
that objects obtained from the bridge's ELResolver match expected values stored
as request attributes. One of these attributes is
org.apache.myfaces.portlet.faces.testsuite.common.portletConfig, which is set
in the {@link GenericFacesTestSuitePortlet#initTestRequest(PortletRequest)}
method. Again, since the Liferay portlet container does not implement
post-redirect-get, it is not possible for the bridge to programatically
determine whether or not this value should be maintained since it is an
instance of javax.portlet.PortletConfig which the Spec requires to 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] [Created] (PORTLETBRIDGE-226) requestProcessingNonFacesTest specifies charset in JSP
Neil Griffin created PORTLETBRIDGE-226:
--
Summary: 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
[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] [Created] (PORTLETBRIDGE-224) Mojarra version dependency in JSF_ELTest for facesContext implicit object
Neil Griffin created PORTLETBRIDGE-224: -- Summary: Mojarra version dependency in JSF_ELTest for facesContext implicit object Key: PORTLETBRIDGE-224 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-224 Project: MyFaces Portlet Bridge Issue Type: TCK Challenge Components: TCK Affects Versions: 2.0.0 Reporter: Neil Griffin Assignee: Michael Freedman [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] TestPage203 (JSF_ELTest) [Complaint (argument for why test is invalid)] The JSF_ELTest verifies facesContext implicit object is equal to the value returned by FacesContext.getCurrentInstance(). This works fine with Mojarra 1.2_03, but newer versions of Mojarra have different behavior possibly due to http://java.net/jira/browse/JAVASERVERFACES-565. In newer versions of Mojarra, the com.sun.faces.el.ImplicitObjectELResolver.getValue(ELContext context, Object base, Object property) method returns an instance of com.sun.faces.context.FacesContextImpl, which does not match the value returned by FacesContext.getCurrentInstance(). I'm filing this as a TCK Challenge because Liferay Faces Bridge requires Mojarra 1.2_13-b01 (or newer) due to the following issue: http://java.net/jira/browse/JAVASERVERFACES-977 -- 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-225) TCK assumption regarding portlet name
Neil Griffin created PORTLETBRIDGE-225: -- Summary: TCK assumption regarding portlet name Key: PORTLETBRIDGE-225 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-225 Project: MyFaces Portlet Bridge Issue Type: TCK Challenge Components: TCK Affects Versions: 2.0.0 Reporter: Neil Griffin Assignee: Michael Freedman [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 portlet-bridge-tck-section3-2-lifecycle-set, v1.0.0 portlet-bridge-tck-section6-2-configured-response-wrapper, v1.0.0 [Exclude List Version] N/A [Test Name] ALL tests in the TCK. [Complaint (argument for why test is invalid)] The JSR 329 TCK assumes that PortletConfig.getPortletName() returns the same value specified in the WEB-INF/portlet.xml portlet-name element. This is true for Pluto, but not for Liferay Portal. For example, if the portlet-name is chapter5_2Tests-isPostbackTest-portlet, then Liferay Portal will return chapter5_2TestsisPostbackTestportlet. This causes all TCK tests to fail when running under Liferay Portal. I'm filing this as a TCK Challenge because the Portlet API JavaDocs for [PortletConfig.getPortletName()\http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/PortletConfig.html#getPortletName()] do not require that PortletConfig.getPortletName() be the same value specified in the portlet-name element. -- 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] (TRINIDAD-2284) Trinidad CoreForm does not render standard javax.faces.encodedURL hidden field
Neil Griffin created TRINIDAD-2284: -- Summary: Trinidad CoreForm does not render standard javax.faces.encodedURL hidden field Key: TRINIDAD-2284 URL: https://issues.apache.org/jira/browse/TRINIDAD-2284 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Neil Griffin Trinidad PPR Ajax does not work in JSF 2 portlet bridges (like Liferay Faces Bridge) because the renderer for tr:form does not render the standard hidden field: input type=hidden name=javax.faces.encodedURL value=... / http://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/renderkitdocs/HTML_BASIC/javax.faces.Formjavax.faces.Form.html Since the field is not rendered, jsf.js uses the action attribute of the form, which invokes the ACTION_PHASE of the portlet lifecycle. If the hidden field is rendered properly, then the value of the hidden field is a portlet ResourceURL which invokes the RESOURCE_PHASE of the portlet lifecycle. -- 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] [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=13029877#comment-13029877 ] Neil Griffin commented on PORTLETBRIDGE-192: Regarding #1, #2, and #4: Sounds fine, I could go either way. Regarding #3: I've implemented BridgeContext and BridgeConfig and found that the getPortletConfig() and getDefaultViewIdMap() belong on BridgeContext. This is because BridgeContext contains information about the current portlet-name from portlet.xml, since more than one portlet can be defined in portlet.xml. When I had those methods on BridgeConfig, I found that BridgeConfig.getPortletConfig() didn't know which portlet-name to work with, since it is didn't know what the current portlet was. For example, getting context-param values. 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] [Commented] (PORTLETBRIDGE-205) Proposal for 3.0 API: Deprecate constant Bridge.PORTLET_LIFECYCLE_PHASE and refactor BridgeUtil methods accordingly
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014483#comment-13014483
]
Neil Griffin commented on PORTLETBRIDGE-205:
Note that the RI's BridgeImpl has a RequestAttributeListener that relies on the
Bridge.PORTLET_LIFECYCLE_PHASE being present as a request attribute. I still
recommend that Bridge.PORTLET_LIFECYCLE_PHASE be deprecated, and would say that
the RI should do the request attribute as an internal, implementation dependent
technique.
Proposal for 3.0 API: Deprecate constant Bridge.PORTLET_LIFECYCLE_PHASE and
refactor BridgeUtil methods accordingly
---
Key: PORTLETBRIDGE-205
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-205
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
Proposal is to do this in Bridge.java:
/** @deprecated replaced by {@link Bridge#BRIDGE_CONTEXT_ATTRIBUTE} and
{@link BridgeContext#getPortletLifecyclePhase()} */
@Deprecated public static final String PORTLET_LIFECYCLE_PHASE =
javax.portlet.faces.phase;
And to refactor BridgeUtil.getPortletRequestPhase() to something like this:
public static Bridge.PortletPhase getPortletRequestPhase() {
Bridge.PortletPhase portletRequestPhase = null;
FacesContext facesContext = FacesContext.getCurrentInstance();
BridgeContext bridgeContext = (BridgeContext)
facesContext.getAttributes().get(Bridge.BRIDGE_CONTEXT_ATTRIBUTE);
if (bridgeContext != null) {
portletRequestPhase =
bridgeContext.getPortletRequestPhase();
}
return portletRequestPhase;
}
And refactor BridgeUtil.isPortletRequest() to something like this:
public static boolean isPortletRequest() {
FacesContext facesContext = FacesContext.getCurrentInstance();
BridgeContext bridgeContext = (BridgeContext)
facesContext.getAttributes().get(Bridge.BRIDGE_CONTEXT_ATTRIBUTE);
return (bridgeContext != null);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-210) Proposal for 3.0 API: Remove deprecated methods from GenericFacesPortlet
Proposal for 3.0 API: Remove deprecated methods from GenericFacesPortlet
Key: PORTLETBRIDGE-210
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-210
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
The following methods were @Deprecated in Bridge Spec version 2.0.0 and I would
propose they should be removed in 3.0.0:
@Deprecated
public String getResponseCharacterSetEncoding(PortletRequest request) {
...
}
@Deprecated
public String getResponseContentType(PortletRequest request) {
...
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (PORTLETBRIDGE-208) Proposal for 3.0 API: Expose attributes on BridgeRequestScope
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014618#comment-13014618
]
Neil Griffin edited comment on PORTLETBRIDGE-208 at 4/1/11 2:37 PM:
The current thinking is that the BridgeRequestScope interface will be defined
like this:
public interface BridgeRequestScopeK, V extends ConcurrentMapString, Object
{
}
So the getAttribute/setAttribute would not be necessary since it extends
ConcurrentMap.
Closing this issue as WONTFIX
was (Author: ngriffin7a):
The current thinking is that the BridgeRequestScope interface will be
defined like this:
public interface BridgeRequestScopeString, Object extends
ConcurrentMapString, Object {
}
So the getAttribute/setAttribute would not be necessary since it extends
ConcurrentMap.
Closing this issue as WONTFIX
Proposal for 3.0 API: Expose attributes on BridgeRequestScope
-
Key: PORTLETBRIDGE-208
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-208
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
It would be nice for the bridge implementation to be able to get/set various
implementation-dependent attributes on the BridgeRequestScope, like the
following method signatures:
public interface BridgeRequestScope {
...
Object getAttribute(String key);
void setAttribute(String key, Object value);
...
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (PORTLETBRIDGE-208) Proposal for 3.0 API: Expose attributes on BridgeRequestScope
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014618#comment-13014618
]
Neil Griffin edited comment on PORTLETBRIDGE-208 at 4/1/11 2:40 PM:
The current thinking is that the BridgeRequestScope interface will be defined
like this:
public interface BridgeRequestScope extends ConcurrentMapString, Object {
}
So the getAttribute/setAttribute would not be necessary since it extends
ConcurrentMap.
Closing this issue as WONTFIX
was (Author: ngriffin7a):
The current thinking is that the BridgeRequestScope interface will be
defined like this:
public interface BridgeRequestScopeK, V extends ConcurrentMapString, Object
{
}
So the getAttribute/setAttribute would not be necessary since it extends
ConcurrentMap.
Closing this issue as WONTFIX
Proposal for 3.0 API: Expose attributes on BridgeRequestScope
-
Key: PORTLETBRIDGE-208
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-208
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
It would be nice for the bridge implementation to be able to get/set various
implementation-dependent attributes on the BridgeRequestScope, like the
following method signatures:
public interface BridgeRequestScope {
...
Object getAttribute(String key);
void setAttribute(String key, Object value);
...
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-209) Proposal for 3.0 IMPL: BridgeRequestScope must not be restored when a supported-public-render-parameter value changes
Proposal for 3.0 IMPL: BridgeRequestScope must not be restored when a supported-public-render-parameter value changes - Key: PORTLETBRIDGE-209 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-209 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman This is a proposal to add the following language to Section 5.3 of the Spec which discusses Public Render Parameters: If the current portlet is participating in Inter-Portlet Communication (IPC) via supported-public-render-parameter entries in portlet.xml and any of the values have changed, then the BridgeRequestScope must not be restored. I discovered this use case while testing the Public Render Parameters example portlet at portletfaces.org: http://www.portletfaces.org/portletfaces-bridge/examples/jsf2-ipc-pub-render-params I think that this one is hard to understand at first, so perhaps the following Use Case (taken from the aforementioned example portlet) will help describe the problem: 1. Customers portlet and Bookings portlet are placed on the same portal page 2. User selects a customer from the Customers portlet, which invokes the portlet ACTION_PHASE and the bridge processes selectedCustomerId as an OUTGOING Public Render Parameter 3. Bookings portlet undergoes the RENDER_PHASE of the portlet lifecycle, and the bridge processes selectedCustomerId as an INCOMING Public Render Parameter. Bookings portlet updates its UI to show booking details for the selected customer. 4. User changes a form field value (like first name or last name) in the Bookings portlet and clicks Submit which invokes the portlet ACTION_PHASE for the Bookings portlet. Consequently a new BridgeRequestScope is created for the Bookings portlet. Customers portlet undergoes the RENDER_PHASE of the portlet lifecycle and updates its UI accordingly. 5. User selects a DIFFERENT customer from the Customers portlet, which again invokes the ACTION_PHASE and the bridge processes selectedCustomerId as an OUTGOING Public Render Parameter 6. Bookings portlet again undergoes the RENDER_PHASE of the portlet lifecycle. BUT AT THIS POINT the BridgeRequestScope created in Step#4 MUST NOT BE RESTORED. If it were restored, then the bridge would not Lifecycle.execute(), and skip directly to the RENDER_RESPONSE phase. That means that the INCOMING Public Render Parameters handled by the PhaseListener in Spec Section 5.3.2 would get skipped, and the new selectedCustomerId would not be processed. By not restoring, Lifecycle.execute() is permitted to happen, and the INCOMING Public Render Parameters are processed accordingly. -- 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=13013890#comment-13013890 ] Neil Griffin commented on PORTLETBRIDGE-206: I tried implementing this with facesContext.getAttributes.put(name, value) but couldn't make it work. I had to use portletRequest.setAttribute(name, value) instead. Explanation: The bridge's ExternalContext implementation needs to get access to the BridgeContext during construction. At this time, the FacesContext is also undergoing construction. Therefore it is not possible for the ExternalContext implementation to call FacesContext.getCurrentInstance().getAttributes().get(name). However, it can call portletRequest.getAttribute(name) since the portletRequest is passed to the ExternalContext implementation during construction. 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=13014241#comment-13014241 ] Neil Griffin commented on PORTLETBRIDGE-206: Mike and I discussed this and the facesContext.getAttributes.put(name, value) approach will be the way to go. 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] [Created] (PORTLETBRIDGE-205) Proposal for 3.0 API: Deprecate constant Bridge.PORTLET_LIFECYCLE_PHASE and refactor BridgeUtil methods accordingly
Proposal for 3.0 API: Deprecate constant Bridge.PORTLET_LIFECYCLE_PHASE and
refactor BridgeUtil methods accordingly
---
Key: PORTLETBRIDGE-205
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-205
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
Proposal is to do this in Bridge.java:
/** @deprecated replaced by {@link Bridge#BRIDGE_CONTEXT_ATTRIBUTE} and
{@link BridgeContext#getPortletLifecyclePhase()} */
@Deprecated public static final String PORTLET_LIFECYCLE_PHASE =
javax.portlet.faces.phase;
And to refactor BridgeUtil.getPortletRequestPhase() to something like this:
public static Bridge.PortletPhase getPortletRequestPhase() {
Bridge.PortletPhase portletRequestPhase = null;
FacesContext facesContext = FacesContext.getCurrentInstance();
ExternalContext externalContext =
facesContext.getExternalContext();
MapString, Object requestMap =
externalContext.getRequestMap();
BridgeContext bridgeContext = (BridgeContext)
requestMap.get(Bridge.BRIDGE_CONTEXT_ATTRIBUTE);
if (bridgeContext != null) {
portletRequestPhase =
bridgeContext.getPortletRequestPhase();
}
return portletRequestPhase;
}
And refactor BridgeUtil.isPortletRequest() to something like this:
public static boolean isPortletRequest() {
FacesContext facesContext = FacesContext.getCurrentInstance();
ExternalContext externalContext =
facesContext.getExternalContext();
MapString, Object requestMap =
externalContext.getRequestMap();
BridgeContext bridgeContext = (BridgeContext)
requestMap.get(Bridge.BRIDGE_CONTEXT_ATTRIBUTE);
return (bridgeContext != null);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-206) Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE
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] [Issue Comment Edited] (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008752#comment-13008752 ] Neil Griffin edited comment on PORTLETBRIDGE-189 at 3/30/11 11:38 AM: -- Factory discovery by the implementation should support the following syntax in any META-INF/faces-config.xml in the classpath, or WEB-INF/faces-config.xml in the WAR: factory factory-extension bridge:bridge-factoryFQCN/bridge:bridge-factory bridge:bridge-context-factoryFQCN/bridge:bridge-context-factory bridge:bridge-navigation-handler-factoryFQCN/bridge:bridge-navigation-handler-factory bridge:bridge-request-scope-factoryFQCN/bridge:bridge-request-scope-factory bridge:bridge-request-scope-manager-factoryFQCN/bridge:bridge-request-scope-manager-factory bridge:portlet-container-adapter-factoryFQCN/bridge:portlet-container-adapter-factory /factory-extension /factory was (Author: ngriffin7a): Factory discovery by the implementation should support the following syntax in any META-INF/faces-config.xml in the classpath, or WEB-INF/faces-config.xml in the WAR: factory factory-extension bridge:bridge-factoryFQCN/bridge:bridge-factory bridge:bridge-context-factoryFQCN/bridge:bridge-context-factory bridge:bridge-navigation-handler-factoryFQCN/bridge:bridge-navigation-handler-factory bridge:bridge-request-scope-factoryFQCN/bridge:bridge-request-scope-factory bridge:bridge-scope-manager-factoryFQCN/bridge:bridge-scope-manager-factory bridge:portlet-container-adapter-factoryFQCN/bridge:portlet-container-adapter-factory /factory-extension /factory Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- 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=13013525#comment-13013525 ] Neil Griffin commented on PORTLETBRIDGE-206: Do you mean calling facesContext.getAttributes.put(name, value) rather than portletRequest.setAttribute(name, value)? 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] [Created] (PORTLETBRIDGE-207) Proposal for 3.0 alignment with JSF 2.2: Add method ExternalContext#setFlash(Flash) to JSF API
Proposal for 3.0 alignment with JSF 2.2: Add method ExternalContext#setFlash(Flash) to JSF API -- Key: PORTLETBRIDGE-207 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-207 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Currently the JSF 2.0 ExternalContext has a method named ExternalContext.getFlash() http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getFlash() But there is no ExternalContext.setFlash(Flash); Because of PORTLETBRIDGE-201 it would be necessary to add this method to ExternalContext in the JSF API. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-208) Proposal for 3.0 API: Expose attributes on BridgeRequestScope
Proposal for 3.0 API: Expose attributes on BridgeRequestScope
-
Key: PORTLETBRIDGE-208
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-208
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
It would be nice for the bridge implementation to be able to get/set various
implementation-dependent attributes on the BridgeRequestScope, like the
following method signatures:
public interface BridgeRequestScope {
...
Object getAttribute(String key);
void setAttribute(String key, Object value);
...
}
--
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=13013637#comment-13013637
]
Neil Griffin commented on PORTLETBRIDGE-202:
Can you point me to the code in the RI that:
1) Handles the encoding of the target viewId
2) Performs restoration if the mode is the same
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] [Created] (PORTLETBRIDGE-201) Proposal for 3.0 IMPL: Preserve and restore Flash scope within BridgeRequestScope
Proposal for 3.0 IMPL: Preserve and restore Flash scope within BridgeRequestScope - Key: PORTLETBRIDGE-201 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-201 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman In order to make the JSF2 Flash scope work with navigation-rules that take place within the Portlet 2ACTION_PHASE, it is necessary to preserve the Flash scope in the BridgeRequestScope so that it can survive into the RENDER_PHASE. For more info as to implementation details, search for flash 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-202) Proposal for 3.0 IMPL: Support mode changes via StateAwareResponse#setPortletMode(PortletMode)
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. For more information regarding implementation details, please search for mode 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-203) Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope
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] [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=13012597#comment-13012597
]
Neil Griffin commented on PORTLETBRIDGE-203:
Not sure about application developers, but there's a bunch of stuff that
Mojarra is placing in this scope:
18:20:47,625 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[com.sun.faces.renderKitImplForRequest]
value=[com.sun.faces.renderkit.RenderKitFactoryImpl@2c29c8]
18:20:47,626 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[com.sun.faces.context.StateContext_KEY]
value=[com.sun.faces.context.StateContext@6b3c55]
18:20:47,627 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[com.sun.faces.context.FacesContextImpl_POST_BACK] value=[true]
18:20:47,627 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[RequestFlashManager] value=[previousRequestSequenceNumber: 3
nextRequestSequenceNumber: 1]
18:20:47,628 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[SavedResponseCompleteFlagValue] value=[false]
18:20:47,629 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[javax.faces.component.AjaxBehaviors]
value=[com.sun.faces.component.behavior.AjaxBehaviors@462601]
18:20:47,630 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[com.sun.faces.facelets.FACELET_CONTEXT]
value=[com.sun.faces.facelets.impl.DefaultFaceletContext@6938ed]
18:20:47,631 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[com.sun.faces.INVOCATION_PATH] value=[/*]
18:20:47,633 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute
name=[com.sun.faces.application.ApplicationImpl.IS_PROCESSING_LISTENERS]
value=[{class javax.faces.event.PostAddToViewEvent=false, class
javax.faces.event.PreValidateEvent=false, class
javax.faces.event.PostConstructViewMapEvent=false, class
javax.faces.event.PostValidateEvent=false}]
18:20:47,634 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[com.sun.faces.FACES_VIEW_STATE] value=[... MORE STUFF ...]
18:20:47,635 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[com.sun.faces.logicalViewMap] value=[8077633702120430112]
18:20:47,645 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[facelets.Encoding] value=[UTF-8]
18:20:47,646 TRACE [BridgeRequestScopeImpl:243] Restoring FacesContext
attribute name=[javax.faces.SEPARATOR_CHAR] value=[:]
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] [Issue Comment Edited] (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008752#comment-13008752 ] Neil Griffin edited comment on PORTLETBRIDGE-189 at 3/29/11 8:12 PM: - Factory discovery by the implementation should support the following syntax in any META-INF/faces-config.xml in the classpath, or WEB-INF/faces-config.xml in the WAR: factory factory-extension bridge:bridge-factoryFQCN/bridge:bridge-factory bridge:bridge-context-factoryFQCN/bridge:bridge-context-factory bridge:bridge-navigation-handler-factoryFQCN/bridge:bridge-navigation-handler-factory bridge:bridge-request-scope-factoryFQCN/bridge:bridge-request-scope-factory bridge:bridge-scope-manager-factoryFQCN/bridge:bridge-scope-manager-factory bridge:portlet-container-adapter-factoryFQCN/bridge:portlet-container-adapter-factory /factory-extension /factory was (Author: ngriffin7a): Factory discovery by the implementation should support the following syntax in any META-INF/faces-config.xml in the classpath, or WEB-INF/faces-config.xml in the WAR: factory factory-extension bridge:bridge-factoryFQCN/bridge:bridge-factory bridge:bridge-context-factoryFQCN/bridge:bridge-context-factory bridge:bridge-navigation-handler-factoryFQCN/bridge:bridge-navigation-handler-factory bridge:bridge-request-scope-factoryFQCN/bridge:bridge-request-scope-factory bridge:portlet-container-adapter-factoryFQCN/bridge:portlet-container-adapter-factory /factory-extension /factory Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PORTLETBRIDGE-200) Proposal for 3.0 alignment with JSF 2.2: Scope management in support of @PreDestroy annotation
Proposal for 3.0 alignment with JSF 2.2: Scope management in support of @PreDestroy annotation -- Key: PORTLETBRIDGE-200 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-200 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Section 6.8.1 of the Spec discusses the need for the @BridgePreDestroy annotation. Here's the background for the requirement... Let's start by looking at the JavaDoc comments for the following methods on the JSF ExternalContext class: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getApplicationMap() http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestMap() http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getSessionMap() The design here seems good, in that it is servlet/portlet agnostic: The JSF API makes it clear that it is the responsibility of the underlying java.util.Map to invoke methods annotated with javax.annotation.PreDestroy when attributes are removed from the Map. But here is the problem: The Mojarra and MyFaces JSF implementations don't have this logic in their Map implementations. Instead, they that they rely on the underlying Servlet Container (i.e. Tomcat) to call the listeners when attributes are added/removed. See: http://download.oracle.com/javaee/6/api/javax/servlet/ServletContextAttributeListener.html Mojarra: The class named ConfigureListener implements the javax.servlet.ServletContextAttributeListener interface: http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java?rev=8946 MyFaces: The class named ManagedBeanDestroyerListener implements the javax.servlet.ServletContextAttributeListener interface: http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/webapp/ManagedBeanDestroyerListener.java To further explain the problem... Portlet Containers typically implement the javax.portlet.PortletRequest as a layer of abstraction on top of an underlying javax.servlet.http.HttpServletRequest. However, often times that underlying HttpServletRequest is issued against a webapp context other than that of the portlet. In the case of the typical Portal+Tomcat bundle, the browser issues an HTTP-GET request to the tomcat/webapps/ROOT context. If the JSF implementation (Mojarra or MyFaces) where present in the tomcat/webapps/ROOT context, then their ServletContextAttributeListeners would get invoked. But that's not where the JSF implementation typically lives -- instead, it lives in a different context like tomcat/webapps/my-jsf-portlet. So that means in a (local) portal environment, the ServletContextAttributeListeners do not get invoked. What's further complicates things... There are two different kinds of portals: Local (like Liferay) and Remote (like Oracle WebCenter). Local Portals invoke portlets that are running within the same servlet container. Remote Portals invoke portlets that are running elsewhere via WSRP. As I stated earlier, in the case of Local Portals, the Mojarra and MyFaces ServletContextAttributeListeners don't get invoked in other contexts. BUT in the Remote Portal WSRP scenario, the Mojarra and MyFaces ServletContextAttributeListeners DO INDEED get invoked. Finally, the last component of the problem is that the JSF API doesn't really address the whole idea of scope management, such as listening to when a scope comes to an end. That's left as an implementation detail, and the bridge basically is left in the dark as to when underlying map entries are supposed to go out-of-scope, and also has no idea which entries in the map are managed beans, unless they are annotated with the @ManagedBean annotation. So that's why Section 6.8.1 introduces the @BridgePreDestroy annotation. In a portlet environment, Mojarra/MyFaces cannot be relied upon to invoke methods annotated with plain old @PreDestroy. They might, or they might not. So in order to have a reliable mechanism for a pre destroy type of annotated method in a portlet environment, the Bridge provides the @BridgePreDestroy annotation. It is guaranteed to always work in a portlet environment. So this issue serves as a proposal to align with the JSF 2.2 EG in order to fortify the JSF API with scope management (or scope listening) features. This would also enable us to deprecate the @BridgePreDestroy feature. Bear in mind that CDI comes into play here as well. Whatever we do, we want to play nicely with CDI when it is present in the portlet application. -- This message is automatically generated by
[jira] [Commented] (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009609#comment-13009609 ] Neil Griffin commented on PORTLETBRIDGE-189: I like it. I like it alot. @Alexander: Is ServiceTracker fully CDI compatible in its current form? Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-196) Proposal for 3.0 API: javax.portlet.faces.application.BridgeNavigationHandler and associated BridgeNavigationHandlerFactory
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009067#comment-13009067 ] Neil Griffin commented on PORTLETBRIDGE-196: Gee I was not aware of an existing NavigationHandler factory. I just checked the JavaDoc but I'm not seeing it in the typical spot: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html Proposal for 3.0 API: javax.portlet.faces.application.BridgeNavigationHandler and associated BridgeNavigationHandlerFactory --- Key: PORTLETBRIDGE-196 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-196 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman This abstract class would define the contract for a brige-specific NavigationHandler that fortifies the JSF runtime with the ability to handle to-view-id entries in navigaion-case blocks that respect the Bridge.PORTLET_MODE_PARAMETER parameter for switching to a different PortletMode(s) and the Bridge.PORTLET_WINDOWSTATE_PARAMETER parameter for switching to a different WindowState(s). It would also have the ability to react to changes in portlet modes that were done programattically by portlet developers that called StateAwareResponse.setWindowState(WindowState) during the INVOKE_APPLICATION phase of the JSF lifecycle. Finally, this abstraction would remove the requirement for setting values on the ActionResponse in the ExternalContext.encodeActionURL(String) method as described in Spec section 5.4.2. Strictly speaking that method, is only supposed to return a value, and not take any underlying actions. 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/application/BridgeNavigationHandler.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/application/BridgeNavigationHandlerFactory.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009069#comment-13009069 ] Neil Griffin commented on PORTLETBRIDGE-189: Hi Scott, could you clarify for my what you mean by follow the complete hierarchy ? Thanks. Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-199) Proposal for 3.0 API: BridgeUtil.getClassPathResourceAsString(String resourcePath)
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009077#comment-13009077
]
Neil Griffin commented on PORTLETBRIDGE-199:
The functionality of this method is currently provided in
GenericFacesPortlet.java:
private String getFromServicesPath(PortletContext context, String resourceName)
{
...
}
The reason why I suggested moving this to BridgeUtil, was because at one time
in the development of the PortletFaces Bridge, I needed this functionality both
in GenericFacesPortlet (to discover the bridge impl) and in another place to
discover the BridgeConfig impl. Having the method in BridgeUtil provided an
opportunity to reuse code. However, I just realized that, since I'm using
BridgeFactoryFinder (PORTLETBRIDGE-189), I don't need it to be in BridgeUtil
anymore. If we perform bridge discovery with a Factory mechanism as proposed in
PORTLETBRIDGE-195, then this private method would no longer be required in
GenericFacesPortlet. Instead, it would be required in BridgeFactoryFinder, so
that it could find an implementation of the finder in the classpath. So I would
be willing to retract this proposal if we do the BridgeFactoryFinder.
Proposal for 3.0 API: BridgeUtil.getClassPathResourceAsString(String
resourcePath)
--
Key: PORTLETBRIDGE-199
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-199
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
Proposal is to introduce a utility method that can load the contents of
classpath resources (like META-INF/services/filename) into a String.
This will help the API with discovery of the implementation of
BridgeFactoryFinder specified in PORTLETBRIDGE-189
See the following class for more details:
http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeUtil.java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-197) Proposal for 3.0 API: Integration with CDI
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009180#comment-13009180
]
Neil Griffin commented on PORTLETBRIDGE-197:
Totally agree -- thanks Kito!
Proposal for 3.0 API: Integration with CDI
--
Key: PORTLETBRIDGE-197
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-197
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
There are some areas that I can think of that pertain to integration with CDI:
1. General CDI integration/compatibility for the bridge, portlet lifecycle,
and faces lifecycle.
2. Ability to @Inject into instances of
javax.portlet.faces.BridgePublicRenderParameterHandler
3. Ability to @Inject into instances of
javax.portlet.faces.event.EventNavigationResult
4. Ability to @Inject public render parameter values #{el-expression} into
CDI managed beans and Faces @ManagedBean
5. Ability to @Inject factory implementations, rather than specifying them in
faces-config.xml files, and have this integrate with the BridgeFactoryFinder
specified in PORTLETBRIDGE-189
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (PORTLETBRIDGE-197) Proposal for 3.0 API: Integration with CDI
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009180#comment-13009180
]
Neil Griffin edited comment on PORTLETBRIDGE-197 at 3/21/11 3:38 PM:
-
Actually I entered BridgeEventHandler by mistake. I'll make the change in the
issue writeup.
was (Author: ngriffin7a):
Totally agree -- thanks Kito!
Proposal for 3.0 API: Integration with CDI
--
Key: PORTLETBRIDGE-197
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-197
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
There are some areas that I can think of that pertain to integration with CDI:
1. General CDI integration/compatibility for the bridge, portlet lifecycle,
and faces lifecycle.
2. Ability to @Inject into instances of
javax.portlet.faces.BridgePublicRenderParameterHandler
3. Ability to @Inject into instances of
javax.portlet.faces.event.EventNavigationResult
4. Ability to @Inject public render parameter values #{el-expression} into
CDI managed beans and Faces @ManagedBean
5. Ability to @Inject factory implementations, rather than specifying them in
faces-config.xml files, and have this integrate with the BridgeFactoryFinder
specified in PORTLETBRIDGE-189
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (PORTLETBRIDGE-197) Proposal for 3.0 API: Integration with CDI
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009180#comment-13009180
]
Neil Griffin edited comment on PORTLETBRIDGE-197 at 3/21/11 3:38 PM:
-
Actually I entered EventNavigationResult by mistake. I'll make the change in
the issue writeup.
was (Author: ngriffin7a):
Actually I entered BridgeEventHandler by mistake. I'll make the change in
the issue writeup.
Proposal for 3.0 API: Integration with CDI
--
Key: PORTLETBRIDGE-197
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-197
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
There are some areas that I can think of that pertain to integration with CDI:
1. General CDI integration/compatibility for the bridge, portlet lifecycle,
and faces lifecycle.
2. Ability to @Inject into instances of
javax.portlet.faces.BridgePublicRenderParameterHandler
3. Ability to @Inject into instances of
javax.portlet.faces.event.EventNavigationResult
4. Ability to @Inject public render parameter values #{el-expression} into
CDI managed beans and Faces @ManagedBean
5. Ability to @Inject factory implementations, rather than specifying them in
faces-config.xml files, and have this integrate with the BridgeFactoryFinder
specified in PORTLETBRIDGE-189
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009325#comment-13009325 ] Neil Griffin commented on PORTLETBRIDGE-189: Hi Alexander, can you paste a link to the source in SVN? I tried to find in the trunk but didn't see it. Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009325#comment-13009325 ] Neil Griffin edited comment on PORTLETBRIDGE-189 at 3/21/11 7:29 PM: - Hi Alexander, can you paste a link to the source in SVN? I tried to find in the bridge trunk but didn't see it. Is it part of the RichFaces trunk? was (Author: ngriffin7a): Hi Alexander, can you paste a link to the source in SVN? I tried to find in the trunk but didn't see it. Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008752#comment-13008752 ] Neil Griffin commented on PORTLETBRIDGE-189: Factory discovery by the implementation should support the following syntax in any META-INF/faces-config.xml in the classpath, or WEB-INF/faces-config.xml in the WAR: factory factory-extension bridge:bridge-factoryFQCN/bridge:bridge-factory bridge:bridge-context-factoryFQCN/bridge:bridge-context-factory bridge:bridge-navigation-handler-factoryFQCN/bridge:bridge-navigation-handler-factory bridge:bridge-request-scope-factoryFQCN/bridge:bridge-request-scope-factory bridge:portlet-container-adapter-factoryFQCN/bridge:portlet-container-adapter-factory /factory-extension /factory Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-197) Proposal for 3.0 API: Integration with CDI
Proposal for 3.0 API: Integration with CDI
--
Key: PORTLETBRIDGE-197
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-197
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
There are some areas that I can think of that pertain to integration with CDI:
1. General CDI integration/compatibility for the bridge, portlet lifecycle, and
faces lifecycle.
2. Ability to @Inject into instances of
javax.portlet.faces.BridgePublicRenderParameterHandler
3. Ability to @Inject into instances of
javax.portlet.faces.event.EventNavigationResult
4. Ability to @Inject public render parameter values #{el-expression} into CDI
managed beans and Faces @ManagedBean
5. Ability to @Inject factory implementations, rather than specifying them in
faces-config.xml files, and have this integrate with the BridgeFactoryFinder
specified in PORTLETBRIDGE-189
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-198) Proposal for 3.0 API: javax.portlet.faces.scope.BridgeScopeManager and associated BridgeScopeManagerFactory
Proposal for 3.0 API: javax.portlet.faces.scope.BridgeScopeManager and associated BridgeScopeManagerFactory --- Key: PORTLETBRIDGE-198 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-198 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman 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/scope/BridgeScopeManager.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/scope/BridgeScopeManagerFactory.java Note that the API method signatures for the BridgeScopeManager interface are yet to be defined. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-199) Proposal for 3.0 API: BridgeUtil.getClassPathResourceAsString(String resourcePath)
Proposal for 3.0 API: BridgeUtil.getClassPathResourceAsString(String resourcePath) -- Key: PORTLETBRIDGE-199 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-199 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Proposal is to introduce a utility method that can load the contents of classpath resources (like META-INF/services/filename) into a String. This will help the API with discovery of the implementation of BridgeFactoryFinder specified in PORTLETBRIDGE-189 See the following class for more details: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeUtil.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008632#comment-13008632 ] Neil Griffin commented on PORTLETBRIDGE-189: Note that I just did a commit to the BridgeFactoryFinder.java class and simplified it. Please review when y'all get a chance. It now has the ability to have a BridgeFactoryFinderImpl.java in the bridge implementation. Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-191) Proposal for 3.0 API: javax.portlet.faces.config.BridgeConfig and associated BridgeConfigFactory
Proposal for 3.0 API: javax.portlet.faces.config.BridgeConfig and associated BridgeConfigFactory Key: PORTLETBRIDGE-191 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-191 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman This interface defines a contract for getting portlet bridge configuration values. 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/config/BridgeConfig.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/config/BridgeConfigFactory.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-192) Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory
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] Created: (PORTLETBRIDGE-193) Proposal for 3.0 API: javax.portlet.faces.adapter.PortletContainerAdapter and associated PortletContainerAdapterFactory
Proposal for 3.0 API: javax.portlet.faces.adapter.PortletContainerAdapter and associated PortletContainerAdapterFactory --- Key: PORTLETBRIDGE-193 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-193 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman This proposal is for a simple contract for adapting features and idiosyncrasies of different portlet containers to the bridge. 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/adapter/PortletContainerAdapter.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/adapter/PortletContainerAdapterFactory.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/adapter/ActionResponseAdapter.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/adapter/MimeResponseAdapter.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/adapter/PortletRequestAdapter.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-194) Proposal for 3.0 API: javax.portlet.faces.scope.BridgeRequestScope and associated BridgeRequestScopeFactory
Proposal for 3.0 API: javax.portlet.faces.scope.BridgeRequestScope and associated BridgeRequestScopeFactory --- Key: PORTLETBRIDGE-194 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-194 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Section 5.1.2 of the Spec describes a concept called the bridge request scope and this proposal would abstract-out this concept for better modularity. 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/scope/BridgeRequestScope.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/scope/BridgeRequestScopeFactory.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-195) Proposal for 3.0 API: BridgeFactory mechanism for bridge discovery an instantiation
Proposal for 3.0 API: BridgeFactory mechanism for bridge discovery an instantiation --- Key: PORTLETBRIDGE-195 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-195 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Note that for backward-compatibility, the factory implementation could first check for GenericFacesPortlet.BRIDGE_CLASS and GenericFacesPortlet.BRIDGE_SERVICE_CLASSPATH before creating a default instance. Please refer to the following class for this proposal: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactory.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-196) Proposal for 3.0 API: javax.portlet.faces.application.BridgeNavigationHandler and associated BridgeNavigationHandlerFactory
Proposal for 3.0 API: javax.portlet.faces.application.BridgeNavigationHandler and associated BridgeNavigationHandlerFactory --- Key: PORTLETBRIDGE-196 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-196 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman This abstract class would define the contract for a brige-specific NavigationHandler that fortifies the JSF runtime with the ability to handle to-view-id entries in navigaion-case blocks that respect the Bridge.PORTLET_MODE_PARAMETER parameter for switching to a different PortletMode(s) and the Bridge.PORTLET_WINDOWSTATE_PARAMETER parameter for switching to a different WindowState(s). It would also have the ability to react to changes in portlet modes that were done programattically by portlet developers that called StateAwareResponse.setWindowState(WindowState) during the INVOKE_APPLICATION phase of the JSF lifecycle. Finally, this abstraction would remove the requirement for setting values on the ActionResponse in the ExternalContext.encodeActionURL(String) method as described in Spec section 5.4.2. Strictly speaking that method, is only supposed to return a value, and not take any underlying actions. 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/application/BridgeNavigationHandler.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/application/BridgeNavigationHandlerFactory.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PORTLETBRIDGE-191) Proposal for 3.0 API: javax.portlet.faces.config.BridgeConfig and associated BridgeConfigFactory
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008660#comment-13008660 ] Neil Griffin commented on PORTLETBRIDGE-191: Forgot to mention that I haven't been able to figure out how to make the BridgeConfigFactory wrappaple (participate in a chain-of-responsibility). It seems to me that this one is a chicken-and-the-egg scenario. Not really sure why anyone would want to inject a different one of these anyway. Proposal for 3.0 API: javax.portlet.faces.config.BridgeConfig and associated BridgeConfigFactory Key: PORTLETBRIDGE-191 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-191 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman This interface defines a contract for getting portlet bridge configuration values. 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/config/BridgeConfig.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/config/BridgeConfigFactory.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-189) Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder
Proposal for 3.0 API: javax.portlet.faces.BridgeFactoryFinder - Key: PORTLETBRIDGE-189 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-189 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Discussion of *which* factories can be done in other issues, but I wanted to discuss the idea of having a BridgeFactoryFinder in this issue. In order to make the bridge more extensible, I would propose a javax.portlet.faces.BridgeFactoryFinder based on the same idea found in Faces: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/FactoryFinder.html For a prototype of this idea, please refer to the following class in the PortletFaces Bridge trunk: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/BridgeFactoryFinder.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PORTLETBRIDGE-112) Improve compatibility with Liferay Portal for portlets that extend GenericFacesPortlet
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852849#action_12852849
]
Neil Griffin commented on PORTLETBRIDGE-112:
This is something that would best be fixed in the Liferay portlet container
itself. We can do this for Liferay 6, but Liferay 4.x and Liferay 5.x are not
getting dot-releases anymore. My guess is that Liferay 5.x has the widest
deployment, so that's why I recommended putting the hack in the bridge.
Improve compatibility with Liferay Portal for portlets that extend
GenericFacesPortlet
--
Key: PORTLETBRIDGE-112
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-112
Project: MyFaces Portlet Bridge
Issue Type: Improvement
Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Neil Griffin
Liferay Portal 5.2.3 (and newer) has a PortletInvokerImpl.isFacesPortlet()
method that will return true if the value of the portlet-class from
WEB-INF/portlet.xml for javax.portlet.faces.GenericFacesPortlet. However,
if someone needs to subclass javax.portlet.faces.GenericFacesPortlet and
override the getBridgeClassName() method, then Liferay's
PortletInvokerImpl.isFacesPortlet() will return false.
The purpose of PortletInvokerImpl.isFacesPortlet() is really just for
Liferay's PortletRequestImpl.init(HttpServletRequest, Portlet,
InvokerPortlet, PortletContext, WindowState, PortletMode, PortletPreferences,
long) method, which will strip-off the namespace from request parameters for
all portlets except JSF portlets.
This is somewhat of a hack, but in order to fake-out Liferay's
PortletRequestImpl.init(...) method, I am recommending that you have the
MyFaces Bridge's PortletExternalContextImpl.encodeNameSpace(String) method
from this:
public String encodeNamespace(String s)
{
return ((PortletResponse) mPortletResponse).getNamespace() + s;
}
To this:
private static final String LIFERAY_NAMESPACE_PREFIX_HACK = A;
public String encodeNamespace(String s)
{
return (LIFERAY_NAMESPACE_PREFIX_HACK + (PortletResponse)
mPortletResponse).getNamespace() + s;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PORTLETBRIDGE-112) Improve compatibility with Liferay Portal for portlets that extend GenericFacesPortlet
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840975#action_12840975
]
Neil Griffin commented on PORTLETBRIDGE-112:
Yes, if portletRequest.getAttribute(THEME_DISPLAY) is not null, then you're
running in Liferay's portlet container.
Improve compatibility with Liferay Portal for portlets that extend
GenericFacesPortlet
--
Key: PORTLETBRIDGE-112
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-112
Project: MyFaces Portlet Bridge
Issue Type: Improvement
Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Neil Griffin
Liferay Portal 5.2.3 (and newer) has a PortletInvokerImpl.isFacesPortlet()
method that will return true if the value of the portlet-class from
WEB-INF/portlet.xml for javax.portlet.faces.GenericFacesPortlet. However,
if someone needs to subclass javax.portlet.faces.GenericFacesPortlet and
override the getBridgeClassName() method, then Liferay's
PortletInvokerImpl.isFacesPortlet() will return false.
The purpose of PortletInvokerImpl.isFacesPortlet() is really just for
Liferay's PortletRequestImpl.init(HttpServletRequest, Portlet,
InvokerPortlet, PortletContext, WindowState, PortletMode, PortletPreferences,
long) method, which will strip-off the namespace from request parameters for
all portlets except JSF portlets.
This is somewhat of a hack, but in order to fake-out Liferay's
PortletRequestImpl.init(...) method, I am recommending that you have the
MyFaces Bridge's PortletExternalContextImpl.encodeNameSpace(String) method
from this:
public String encodeNamespace(String s)
{
return ((PortletResponse) mPortletResponse).getNamespace() + s;
}
To this:
private static final String LIFERAY_NAMESPACE_PREFIX_HACK = A;
public String encodeNamespace(String s)
{
return (LIFERAY_NAMESPACE_PREFIX_HACK + (PortletResponse)
mPortletResponse).getNamespace() + s;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-112) Improve compatibility with Liferay Portal for portlets that extend GenericFacesPortlet
Improve compatibility with Liferay Portal for portlets that extend
GenericFacesPortlet
--
Key: PORTLETBRIDGE-112
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-112
Project: MyFaces Portlet Bridge
Issue Type: Improvement
Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Neil Griffin
Liferay Portal 5.2.3 (and newer) has a PortletInvokerImpl.isFacesPortlet()
method that will return true if the value of the portlet-class from
WEB-INF/portlet.xml for javax.portlet.faces.GenericFacesPortlet. However, if
someone needs to subclass javax.portlet.faces.GenericFacesPortlet and override
the getBridgeClassName() method, then Liferay's
PortletInvokerImpl.isFacesPortlet() will return false.
The purpose of PortletInvokerImpl.isFacesPortlet() is really just for Liferay's
PortletRequestImpl.init(HttpServletRequest, Portlet, InvokerPortlet,
PortletContext, WindowState, PortletMode, PortletPreferences, long) method,
which will strip-off the namespace from request parameters for all portlets
except JSF portlets.
This is somewhat of a hack, but in order to fake-out Liferay's
PortletRequestImpl.init(...) method, I am recommending that you have the
MyFaces Bridge's PortletExternalContextImpl.encodeNameSpace(String) method from
this:
public String encodeNamespace(String s)
{
return ((PortletResponse) mPortletResponse).getNamespace() + s;
}
To this:
private static final String LIFERAY_NAMESPACE_PREFIX_HACK = A;
public String encodeNamespace(String s)
{
return (LIFERAY_NAMESPACE_PREFIX_HACK + (PortletResponse)
mPortletResponse).getNamespace() + s;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PORTLETBRIDGE-112) Improve compatibility with Liferay Portal for portlets that extend GenericFacesPortlet
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12830294#action_12830294
]
Neil Griffin commented on PORTLETBRIDGE-112:
See also: http://issues.liferay.com/browse/LPS-3082
Improve compatibility with Liferay Portal for portlets that extend
GenericFacesPortlet
--
Key: PORTLETBRIDGE-112
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-112
Project: MyFaces Portlet Bridge
Issue Type: Improvement
Components: Impl
Affects Versions: 2.0.0-alpha
Reporter: Neil Griffin
Liferay Portal 5.2.3 (and newer) has a PortletInvokerImpl.isFacesPortlet()
method that will return true if the value of the portlet-class from
WEB-INF/portlet.xml for javax.portlet.faces.GenericFacesPortlet. However,
if someone needs to subclass javax.portlet.faces.GenericFacesPortlet and
override the getBridgeClassName() method, then Liferay's
PortletInvokerImpl.isFacesPortlet() will return false.
The purpose of PortletInvokerImpl.isFacesPortlet() is really just for
Liferay's PortletRequestImpl.init(HttpServletRequest, Portlet,
InvokerPortlet, PortletContext, WindowState, PortletMode, PortletPreferences,
long) method, which will strip-off the namespace from request parameters for
all portlets except JSF portlets.
This is somewhat of a hack, but in order to fake-out Liferay's
PortletRequestImpl.init(...) method, I am recommending that you have the
MyFaces Bridge's PortletExternalContextImpl.encodeNameSpace(String) method
from this:
public String encodeNamespace(String s)
{
return ((PortletResponse) mPortletResponse).getNamespace() + s;
}
To this:
private static final String LIFERAY_NAMESPACE_PREFIX_HACK = A;
public String encodeNamespace(String s)
{
return (LIFERAY_NAMESPACE_PREFIX_HACK + (PortletResponse)
mPortletResponse).getNamespace() + s;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PORTLETBRIDGE-77) Add detection of Servlet API dependencies in JSF implementation
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12717289#action_12717289 ] Neil Griffin commented on PORTLETBRIDGE-77: --- I too searched *.xml *.java and *.jsp for occurrences of /invoke and couldn't find any. So I don't know the answer to your question, but I have a guess... Section PLT.19.3.1 of the Portlet 2.0 spec says that the following parameters must be set: javax.servlet.include.request_uri javax.servlet.include.context_path javax.servlet.include.servlet_path javax.servlet.include.path_info javax.servlet.include.query_string So it might be that Liferay sets a value to /invoke, simply to pass the TCK test suite, thus achieving compliance. Add detection of Servlet API dependencies in JSF implementation --- Key: PORTLETBRIDGE-77 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-77 Project: MyFaces Portlet Bridge Issue Type: Improvement Reporter: Neil Griffin Attachments: FacesUtil.java, PortletExternalContextImpl.java This issue was discovered when trying to use the JSR 301 RI with Liferay Portal. The Portlet spec requires the implementing portlet container (in this case, specifically Liferay Portal) to specify the following request attributes: javax.servlet.include.path_info javax.servlet.include.servlet_path Mojarra 1.2_12 is trying to determine the viewId by checking the values of these attributes. I would consider this to be a Servlet API dependency (or assumption) by Mojarra. Liferay Portal is supplying its own internal values for these attributes, which have no JSF viewId meaning to Mojarra. I submitted patches to Sun, which will appear in Mojarra 1.2_13 when it is released. Until then, the patch appears in nightly snapshots. The JSR 301 RI is aware of these servlet dependency problems in Mojarra, and contains some workarounds. This ticket describes an improvement that needs to be made to the JSR 301 RI, such that it will add detection of Servlet API dependencies in the JSF implementation, and only perform the workarounds if those dependencies are found. I'll attach patches to this ticket shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-77) Add detection of Servlet API dependencies in JSF implementation
Add detection of Servlet API dependencies in JSF implementation --- Key: PORTLETBRIDGE-77 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-77 Project: MyFaces Portlet Bridge Issue Type: Improvement Reporter: Neil Griffin This issue was discovered when trying to use the JSR 301 RI with Liferay Portal. The Portlet spec requires the implementing portlet container (in this case, specifically Liferay Portal) to specify the following request attributes: javax.servlet.include.path_info javax.servlet.include.servlet_path Mojarra 1.2_12 is trying to determine the viewId by checking the values of these attributes. I would consider this to be a Servlet API dependency (or assumption) by Mojarra. Liferay Portal is supplying its own internal values for these attributes, which have no JSF viewId meaning to Mojarra. I submitted patches to Sun, which will appear in Mojarra 1.2_13 when it is released. Until then, the patch appears in nightly snapshots. The JSR 301 RI is aware of these servlet dependency problems in Mojarra, and contains some workarounds. This ticket describes an improvement that needs to be made to the JSR 301 RI, such that it will add detection of Servlet API dependencies in the JSF implementation, and only perform the workarounds if those dependencies are found. I'll attach patches to this ticket shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PORTLETBRIDGE-77) Add detection of Servlet API dependencies in JSF implementation
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neil Griffin updated PORTLETBRIDGE-77: -- Status: Patch Available (was: Open) Add detection of Servlet API dependencies in JSF implementation --- Key: PORTLETBRIDGE-77 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-77 Project: MyFaces Portlet Bridge Issue Type: Improvement Reporter: Neil Griffin This issue was discovered when trying to use the JSR 301 RI with Liferay Portal. The Portlet spec requires the implementing portlet container (in this case, specifically Liferay Portal) to specify the following request attributes: javax.servlet.include.path_info javax.servlet.include.servlet_path Mojarra 1.2_12 is trying to determine the viewId by checking the values of these attributes. I would consider this to be a Servlet API dependency (or assumption) by Mojarra. Liferay Portal is supplying its own internal values for these attributes, which have no JSF viewId meaning to Mojarra. I submitted patches to Sun, which will appear in Mojarra 1.2_13 when it is released. Until then, the patch appears in nightly snapshots. The JSR 301 RI is aware of these servlet dependency problems in Mojarra, and contains some workarounds. This ticket describes an improvement that needs to be made to the JSR 301 RI, such that it will add detection of Servlet API dependencies in the JSF implementation, and only perform the workarounds if those dependencies are found. I'll attach patches to this ticket shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1671) MyFacesGenericPortlet is causing multiple instances of PhaseListeners to be created
MyFacesGenericPortlet is causing multiple instances of PhaseListeners to be created --- Key: MYFACES-1671 URL: https://issues.apache.org/jira/browse/MYFACES-1671 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 1.1.4 Environment: WinXP / Liferay 4.3.0 / Tomcat 6.0.13 / Seam 1.2.1GA Reporter: Neil Griffin As described in this issue: http://jira.jboss.com/jira/browse/JBSEAM-1556 When running in a portlet environment and using MyFaces, JSF PhaseListeners get registered TWICE, due to the way MyFaces initializes itself: 1. MyFaces has a StartupServletContextListener that initializes the JSF framework (the first time). 2. The MyFacesGenericPortlet.initMyFaces() method initializes the JSF framework (a second time). In order to fix this, the MyFacesGenericPortlet must do a better job at determining whether or not the JSF framework has been initialized. There is no need to add the PhaseListeners to the Lifecycle a second time. And in the case of Seam, this can actually cause a problem, because there can be only one Seam phase listener active (that extends Seam's AbstractSeamPhaseListener) at any given time. In the case of other portlet phase listeners (like FileUpload ones that parse mutlipart-formdata), uploaded files would get saved twice, I would imagine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
