[JAVASERVERFACES_SPEC_PUBLIC-1071] Portlet bridge unable to wrap Flash implementation Created: 14/Feb/12  Updated: 01/Aug/14  Resolved: 03/Dec/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.2 Sprint 11

Type: Bug Priority: Major
Reporter: Neil Griffin Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 20 minutes
Original Estimate: Not Specified

Attachments: Text File 20120214-1203-i_spec_1071_snapshot-javadoc.patch     Text File 20120214-1203-i_spec_1071_snapshot.patch    
Issue Links:
is related to JAVASERVERFACES_SPEC_PUBLIC-1070 Add ExternalContext#setFlash(Flash) m... Open


Unless Java reflection is used, it is not possible for a portlet bridge to use the JSF 2.0/2.1 API to wrap the Flash implementation provided by Mojarra or MyFaces.

In order to solve this problem, this issue serves as a proposal to add javax.faces.context.FlashWrapper and javax.faces.context.FlashFactory to the JSF API.


The JSF 2.0/2.1 API does not currently provide a factory-style way of obtaining Flash scope instances. Instead, the ExternalContext#getFlash() method inside the JSF runtime is responsible for acting as
a pseudo-factory for creating instances.

One solution for a portlet bridge would be to create its own implementation of the Flash interface. However it is much more desirable to simply wrap the Mojarra/MyFaces flash implementation and override methods where necessary.

1) Add a FlashWrapper class:

package javax.faces.context;
public abstract class FlashWrapper extends Flash implements FacesWrapper<Flash>


2) Also to add a FlashFactory:

package javax.faces.context;
public abstract class FlashFactory
extends Object implements FacesWrapper<FlashFactory>
public abstract Flash getFlash();

The wrappable FlashFactory instance would take a one-arg constructor and look something like this:

public class FlashFactoryImpl extends FlashFactory {

private FlashFactory wrappedFactory;

public FlashFactoryImpl(FlashFactory flashFactory)

{ wrappedFactory = flashFactory; }

public Flash getFlash()

{ return new FlashImpl(wrappedFactory.getFlash()); }

public FlashFactory getWrapped()

{ return wrappedFactory; }



3) Add constant FLASH_FACTORY to FactoryFinder and require JSF implementations to return a wrappable FlashFactory instance.


Comment by Ed Burns [ 14/Feb/12 ]

Neil, I'll meet you half way. Here's the first part of the work already done.

I need you to fill out the API javadoc for the two new classes in jsf-api. The real kicker is my insistence on the color coded changebars.

I'm about to write a FAQ entry on how to do those. When I have done so, I'll point to it from this issue.

Comment by Neil Griffin [ 14/Feb/12 ]

Thanks so much for this – I'd be happy to fill out the API JavaDoc.

Comment by Ed Burns [ 14/Feb/12 ]

As promised, here's the FAQ entry.


Neil, please download, apply, edit (following the recommendations of the FAQ entry), re-diff, and attach a new patch.

Let me know when you've done it and I'll go to the next base.

Comment by Neil Griffin [ 14/Feb/12 ]

JavaDoc changes incorporated into original patch

Comment by Ed Burns [ 15/Feb/12 ]

Looks great! I'll take it to the next base. I'll be rounding third toward home tomorrow.

Comment by Ed Burns [ 15/Feb/12 ]

Sending jsf-api/doc/web-facesconfig_2_2.xsd
Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Adding jsf-api/src/main/java/javax/faces/context/FlashFactory.java
Adding jsf-api/src/main/java/javax/faces/context/FlashWrapper.java
Sending jsf-api/src/main/resources/overview.html
Sending jsf-ri/resources/jsf-ri-config.xml
Sending jsf-ri/src/main/java/com/sun/faces/config/processor/FactoryConfigProcessor.java
Sending jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/context/FacesContextFactoryImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/context/flash/ELFlash.java
Sending jsf-ri/src/main/java/com/sun/faces/context/flash/FlashELResolver.java
Adding jsf-ri/src/main/java/com/sun/faces/context/flash/FlashFactoryImpl.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java/com/sun/faces/test
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java/com/sun/faces/test/i_spec_1071_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java/com/sun/faces/test/i_spec_1071_war/EchoFlash.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java/com/sun/faces/test/i_spec_1071_war/MyFlashFactory.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/java/com/sun/faces/test/i_spec_1071_war/MyFlashImpl.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/webapp/WEB-INF/beans.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1071/i_spec_1071_war/src/main/webapp/i_spec_1071_war.xhtml
Sending jsf-test/build.xml
Transmitting file data ......................
Committed revision 9683.

Comment by Neil Griffin [ 15/Feb/12 ]

Thanks Ed!!!

Comment by Ed Burns [ 28/Feb/12 ]

Thank goodness for thorough tests.

One testcase that only failed in virtual server mode started failing after this commit and it found this problem:

private static final String[] FACTORY_NAMES = {

doesn't have FlashFactory.

Comment by Ed Burns [ 28/Feb/12 ]

Sending jsf-ri/src/main/java/com/sun/faces/config/processor/FactoryConfigProcessor.java
Transmitting file data .
Committed revision 9735.

Comment by Ed Burns [ 03/Dec/12 ]

Re-open at Neil's request to add wrapper.

Comment by Ed Burns [ 03/Dec/12 ]

>>>>> On Sat, 24 Nov 2012 15:11:44 -0500, Neil Griffin said:

NG> Regarding JAVASERVERFACES_SPEC_PUBLIC-1071 [1], the signature for
NG> the FlashFactory.getFlash [2] method currently looks like this:

NG> public abstract Flash getFlash(ExternalContext context, boolean create);

NG> But I think that the signature should look like the following:

NG> public abstract Flash getFlash(boolean create);

NG> The ExternalContext parameter is used by Mojarra as an internal
NG> implementation detail, and should not be passed as a
NG> parameter. Instead, the Mojarra FlashImpl constructor should call
NG> FacesContext.getCurrentInstance().getExternalContext().

Comment by Ed Burns [ 03/Dec/12 ]

Mark closed when < http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_TRUNK_GLASSFISH_3_1_2_2_NO_CLUSTER/61/ > and < http://tim-vm9.us.oracle.com:7070/hudson/view/Mojarra%20Trunk/job/trunk-test-glassfish-3_1_2_2/184/ > are clean.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

[JAVASERVERFACES_SPEC_PUBLIC-949] Window-id Created: 16/Mar/11  Updated: 15/Mar/13  Resolved: 15/Mar/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.1
Fix Version/s: 2.2 Sprint 11

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 14
Labels: None
Remaining Estimate: 1 week, 17 hours, 15 minutes
Time Spent: 6 hours, 45 minutes
Original Estimate: 1 week, 1 day

Attachments: Text File 20120222-2138-i_spec_949.patch     File getWindowId.js    
Issue Links:
depends on JAVASERVERFACES-2572 Implement ClientWindow Closed
blocks JAVASERVERFACES_SPEC_PUBLIC-730 Make flows reusable Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1052 add API for a pluggable WindowIdProvider Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1094 Rename WINDOW_ID_MODE strings to be C... Closed
Status Whiteboard:

size_large importance_medium


Somehow we have never specified how web apps that have multiple simultaneous windows should operate. This issue requests to specify this behavior.

Comment by gerhard_petracek [ 16/Mar/11 ]

thx for accepting this feature request.

short addition:
the window-id has to be restored before the request-lifecycle starts.
we also have to think about handling pop-up windows,... (same window-id as well as an api for forcing a new window-id)

Comment by arjan tijms [ 15/May/11 ]

What about the relation between the conversation-scope introduced by CDI and this feature request?

Comment by gerhard_petracek [ 15/May/11 ]

they aren't related because the cdi conversation-id isn't present all the time and can change if a new conversation gets started.

Comment by arjan tijms [ 17/May/11 ]

I see.

Can you give an example of the kind of behavior that needs to be specified?

Is it intended for communication between two or more windows? In that case it's in fact kind of the opposite of the conversation scope, which is practically intended to isolate page flows occurring in multiple simultaneous windows.

Or is it intended to create a WindowScope? In that case, a window-id is maybe not unlike a conversation-id tied to the life-time of a particular window.

Comment by gerhard_petracek [ 18/May/11 ]

we will prototype it in myfaces-core.
the absolute min. is something like:

imo it makes sense to introduce something like a WindowHandler which provides those methods (instead of adding them to the FacesContext directly).
but as mentioned before, we will prototype it in myfaces-core based on our experience with orchestra, codi, trinidad,...

no - there is no inter-window communication.
yes - a window-id can be used for implementing a WindowScope in a portable way.
we already do that in myfaces codi. trinidad, icefaces,... also implement something like that (but not as cdi scope). in codi we can use a custom window-handler to write adaptors which re-use the window-id of component libs instead of the default implementation of codi. a jsf impl or component lib is able to implement more edge cases because codi isn't aware of 3rd party components and isn't allowed to render e.g. js to cover edge cases. since it's a very basic concept and implementations of different libs lead to additional problems, it makes sense to add it to the spec.

Comment by tedgoddard [ 29/Aug/11 ]

Two of the main difficulties with implementing a window ID are: maintaining the window ID across reload and navigation and detecting when a window ID is no longer valid (window is closed). Is this feature intended to handle both of these areas?

Comment by gerhard_petracek [ 29/Aug/11 ]

yes - currently we are thinking about possible impacts on the saved states.
some of the information which looks to be stable is available at http://wiki.apache.org/myfaces/Drafts/WindowId
the next step is to discuss the proposed changes with all major vendors/developers of component libs.

Comment by Ed Burns [ 02/Nov/11 ]

Carry forward to 2.2 Sprint 9.

Comment by Ed Burns [ 02/Dec/11 ]

WindowContext looks good for this.


Comment by arjan tijms [ 31/Jan/12 ]

since it's a very basic concept and implementations of different libs lead to additional problems, it makes sense to add it to the spec.

I agree with that. Since this concept is so basic, maybe it also make sense trying to get support for this directly into the HTTP standard? Currently there seems to an effort starting for a new version of HTTP (see e.g. http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0098.html).

Comment by gerhard_petracek [ 31/Jan/12 ]

@HTTP standard:

A JSF implementation can use this information at any time (if it is available). At least it's covered implicitly by Level #3 mentioned in the proposal. It doesn't change the requirements of the new JSF-APIs itself.

However, mentioning the link was a nice idea - thx Arjan.

Comment by Ed Burns [ 31/Jan/12 ]


Comment by Ed Burns [ 09/Feb/12 ]

See: https://github.com/os890/JSF_SPEC_PUBLIC-949_Discuss

Comment by Ed Burns [ 14/Feb/12 ]

Q.2 aside from before RestoreView, what other pre-phase actions are required?

Q.3 post-phase action is currently empty. What possible actions could
there be here?

Q.4 It seems like the right place to handle the creation of the windowId
is in the FacesServlet. Why not there?

Comment by Ed Burns [ 20/Feb/12 ]

Added requirement regarding flash to <https://cwiki.apache.org/confluence/display/MYFACES/WindowId+Proposal>.

Comment by lightguard [ 20/Feb/12 ]

To go along with this (and possibly CDI conversations which were mentioned before) I'd like to have the ability to start / end off an h:link / h:button.

Comment by Ed Burns [ 20/Feb/12 ]


Comment by Ed Burns [ 22/Feb/12 ]

snapshot, actually works, and with a sample app.

Comment by Ed Burns [ 22/Feb/12 ]

Snapshot with working and automated test.

Comment by Ed Burns [ 22/Feb/12 ]

Passes all tests. Yields 2256 passed tests.

Comment by Ed Burns [ 23/Feb/12 ]

Add spec language.

Comment by gerhard_petracek [ 23/Feb/12 ]

feedback for the first draft:

javax.faces.WINDOW_ID_MODE currently allows: "none" and "field"

(hidden) "field" as only mode for activated window-ids breaks some important use-cases in the browser - esp. a page refresh. (it would trigger a request which leads to a new window-id and everything connected to the previous id gets lost).

if "field" is really needed, we can add it to the values of the existing proposal.


  • none
  • field (suggested by the first draft)
  • url
  • script (renamed - original suggestion: client)
Comment by Ed Burns [ 23/Feb/12 ]

I only added field because it was the easiest to implement. We don't have to have it in the final feature.

Comment by Ed Burns [ 23/Feb/12 ]

committed version 9731.

Comment by werpu12 [ 28/Feb/12 ]

Attached is an implementation on how to fetch the windowid from a javascript client, the implementation is under ASL 2.0 license which should be liberal enough to be integrated in both Mojarra and MyFaces.

Comment by Ed Burns [ 29/Feb/12 ]

Sending jsf-api/src/main/java/javax/faces/render/ResponseStateManager.java
Sending jsf-api/src/main/resources/jsf.js
Sending jsf-ri/src/main/java/com/sun/faces/util/Util.java
Transmitting file data ...
Committed revision 9737.

  • Change the spec for the WindowId parameter to require the
    UIViewRoot.getContainerClientId() to be prepended.
Comment by Ed Burns [ 29/Feb/12 ]

Sending jsf-api/src/main/resources/jsf.js
Transmitting file data .
Committed revision 9738.
Rhombus2:i_spec_949 ejburns$ svncom
Sending jsf-api/src/main/resources/jsf.js
Transmitting file data .
Committed revision 9739.

Add Werner's getWindowId().

Comment by Ed Burns [ 14/Mar/12 ]


  • Add URL mode. After this commit, there are three outstanding issues

1.What do we need to say in jsf.js to properly handle url-mode in the
case when the user opens a new tab. I think we need to say something
in that case, but I need some help, perhaps from Werner Punz, to learn
what to say.

2.Make it so the flash is based on the WindowId, if present. I'm not
entirely convinced we need this one, though.

3.Make changes to the renderkit doc so that tags that render links have
an additional attribute that prevents the windowId from being appended to
that link.

  • Here's a guide to the feature to aid in review, taken from the class
    javadocs for ClientWindow.

This class represents a client window, which may be a browser tab,
browser window, browser pop-up, portlet, or anything else that can
display a UIComponent hierarchy rooted at a UIViewRoot.

Modes of Operation

none mode

The generation of ClientWindow is controlled by the value of the
context-param named by the value of
WINDOW_ID_MODE_PARAM_NAME. If this context-param is not
specified, or its value is "none", no ClientWindow instances
will be generated, and the entire feature is effectively
disabled for the entire application.

Other modes

For all other valid values of WINDOW_ID_MODE_PARAM_NAME,
including custom values not explicitly covered in this
specification, the lifetime of a ClientWindow starts on the
first request made by a particular client window (or tab, or
pop-up, etc) to the JSF runtime and persists as long as that
window remains open or the session expires, whichever comes
first. A client window is always associated with exactly one
UIViewRoot instance at a time, but may display many different
UIViewRoots during its lifetime.

The ClientWindow instance is associated with the incoming
request during the
method. This method will cause a new instance of ClientWindow to
be created, assigned an id, and passed to

During state saving, regardless of the window id mode, or state
saving mode, a hidden field must be written whose name, id and
value are given as specified in

url mode

If the value of the WINDOW_ID_MODE_PARAM_NAME is "url",
without the quotes, the encoding of the ClientWindow must be
performed as follows, in addition to the hidden field already
described. The runtime must ensure that any component that
renders a hyperlink that causes the user agent to send a GET
request to the Faces server when it is clicked has a query
parameter with a name and value specified in
ResponseStateManager.WINDOW_ID_URL_PARAM. This requirement is
met by several of the "encode" methods on ExternalContext See
ExternalContext.encodeActionURL(java.lang.String) for details,
including a special case where the windowId is not appended
even though url mode is enabled.


M jsf-api/src/main/java/javax/faces/lifecycle/Lifecycle.java

  • Specify attachWindow().

M jsf-api/src/main/java/javax/faces/lifecycle/ClientWindow.java

  • The heart of the spec for the feature.

M jsf-api/src/main/java/javax/faces/render/ResponseStateManager.java

  • Constants, their names, and values.

M jsf-api/src/main/java/javax/faces/context/ExternalContext.java

  • encodeActionURL() and related methods

M jsf-api/src/main/resources/jsf.js

  • Unrelated: increment version number to 2.2.

M jsf-ri/src/main/java/com/sun/faces/context/UrlBuilder.java
M jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java

  • Changes related to url-mode.

M jsf-ri/src/main/java/com/sun/faces/lifecycle/ClientWindowImpl.java

  • Implement the feature

M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/main.xhtml
M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/WEB-INF/web.xml
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/page2.xhtml
M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_htmlunit/src/main/java/com/sun/faces/test/i_spec_949_htmlunit/IssueSpec949TestCase.java

  • Test the feature

M nbproject/project.xml

  • spell checker

M jsf-api/doc/standard-html-renderkit-base.xml

  • Unrelated, fix typo in link renderer spec.

Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java
Sending jsf-api/src/main/java/javax/faces/lifecycle/ClientWindow.java
Sending jsf-api/src/main/java/javax/faces/lifecycle/Lifecycle.java
Sending jsf-api/src/main/java/javax/faces/render/ResponseStateManager.java
Sending jsf-api/src/main/resources/jsf.js
Sending jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/context/UrlBuilder.java
Sending jsf-ri/src/main/java/com/sun/faces/lifecycle/ClientWindowImpl.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_htmlunit/src/main/java/com/sun/faces/test/i_spec_949_htmlunit/IssueSpec949TestCase.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/WEB-INF/web.xml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/main.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-949/i_spec_949_war/src/main/webapp/page2.xhtml
Sending nbproject/project.xml
Transmitting file data ..............
Committed revision 9763.

Comment by Ed Burns [ 15/Mar/12 ]

EB> ACTION: Leonardo, can you please tell me why you feel this is important.

LU> Suppose an application with two windows. The user then do something
LU> on one window and internally "flash scope" is used. Then the user
LU> change of window and do other thing using "flash scope". Since flash
LU> request identifier is stored in a cookie, when the user goes back to
LU> the first window and continue working, the latest identifier in
LU> flash scope is sent, breaking "flash scope". In multi-window
LU> applications, flash scope should be able to use windowId to prevent
LU> that kind of situations.

Comment by arjan tijms [ 27/May/12 ]

An additional mechanism to store the window ID on the client that may be considered is the HTML 5 session storage. Like window.name, this is per-window/tab scoped.

Some pointers:

Comment by gerhard_petracek [ 27/May/12 ]

see also ClientSideWindowHandler in myfaces codi, however, that's a detail of an implementation.

Comment by arjan tijms [ 27/May/12 ]

Thanks Gerhard!

For easy reference, here's the source of ClientSideWindowHandler.

It's an implementation detail indeed and I hope it's okay to discuss it here, but doesn't windowhandler.html makes use of localStorage and not sessionStorage?

Comment by gerhard_petracek [ 27/May/12 ]

you have to use what works across all browsers (which support html5) and with all constellations (get-/post-requests, open in new tab, window refresh,...)
also myfaces core will use the approach we found for myfaces codi (at least the current prototype does).

Comment by Mark Struberg [ 29/May/12 ]

Ed, Leo and I are currently working on the ClientWindow stuff. We now face the question if we really need to specify the name of the windowId URL parameter (ResponseStateManager#CLIENT_WINDOW_URL_PARAM). This is mostly a contract between the windowhandler javascript and the pluggable ClientWindow implementation which parses this parameter and extracts the windowId from it.

The only part so far where we would need it is to 'rewrite' h:link and stuff via encodeActionUrl, encodeBookmarkableUrl, etc. But this could probably also be done in JavaScript on the client side. In this case we would not need to specify the windowId URL parameter in the spec at all. Both options of course have pros and cons!

Generated at Tue Sep 01 06:24:24 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.