[JAVASERVERFACES_SPEC_PUBLIC-1169] Convert namespace URIs to use new hostname: xmlns.jcp.org instead of java.sun.com. Created: 04/Feb/13  Updated: 26/Jun/13  Resolved: 26/Jun/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 days, 23 hours
Time Spent: 1 hour
Original Estimate: 3 days

Issue Links:
Dependency
blocks JAVASERVERFACES-2764 Apply java.sun.com -> xmlns.jcp.org c... Closed

 Description   

Per Bill Shannon, all newly created XML namespaced artifacts in JSF 2.2 must use the new xmlns.jcp.org hostname instead of java.sun.com. For example, the faces-config.xml schema will be <http://xmlns.jcp.org/xml/ns/javaee> instead of <http://java.sun.com/xml/ns/javaee>.



 Comments   
Comment by Ed Burns [ 06/Feb/13 ]

EB> Pass Through Attributes
EB>
EB> http://java.sun.com/jsf/passthrough
EB>
EB> becomes

http://xmlns.jcp.org/xml/ns/jsf/passthrough

EB> Pass Through Elements
EB>
EB> http://java.sun.com/jsf
EB>
EB> becomes

http://xmlns.jcp.org/xml/ns/jsf

Comment by Ed Burns [ 06/Feb/13 ]

EB> * Looking at overview-summary in JSF 2.2 you can see that there are three new XSD files in JSF
EB> 2.2. They are all increments of anologous files in JSF 2.1. All of
EB> these will use the new XML ns.





[JAVASERVERFACES_SPEC_PUBLIC-1167] <f:selectItems> itemLabelEscaped: if not specified, behave as if true. Created: 22/Feb/13  Updated: 22/Feb/13  Resolved: 22/Feb/13

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

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 22 minutes
Time Spent: 8 minutes
Original Estimate: 30 minutes

Issue Links:
Dependency
blocks JAVASERVERFACES-2747 XSS hole: GenericObjectSelectItem inc... Closed

 Description   

See http://java.net/jira/browse/JAVASERVERFACES-2747






[JAVASERVERFACES_SPEC_PUBLIC-1166] Make it so proper license is included and linked from Javadocs Created: 19/Feb/13  Updated: 19/Feb/13  Resolved: 19/Feb/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: None
Fix Version/s: 2.2

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 45 minutes
Original Estimate: Not Specified


 Description   

See http://aseng-wiki.us.oracle.com/asengwiki/display/JavaEE/JavadocsSpecLicense






[JAVASERVERFACES_SPEC_PUBLIC-1165] Leverage the default "value" attribute of an annotation to be the flow id of a @FlowScoped bean Created: 18/Feb/13  Updated: 22/Feb/13  Resolved: 22/Feb/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Managed Beans
Affects Version/s: None
Fix Version/s: 2.2

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 25 minutes
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-730 Make flows reusable Closed

 Description   

Hello Experts,

This came in on the users list.

>>>>> On Mon, 11 Feb 2013 07:01:07 -0800, Edward Burns said:

>>>>> On Thu, 24 Jan 2013 17:49:23 +0000 (GMT), said:
AG> I was wondering if any discussions have happened around changing
AG> @FlowScoped(id="...") to @FlowScoped(value="..."). This will make my
AG> bean declaration cleaner.

AG> @FlowScoped("foo")
AG> public class MyBean implements Serializable

{ AG> }

AG> instead of

AG> @FlowScoped(id="foo")
AG> public class MyBean implements Serializable {AG> }

AG> Comments ?

EB> Yes, I like that idea.

EB> I'll do it that way instead.

Any objections?

Ed






[JAVASERVERFACES_SPEC_PUBLIC-1164] Leverage EL 3.0 if present. Created: 15/Feb/13  Updated: 15/Feb/13  Resolved: 15/Feb/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: EL
Affects Version/s: None
Fix Version/s: 2.2

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 hours, 25 minutes
Time Spent: 35 minutes
Original Estimate: 3 hours

Issue Links:
Dependency
blocks JAVASERVERFACES-2742 Leverage EL 3.0 if present. Closed

 Description   

>>>>> On Thu, 14 Feb 2013 16:00:29 -0800, Kin-man Chung said:

KC> The amount of work to support EL 3.0 is really small
KC> The following is what is done for JSP (from the change log):

KC> 3. Support EL 3.0 (JSR 341).
KC> In JSP.2.9, add the following two ELResovers, after item 2, and renumberKC> the other ELResolvers on the list. That is, place these ELResolvers
KC> between
KC> the custom ELResolvers and the MapELResolver.

KC> 3. The ELResolver returned by ExpressionFactory.getStreamELResolver().
KC> 4. javax.el.StaticFieldELResolver.






[JAVASERVERFACES_SPEC_PUBLIC-1145] HtmlPanelGroup Does Not Implement ClientBehaviorHolder Created: 16/Nov/12  Updated: 30/Nov/12  Resolved: 30/Nov/12

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See: http://java.net/jira/browse/JAVASERVERFACES-1957

The spec 2.1 lists in section 8.7 all concrete HTML component classes and states that all these classes implement BehaviorHolder. This list includes HtmlPanelGroup but it does not implements ClientBehaviorHolder like HtmlPanelGrid.



 Comments   
Comment by rogerk [ 30/Nov/12 ]

See JAVASERVERFACES-1957





[JAVASERVERFACES_SPEC_PUBLIC-1136] ExternalContext.dispatch Javadocs Should Match Implementation Created: 12/Oct/12  Updated: 01/Aug/14  Resolved: 12/Oct/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: 2.2

Type: Bug Priority: Minor
Reporter: rogerk Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-sp-1136.txt    

 Description   

Currently the Javadocs for ExternalContext.dispatch method say:

@throws IllegalArgumentException if no request dispatcher

  • can be created for the specified path
    @throws NullPointerException if <code>path</code>
  • is <code>null</code>

However the implementation does this:

RequestDispatcher requestDispatcher = request.getRequestDispatcher(
requestURI);
if (requestDispatcher == null)

{ ((HttpServletResponse) response). sendError(HttpServletResponse.SC_NOT_FOUND); return; }

The servlet specification indicates that a null RequestDispatcher will be returned if one cannot be created (for example by passing in a null argument to request.getRequestDispatcher). The JavaDocs for ExternalContextDispatcher should be changed as follows:

1. remove throws IllegalArgumentException, NullpointerException verbage.
2. add "If the call to <code>getRequestDisatcher(path)</code> returns null, send a<code>ServletResponse SC_NOT_FOUND</code> error code.



 Comments   
Comment by rogerk [ 12/Oct/12 ]

Changes.

Comment by rogerk [ 12/Oct/12 ]

Committed to trunk:
Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java
Transmitting file data .
Committed revision 10834.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1110] Add NavigationCaseWrapper Created: 30/May/12  Updated: 01/Aug/14  Resolved: 30/Nov/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2

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

Attachments: Java Source File NavigationCaseWrapper.java    

 Description   

During the development of Liferay Faces Bridge, I found it necessary to wrap the NavigationCase implementation of Mojarra/MyFaces. To this end, I hereby request that a NavigationCaseWrapper be added to the JSF API. The code is attached.



 Comments   
Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1109] Add RendererWrapper Created: 30/May/12  Updated: 01/Aug/14  Resolved: 30/Nov/12

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

Type: New Feature Priority: Major
Reporter: Neil Griffin Assignee: rogerk
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: Not Specified

Attachments: Java Source File RendererWrapper.java    

 Description   

During the development of Liferay Faces Bridge, I found it necessary to wrap renderers provided by various component suites. To this end, I hereby request that a RendererWrapper be added to the JSF API. The code is attached.



 Comments   
Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1108] Add LifecycleWrapper Created: 30/May/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: 2.2

Type: New Feature Priority: Major
Reporter: Neil Griffin Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File LifecycleWrapper.java    

 Description   

During the development of Liferay Faces Bridge, I found it necessary to wrap the LifecycleImpl of Mojarra/MyFaces. To this end, I hereby request that a LifecycleWrapper class be added to the JSF 2.2 API. The code is attached.



 Comments   
Comment by Neil Griffin [ 24/Nov/12 ]

The javax.faces.lifecycle.LifecycleWrapper class is present in the latest JSF 2.2 jsf-api artifact, so I think that this issue can be closed.





[JAVASERVERFACES_SPEC_PUBLIC-1094] Rename WINDOW_ID_MODE strings to be CLIENTWINDOW_MODE Created: 03/May/12  Updated: 17/Dec/13  Resolved: 17/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 10
Fix Version/s: 2.2

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-949 Window-id Closed




[JAVASERVERFACES_SPEC_PUBLIC-1090] HTML5 Support Created: 18/Apr/12  Updated: 25/Jul/13  Resolved: 25/Jul/13

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: rogerk
Resolution: Fixed Votes: 1
Labels: None
Σ Remaining Estimate: 4 weeks, 5 days, 6 hours, 12 minutes Remaining Estimate: Not Specified
Σ Time Spent: 2 days, 17 hours, 48 minutes Time Spent: Not Specified
Σ Original Estimate: 5 weeks, 1 day Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES-2512 Implement HTML5 support Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-990 HTML5 Forms Support Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-991 Support for new/changed features in H... Sub-task Closed  
JAVASERVERFACES_SPEC_PUBLIC-1075 HTML5 Metadata Content Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-1076 HTML5 Sectioning and Heading Sub-task Resolved  
JAVASERVERFACES_SPEC_PUBLIC-1077 HTML5 Form Associated Elements Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-1089 Support for HTML5 passthru attributes... Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-1111 Generic Passthru Elements Sub-task Closed Ed Burns  

 Description   

Umbrella issue for HTML 5 support in JSF 2.2



 Comments   
Comment by Ed Burns [ 25/Jul/13 ]

The HTML5 Friendly Markup feature is the extent of HTML5 support in JSF 2.2.





HTML5 Support (JAVASERVERFACES_SPEC_PUBLIC-1090)

[JAVASERVERFACES_SPEC_PUBLIC-1075] HTML5 Metadata Content Created: 22/Feb/12  Updated: 25/Jul/13  Resolved: 25/Jul/13

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

Type: Sub-task Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days


 Description   

See http://dev.w3.org/html5/spec/Overview.html#metadata-content

HTML5 makes enhancements in the following elements

base
command
link
meta
noscript
script
style
title

We need to examine the JSF Renderers that generate these elements and update them accordingly.






[JAVASERVERFACES_SPEC_PUBLIC-1072] Add javax.faces.application.NavigationHandlerWrapper to JSF API Created: 14/Feb/12  Updated: 01/Aug/14  Resolved: 30/Nov/12

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

Type: Improvement Priority: Minor
Reporter: Neil Griffin Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1066 JavaDoc for Application#getNavigation... Open

 Description   

This is related to Spec bug JAVASERVERFACES_SPEC_PUBLIC-1066 but I thought it was best to create a separate issue as a formal request to add a javax.faces.application.NavigationHandlerWrapper to the JSF API.

There is precedent set for this with javax.faces.application.ResourceHandlerWrapper:

http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/application/ResourceHandlerWrapper.html

NavigationHandlerWrapper would be useful in the case of a JSF Portlet Bridge, because it would give the bridge the ability to walk the decorator pattern by calling getWrapped().



 Comments   
Comment by Ed Burns [ 14/Feb/12 ]

Because you used the word "useful" in the report, I feel justified in setting the priority to Minor. We'll probably get to it in 2.2, though.

Comment by Neil Griffin [ 14/Feb/12 ]

Thanks Ed. At a minimum, it would make the behavior of Application#getNavigationHandler() and Application#getResourceHandler() more consistent which is good too.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1067] cc with children and/or facets, but no cc:insertChildren and/or cc:insertFacet in impl section Created: 03/Feb/12  Updated: 01/Aug/14  Due: 03/Feb/12  Resolved: 03/Feb/12

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

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Attachments: Text File changebundle.txt    

 Description   

Specify the behavior when you have a composite component in the using page that has children and/or facets, and there is no corresponding cc:insertChildren and/or cc:insertFacet in the cc definition.



 Comments   
Comment by Ed Burns [ 03/Feb/12 ]

Sending jsf-api/src/main/java/javax/faces/model/CollectionDataModel.java
Sending jsf-ri/conf/share/composite.tld
Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Transmitting file data ...
Committed revision 9646.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1065] ResourceManager only checks the Accept-Language to localize resources Created: 25/Jan/12  Updated: 01/Aug/14  Resolved: 26/Jan/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: 2.2

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-1858 ResourceManager only checks the Accep... Closed

 Description   

Copied from <http://java.net/jira/browse/JAVASERVERFACES-1858>.

Now, it's not possible to programatically change the locale of resources like we
do with bundles of messages.

Now, we have to define an entry for javax.faces.resource.localePrefix at
localized files referred at faces-config.xml by a <message-bundle> tag.

Studying the code, I found the ResourceManager class
(com.sun.faces.application.resources). This class has a method called
getLocalePrefix(FacesContext) which finds the localized value for
javax.faces.resource.localePrefix.

The problem is that ResourceManager doesn't work like UIViewRoot which stores
the locale supplied by the user. It just call
context.getApplication().getViewHandler().calculateLocale(FacesContext);

This last method calls the context.getExternalContext().getRequestLocale(). In
other words, the ResourceManager only checks the HTTP header Accept-Language to
reach the resources.

The UIViewRoot, in other hand, has the method setLocale() to store the locale
picked by the user.

So I made changes inside the ResourceManager.getLocalePrefix(FacesContext) to
call the UIViewRoot.getLocale() when there is a viewroot (it was necessary to
fix the "loc" http parameter), and to just return the "loc" parameter when there
is one (at the second request for the resource itself).

That's the new method's body:

private String getLocalePrefix(FacesContext context) {

String localePrefix = null;
String appBundleName = context.getApplication().getMessageBundle();
if (null != appBundleName) {

/** ******** **

NEW CODE **

                • **/
                  if (context.getExternalContext().getRequestParameterMap().get("loc") !=
                  null) { return context.getExternalContext().getRequestParameterMap().get("loc"); }

                  Locale locale = null;
                  if (context.getViewRoot() != null)

                  { locale = context.getViewRoot().getLocale(); }

                  else

                  { locale = context.getApplication().getViewHandler().calculateLocale(context); }

                  /** ************ **
                  END NEW CODE **

                        • **/
                          try { ResourceBundle appBundle = ResourceBundle.getBundle(appBundleName, locale, Util.getCurrentLoader(ResourceManager.class)); localePrefix = appBundle .getString(ResourceHandler.LOCALE_PREFIX); }

                          catch (MissingResourceException ignored) { }
                          }

return localePrefix;

}

For me, the i18n capabilities is fully ok, now.

If any developer wants to make a form to give the user a chance to choose one
locale, the message and now the resources will be translated.



 Comments   
Comment by Ed Burns [ 26/Jan/12 ]

Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceManager.java
Transmitting file data .
Committed revision 9612.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1064] Clarify facelets-processing CDATA handling Created: 06/Jan/12  Updated: 01/Aug/14  Resolved: 01/Feb/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2 Sprint 9
Fix Version/s: 2.2

Type: Bug Priority: Minor
Reporter: aschwart Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2282 Contents of CDATA blocks consumed in ... Closed

 Description   

As discussed in this jsr-344 thread:

http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-01/message/2

There is some confusion over how CDATA blocks should be handled when <facelets-processing> mode is jspx/xml. The spec should make it clear that the CDATA wrapper constructs (ie. "<![CDATA[" and "]]>") are consumed, but the content/body of the CDATA block is not.



 Comments   
Comment by Ed Burns [ 01/Feb/12 ]

Sending appendixA-metadata.fm
Sending preface.fm
Transmitting file data ..
Committed revision 1048.
Rhombus:frame edburns$

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1058] VDL Docs Need Correction/Clarification For ui:repeat size Attribute Created: 01/Dec/11  Updated: 19/Nov/12  Resolved: 19/Nov/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: rogerk Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-1058.txt     Text File changebundle-1058.txt    

 Description   

Currently, the VDL docs say this for ui:repeat "size" attribute:

"Read-write property setting the size of the collection to iterate. If this value is less than the actual size of the collection, a FacesException must be thrown."

However, the purpose of the size attribute is to specify the number of elements or items to iterate over in the overall collection. So, for example:

  • overall collection size = 10
  • u:repeat size="5"
    should iterate over the first 5 items of the collection.


 Comments   
Comment by rogerk [ 01/Dec/11 ]

Changes.

Comment by rogerk [ 01/Dec/11 ]

Revised Change.

Comment by rogerk [ 01/Dec/11 ]

Committed to trunk:
Sending jsf-ri/conf/share/ui.tld
Transmitting file data .
Committed revision 9484.

Comment by rogerk [ 01/Dec/11 ]

checked in.





[JAVASERVERFACES_SPEC_PUBLIC-1055] Provide stateless mode for JSF Created: 30/Nov/11  Updated: 13/Apr/13  Resolved: 28/Feb/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2

Type: New Feature Priority: Major
Reporter: lincolnbaxter Assignee: Ed Burns
Resolution: Fixed Votes: 47
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours, 3 minutes
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES-2761 Honor requirement to log a FacesMessa... Closed

 Description   

As documented and implemented here, a Stateless JSF operation mode would be incredibly useful for high-load applications and architectures:

http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/#comment-4

This has previously been suggested by Jacob: http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin.html

This would help JSF ditch the stigma of "slow and memory hog," and help keep up with current tech trends (statless architectures.)



 Comments   
Comment by arjan tijms [ 30/Nov/11 ]

Strongly in support of this. Internally for my company I have been working on something similar and preparing a proposal, but the referenced article is far more complete than that

For stateless operation, I think it's important to fix some state related bugs like JAVASERVERFACES-2244.

Additionally, some (standard) components make too liberal use of view state for the purpose of caching data. For instance, UIInput puts emptyStringIsNull and validateEmptyFields in view state, but these seem to be global things that don't necessarily belong there.

The simplest case for stateless operation is probably the initial rendering of a view and posting that back. There is often no state there then (besides the state caused by bugs), yet in the current spec posting it back requires view state to be restored, even when that view state appears to be empty (null) later on. This situation could perhaps be easily supported by giving the existing javax.faces.ViewState input element that's rendered a special value like "nostate" or simply leaving it empty?

One concern is that currently the required view state functions as a kind of implicit CSRF protection, so this should perhaps only be done when the user explicitly marks a view as allowed to be accepted without view state?

Comment by Ed Burns [ 01/Feb/12 ]

While this is very important, I have to leave the Fix Version for this as "unknown" for now because I haven't figured out how to slot it into the work for JSF 2.2.

Comment by arjan tijms [ 26/Feb/12 ]

Although principally asking for a different thing, JAVASERVERFACES_SPEC_PUBLIC-776 is somewhat related to this.

JAVASERVERFACES_SPEC_PUBLIC-478, JAVASERVERFACES_SPEC_PUBLIC-879 and JAVASERVERFACES_SPEC_PUBLIC-1056 are likely affected by this topic as well.

Maybe interesting that historically JAVASERVERFACES_SPEC_PUBLIC-139 seems related to this.

Comment by Raj [ 05/May/12 ]

Is this going to be there in JSF 2.2 ?

Comment by Ertio lew [ 24/May/12 ]

+1 for this superb thought!

Btw, when is this expected to be available ?

Comment by Hanspeter Duennenberger [ 24/May/12 ]

I think a proposed stateless mode should work also in a mixed mode to allow e.g. stateless templates to be reused from stateful page content. Of course it should also be possible to have fully stateless views.

Comment by Ertio lew [ 07/Jul/12 ]

Any progress on this ?

Can we have the fix version stated for this issue ? We wish to see it implemented soon

Comment by arjan tijms [ 07/Jul/12 ]

Can we have the fix version stated for this issue ? We wish to see it implemented soon

Much as I would love this to be available today, my guess is this will be rather hard to still stuff into 2.2. As this is such an important issues (IMHO, one of the most important issues), it should be given the attention such a fundamental new feature needs.

Comment by exabrial [ 10/Jul/12 ]

Since this is a major items and the LOE is bigger... instead could we perhaps prioritize tickets like the following:

http://java.net/jira/browse/JAVASERVERFACES-2244 UIInput and UIData create unnecessary state array

My thoughts are if we can't eliminate state quite yet, can a review be conducted of existing classes so that they uses state and partial state more efficiently?

Comment by arjan tijms [ 13/Aug/12 ]

Since this is a major items and the LOE is bigger... instead could we perhaps prioritize tickets like the following:

Well at least JAVASERVERFACES-2244 has been closed, yah! Many thanks to Manfred

There are definitely some implementation issues regarding state that could get some more attention, like those I mentioned above in JAVASERVERFACES_SPEC_PUBLIC-1055#325459

Comment by bohl_-. [ 10/Nov/12 ]

f:viewParam breaks in Stateless JSF mode. There is a line in RestoreViewPhase.java which causes all phases after RestoreViewPhase to get skipped. After removing it, f:viewParam worked as expected. Does anyone know what the following line is supposed to do:

if (!facesContext.isPostback()) {facesContext.renderResponse();}

(line 158 in rev. 10973 of RestoreViewPhase.java) See also https://github.com/methylene/futil-square-validator/tree/jsfun

Comment by vjsingh [ 13/Nov/12 ]

Briefly as per Java EE 6 tutorial:

The lifecycle handles two kinds of requests: initial requests and postbacks. An initial request
occurs when a user makes a request for a page for the first time. A postback request occurs when
a user submits the form contained on a page that was previously loaded into the browser as a
result of executing an initial request.
When the lifecycle handles an initial request, it executes only the Restore View and Render
Response phases, because there is no user input or actions to process. Conversely, when the
lifecycle handles a postback, it executes all of the phases.

Comment by exabrial [ 13/Nov/12 ]

The goal of this ticket is to reduce overhead of the restore view, because it doesn't scale very well.

So on a completely different note, since we're dealing with component trees and recursive traversals, has anyone given thought to perhaps parallelizing the build/restore lifecycle phases? Seems like this could potentially be passed off to the fork/join framework. I know this wouldn't reduce the overhead, but it could make them more bearable.

Comment by bohl_-. [ 17/Nov/12 ]

It appears that, in case the view contains an f:metadata tag, all 6 lifecycle phases are executed, even on an initial request. I updated the SJSF demo project, it now has a PhaseListener to track the executed lifecycle phases and display that information. Also added a new branch to highlight the default JSF behaviour, without SJSF

Comment by Aditya [ 02/Dec/12 ]

I believe, this feature is the major & most important need of JSF for high performance applications. It is simply a waste to save state redundantly when there is no difference across the views saved for a page in different user sessions. For most developers looking for a high performance framework, JSF is turn downed because of its forced stateful behaviour. However in any application not all pages need to be stateful, even more commonly there are more no of applications with pages demanding stateless behavior. If JSF has to survive & excel it has to satisfy those justified needs.

Unfortunately, we had to reject JSF, after year after just because it consumed too much resources & degraded its performance because of its forced stateful behavior. Great to see that this feature is being worked on in JSF & but I wish that we can see this in JSF soon rather than hanging ourselves with forced stateful behaviour for another couple of years. Can't wait to use stateless JSF for my upcoming projects!

And yes, I think this is perhaps the most voted issue on JSF project, so the JSF spec designers should deal with this issue in an expedited manner

Comment by gabz90 [ 21/Feb/13 ]

This feature is essential to JSF. Whenever I vote to use JSF as our front end framework, the development team in my projects brings up this issue. Will this make it to JSF 2.2? It is causing JSF to lose market to other frameworks that are stateless. I'd rather see this feature implemented than a ton of nice smaller ones.

Only last week our new project was close to adopting JSF however the team decided to go a different way over this stateless vs. stateful issue.

This is an issue with a ton of votes and watchers, and my fear is that with the competitive market of web development frameworks out there, is it really wise to push back this feature until the next JSF specification version?

It also brings out unnecessary exceptions which are a pain to handle sometimes. It gives me headaches to get a "ViewExpiredException" when I didn't need any state for that view anyway.

Comment by vjsingh [ 21/Feb/13 ]

I completely agree. I have been working on JSF for some time now and loved the framework but had to drop it for another side-project of mine which is facing the web and needed a stateless architecture. Believe me, it's only going to be used in enterprises and not on public web facing applications because of the statefull architecture.

Comment by lu4242 [ 21/Feb/13 ]

I have been working on this possibility for a long time, but the evidence suggest it is better to keep the concept outside JSF.

In MyFaces land this discussion was open some weeks ago.

http://markmail.org/message/pc42cbcvvhlboivb

The central point is it is possible to improve JSF performance and keep its stateful nature without go into concepts done by "stateless" frameworks like view pooling and so on. With a proper design and implementation it is possible to make the difference between pool a JSF view and create it from scratch relatively small. So, at the end the additional complexity does not really worth to do it, it is better to have a stateful view and let JSF deal with the details (keep view size small, reuse objects and so on).

This topic is controversial, but if you ask me, in my opinion and based on the experimental work done from more than a year over this topic is things are not what they seem to be.

Comment by tommy.a [ 22/Feb/13 ]

Please try Mojarra 2.1.19. Its out with stateless mode.

see here:
http://java.net/jira/browse/JAVASERVERFACES-2731

http://balusc.blogspot.de/2013/02/stateless-jsf.html

Comment by gabz90 [ 22/Feb/13 ]

Perfect! Thanks! will definitely try it out.

Comment by Ertio lew [ 24/Feb/13 ]

@tommy.a: Thanks a lot for the absolutely great news!
Will definitely try it out!!

Comment by Ed Burns [ 25/Feb/13 ]

I just sent this to jsr344-experts.

EB> Hello Volunteers,
EB> You may have seen Manfred Riem's blog entry about stateless JSF. [1] I
EB> wonder what you think about adding this for 2.2? Here are the spec
EB> changes we would need for this minimal, yet effective approach.

EB> * Expose existing transient attribute on UIComponent on VDLDoc for
EB> <f:view>.

EB> The text of the attribute will be based on UIComponent.isTransient():

EB> If true, the component (and therefore the children of the component)
EB> must not participate in state saving or restoring.

EB> * In section 7.7.2.8 ViewDeclarationLanguage.restoreView(), change the
EB> text to be the following.

EB> The JSP implementation must:

EB> [include the existing text of the section.]

EB> The Facelet implementation must:

EB> Call ResponseStateManager.isStateless(). If true, take the
EB> following action (I will put this in English rather than code).

EB> ViewDeclarationLanguage vdl = vdlFactory.getViewDeclarationLanguage(viewId);
EB> viewRoot = vdl.createView(context, viewId);
EB> @@ -543,9 +547,9 @@
EB> ViewDeclarationLanguage vdl = vdlFactory.getViewDeclarationLanguage(viewId);
EB> viewRoot = vdl.getViewMetadata(context, viewId).createMetadataView(context);
EB> context.setViewRoot(viewRoot);

EB> and return, otherwise [...include existing text of the section].

EB> * In ResponseStateManager.writeState(), if the UIViewRoot is transient,
EB> take impl specific action to make it so the call to
EB> ResponseStateManager.isStateless() during the the next call, from
EB> ViewDeclarationLanguage.restoreView(), returns true.

EB> * Spec for new method ResponseStateManager.isStateless(). If the
EB> preceding writeState() was stateless, return true. If the preceding
EB> writeState() was statefull return false, otherwise throw
EB> IllegalStateException.

EB> Thanks,

EB> Ed

EB> [1] http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless

Comment by Ed Burns [ 27/Feb/13 ]

Make it so a FacesMessage is logged in the page if ProjectStage is not Production and we find that we have a @ViewScoped bean and the current UIViewRoot returns true from its isTransient() method.

Comment by Ed Burns [ 28/Feb/13 ]

SECTION: API changes
--------------------
M applicationIntegration.fm

  • Make 7.7.2.8 be:

The JSP implementation must:

If no viewId could be identified, return null.

Call the restoreView() method of the associated StateManager, passing
the FacesContext instance for the current request and the calculated
viewId, and return the returned UIViewRoot, which may be null.

The Facelets implementation must:

Call ResponseStateManager.isStateless(). If the result is false,
proceed as specified in the JSP implementation. Otherwise, take the
following steps and return.

  • Obtain a reference to the ViewDeclarationLanguage from the
    ViewDeclarationLanguageFactory. This is necessary to allow for proper
    decoration. It is not acceptable to simply use the java language this
    keyword.
  • Call createView() on the ViewDeclarationLanguage instance, passing the
    context and viewId arguments. Let viewRoot be the result.
  • Call FacesContext.setViewRoot(viewRoot).
  • Call buildView() on the ViewDeclarationLanguage, passing the context
    and viewRoot.

Return the viewRoot.

  • Add new section 7.8.1.1

Version 2.2 of the specification adds support for stateless views. In
such a view, the UIComponent state for the components is not
saved. This feature must be used with full awareness of the
statefulness requirements of the components in the view. If a
component requires state to operate correctly, it must not be used in
a stateless view. Furthermore, it is not required that @ViewScoped
managed beans work at all with stateless views. This feature only
works with Facelet based views, not JSP based views.

To mark a view as stateless, the existing transient property from
UIComponent is exposed to the view author by means of the transient
attribute on the <f:view> tag from the Faces Core tag library. The
following spec sections contain more normative requirements for
stateless views.

  • The vdldocs for the Facelet variant of the <f:view> tag.
  • The javadocs for ResponseStateManager.writeState(FacesContext, Object)
  • The javadocs for ResponseStateManager.isStateless(FacesContext)
    Section 7.7.2.8 "ViewDeclarationLanguage.restoreView()"
  • The javadocs for javax.faces.view.ViewScoped
  • The javadocs for javax.faces.bean.ViewScoped

M preface.fm

  • Add new big ticket feature, Stateless Views, with cross reference to
    overview section 7.8.1.1.

Sending applicationIntegration.fm
Sending preface.fm
Transmitting file data ..
Committed revision 1131.

Comment by kito75 [ 28/Feb/13 ]

I'd like to see a console warning, not just a FacesMessage. A FacesMessage may not be displayed in production, and doesn't show up in the logs.

Comment by exabrial [ 08/Mar/13 ]

Hey I know this issue is closed, but on a closely related feature request, could this be extended slightly to specify the state saving method on a per-view basis? So there'd be 'none','server','client'? I think I saw this in JIRA somewhere but I can't find the feature request.

Comment by kithouna [ 08/Mar/13 ]

I think I saw this in JIRA somewhere but I can't find the feature request.

JAVASERVERFACES_SPEC_PUBLIC-1056

It would be great if this too would have been included, but the work for JSF 2.2 has to stop at some point, otherwise there'll never be a release.

I really hope that issue will be one of the first things addressed for 2.3

Comment by Ertio lew [ 13/Apr/13 ]

Would viewscope work in stateless mode ?

It would be good if viewscope works in stateless mode or otherwise there is some appropriate substitute for replacing viewscope.

Comment by arjan tijms [ 13/Apr/13 ]

Would viewscope work in stateless mode?

No, it explicitly doesn't work. If you try it JSF will throw a specific exception to warn you about this.

It would be good if viewscope works in stateless mode or otherwise there is some appropriate substitute for replacing viewscope.

There should be something, but personally I think this would only make sense when it's possible to make a distinction between "state" and "cache". In a stateless mode it would defeat the purpose to use a bean that keeps state, but it might very well be used for cache. In this context I then define "state" as unique data and "cache" as data that can be restored somehow.





[JAVASERVERFACES_SPEC_PUBLIC-1054] Define a standard structure for a JSF application Created: 29/Nov/11  Updated: 01/Aug/14  Resolved: 29/Nov/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.2
Fix Version/s: 2.2

Type: New Feature Priority: Major
Reporter: lamine_ba Assignee: Ed Burns
Resolution: Works as designed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The goal of this feature is to define a standard structure for a JSF 2.2 application. And here is the proposal :

Resources


The css, js, images files must be stored in the resources folder like for JSF 2.0

  • resources
Views


The views must be stored in a folder named views

  • views


The protected views must be stored in a sub folder named protected

  • views
    • protected
Templates


The templates must be stored in a folder named templates

  • templates
    • mytemplate
      • css
      • js
      • images
      • template.xhtml
      • template.png
      • template.xml
Tasks Flows (modules)


The modules must be stored in a folder named modules. Note that the structure of a Task flow has not yet been set.

  • modules

And we end up finally with this standard and cohesive structure :

  • app
    • resources
    • views
    • templates
    • modules
    • web-inf
Externalization of the JSF artifacts


The folders must be externalized and stored out of the WAR file to enlarge the possibilities for new ideas and systems.



 Comments   
Comment by Neil Griffin [ 29/Nov/11 ]

Should templates be under /WEB-INF in order to protect them from direct access by the user-agent?

Comment by lamine_ba [ 29/Nov/11 ]

Yes Neil, that is the next step. Find the right location. Can we protect the artifacts from direct access by the user-agent if they are not under /WEB-INF? If so, I would love to have this solution..

Comment by Neil Griffin [ 29/Nov/11 ]

Well, I don't know if this is the most elegant solution, and it's certainly not zero-config, but this is what I do to protect XHTML files from direct access via WEB-INF/web.xml:

<!-- Prevent direct access to Facelet view XHTML by the userAgent (browser). -->
<security-constraint>
<web-resource-collection>
<web-resource-name>Facelet View XHTML</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>nobody</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>nobody</role-name>
</security-role>

Comment by lu4242 [ 29/Nov/11 ]

MyGourmet JSF examples here:

https://github.com/jsflive/mygourmet-ee

uses META-INF/templates. I think it has more sense to use that location, but I have seen other applications using WEB-INF/templates too. I'm not an EG expert, but I vote for META-INF/templates.

Comment by lamine_ba [ 29/Nov/11 ]

Yes the solution proposed by Neil would be very nice if we could make it automatic. Can we add this behavior at runtime? Regarding the proposal of lu4242, Yes like the resources directory of JSF 2.0, the templates can be stored in the META-INF/templates directory. One can have the need to package things in a jar file.

Comment by lamine_ba [ 29/Nov/11 ]

If JSF 2.2 has a dependency with the Servlet 3.0 api. I think the solution that Neil comes with can be implemented using the web-fragment feature.

1) http://www.javabeat.net/articles/97-new-features-in-servlets-30-2.html

We just provide and write this default behavior in a predefined web-fragment.xml thus we can bring an automatic and default protection for our standard folders from direct access by the user-agent.

Comment by Neil Griffin [ 29/Nov/11 ]

I think we need to maintain compatibility with Servlet 2.5 (Tomcat 6) for JSF 2.2

So I think the web fragment feature could be utilized, so long as developers realize that a zero-config feature like that will only get activated if they deploy their webapps/portlets in Servlet 3.0 (Tomcat 7).

Comment by lamine_ba [ 29/Nov/11 ]

Yes I agree but having a default web-fragment.xml file does not mean, we will not be compatible with Servlet 2.5. This api does not even know what a web-fragment.xml is all about. It means only when a developer is using a server like Tomcat 6, he has to do things manually but when he moves to use tomcat 7, things are done automatically for him. And that is another good reason for a developer to make the switch...

Comment by Neil Griffin [ 29/Nov/11 ]

Right, I think you and I basically just said the same thing.

Comment by lamine_ba [ 29/Nov/11 ]

I'm closing this feature now. Thank you all for your clever comments.

As blake sullivan wrote, it is better to make it a recommended best practice.
Thus it will be implemented as a JSF 2.2 maven archetype. In this implementation, you will see also the solution described by Neil Griffin to protect the artifacts from direct access by the user-agent. This behavior will be automated and implemented using the Servlet 3.0 web-fragment feature. So if you are not using this api, please do it yourself.

Thanks.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1052] add API for a pluggable WindowIdProvider Created: 23/Nov/11  Updated: 01/Aug/14  Resolved: 25/Jul/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.2
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: Mark Struberg Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-949 Window-id Closed

 Description   

Currently any state information stored on the server side (either with ServerSideStateHandling or tokens to prevent XSSF and replay attacks) are all stored on a per-session basis.

Since multi-browser-tab editing becomes increasingly popular, we should provide a way to plugin a windowId mechanism.

If the user currently opens an additional browser tab and clicks around in his application for a bit (I think in Mojarra and MyFaces the default is to store the 20 last views per session), and then goes back to the first browser tab, he will get a ViewExpiredException.

Since doing the windowId handling inside the spec is pretty complicated (there is not yet a perfect solution without any downsides, see JAVASERVERFACES_SPEC_PUBLIC-949), we could leave this to the application and just use some provided windowId to keep the last n states for each browser tab.

We would then have a MAX_VIEWS_PER_TAB and MAX_TABS_PER_SESSION limit.
This is needed regardless if JAVASERVERFACES_SPEC_PUBLIC-949 is finally solved or not.



 Comments   
Comment by gerhard_petracek [ 23/Nov/11 ]

JAVASERVERFACES_SPEC_PUBLIC-949 is just an umbrella-ticket. currently it isn't bound to a concrete approach. for sure we will need a pluggable mechanism e.g. inspired by the WindowHandler of myfaces codi

Comment by lu4242 [ 23/Nov/11 ]

I think it is worth to add some comments from myfaces mailing list. In MyFaces there is this issue:

https://issues.apache.org/jira/browse/MYFACES-3404

In few words, this concept becomes useful to fix server side state saving and flash scope. So, even if by default this is not implemented fully, at least the spec should provide an interface to delegate to other jsf libraries to implement this concept and let the logic so if this is provided the problems on server side state saving and flash scope could be handled in a "decoupled" way.

From MyFaces dev list:

Hi

MS>> The ClientSideWindowHandler solution in CODI looks good so far, but there
MS>> is still a lot to do.

MS>> And like every technology, it has it's pros and cons...

MS>> What do you think about making the windowId provider pluggable in MyFaces
MS>> core first?

I have been thinking about every possible option we have for implement this and
the conclusion was the best way is make something like the hack done in CODI or
a "variant" of it, like the one described on:

http://wiki.apache.org/myfaces/Drafts/WindowId

(Mixed approach of the first prototype)

From the point of view of MyFaces Core, any solution should be bound to the
renderkit in some way. So, windowId concept has sense to include it on the spec
but its implementation should be done according to the renderkit. If the
renderkit handles html, do the hack proposed but if is xml, do other thing
and so on. It sounds like something to do outside MyFaces Core. Basically the
problem is how to create an interface about something that could require
changes over the renderkit/viewhandler?.

Maybe we can minimize the problem, and provide an interface like this:

public interface WindowIdRenderKitAware

{ public String getCurrentWindowId(FacesContext facesContext); }

But let the details about how to "plug" all pieces inside CODI. MyFaces Core
just offer the "integration point", and the default algorithm just do what is
doing right now. Who should implement this interface? the renderkit, even if
in the implementation the value can be stored inside FacesContext attribute
map or request map. There exists a RenderKitWrapper interface, so it is
easy to create a wrapper for default HTML_BASIC renderkit or any other and
then scan through the wrappers and the first one implementing the interface
will be the choosen.

MS>> The REAL problem with JSF and multiple tabs is that once you open 2 tabs
MS>> and click in 1 of them often enough, then you will destroy the state of
MS>> the view in the other tab as well somewhen. Usually after 20 requests
MS>> (default).

There are two points where this logic could be useful inside MyFaces Core :

1. Server side state
2. Flash scope

But in practice the only really relevant is 1. To implement 2. it is necessary
a "requestId". MyFaces FlashImpl uses a counter and store its value inside
a cookie. To fix this scope properly, the best is create a ExternalContext
wrapper and provide and alternate Flash object, but that sounds like something
that can be done outside MyFaces Core. If you are using CDI scopes, it sounds
reasonable to provide an alternate Flash scope in CODI.

If we can just modify the logic inside server side state to include "windowId"
concept, it will be enough.

MS>> To come over this, we need to store the n last views not only per session,
MS>> but also per browser tab (==windowId).
MS>> Of course, there can be lots of fancy stuff done to detect closed tabs,
MS>> etc. But all this is much more stable if we really have the opportunity
MS>> to distinguish between tabs. We can e.g. also introduce a configuration
MS>> for maximum allowed tabs, to reduce memory blasting.

Really since all state is stored in session, if the session is invalidated all
tabs are removed from memory. Basically we already have params for max number
of sessions and max number of logical sessions (which in fact can be seen
as "tabs"). So what we have right now is ok, we just need to include windowId
concept into the logic and that's it.

MS>> All this is actually completely independent of how the windowId get's
MS>> created and checked imo.

Yes, that's right.

MS>> I now tend to do the following (just atm creating a better playground
MS>> example in CODI + hack on the ClientSideWindowHandler):
MS>>
MS>> a.) the cookie thingy is pretty bääh. it just doesn't work if a
user clicks
MS>> quickly through a list and opens lots of 'detail pages' on different tabs
MS>> within 2 seconds.
MS>>
MS>> b.) it's currently a 'one or the other' thingy, and I now thought about
MS>> combining the lazyWindowIdDropp.js and the current windowhandler.js
MS>>
MS>> My current research goes into the direction of
MS>>
MS>> 1.) always adding the windowId to each and every link and transport the
MS>> windowId only via this parameter.
MS>>
MS>> 2.) For HTML5-browsers (detected via UserAgent) I render the
MS>> windowhandler.html intermediate page which does all the fancy stuff of
MS>> dynamically applying the old DOM on the intermediate page, etc. For other
MS>> clients we rely on the lazyWindowId script.

Ok, sounds promising. So, I'll focus on how to fix the logic for myfaces
core server side state saving
(org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the alternative
proposed in this mail (WindowIdRenderKitAware interface, and then use a
RenderKit wrapper).

Comment by Mark Struberg [ 23/Nov/11 ]

txs Gerhard and Leo!

Gerhard, you are right that this is actually a part of JAVASERVERFACES_SPEC_PUBLIC-949.
Imo creating a way to plugin any windowId provider into JSF is necessary in any case, and it's easily doable by now.

The reason I did split this one from the umbrella is because I fear that all ways to implement any windowId mechanism itself (the piece which detects and handles different browser tabs) all have certain side effects. I think we couldn't enable any one of those (nor a combined variant) for JSF by default - mainly because of compatibility reasons with older JSF versions.

But we can easily add the support for pluggable windowId providers which a user must activate themselfs as a first step.

If the one WindowHandler approach we currently work on in Apache MyFaces CODI proves itself usable, then we will definitely contribute it to the JSF spec!

Comment by gerhard_petracek [ 23/Nov/11 ]

yes - as discussed several times, we can't enable it by default.
all those details will be provided for the initial suggestion for JAVASERVERFACES_SPEC_PUBLIC-949.

Comment by Ed Burns [ 25/Jul/13 ]

I assert that the design for ClientWindow does allow for plugability.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1051] Externalize the templates from the actual WAR Created: 20/Nov/11  Updated: 25/Jul/13  Resolved: 25/Jul/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2
Fix Version/s: 2.2

Type: New Feature Priority: Major
Reporter: lamine_ba Assignee: Ed Burns
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-971 Multi-templating System Closed

 Description   

I wonder if it would be possible to have the templates externalized from the actual WAR file which has a number of advantages.

Regards,

Mark P Ashworth (http://mpashworth.wordpress.com)






[JAVASERVERFACES_SPEC_PUBLIC-1041] error in API doc of FactoryFinder Created: 20/Oct/11  Updated: 01/Aug/14  Resolved: 20/Oct/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: 2.2

Type: Improvement Priority: Trivial
Reporter: bernd_mueller Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

copy/paste error in javax/faces/FactoryFinder.java on newly introduced constant FACELET_FACTORY

Doc is

/**

  • <p class="changed_added_2_1">The property name for the
  • {@link javax.faces.view.facelets.FaceletCacheFactory}

    class name.</p>
    *

  • @since 2.2
    */
    public final static String FACELET_FACTORY;

but should be

/**

  • <p class="changed_added_2_2">The property name for the
  • {@link javax.faces.view.facelets.FaceletFactory}

    class name.</p>
    *

  • @since 2.2
    */
    public final static String FACELET_FACTORY;

change "2_1" to "2_2"
and change "FaceletCacheFactory" to "FaceletFactory"



 Comments   
Comment by Ed Burns [ 20/Oct/11 ]

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Transmitting file data .
Committed revision 9409.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1038] Provide annotation for declaring Facelets ResourceResolver Created: 06/Oct/11  Updated: 15/May/12  Resolved: 20/Oct/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Attachments: Text File changebundle.txt     Text File diffs.patch    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-599 Application.createComponent(): compco... Closed

 Description   

We need a way to declare a ResourceResolver without XML.



 Comments   
Comment by Ed Burns [ 06/Oct/11 ]

Adding jsf-api/src/main/java/javax/faces/view/facelets/FaceletsResourceResolver.java
Transmitting file data .
Committed revision 9400.

Still need to implement

Comment by Ed Burns [ 06/Oct/11 ]

Fix in progress. Incomplete.

Comment by Ed Burns [ 07/Oct/11 ]

in progress, need test before commit

Comment by Ed Burns [ 12/Oct/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/config/AnnotationScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/util/ReflectionUtil.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/java/com/sun/faces/regression/i_spec_1038_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/java/com/sun/faces/regression/i_spec_1038_war/AnnotationDeclaredResourceResolver.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/webapp/WEB-INF/beans.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-1038/i_spec_1038_war/src/main/webapp/i_spec_1038_war.xhtml
Transmitting file data .........
Committed revision 9401.

Comment by arjan tijms [ 19/Oct/11 ]

I have a question about the implementation. Currently it's:

ApplicationAssociate#createFaceletFactory
Set<? extends Class> resourceResolvers = 
    ConfigManager.getAnnotatedClasses(ctx).get(FaceletsResourceResolver.class);
if ((null != resourceResolvers) && !resourceResolvers.isEmpty()) {
    Class resolverClass = resourceResolvers.iterator().next();
    if (1 < resourceResolvers.size()) {
        if (LOGGER.isLoggable(Level.SEVERE)) {
            LOGGER.log(Level.SEVERE, "Found more than one class " + 
                "annotated with FaceletsResourceResolver.  Will " + 
                "use {0} and ignore the others", resolverClass);
        }
    }
    resolver = (ResourceResolver) 
        ReflectionUtil.decorateInstance(resolverClass,
        ResourceResolver.class,
        resolver);
} else {
    String resolverName = webConfig.getOptionValue(FaceletsResourceResolver);
    if (resolverName != null && resolverName.length() > 0) {
        resolver = (ResourceResolver) 
                ReflectionUtil.decorateInstance(resolverName,
                ResourceResolver.class,
                resolver);
    }
}

So if the @FaceletsResourceResolver annotation is present, it's used. Otherwise the XML is consulted.

Should this perhaps not be the other way around? In Java EE it seems to be the convention that XML can be used to override annotations. Is there a hard rule for this somewhere?

A small other thing; I noticed that in com.sun.faces.config.AnnotationScanner the Javadoc on top of the class has not been updated for the newly added annotation.

Comment by Ed Burns [ 19/Oct/11 ]

Good questions by arjan tims have prompted me to reopen this.

Comment by Ed Burns [ 20/Oct/11 ]

Spec changes.

Sending preface.fm
Sending usingFacesInWebapps.fm
Transmitting file data ..
Committed revision 1041.

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/config/AnnotationScanner.java
Transmitting file data ..
Committed revision 9407.

Comment by Ed Burns [ 20/Oct/11 ]

I don't know what the difference between "close" and "resolve" is so I am doing both.

Comment by arjan tijms [ 15/May/12 ]

Per commit 9755 and issues JAVASERVERFACES_SPEC_PUBLIC-719 and JAVASERVERFACES_SPEC_PUBLIC-809, ResourceResolver has been deprecated.

Perhaps it's a little confusing if a new annotation is introduced for something that is simultaneously deprecated?





[JAVASERVERFACES_SPEC_PUBLIC-1036] Not all attributes are value expression enabled Created: 09/Sep/11  Updated: 01/Aug/14  Resolved: 01/Feb/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: balusc Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JSF 2.1 specification PDF document



 Description   

Chapter 3.1.4 tells the following:

For the standard component classes defined by this specification, all attributes, and all properties other than id and parent, are value expression enabled.

This is confusing. Some of them accept method expressions only, such as action, listener, actionListener, valueChangeListener and validator.

Related: http://stackoverflow.com/questions/7361684



 Comments   
Comment by Ed Burns [ 01/Feb/12 ]

Committed to spec trunk in revision 1047.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1035] Clarify purpose of SEVERITY_INFO and SEVERITY_WARN Created: 07/Sep/11  Updated: 01/Aug/14  Resolved: 12/Sep/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Improvement Priority: Minor
Reporter: kennardconsulting Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days


 Description   

The severity of a FacesMessages (SEVERITY_INFO, SEVERITY_WARN, SEVERITY_ERROR or SEVERITY_FATAL) is mentioned only once in the JSF spec (section 6.3 FacesMessage). Even then, this is only to enumerate its possible values.

The four severity values are arguably self explanatory, but at least one point would bear some clarification. Specifically: is it still considered a validation error if the severity is INFO?

Section 6.3 descibes all severity values as a 'problem' of some kind ('how serious the problem'). Section 2.2.2 indicates "validations that failed will have caused messages to be enqueued via calls to the addMessage() method". So this does indeed seem to suggest that SEVERITY_INFO (and SEVERITY_WARN) are in fact validation errors - in the sense that they cause the 'Process Validations' lifecycle stage to fail.

Can this be stated explicitly in the spec? The severity names are a bit misleading. I have had users of my widget library question whether SEVERITY_INFO should be considered a validation error. Specifically they have questioned whether...

if ( FacesContext.getCurrentInstance().getMaximumSeverity() != null )

...is a valid way to check for the presence of a validation error.



 Comments   
Comment by kennardconsulting [ 09/Sep/11 ]

Brian Leathem has helpfully pointed out there was a FacesContext.isValidationFailed method introduced in JSF 2.0. It does not rely on FacesMessage at all.

Unfortunately it appears to be quite 'baked in' to the JSF 2.0 internals (eg. now UIInput calls FacesContext.validationFailed as well as FacesContext.responseComplete). So I cannot replicate it for JSF 1.x compatibility.

Is there an equivalent to FacesContext.isValidationFailed for JSF 1.x?

Comment by Ed Burns [ 12/Sep/11 ]

Regarding isValidationFailed() for JSF 1.x: No, there is not.

Regarding a decent definition of the logging levels, that is not something we have considered. While it is true that FacesMessage is a JSF class, when we do consider logging levels, they should be considered at the lowest level of the stack as possible.

JavaEE spec section EE.6.2.4.9 explicitly declares the platform spec
doesn't require the logging of any certain events.

I'll put a query in to the Titans of JavaEE about this.

In the meantime, I do agree with your suggestion that even INFO messages should be considered a validation failure.

I'll update the spec accordingly.

Comment by Ed Burns [ 12/Sep/11 ]

Sending perRequestStateInformation.fm
Sending preface.fm
Transmitting file data ..
Committed revision 1031.

Comment by kennardconsulting [ 12/Sep/11 ]

Thanks Ed,

So this would mean that...

if ( context.getMaximumSeverity() != null )

...is a valid way to test if a validation error has occurred in JSF 1.2? Googling for "getMaximumSeverity() != null" this seems to be used by a few people?

Regards,

Richard.

Comment by Ed Burns [ 13/Sep/11 ]

Yes, this seems reasonable and safe.

Comment by lu4242 [ 13/Sep/11 ]

I think it is questionable. Take a Look UIData.encodeBegin javadoc description:

"... In addition to the default behavior, ensure that any saved per-row state for our child input components is discarded unless it is needed to rerender the current page with errors. ..."

There is a check to preserve the model if there is no validation error, looking for no messages with SEVERITY_ERROR.

That description comes from JSF 1.1. If an info message is considered a validation error, is this description wrong?

I was about to ask if we can change that part to use FacesContext.isValidationFailed for JSF 2.0 and upper, instead of rely on this "weird" logic.

Comment by kennardconsulting [ 01/Oct/11 ]

I agree FacesContext.isValidationFailed is a much better choice for JSF 2. We just need to agree what the equivalent should be for JSF 1.

If UIData is looking only for SEVERITY_ERROR, then...

if ( context.getMaximumSeverity() != null )

...is not going to cut it. Perhaps the answer would be in understanding why FacesContext.isValidationFailed was introduced? Were people confused about this area? If so, what was the confusion?

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1032] UIForm.createUniqueId() does not create unique id's in case prependId="false" is specified. Created: 12/Aug/11  Updated: 01/Aug/14  Resolved: 16/Aug/11

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

Type: Bug Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Hanspeter Duennenberger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Text File JAVASERVERFACES_SPEC_PUBLIC-1032-UIForm.createUniqueId.patch    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-787 Restore ViewScope before templates ar... Closed

 Description   

In case prependId="false" is given, UIForm must delegate createUniqueId to it's parent UniqueIdVendor.

Stumbled across that while testing for JAVASERVERFACES_SPEC_PUBLIC-787 - where in a simple view outputText components where added dynamically from a managed bean action. Because the form had prependeId="false" it happened that the dynamically added outputText got the same j_idt3 as the UIOutput for the jsf.js resource already had - jsf.js got the id from UIViewRoot, the dynamically added component got the id from the form with prependId="false".

There might be other NamingContainer/UniqueIdVendor that also support prependId="false" - they need to be checked against that too.

This issue might also be related to JAVASERVERFACES_SPEC_PUBLIC-539 - please verify.

If this is solved with 2.2, consider back-porting it to 2.1/2.0 also.

There is a simple workaround - do not use prependId="false"!

regards
Hanspeter



 Comments   
Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

Patch to let UIForm.createUniqueId() delegate next ancestor UniqueIdVendor, or ViewRoot if ancestor UniqueIdvendor cannot be found.

Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

1032 fix solves the problem that has lead to add a workaround on the 787 changes in StateManagementStrategyImpl before calling UIViewRoot.restoreViewScopeState().

The 787 workaround must be removed at the same time as 1032 fix is commited.

Comment by rogerk [ 12/Aug/11 ]

<p class="changed_modified_2_2">Generate an identifier for a component. The identifier
will be prefixed with UNIQUE_ID_PREFIX, and will be unique
within this component container. Optionally, a unique seed value can
be supplied by component creators which should be
included in the generated unique id.</p>
<p class="changed_added_2_2">
If the <code>prependId</code> property has the value <code>false</code>,
this method must call <code>createUniqueId</code> on the next ancestor
<code>UniqueIdVendor</code>.
</p>

Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

added changebundle for proposed changes.

Comment by rogerk [ 15/Aug/11 ]

Tests on my hosted machine ran successfully.
r=rogerk

Provided you've considered cases where component frameworks have their own custom Forms.

Comment by Hanspeter Duennenberger [ 16/Aug/11 ]

UIForm.createUniqueId() does not create unique id's in case prependId="false" is specified. http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1032

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/component/UIForm.java
M jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java

  • delegate createUniqueId() to ancestor UniqueIdVendor if prependId is set to false
  • removed workaround in StateManagementStrategyImpl that was added because UIViewRoot was false identified as dynamically added because of above bug

Sending /Users/hampi/Projects/ws-helios/Mojarra/jsf-api/src/main/java/javax/faces/component/UIForm.java
Sending /Users/hampi/Projects/ws-helios/Mojarra/jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java
Transmitting file data ...
Committed revision 9268.

Is that UIForm fix also needed on 2.1/2.0 branches?

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1030] Message / Messages Component ToolTip Attribute To Use Detail Message Created: 04/Aug/11  Updated: 10/Aug/11  Resolved: 10/Aug/11

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, the "tooltip" attribute description for message and messages renderer says:

"Flag indicating whether the detail portion of the message should be displayed as a tooltip."

However, the rendering details and the implementation always use the summary.

PROPOSAL:
Use the detail message for the tooltip (if it is set). If no detail message is set, use the summary.

This relates to http://java.net/jira/browse/JAVASERVERFACES-2160



 Comments   
Comment by rogerk [ 10/Aug/11 ]

Fixed. See: http://java.net/jira/browse/JAVASERVERFACES-2160





[JAVASERVERFACES_SPEC_PUBLIC-1023] PostAddToViewEvent publishing conditions still inconsistent Created: 07/Jul/11  Updated: 01/Aug/14  Resolved: 08/Jul/11

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

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File i_spec_1023.tiff    
Issue Links:
Related
is related to JAVASERVERFACES-1985 PostAddToViewEvent publishing conditi... Closed
Status Whiteboard:

size_small importance_small


 Description   

The spec language in PostAddToViewEvent is too specific.



 Comments   
Comment by Ed Burns [ 07/Jul/11 ]

Javadoc screengrab

Comment by Ed Burns [ 08/Jul/11 ]

Sending jsf-api/src/main/java/javax/faces/event/PostAddToViewEvent.java
Transmitting file data .
Committed revision 9191.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1019] h:outputLink etc strange URL encoding Created: 16/Jun/11  Updated: 01/Aug/14  Resolved: 17/Jun/11

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

Type: New Feature Priority: Major
Reporter: ejp Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 13 minutes
Original Estimate: Not Specified
Environment:

All


Attachments: Text File 20110617_i_spec_1019.patch    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-479 UIData should support the collection ... Closed

 Description   

If I have an h:outputLink with a value containing spaces, it is rendered with the spaces converted to +.

It seems to me that if it is going to convert this at all, it should do so correctly, i.e. to %20. Alternatively it should leave it alone and let it fail as originally supplied.

Am I missing something here?

I have a legacy content database where the document index provides URLs contain spaces. I can change that, and probably will, but maybe this is a bug and will get fixed the way I would like?

Discussion <a href="http://forums.oracle.com/forums/thread.jspa?messageID=9639501&#9639501">here</a>. Appears to involve use of URLEncoder for the one thing it cannot do, which is encode a URL. Should be using URI.toASCIIString().



 Comments   
Comment by Ed Burns [ 17/Jun/11 ]

You are correct in filing this as a spec issue, because the problem stems from the specification for the renderer for javax.faces.Output javax.faces.Link.

http://javaserverfaces.java.net/nonav/docs/2.1/renderkitdocs/index.html

The entire "href" string must be passed through a call to the encodeResourceURL() method of the ExternalContext.

Which ends up calling: javax.servlet.http.HttpServletResponse method encodeURL(url).

Comment by Ed Burns [ 17/Jun/11 ]

checkpoint

Comment by Ed Burns [ 17/Jun/11 ]

Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-api/doc/standard-html-renderkit.xml
Sending jsf-api/src/main/java/javax/faces/context/ResponseWriter.java
Sending jsf-ri/src/main/java/com/sun/faces/util/HtmlUtils.java
Sending jsf-ri/systest/build-tests.xml
Adding jsf-ri/systest/web/render/outputLinkSpaces.jsp
Sending jsf-tools/src/main/resources/com/sun/faces/generate/facesdoc/stylesheet.css
Transmitting file data .......
Committed revision 9175.

Comment by ejp [ 17/Jun/11 ]

As a workaround until this fix is released, you can add the following converter to the h:outputLink element:

public class URLConverter implements Converter
{
@Override
public Object getAsObject(FacesContext fc, UIComponent uic, String string)

{ return string; }

@Override
public String getAsString(FacesContext fc, UIComponent uic, Object object)
{
String path = object.toString();
try

{ if (path.indexOf(' ') >= 0) path = new URI(null, path, null).toASCIIString(); }

catch (URISyntaxException exc)

{ // logger.log(Level.SEVERE, "uri="+path, exc); }

return path;
}
}

Comment by ejp [ 03/Dec/12 ]

The same problem also turns up in h:graphicImage. For example:

h:graphicImage value="{{lab.path}}VisualObjective.jpg" where lab.path evaluates to /cLabsTest/EDSILabs/vLearning/Cisco Courses/Enterprise (Routers & Switches)/Interconnecting Cisco Network Devices 1/ICND1 Lab 2-2 Performing Switch Startup and Initial Configuration/VisualObjective.jpg

becomes

img src="/cLabsTest/EDSILabs/vLearning/Cisco+Courses/Enterprise+(Routers+&+Switches)/Interconnecting+Cisco+Network+Devices+1/ICND1+Lab+2-2+Performing+Switch+Startup+and+Initial+Configuration/VisualObjective.jpg"

Should I report this as a new bug?

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1015] Inform about exposed view source when using prefix mapping Created: 14/Jun/11  Updated: 01/Aug/14  Resolved: 14/Jun/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: balusc Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: HTML File FacesServlet.html    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-915 Add non-normative text that documents... Closed
Tags: mapping

 Description   

Trigger: http://stackoverflow.com/questions/6341361/jsf-url-mapping-security-risk

Summary: When prefix mapping is used, the view source is publicity avaliable to enduser by just removing the prefix mapping pattern from the request URL. This can cause privacy issues and in opinion of some even a security issue. This should more clearly be adressed in the specification.



 Comments   
Comment by Jakob Korherr [ 14/Jun/11 ]

Possible workaround: use a filter that prohibits access to everything not containing the prefix mapping of the FacesServlet!

Comment by balusc [ 14/Jun/11 ]

@Jakob: this is pretty poor. How about static resources like JS/CSS/images and plain HTML files?

The common approach to prevent direct access to source files when prefix mapping is used is to put a security constraint on the JSF default view extension:

<security-constraint>
    <display-name>Restrict direct access to XHTML files</display-name>
    <web-resource-collection>
        <web-resource-name>XHTML files</web-resource-name>
        <url-pattern>*.xhtml</url-pattern>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>

An alternative approach is to use extension mapping of *.xhtml instead. The only disadvantage is that you cannot serve "plain" XHTML files anymore without invoking the FacesServlet. But IMO this is not a disadvantage as those kind of files should have the *.html extension.

Comment by Jakob Korherr [ 14/Jun/11 ]

hehe - yep, I know it's pretty poor, but it was the first thing that popped into my mind!

>How about static resources like JS/CSS/images and plain HTML files?

Well, since JSF 2 you should serve these with the JSF resource handler anyway!

However, using a security contraint is better, and of course, using *.xhtml is the best!

Comment by Ed Burns [ 14/Jun/11 ]

Generated documentation. Will be color coded.

Comment by Ed Burns [ 14/Jun/11 ]

Sending jsf-api/src/main/java/javax/faces/webapp/FacesServlet.java
Sending jsf-api/src/main/java/javax/faces/webapp/package.html
Transmitting file data ..
Committed revision 9164.

Comment by balusc [ 14/Jun/11 ]

Great! By the way, I start to realize that the issue is not related to prefix patterns per se. The same issue would expose when you're using a suffix pattern such as *.faces and replace the extension in request URL by *.xhtml.

Comment by Jakob Korherr [ 14/Jun/11 ]

hehehe. you're right. did not think of that!

Comment by arjan tijms [ 17/Sep/11 ]

The only disadvantage is that you cannot serve "plain" XHTML files anymore without invoking the FacesServlet. But IMO this is not a disadvantage as those kind of files should have the *.html extension.

Following that logic, I wonder what the opinions are on adding *.xhtml to the default servlet mapping? This will instantly solve the problem with exposing the source code and as an extra benefit I think *.xhtml to *.xhtml will be easier to understand for those new to JSF.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1014] javax.faces.DECORATORS is a description error Created: 13/Jun/11  Updated: 01/Aug/14  Resolved: 13/Jun/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: xj Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: licbug

 Description   

This is reported against Mojarra-2.1.0.

There is a description of "javax.faces.DECORATORS" in 11.1.3
Application Configuration Parameters of JSF spec. However, RI
implements it as "javax.faces.FACELETS_DECORATORS".



 Comments   
Comment by Ed Burns [ 13/Jun/11 ]

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1014

M usingFacesInWebapps.fm

  • 12.1.3

The specification for the context-param that declares the list of
TagDecorator implementations to the runtime should have always been
javax.faces.FACELETS_DECORATORS. Prior to this revision, the name of
this context param was incorrectly specified as
javax.faces.DECORATORS. The reference implementation has always used
the correct name, however.

Comment by Ed Burns [ 13/Jun/11 ]

Sending usingFacesInWebapps.fm
Transmitting file data .
Committed revision 1018.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1012] Expose Servlet.getContextPath() and PortletRequest.getContextPath() on ExternalContext Created: 26/May/11  Updated: 01/Aug/14  Resolved: 31/May/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator), Portlet
Affects Version/s: 1.1, 1.2, 2.0, 2.1
Fix Version/s: 2.2

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 7 hours
Time Spent: 1 hour
Original Estimate: 8 hours

Issue Links:
Dependency
blocks JAVASERVERFACES-1995 mojarra scanning ear instead of war Closed
Status Whiteboard:

size_small importance_small


 Description   

It would be nice to be able to ask the ExternalContext for the contextpath.



 Comments   
Comment by Ed Burns [ 31/May/11 ]

Committed to trunk.

Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java
Sending jsf-api/src/main/java/javax/faces/context/ExternalContextWrapper.java
Sending jsf-ri/src/main/java/com/sun/faces/config/DelegateToGlassFishAnnotationScanner.java
Sending jsf-ri/src/main/java/com/sun/faces/config/InitFacesContext.java
Sending jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
Adding jsf-test/JAVASERVERFACES-1995
Adding jsf-test/JAVASERVERFACES-1995/build.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_ear
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_ear/pom.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main/java/com/sun/faces/regression/i_jsf_1995
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main/java/com/sun/faces/regression/i_jsf_1995/Issue1995_war_1_TestCase.java
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_htmlunit/src/main/java/com/sun/faces/regression/i_jsf_1995/Issue1995_war_2_TestCase.java
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/pom.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/src
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/src/main
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/src/main/webapp/WEB-INF/glassfish-web.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/src/main/webapp/index.jsp
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_1/src/main/webapp/index.xhtml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2/pom.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2/src
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2/src/main
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2/src/main/webapp
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2/src/main/webapp/WEB-INF/glassfish-web.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-1995/i_jsf_1995_war_2/src/main/webapp/index.xhtml
Sending jsf-test/build.xml
Transmitting file data ....................
Committed revision 9123.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1010] inconsistent behavior in state saving when using upper case Created: 26/May/11  Updated: 01/Aug/14  Resolved: 26/May/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.2

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2080 inconsistent behavior in state saving... Closed

 Description   

There is a description about "Javax.faces.STATE_SAVING_METHOD" in 11.1.3 Application Configuration Parameters saying to use "client" or "server" to specify where state info is saved. When "Client" (that contains upper case) is used, state will be saved on server side though javax.faces.application.StateManager#isSavingStateInClient returns true.
If upper case is not allowed by the specification?



 Comments   
Comment by Ed Burns [ 26/May/11 ]

Committed to Mojarra trunk.

Sending jsf-ri/src/main/java/com/sun/faces/renderkit/ResponseStateManagerImpl.java
Transmitting file data .
Committed revision 9102.

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1010

Check existing usages of the state saving method parameter to ensure
case insensitivity.

  • javax.faces.application.StateManager.isSavingStateInClient()

public boolean isSavingStateInClient(FacesContext context) {
if (null != savingStateInClient)

{ return savingStateInClient.booleanValue(); }

savingStateInClient = Boolean.FALSE;

String saveStateParam = context.getExternalContext().
getInitParameter(STATE_SAVING_METHOD_PARAM_NAME);
if (saveStateParam != null &&
saveStateParam.equalsIgnoreCase(STATE_SAVING_METHOD_CLIENT))

{ savingStateInClient = Boolean.TRUE; }

return savingStateInClient.booleanValue();
}

  • com.sun.faces.renderkit.ResponseStateManagerImpl
  1. This patch file was generated by NetBeans IDE
  2. It uses platform neutral UTF-8 encoding and \n newlines.
      • Base (BASE)
        +++ Locally Modified (Based On LOCAL)
        @@ -65,7 +65,7 @@
        WebConfiguration webConfig = WebConfiguration.getInstance();
        String stateMode =
        webConfig.getOptionValue(StateSavingMethod);
  • helper = ((StateManager.STATE_SAVING_METHOD_CLIENT.equals(stateMode)
    + helper = ((StateManager.STATE_SAVING_METHOD_CLIENT.equalsIgnoreCase(stateMode)
    ? new ClientSideStateHelper()
    : new ServerSideStateHelper()));
  • usingFacesInWebapps.fm

12.1.3 add this text to the javax.faces.STATE_SAVING_METHOD spec.

When examining the value, the runtime must ignore the case.

Comment by Ed Burns [ 26/May/11 ]

Committed to spec trunk.

Sending usingFacesInWebapps.fm
Transmitting file data .
Committed revision 1016.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1004] Specify Reasonable Default For javax.faces.FACELETS_BUFFER_SIZE Created: 19/May/11  Updated: 01/Aug/14  Resolved: 19/May/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In 11.1.3 Application Configuration Parameters of JSF 2.0 specification, there is a description about javax.faces.FACELETS_BUFFER_SIZE.

----->
By default the value is -1, which will not assign a buffer size
<-----

=======

This puts an unnecessary burden on applications to override this -1 value with a context init param in web.xml. A reasonable default such as "1024" should be specified.



 Comments   
Comment by Ed Burns [ 19/May/11 ]

Sending usingFacesInWebapps.fm
Transmitting file data .
Committed revision 1015.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1001] Unable to have UIComponents and Facelet Composite components use the same namespace Created: 13/May/11  Updated: 01/Aug/14  Resolved: 08/Jul/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.2

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2033 Validation of composite components fa... Closed
is duplicated by JAVASERVERFACES-2034 Unable to have UIComponents and Facel... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-594 Add tagName attribute to @FacesCompon... Closed
Status Whiteboard:

size_medium importance_large


 Description   

Background:

Some of the AlloyFaces components are Java UIComponents (mainly for speed/performance), but others are Facelet CCs.

I really wish I could have one namespace, but I can't seem to get Mojarra to let me have both UIComponents and Facelet CCs defined in the same taglib.xml.

For example, UIComponents defined here:
http://svn.portletfaces.org/svn/portletfaces/alloy/faces/alloyfaces/trunk/src/main/resources/META-INF/aui.taglib.xml

And Facelet CCs defined here:
http://svn.portletfaces.org/svn/portletfaces/alloy/faces/alloyfaces/trunk/src/main/resources/META-INF/aui-cc.taglib.xml

The XML Schema of taglib.xml permits both to be defined in the same descriptor, but I can't get Mojarra to work with both.

It's too bad because right now some of the components have the aui: namespace and others have the aui-cc: namespace.



 Comments   
Comment by Ed Burns [ 13/May/11 ]

Proposal 20110513

Comment by Mathias Werlitz [ 16/May/11 ]

I have tried the patch.
There is a small issue left: it does not work if the resource is located in nested folders e.g. /resources/somefolder/otherfolder/tag.xhtml . If the resource is located in a simple subfolder it works nicely (like /resources/somefolder/tag.xhtml).

Comment by Ed Burns [ 16/Jun/11 ]

Adding jsf-api/doc/web-facelettaglibrary_2_2.xsd
Sending jsf-api/src/main/java/javax/faces/application/ResourceHandler.java
Sending jsf-api/src/main/java/javax/faces/application/ResourceHandlerWrapper.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceHandlerImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceManager.java
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigManager.java
Sending jsf-ri/src/main/java/com/sun/faces/config/DbfFactory.java
Sending jsf-ri/src/main/java/com/sun/faces/config/processor/FaceletTaglibConfigProcessor.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/AbstractTagLibrary.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/TagLibraryImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Adding jsf-test/JAVASERVERFACES-2033
Adding jsf-test/JAVASERVERFACES-2033/build.xml
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/pom.xml
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/java
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/java/com/sun/faceression
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/java/com/sun/faceression/i_jsf_2033
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/java/com/sun/faceression/i_jsf_2033/UserBean.java
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/WEB-INF/test.taglib.xml
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/index.xhtml
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/resources
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/resources/myCC
Adding jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/resources/myCC/layout.xhtml
Sending jsf-test/build.xml
Transmitting file data ....................
Committed revision 9172.

Comment by Ed Burns [ 24/Jun/11 ]

Change the schema to have the following as the usage syntax.

<tag>
<tag-name>layout</tag-name>
<component>
<resource-id>myCC/whatever.xhtml</resource-id>
</component>
</tag>

Comment by Ed Burns [ 08/Jul/11 ]

Sending jsf-api/doc/web-facelettaglibrary_2_2.xsd
Sending jsf-ri/src/main/java/com/sun/faces/config/processor/FaceletTaglibConfigProcessor.java
Sending jsf-test/JAVASERVERFACES-2033/i_jsf_2033_war/src/main/webapp/WEB-INF/test.taglib.xml
Transmitting file data ...
Committed revision 9192.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-999] ui:decorate ui:composition "template" Attribute Created: 10/May/11  Updated: 01/Aug/14  Resolved: 10/May/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following issues/inconsistencies exist today w/r/t the "template" attribute for
ui:decorate and ui:composition tags.

1. vdl docs say that ui:composition / ui:decorate "template" attribute is not required.
The Mojarra implementation implements ui:decoreate as required but does nothing for
ui:composition if "template" attribute is not specified.
http://java.net/jira/browse/JAVASERVERFACES-2023

Does it make sense to use these tags without a "template" attribute?
If not we should specify it as required for both tags.

2. What should be the behavior if a page author specifies this:
ui:decorate template="" or ui:composition template=""

Does it make sense to use these tags without a value for "template" attribute?
If not we should specify a TagAttributeException.



 Comments   
Comment by rogerk [ 10/May/11 ]

Actually it does not make sense to make "template" attribute required for
ui:composition, as it is perfectly feasible to author something like this:

<ui:composition>
....
</ui:composition>

But the vdldocs should specify "template" as required attribute for ui:decorate

Comment by Ed Burns [ 10/May/11 ]

Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Sending jsf-ri/conf/share/ui.tld
Transmitting file data ..
Committed revision 9024.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-998] Clarify VDL documentation for UI:component binding attribute. Created: 02/May/11  Updated: 01/Aug/14  Resolved: 02/May/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Bug Priority: Minor
Reporter: dougd Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

In the VDL Documentation it states the following for the binding attribute on ui:component.

"Binds the component to a backing bean property, as specified in the JSF specification."

IMOP we should also add the following to clarify that this binding attribute requires the bean property type to be of type UIComponent.



 Comments   
Comment by Ed Burns [ 02/May/11 ]

Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Sending jsf-ri/conf/share/ui.tld
Transmitting file data ..
Committed revision 9001.

Comment by dougd [ 02/May/11 ]

Please update the ui:fragment tag as well, this issue exists for the binding attribute in ui:fragment also.

Comment by Ed Burns [ 03/May/11 ]

Handled ui:fragment.

Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Sending jsf-ri/conf/share/ui.tld
Transmitting file data ..
Committed revision 9003.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-997] UIComponent event-listening APIs are inconsistent Created: 29/Apr/11  Updated: 01/Aug/14  Resolved: 01/Feb/12

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

Type: Improvement Priority: Minor
Reporter: Matt Benson Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 20120201-1427-i_spec_997.patch     Text File changebundle.txt    
Status Whiteboard:

size_medium importance_medium


 Description   

UIComponent defines the pair of:

void subscribeToEvent(Class<? extends SystemEvent>, ComponentSystemEventListener)
void unsubscribeFromEvent(Class<? extends SystemEvent>, ComponentSystemEventListener)

The rationale given for ComponentSystemEventListener is that, being installed on a specific component, there is no need for an instance to implement the full-blown SystemEventListener interface. It was not desired that ComponentSystemEventListener be an abstract class itself implementing SystemEventListener presumably because (a) that would force a listener into a particular inheritance hierarchy and (b) in order to narrow the argument accepted for .processEvent(), would most likely have necessitated the introduction of generics into the SystemEventListener taxonomy. The point at which the inconsistency arises is when UIComponent defines:

List<SystemEventListener> getListenersForEventClass(Class<? extends SystemEvent>)

Ignoring the contrived possibility that all ComponentSystemEventListeners installed on a given UIComponent also implement SystemEventListener, the getListeners... method is meaningless and cannot return the objects registered via subscribeToEvent().



 Comments   
Comment by rogerk [ 02/May/11 ]

triage

Comment by Ed Burns [ 12/May/11 ]

Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Sending jsf-api/src/main/java/javax/faces/event/ComponentSystemEvent.java
Sending jsf-api/src/main/java/javax/faces/event/SystemEvent.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun/faces/regression/i_spec_997
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun/faces/regression/i_spec_997/Issue997TestCase.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun/faces/i_spec_997
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun/faces/i_spec_997/ListenerForComponent.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun/faces/i_spec_997/ListenersForComponent.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/resources/META-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/resources/META-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/resources/META-INF/i_jsf_1948.taglib.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/webapp/main.xhtml
Sending jsf-test/build.xml
Transmitting file data ...............
Committed revision 9035.

Comment by dougd [ 09/Jan/12 ]

I am hitting a ClassCastException when calling to ComponentSystemEvent.processListener(ComponentSystemEventListener).

This is due to the fact that we call SystemEvent.processListener() from ComponentSystemEvent.processListenerwhich is now trying to cast to a SystemEventListener(). The issue is that ComponentSystemEventLIstener and SystemEventListener are peers. This is unlike ComponentSystemEvent which is a SystemEvent in the hierarchy.

Comment by Ed Burns [ 01/Feb/12 ]

Sending jsf-api/src/main/java/javax/faces/event/ComponentSystemEvent.java
Transmitting file data .
Committed revision 9630.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-995] FaceletContext.FACELET_CONTEXT_KEY should be "javax.faces.FACELET_CONTEXT" Created: 29/Apr/11  Updated: 01/Aug/14  Resolved: 09/May/11

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

Type: Bug Priority: Minor
Reporter: kito75 Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_small


 Description   

Currently the value of FaceletContext.FACELET_CONTEXT_KEY is "com.sun.faces.facelets.FACELET_CONTEXT"'; should be "javax.faces.FACELET_CONTEXT".



 Comments   
Comment by Ed Burns [ 09/May/11 ]

Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletContext.java
Transmitting file data .
Committed revision 9019.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-993] ActionListenerWrapper is missing Created: 29/Apr/11  Updated: 01/Aug/14  Resolved: 09/May/11

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

Type: Bug Priority: Major
Reporter: kito75 Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

To complement the other wrapper classes, there should be an ActionListenerWrapper.



 Comments   
Comment by Ed Burns [ 09/May/11 ]

Adding jsf-api/src/main/java/javax/faces/event/ActionListenerWrapper.java
Sending jsf-api/src/main/java/javax/faces/event/package.html
Transmitting file data ..
Committed revision 9022.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-992] <f:viewParam> should not have a "maxlength" attribute Created: 28/Apr/11  Updated: 28/Apr/11  Resolved: 28/Apr/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_small


 Description   

The problem was reported against RI mojarra-2.1.0.

In VDL document, the attribute table of tag f:viewParam has a
"maxlength" attribute. We used this attribute to set a max value on
a test program but it did not work. E.g. after setting to 5 on
maxlength, the RI did not show any error messages if you input some
value greater than 5. We looked through the source code and it seems the RI
did not implement this part.
If the VDL Document has a wrong description or there is a mistake in
RI?



 Comments   
Comment by Ed Burns [ 28/Apr/11 ]

Sending jsf-api/src/main/resources/overview.html
Sending jsf-ri/conf/share/facelets_jsf_core.tld
Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Transmitting file data ...
Committed revision 9000.





HTML5 Support (JAVASERVERFACES_SPEC_PUBLIC-1090)

[JAVASERVERFACES_SPEC_PUBLIC-991] Support for new/changed features in HTML5 related to javax.faces.Input javax.faces.Text Created: 27/Apr/11  Updated: 17/Dec/13  Resolved: 17/Dec/13

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

Type: Sub-task Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_large importance_large


 Description   

The input has many new features like:

autocomplete
autofocus
pattern
placeholder
type (email, number ect.)
http://www.w3schools.com/html5/tag_input.asp

It would be nice to be able to use these in <h:inputText >



 Comments   
Comment by Frank Caputo [ 05/May/12 ]

jsf.getViewState in jsf.js must also support the new types.

Comment by Ed Burns [ 17/Dec/13 ]

This is handled by passthrough attributes.





HTML5 Support (JAVASERVERFACES_SPEC_PUBLIC-1090)

[JAVASERVERFACES_SPEC_PUBLIC-990] HTML5 Forms Support Created: 27/Apr/11  Updated: 01/Aug/14  Resolved: 19/Apr/12

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

Type: Sub-task Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-1077 HTML5 Form Associated Elements Open
Status Whiteboard:

size_large importance_large


 Description   

The JSR for JSF 2.2 states <http://jcp.org/en/jsr/proposalDetails?id=344> the following regarding HTML5 forms.

Support for select HTML5 features, possibly including the following.

o HTML5 Forms (Flow and Interactive content models)



 Comments   
Comment by Ed Burns [ 09/Aug/11 ]

This presentation, which Roger found for us, has some really great HTML5 elements we should support. http://html5-demos.appspot.com/static/html5-whats-new/template/index.html#1

The presentation itself only works on Chrome, but the HTML5 features it documents work more widely than Chrome.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-971] Multi-templating System Created: 14/Apr/11  Updated: 08/Nov/12  Resolved: 08/Nov/12

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

Type: New Feature Priority: Major
Reporter: lamine_ba Assignee: Ed Burns
Resolution: Won't Fix Votes: 10
Labels: None
Σ Remaining Estimate: 2 weeks, 1 day Remaining Estimate: 0 minutes
Σ Time Spent: 5 hours Time Spent: 5 hours
Σ Original Estimate: 2 weeks, 1 day Original Estimate: Not Specified

Attachments: JPEG File screenshot-1.jpg    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-948 JSF Security Resolved
depends on JAVASERVERFACES_SPEC_PUBLIC-532 Support for modular, reusable, fragme... Closed
blocks JAVASERVERFACES_SPEC_PUBLIC-1051 Externalize the templates from the ac... Closed
blocks JAVASERVERFACES_SPEC_PUBLIC-1047 Conditional Layout in a template base... Closed
blocks JAVASERVERFACES_SPEC_PUBLIC-1046 Template highlighting Closed
blocks JAVASERVERFACES-2511 Implement ResourceResourceLibraryCont... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1142 ResourceLibraryPrefix Introduce "pref... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-316 Skinning Sub-task Closed Ed Burns  
Status Whiteboard:

size_large importance_medium


 Description   

give to a JSF application, the ability to change its look and feel with the use of several templates



 Comments   
Comment by lamine_ba [ 15/Apr/11 ]

Our multi-templating system will be made by several templates and each template will come with its own index file. A JSF application will be able to change its look and feel because each template will come with its own resources (css,js,images), a thumbnail for one to see what it looks like and its metadata.

Template Reference in a view

<ui:composition template="#

{template}

">
</ui:composition>

Template Structure

  • templates
    • joomswanky
      • css
        • template.css ( default skinning file)
      • images
      • js
      • template.png (thumbnail)
      • template.xml (metadata)
      • template.xhtml (facelets template)

Template Metadata (template.xml)

<template>
<name>joomswanky</name>
<version>1.1</version>
<creationDate>01.08.2008</creationDate>
<author>Nicole Ignaciuk</author>
<authorEmail>nicole@younic.de</authorEmail>
<authorUrl>http://www.younic.de</authorUrl>
<copyright>Nicole Ignaciuk</copyright>
<license>GNU/GPL version 2</license>
<description>Blogstyle Template based on Free CCS Template
swanky</description>
</template>

Comment by arjan tijms [ 13/Sep/11 ]

This is a really interesting idea...

Comment by lamine_ba [ 13/Sep/11 ]

This concept is another form of skinning (http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-316).

You can try the prototype here : http://jsfmtsystem.appspot.com/

and You can read more about it here :

http://weblogs.java.net/blog/lamineba/archive/2011/08/28/multi-templating-jsf-2-prototype

Comment by rdelaplante [ 19/Jan/12 ]

I have implemented a similar concept in JSF as well. In my experience you need a hierarchy of message resource bundles as well. You have a global system bundle for the majority of messages, and a template/brand/theme specific resource bundle that can override any of the global system messages, as well as add additional messages needed by the template/brand/theme (for their header, footer, etc.) You also need to take into account images that have text on them and need to be localized.

Also, we have created a .xhtml facelet file for every screen of our application in each template/brand/theme directory. It's not just the header/footer that changes... the way they want to lay out panels looks different, their placement of buttons, etc. We need to make our application look exactly like the customer's existing website so their customers don't realize they have gone to another site for our particular workflow. Every customer is totally different.

One more comment... every resource used by our template/brand/theme is listed in a configuration file so that when a web user requests it, we can make sure they are allowed to read that file and don't try to hack the system by doing things such as ../../../../. When I say resource, I'm talking about images, JavaScript files, CSS files, etc.

Comment by Frank Caputo [ 01/May/12 ]

rdelaplante is absolutely right:

It's not just the header/footer that changes... the way they want to lay out panels looks different, their placement of buttons, etc. We need to make our application look exactly like the customer's existing website so their customers don't realize they have gone to another site for our particular workflow. Every customer is totally different.

I also implemented something similar called skinning with JSF 2.0. I extended ResourceHandler, ResourceManager, ResourceResolver and the FaceletFactory. This way we were able to replace every single facelet (eg. includes or templates). We could replace resources and thereby even composite components.

It used convention without any configuration. With the following directory structure:

 
\--folder
   \--sample.xhtml
\--skins
   \--foo
      \--sample.xhtml
\--resources
   \--logo.png
   \--skins
      \--foo
         \--logo.png

The skins folder inside the resources folder was a compromise because resources is quite hardcoded. It would be nicer to have skins/foo/resources. If we add resource bundles to this skinning, we have real multi tenancy.

I think the possibility to replace every single facelet and resource is essential for multi tenancy. Because sometimes it is done by replacing a logo and a login box for example for SSO or whatever. In other cases you must replace some composite components, because the UX of the tenant uses other metaphors, but the placement on the page stays the same as for all other tenants.

And i think this way is more object/component oriented.

Comment by lamine_ba [ 26/May/12 ]

It seems that in 2012, multi-tenancy is the new buzzword in JSF 2.2 when myself I created a multi-tenant SAAS application level 4 in 2007 with JSF 1. x. And based on this difficult experience, I can assure you that with just your faces flows and this little feature I have donated to JSF, you'll never be able to reach this level.
Now to answer these comments above, a multi-templating system does not mean to take a generic template and make it fit to all your customers. That is where the mistake starts and ../../../../ is impossible to do in JSF 2 if you understand very well how its resource handling works.

Also the first and simple requirement for a framework to have multi-tenancy capabilities is to first scale...

Comment by rdelaplante [ 27/May/12 ]

I respectfully disagree. I have also created a multi-tenant SAAS application in 2007 with JSF 1.x and continue to maintain it today. The whole point of multi-templating is to be able to style the web application the way the customer wants, which with my customers, is always to make it look like their existing website. I keep a runtime data directory outside of the .war file, on the filesystem, and it includes multiple "themes" for customer brands including desktop and mobile themes. That is why MY custom facelet resource resolver reads from the filesystem and needs protection from ../../../../ by using a theme configuration file that lists which resources to make available. When discussing this with JSF people years ago they thought it was totally wrong to use the filesystem. I completely disagree because I should not have to do custom builds of my application for each customer. One build works for all customers, and their "runtime data" including HTML/CSS/images/email templates/language files/log files/configuration/etc. all lives outside of the application, as it should. They can make tweaks to their templates and have it take effect immediately. When I deploy the latest version of the .war, they do not need to touch the runtime data directly unless they want to add support for a new software feature in their theme templates.

Comment by lamine_ba [ 27/May/12 ]

And myself I respectfully agree to any of your comments. And here is how life is, full of diversity and full of contradictions. We no longer share the same vision, nor the same goal, nor the same requirements. And that is why I have waited a long time before answering.

I think it is better now for the JSF EG to keep just the idea and design it based on your visions. Myself here is how my multi-templating system is designed (back-end, front-end support....) and if you watch carefully at its video, you will read its well-defined slogan : Design and share your templates through REST. It was self evident that JAX-RS was on my mind.....

1) http://youcontrol.lamine.cloudbees.net/faces/admin/templates/
2) http://www.youtube.com/watch?v=6t-xB8wP8Rg

Thank you very much for your nice comments, I have really learned a lot from you.......

Comment by lamine_ba [ 27/May/12 ]

rdelaplante>That is why MY custom facelet resource resolver reads from the filesystem and needs
rdelaplante>protection from ../../../../

I understand now what you mean. I thought you were talking about the ResourceHandler.

rdelaplante>When discussing this with JSF people years ago they thought it was totally wrong to
rdelaplante>use the filesystem

I have ever used this strategy and I will continue to use it because you and I, we know the value in it but sadly the vision of the JSF spec lead is to store your templates in a jar.

http://jaxenter.com/interview-with-jsf-spec-lead-ed-burns-41883.html

Comment by rdelaplante [ 27/May/12 ]

You have obviously put a lot of thought and effort into your design, and it's great that you are contributing to the JSF spec. I've been meaning to join the JSF EG to standardize the Tomahawk radio button for years after realizing that making noise about it doesn't seem to be convincing enough to them. Someday when I have more time I will need to look through your work in more detail, as well as the JSF EG's refinements. Surely there are good ideas in there. What I created was based on my app's requirements, so I don't know how other people have approached the problem, especially from JSF perspective. Regarding .jar vs filesystem... who knows, there may be a very good reason why the EG prefers this approach that we never considered. Maybe they are thinking ahead to the Java 8 module system which might enable us to dynamically reload modules at runtime. We should ask.

Comment by lamine_ba [ 27/May/12 ]

Yes that is right : Since 2005, I have put a lot of thought and effort in my obsession to build a clone of the multi-templating system of Joomla : http://docs.joomla.org/Introduction_to_Joomla!_templates.

Reading just your comments, you would have been a wonderful Expert if you had joined the JSF 2.2 EG. Myself I was a member of this EG but sadly I have now no time for JSF. But as a farewell, I thought it would great if I could leave them with this idea....

Comment by rdelaplante [ 27/May/12 ]

Just curious... when you say you have no more time for JSF, and are saying farewall, does that mean you will no longer be using JSF in any future projects? If yes, what will you be using?

Comment by lamine_ba [ 27/May/12 ]

We are in the midst of a paradigm shift that will dramatically change how many of us build and deploy software. The age of server side UI framework is over since the client side is now powerful and mature. Modern web application architecture moves the UI to the client, where all user interactions are handled on the client-side. All UI state, too, moves to the client-side. The client then just makes calls to the server when it needs to access shared data or communicate with other clients / systems. The client talks to the server through HTTP using a RESTful pattern or possibly the newer WebSockets protocol which allows for bidirectional communication.

I have built a web framework for JAX-RS on top of JSF in the goal to run it in a stateless mode and reuse Facelets , the resource handling and the composite components features:

for more information, read this

1)http://weblogs.java.net/blog/lamineba/archive/2012/04/10/if-jax-rs-had-mvc-framework
2)http://weblogs.java.net/blog/lamineba/archive/2012/05/20/building-restful-web-services-jax-rs-jaxb-and-groovy

Comment by gonzalad [ 12/Jul/12 ]

I'm currenlty using Seam theme (http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/i18n.html#d0e14307) to handle multiple themes in some applications.

I would like to know about the following notions are likely to be integrated in this ticket:

  1. Theme parameters
    Are you going to 'standardise' theme configuration ? Something like : http://docs.joomla.org/Template_parameters
    for instance a theme could require general color or xhtml/html5 configuration parameter.
    Can we use the same theme multiple times in the same application but with different configurations ?
  2. Theme inheritance
    For instancen we have a company A theme.
    We need to create a theme for a subsidary company (which is similar to company A theme).
    I would like to customise theme A to create theme B.
    Would it be possible without copy/paste ?
  3. Theme selection
    Theme selection algorithm must be pluggable (i.e. from HTTP parameter, from cookie or whatever)
Comment by Ed Burns [ 08/Nov/12 ]

Deferring this to a later release.





[JAVASERVERFACES_SPEC_PUBLIC-967] VDLDoc for <f:selectItems itemValue> is incorrect. Created: 07/Apr/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_small


 Description   
  • Imre pointed out on IRC that the f:selectItems itemValue attribute
    description was incorrect. This fixes that problem.

The new description is:

This attribute lets you refer to a property of the current member of
the collection referenced by the "value" attribute, using the value
of the "var" attribute as the base. For example, #

{n.id}

.



 Comments   
Comment by Ed Burns [ 10/Apr/11 ]

Sending jsf-ri/conf/share/facelets_jsf_core.tld
Sending jsf-ri/conf/share/jsf_core.tld
Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Transmitting file data ...
Committed revision 8986.





[JAVASERVERFACES_SPEC_PUBLIC-943] Add ViewDeclarationLanguageWrapper Created: 12/Feb/11  Updated: 01/Aug/14  Resolved: 12/Feb/11

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_small


 Description   

We need a wrapper class for ViewDeclarationLanguage



 Comments   
Comment by Ed Burns [ 12/Feb/11 ]

Sending common/ant/common.xml
Sending common/ant/template/jsf-api-pom-template.xml
Sending common/ant/template/jsf-impl-pom-template.xml
Adding jsf-api/src/main/java/javax/faces/view/ViewDeclarationLanguageWrapper.java
Sending jsf-tools/pom.xml
Sending nbproject/project.xml
Transmitting file data ......
Committed revision 8845.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-940] Custom scope cyclic detection needs to be added. Created: 31/Jan/11  Updated: 17/Dec/13  Resolved: 17/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Managed Beans
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

Need to handle cyclic detection with custom scoped beans.



 Comments   
Comment by Ed Burns [ 17/Dec/13 ]

With JSF getting out of the business of managed beans, this problem now becomes the domain of CDI.





[JAVASERVERFACES_SPEC_PUBLIC-938] PartialViewContextWrapper is missing setPartialRequest Created: 31/Jan/11  Updated: 01/Aug/14  Resolved: 19/May/11

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Hanspeter Duennenberger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-917 add a JUnit test to make sure that cl... Closed
Status Whiteboard:

size_medium importance_medium


 Description   

PartialViewContextWrapper is supposed to only require getWrapped to be implemented by subclasses.

ADDITIONAL COMMENTS:

http://java.net/jira/secure/ViewProfile.jspa?name=ioss added attachment.



 Comments   
Comment by Hanspeter Duennenberger [ 19/May/11 ]

This issue was resolved by JAVASERVERFACES_SPEC_PUBLIC-917

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-932] PreValidate/PostValidate events are not published properly Created: 31/Jan/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.2

Type: Bug Priority: Trivial
Reporter: rogerk Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

In UIComponentBase implementation, PreValidate/PostValidate events are
published as below:

Application app = context.getApplication();
app.publishEvent(context, PreValidateEvent.class, this);
// Process all the facets and children of this component
Iterator kids = getFacetsAndChildren();
while (kids.hasNext())

{ UIComponent kid = (UIComponent) kids.next(); kid.processValidators(context); }

app.publishEvent(context, PostValidateEvent.class, this);

This makes overrided methods of subclasses cannot publish these events
properly. For example in UIInput as below:

super.processValidators(context);
if (!isImmediate())

{ executeValidate(context); }

You can see, the PostValidate event for UIInput will always be published BEFORE
its own actual validating



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-929] @ViewScoped fails when an UIComponent is bound to bean Created: 31/Jan/11  Updated: 01/Jul/13  Resolved: 01/Jul/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

A @ViewScoped bean will behave like a @RequestScoped bean when at least an
UIComponent is bound to the bean using binding attribute in the view. I.e. it
will be recreated on every request.

I can't find any line in the JSF specification if this is intentional or not.

A side effect is that UIData#getRowData() of the bound h:dataTable returns only
the 1st item everytime. When the bean is @RequestScoped, the UIData#getRowData()
returns the expected item.



 Comments   
Comment by arjan tijms [ 17/Apr/11 ]

See http://java.net/jira/browse/JAVASERVERFACES-1658 for additional details.

Comment by Darious3 [ 20/Dec/12 ]

Wasn't this fixed already by the way the view scope is handled now in JSF 2.2? (restoring the view scope first)

Comment by arjan tijms [ 19/May/13 ]

It looks like this has been fixed indeed.

I tested on GlassFish 4.0 b88 with the following Facelet:

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
>
    <h:body>
        <h:form id="form">
            <p>
                <h:outputText id="test" value="test component" binding="#{viewScopedBean.component}" />
            </p>
            
            <p>
                Output from bean:
                <h:outputText value="#{viewScopedBean.value}" />
            </p>
        
            <h:commandButton value="Submit form" action="#{viewScopedBean.doAction}" />
        </h:form>
    </h:body>
</html>

and the following bean:

@ViewScoped
@ManagedBean
public class ViewScopedBean {

    private Date date = new Date();
    private UIComponent component;
    private int postbackCount;
    
    private String value;

    public String doAction() {
        value = String.format("Postback: '%d' -- Bean created at: '%s' -- Component id: '%s'  -- Bean class id: '%s'",
            ++postbackCount,
            date,
            component.getClientId(),
            this
        );
                
        return null;
    }

    public UIComponent getComponent() {
        return component;
    }

    public void setComponent(UIComponent component) {
        this.component = component;
    }
    
    public String getValue() {
        return value;
    }
    
}

After the first postback I got:

test component

Output from bean: Postback: '1' -- Bean created at: 'Sun May 19 14:32:55 CEST 2013' -- Component id: 'form:test' -- Bean class id: 'beans.ViewScopedBean@552f82fe'

After the second:

test component

Output from bean: Postback: '2' -- Bean created at: 'Sun May 19 14:32:55 CEST 2013' -- Component id: 'form:test' -- Bean class id: 'beans.ViewScopedBean@552f82fe'

etc.

I also tried with the new JSF 2.2 CDI view scope and an @Named bean and there it also worked; after every postback the bean instance remains the same one and the counter correctly increases.





[JAVASERVERFACES_SPEC_PUBLIC-928] @ViewScoped fails when JSTL c:forEach or c:if is used in view Created: 31/Jan/11  Updated: 01/Jul/13  Resolved: 01/Jul/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

A @ViewScoped bean will behave like a @RequestScoped bean when JSTL c:forEach or
c:if tag is been used in the view. I.e. it will be recreated on every request.

I can't find any line in the JSF specification if this is intentional or not.



 Comments   
Comment by Hanspeter Duennenberger [ 18/Apr/11 ]

I think http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-787 would solve this too.

Comment by dwightd [ 22/Feb/13 ]

This problem appears to be fixed in 2.1.18, at least in my environment (with ICEfaces 3.2). It was still broken in 2.1.17. Looking over the fixes in 2.1.18, it might be that http://java.net/jira/browse/JAVASERVERFACES-2688 fixed it, although I'm guessing somewhat. (I have a limited understanding of the cause and possible fixes!)

This also seems related to http://java.net/jira/browse/JAVASERVERFACES-1492





[JAVASERVERFACES_SPEC_PUBLIC-921] FacesMessage.Severity is not Serializable Created: 20/Jan/11  Updated: 01/Aug/14  Resolved: 17/Dec/13

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

Type: Bug Priority: Major
Reporter: tedgoddard Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_medium

Tags: 3_1-exclude

 Description   

FacesMessage is Serializable, but FacesMessage typically contain a FacesMessage.Severity instance which is
not Serializable.



 Comments   
Comment by ramiromagalhaes [ 14/Apr/11 ]

This is a duplication of JAVASERVERFACES_SPEC_PUBLIC-912.

Comment by Ed Burns [ 17/Dec/13 ]

Duplicates JAVASERVERFACES_SPEC_PUBLIC-912.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-917] add a JUnit test to make sure that classes implementing FacesWrapper do wrap all public and protected methods of the wrapped class Created: 23/Dec/10  Updated: 01/Aug/14  Resolved: 19/May/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.1
Fix Version/s: 2.1, 2.2

Type: Task Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Hanspeter Duennenberger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File spec-917-FacesWrapper-testcase-ready-for-commit.patch     Text File spec-917-FacesWrapper-testcase-with-docs.patch     Text File spec-917-FacesWrapper-testcase.patch    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-914 add ResourceWrapper#getContentType() ... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-938 PartialViewContextWrapper is missing ... Closed

 Description   

Often it gets forgotten to change the wrapper classes whe a method is changed or added to the wrapped class. This can result in unexpected behavior.

Therfore I developed the attached JUnit test to scan all classes implementing FacesWrapper and make sure the wrappers do wrap all public and protected methods of the wrapped class.

On the current 2.1.0 development stage as of 23. dec 2010, the following missing wrapper methods where detected:

ResourceWrapper:

  • getContentType()
  • getLibraryName()
  • getResourceName()
  • setContentType(String)
  • setLibraryName(String)
  • setResourceName(String)

ExternalContextWrapper:

  • getSessionMaxInactiveInterval()
  • isSecure()
  • setSessionMaxInactiveInterval()

PartialViewContextWrapper

  • setPartialRequest(boolean)

Since the above methods would cause API change and 2.1 closed, this has to be planned for 2.2.

See also attached patch file providing the FacesWrapperTestCase and the minimal change for the wrapper classes.



 Comments   
Comment by Hanspeter Duennenberger [ 23/Dec/10 ]

914 is related, but this one goes the full way to make sure wrappers do wrap all methods.

Comment by Ed Burns [ 20/Jan/11 ]

Make this a task.

Comment by Hanspeter Duennenberger [ 15/Feb/11 ]

Hi Ed,

I'd like to contribute that - please review patches and let me commit these changes.
While updating on this issue I also fixed some missing/wrong javadocs on ExteralContextWrapper - see latest attachement.

regards
Hanspeter

Comment by Hanspeter Duennenberger [ 03/May/11 ]

Hi Ed,

just updated the patch to also include the build.xml changes to run the FacesWrapperTestCase.

I was able to run "ant clean main test.with.container.refresh" with no error. Please review the patch or let someone test it so I can commit the changes.

Since these changes also affect the TCK for JSF 2.2, how are the changes sent to the TCK developers?

regards
Hanspeter

Comment by i_oss [ 03/May/11 ]

Hi Hanspeter,
nice solution!!!

Ed: maybe you want to add this one: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-938 as a duplicate or "going to be fixed by this" .

Thank you,
Imre

Comment by Ed Burns [ 10/May/11 ]

I like this. r=edburns.

This is the first change to any class in package javax.faces.application in JSF 2.2. Therefore, make sure to modify javax/faces/application/package.html to include changed_modified_2_2 in the span there where the rest of the changes are flagged.

Please commit to trunk when the extenal hudson jobs for trunk are all clean <http://hudson.glassfish.org/view/JSF%20Mojarra/>.

Comment by Hanspeter Duennenberger [ 17/May/11 ]

updated patch with changed_added_2_2/changed_modified_2_2 markers

Comment by Hanspeter Duennenberger [ 19/May/11 ]

Added FacesWrapperTestCase to ensure wraper classes do wrap all the public/protected methods of the wrapped class.
By adding this test missing wrapper methods on 3 existing wrappers where detected:

javax.faces.application.ResourceWrapper:

  • getContentType()
  • getLibraryName()
  • getResourceName()
  • setContentType(String)
  • setLibraryName(String)
  • setResourceName(String)
    javax.faces.context.ExternalContextWrapper:
  • getSessionMaxInactiveInterval()
  • isSecure()
  • setSessionMaxInactiveInterval()
    javax.faces.context.PartialViewContextWrapper
  • setPartialRequest(boolean)

r=edburns

SECTION: Modified files

M jsf-api/build.xml
M jsf-api/build-source.xml
M jsf-api/src/main/java/javax/faces/application/package.html
M jsf-api/src/main/java/javax/faces/application/ResourceWrapper.java
M jsf-api/src/main/java/javax/faces/context/ExternalContextWrapper.java
M jsf-api/src/main/java/javax/faces/context/package.html
M jsf-api/src/main/java/javax/faces/context/PartialViewContextWrapper.java
A jsf-api/src/test/java/javax/faces/context/FacesWrapperTestCase.java

Comment by Hanspeter Duennenberger [ 19/May/11 ]

Patch created immediately before commit.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-915] Add non-normative text that documents the need for users to be aware of HTTP methods other than GET or POST. Created: 06/Dec/10  Updated: 01/Aug/14  Resolved: 14/Jun/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.2

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1015 Inform about exposed view source when... Closed
Status Whiteboard:

size_small importance_small

Tags: 3_1-exclude

 Description   

Add normative text that advises users that the JSF spec only requires the web app support GET and POST. If you don't need other HTTP methods, it is advisable to restrict the web.xml to only support GET and POST.



 Comments   
Comment by Ed Burns [ 14/Jun/11 ]

Sending jsf-api/src/main/java/javax/faces/webapp/FacesServlet.java
Sending jsf-api/src/main/java/javax/faces/webapp/package.html
Transmitting file data ..
Committed revision 9164.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-914] add ResourceWrapper#getContentType() or define resource behaviour for null values Created: 30/Nov/10  Updated: 01/Aug/14  Resolved: 19/May/11

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

Type: Improvement Priority: Major
Reporter: Mark Struberg Assignee: Hanspeter Duennenberger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-917 add a JUnit test to make sure that cl... Closed
Status Whiteboard:

size_medium importance_medium

Tags: 3_1-exclude

 Description   

Component libraries which use the ResouceWrapper but do not explicitely override Resource#getContentType() will cause an undefined content Type (aka null).

So we either also provide delegation for this method in ResourceWrapper() or we define that the resource handler implementation must use the external context to determine the default contentType to use as fallback.



 Comments   
Comment by rogerk [ 30/Nov/10 ]

I would prefer to go the route of providing delegation in ResourceWrapper - see: http://java.net/jira/browse/JAVASERVERFACES-1879
However, this may be classified as a spec change and therefore we may not be able to get it into 2.1 (but let's see). To speed things up, can you provide a patch for the implementation workaround option?

Comment by rogerk [ 01/Dec/10 ]

Assign

Comment by rogerk [ 01/Dec/10 ]

Need to defer to 2.2 since this is a spec change.

Comment by Hanspeter Duennenberger [ 07/Dec/10 ]

The patch is attached to http://java.net/jira/browse/JAVASERVERFACES-1879

Comment by Ed Burns [ 08/Dec/10 ]

This should be done for 2.2

Comment by rogerk [ 18/Jan/11 ]

triage

Comment by Hanspeter Duennenberger [ 19/May/11 ]

This issue was resolved by JAVASERVERFACES_SPEC_PUBLIC-917

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-905] Invoke @PreDestroy on ViewScoped ManagedBeans upon session expiration Created: 02/Nov/10  Updated: 29/Nov/12  Resolved: 26/Oct/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Managed Beans
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: jack_van_ooststroom Assignee: Ed Burns
Resolution: Fixed Votes: 8
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 4 hours, 34 minutes
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive 20121025-1757-i_spec_905-mods.zip     Text File 20121026-0924-i_spec_905.patch    
Issue Links:
Dependency
depends on JAVASERVERFACES-2560 move formOmittedTrinidad testcase fro... Closed
blocks JAVASERVERFACES-2620 Verify that @PreDestroy on @javax.fac... Closed
blocks JAVASERVERFACES-2561 Implement requirements for @PreDestro... Closed
Issuezilla Id: 905
Status Whiteboard:

size_large importance_small


 Description   

When session expiration occurs it would be nice if the @PreDestroy of ViewScoped
ManagedBeans gets invoked.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1839



 Comments   
Comment by Ed Burns [ 03/Nov/10 ]

triage

Comment by ssilvert [ 24/Oct/12 ]

Hi Ed,

Do you think this will be fixed in 2.2? I'm seeing more complaints about it.

Stan

Comment by Ed Burns [ 24/Oct/12 ]

I can commit to making sure it works for the new javax.faces.flow.ViewScoped managed beans, which is based on CDI.

I will also investigate what it will take to make it work for the non-CDI based ones as well.

Thanks for bringing my attention to it.

Comment by Ed Burns [ 24/Oct/12 ]

testcase showing problem

Comment by Ed Burns [ 25/Oct/12 ]

This one is proving very tricky due to the many points in time and different scenarios where sessions can be invalidated. The fix for this must be very closely scrutinized, and, more importantly, must pass all the automated tests.

Comment by Ed Burns [ 25/Oct/12 ]

Mojarra changes.

Comment by ssilvert [ 26/Oct/12 ]

We're also getting reports of memory leaks with view-scoped beans. I've verified the leak, but not traced its exact cause. I'm assuming that the leak is related to this issue.

Any opinion on that or insight into how the instances are referenced? I'm assuming that if view-scoped beans aren't eligible for GC when the session ends then they must be tied to application scope or to a ThreadLocal. Any other possibilities?

Comment by Ed Burns [ 26/Oct/12 ]

See JAVASERVERFACES-2561 for implementation.





[JAVASERVERFACES_SPEC_PUBLIC-901] Deprecate "targets" concept Created: 29/Oct/10  Updated: 01/Aug/14  Resolved: 21/Jul/11

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Won't Fix Votes: 10
Labels: None
Σ Remaining Estimate: 0 minutes Remaining Estimate: 0 minutes
Σ Time Spent: 42 minutes Time Spent: 42 minutes
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File i_spec_901.patch     Zip Archive JAVASERVERFACES_SPEC_PUBLIC-901.zip     Text File jsf-spec-901-prototype-including-systest.patch    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-755 passing through of actionListener, ac... Open
is related to JAVASERVERFACES-3121 Migrate test for spec issue 901 to te... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-755 passing through of actionListener, ac... Sub-task Open  
Issuezilla Id: 901
Status Whiteboard:

size_large importance_large draft


 Description   

The "targets" attribute, present on several elements in the <cc:interface> section, is a blemish on the
purity of the interface declaration. It introduces a touch of implementation detail to the <cc:interface>
section. The "targets" attribute conceptually pushes information from the interface into the
implementation.

A less architecturally offensive solution is to make it so the implementation pulls this information from
the interface section.



 Comments   
Comment by Ed Burns [ 29/Oct/10 ]

Target 2.2

Comment by Jakob Korherr [ 01/Nov/10 ]

Created an attachment (id=333)
Prototype for implementsActionSource,... including systest for actionSource and editableValueHolder

Comment by Jakob Korherr [ 01/Nov/10 ]

I added a prototype-patch for this issue that adds the following tags:

  • cc:implementsActionSource
  • cc:implementsEditableValueHolder
  • cc:implementsValueHolder
  • cc:insertClientBehavior

In addition, the patch contains a systest for cc:implementsActionSource and
cc:implementsEditableValueHolder.

Everything works great and it really felt good writing the tests with these new
tags.

One thing did not work though: f:ajax. It seems that it has some hack for
composite components which uses the targets attribute of cc:clientBehavior. Did
not jump into deep here, but "normal" client behaviors are working.

Frankly, I would really like to see some of this in JSF 2.1. If necessary, I can
provide more systests.

Comment by kellerapps [ 18/Apr/11 ]

Without targets=, how does one route composite component attrs like ValueChangeListener & validators to an impl component?

Comment by Jakob Korherr [ 18/Apr/11 ]

via special tags as children of the target component(s). just see the above post..

Comment by Ed Burns [ 02/Jun/11 ]

LU> To be more explicit, this is the example that should fail:

LU> <ez:loginPanel id="loginPanel" model="#

{bean}

">
LU> <f:actionListener for="loginEvent"
LU> binding="#

{bean.loginEventListener}

" />
LU> <f:actionListener for="loginEvent"
LU> binding="#

{bean.loginEventListener2}

" />
LU> <f:actionListener for="cancelEvent"
LU> binding="#

{bean.cancelEventListener}

" />
LU> </ez:loginPanel>

LU> <composite:interface name="loginPanel">
LU> <composite:actionSource name="loginEvent" />
LU> <composite:actionSource name="cancelEvent" />
LU> </composite:interface>
LU> <composite:implementation>
LU> <h:commandButton name="button1">
LU> <f:actionListener
LU> binding="#

{cc.actionSource.loginEvent}

"/>
LU> </h:commandButton>
LU> <x:mycompositecomponent name="button2">
LU> <f:actionListener
LU> binding="#

{cc.actionSource.cancelEvent}

" for="someOtherEvent"/>
LU> </x:mycompositecomponent>
LU> </composite:implementation>

Comment by Ed Burns [ 02/Jun/11 ]
Comment by Ed Burns [ 21/Jul/11 ]

Due to lack of reply to my message about this issue on 2 June 2011 <http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-06/message/1> I am closing this issue and stating that the only real problem is JAVASERVERFACES_SPEC_PUBLIC-755.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-898] Please, one "upload file" component in standard. Created: 23/Oct/10  Updated: 01/Aug/14  Resolved: 31/Jan/11

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

Type: New Feature Priority: Blocker
Reporter: angelcervera Assignee: rogerk
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 898
Status Whiteboard:

size_medium importance_large


 Description   

All developers go on crazy when need upload files using JSF.
Each JSF implementation uses her own component, breaking portability in
applications.
Why is not this common component included in standard? Are there problems with
multipart request? Ok, is not this place and moment to find a solution?

Thanks a lot.



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 31/Jan/11 ]

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-802

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-895] Add new FacesMessage Severity "SUCCESS" Created: 14/Oct/10  Updated: 01/Aug/14  Resolved: 14/Oct/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: domdorn Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 895

 Description   

FacesMessages do have a specific severity.
However, those messages are currently only designed for
failures or general notices. There's currently no way
to specify a severity for "SUCCESS" events, but programmers are facing that
problem every day and miss-use INFO or other severities for such a purpose.

I propose adding a new severity "SUCCESS" that will be accessible
through
FacesMessage.SEVERITY_SUCCESS.
Also adding required attributes to h:messages and h:message:
successClass, successStyle.



 Comments   
Comment by Ed Burns [ 14/Oct/10 ]

I like this idea. If you could submit a patch, that would make it easier to get
it into 2.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-890] Give the ability to change the scope of <f:loadBundle> to ease its use in composites. Created: 26/Sep/10  Updated: 01/Aug/14  Resolved: 17/Dec/13

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

Type: Improvement Priority: Major
Reporter: grunt2000 Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 890
Status Whiteboard:

size_medium importance_small


 Description   

When you have a page using these composites:
<myTools:a/>
<myTools:b/>
<myTools:c/>

and that these composites use a resource bundle by the mean of <f:loadBundle>
for their own work, you have to take care of using a unique variable for each of
them.

If you attempt to ease your coding by using the same variable each time in all
your composites, such as here (using x):
<html xmlns="http://www.w3.org/1999/xhtml" [...]>
</cc:interface/>

<cc:implementation>
<f:loadBundle basename="myWork_a" var="x" />
...

Then <myTools:a/>, <myTools:b/>, and <myTools:c/> will use the same bundle,
whatever their own basename is saying. (I don't remember if only the basename of
the myWork_a bundle will be used or only myWork_c).

Then, we have to find unique variables one to ensure our composite won't have
bundle variables that could collide. Like:
<f:loadBundle basename="myWork_a" var="xa" /> for component a,
<f:loadBundle basename="myWork_b" var="xb" /> for component b,
<f:loadBundle basename="myWork_c" var="xc" /> for component c.

and of course, it's a bit boring. The problem comes from <f:loadBundle> that has
a request scope, I think. Can something be done to allow it having only the
strict composite scope (= no scope at all?).

Regards,

Grunt.



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 17/Dec/13 ]

<f:loadBundle> is not the recommended way to perform I18N in JSF. Instead, use application level config in the faces-config.xml.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-887] Allow locale fallback with resource loading Created: 17/Sep/10  Updated: 01/Aug/14  Resolved: 19/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: cayhorstmann Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 887
Status Whiteboard:

size_medium importance_medium


 Description   

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=548
describes that the current attempt at providing localizable resources is
irretrievably broken.

In addition to the issues noted in issue 548, note that the proposed scheme
doesn't play nicely with versioning. If someone versions a library, that
particular library version may have support for different locales. That is, the
library version should be resolved first, then the locale.

Here is a proposed enhancement (which depends on the implementation of
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=885).

In 2.6.1.3, allow resource identifiers of the form

[libraryName/][libraryVersion/][locale/]resourceName[/resourceVersion]

where locale is a regex of the form [A-Za-z]

{2}(_[A-Za-z]{2}

(_[A-Za-z]+)?)?

In 2.6.1.4 function deriveResourceId, require inspection of the directories

libraryName/language_locale_variant
libraryName/language_locale
libraryName/language
libraryName

for locating a resource, in the case that localePrefix is null.

This behavior is what people would expect from a Java SE ResourceBundle.

Note that this is a compatible change. Anyone who wants the old behavior simply
adds a ResourceHandler.LOCALE_PREFIX to the application's message bundle. Anyone
who wants the new behavior doesn't do that but instead adds locale directories.
If someone does neither, there is no change in behavior.



 Comments   
Comment by Ed Burns [ 26/Oct/10 ]

2.2

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 19/Dec/13 ]

We've done all we plan to do on this issue in 2.2.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-886] Allow hierarchical resource library names Created: 17/Sep/10  Updated: 01/Aug/14  Resolved: 19/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: cayhorstmann Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 886
Status Whiteboard:

size_medium importance_medium


 Description   

The spec is a bit unclear about this, but it appears that hierarchical resource
library names are not supported. It is desirable to support them for two reasons.

1) It allows developers greater flexibility in structuring their resources and
composite components
2) It allows for longer package names with backing components for composite
components.

(NB. Mojarra will load hierarchical names such as components/util.)

Two changes are required.

1) In section 2.6.1.3, add a bullet that a libraryName is a /-separated sequence
of libraryDirname. If
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=884 is
adopted, specify that each libraryDirname must not match the regexes for
versions or locales.

2) In
https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Application.html#createComponent(javax.faces.context.FacesContext,%20javax.faces.application.Resource),
change

let fqcn be library-name + "." + resource-name

to

let fqcn be library-name.replace("/", ".") + "." + resource-name



 Comments   
Comment by cayhorstmann [ 17/Sep/10 ]

Changed to Enhancement

Comment by cayhorstmann [ 17/Sep/10 ]

That's
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=885, not
884 in part 1).

Comment by Ed Burns [ 26/Oct/10 ]

2.2

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-860] com.sun.faces literal string value in public FaceletContext public API Created: 29/Jun/10  Updated: 12/Aug/14  Resolved: 12/Aug/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 860
Status Whiteboard:

size_small importance_small


 Description   

public abstract class FaceletContext extends ELContext {

// The key in the FacesContext attribute map
// for the FaceletContext instance.
public static final String FACELET_CONTEXT_KEY =
"com.sun.faces.facelets.FACELET_CONTEXT";



 Comments   
Comment by Ed Burns [ 29/Jun/10 ]

triage

Andy suggested a typesafe utility method.

I think that's too big for now, so I'll settle for just changing the value of the string and specifying that the
old value must be supported as well.

Comment by Ed Burns [ 30/Aug/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-859] Composite components only support one action attribute Created: 28/Jun/10  Updated: 01/Aug/14  Resolved: 28/Oct/10

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

Type: Bug Priority: Blocker
Reporter: michael_kurz Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 859-cc-attribute-methodType.patch     Text File changebundle.txt     Zip Archive composite-component-targets-test-3.zip     File composite-component-targets-test.war    
Issuezilla Id: 859
Status Whiteboard:

size_medium importance_large


 Description   

As far as I have seen there is no way to make a composite component properly
support more than one action (actionListener...) attribute. While the
re-targeting works fine for one action attribute, it is not possible to have two
action sources with two independant action attributes.

Here is a very simple and not so uncommon example of what I mean:

<cc:interface>
<cc:attribute name="submitAction" targets="submitButton"/>
<cc:attribute name="cancelAction" targets="cancelButton"/>
<cc:actionSource name="submitButton"/>
<cc:actionSource name="cancelButton"/>
</cc:interface>

The attributes are not handled completely (can be a string or a method
expression) as they are not named action.

One solution for this problem might be to have a targetName attribute:

<cc:interface>
<cc:attribute name="submitAction" targets="submitButton" targetName="action"/>
<cc:attribute name="cancelAction" targets="cancelButton" targetName="action"/>
<cc:actionSource name="submitButton" targets="myForm:submitBtnId"/>
<cc:actionSource name="cancelButton" targets="myForm:cancelBtnId"/>
</cc:interface>



 Comments   
Comment by rogerk [ 28/Jun/10 ]

triage

Comment by rogerk [ 07/Jul/10 ]

retarget

Comment by rogerk [ 26/Aug/10 ]

triage

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=326)
Patch proposed adding cc:attribute methodType property (prefer that name than targetName)

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=327)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=328)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by ganeshpuri [ 27/Oct/10 ]

From JSR-314-open:

2010/10/27 Ganesh <ganesh@j4fry.org>
G> Can you please give a use case for multiple method signatures?
G> The use cases that come to my mind would work fine with:

G> <cc:attribute name="testAction" method-signature="String method()" />

LU> "action" could receive the following signatures:
LU> String method()
LU> Object method()
LU> void method()
LU>
LU> Really the most clear case is "actionListener":
LU>
LU> void method(javax.faces.event.ActionEvent )
LU> void method()
LU>

Comment by ganeshpuri [ 27/Oct/10 ]

In which case would you need an actionListener with the signature "void
method()"? Wouldn't you always pass this parameter to UICommand thus requiring
the signature "void method(javax.faces.event.ActionEvent )"?

Same for action: Why do you propose allowing signatures "Object method()" and
"void method()" though the underlying UICommand will definitely require "String
method()"?

Comment by michael_kurz [ 28/Oct/10 ]

Please keep in mind, that an action attribute is not necessarily a method
expression but can also be an outcome String.

I prefer targetName over methodType as it takes in fact the name of the
attribute for re-targeting.

Comment by Ed Burns [ 28/Oct/10 ]

take ownership

Comment by Ed Burns [ 28/Oct/10 ]

Thanks so much for submitting a patch, Leonardo. I looked at your patch and ended up writing my own
which turned out to be very similar.

Please review it. Not that my patch also includes an automated test, which is, in fact, required to be a
good citizen committer to Mojarra.

Comment by Ed Burns [ 28/Oct/10 ]

Created an attachment (id=329)
Alternat patch, includes spec language, feature, and automated test

Comment by Ed Burns [ 28/Oct/10 ]

>>>>> On Thu, 28 Oct 2010 12:11:52 +0200, Jakob Korherr <jakob.korherr@irian.at>
said:

JK> The patch looks very good, however I don't really like the idea of
JK> pushing the "target-approach". By reasons explained on the
JK> jsr-314-open list it is much easier for the user to refer from the
JK> implementation to the interface via #

{cc.attrs.submitAction}

or
JK> #

{cc.attrs.cancelAction}

.

Yes, and this is the crux of issue 755. I do not feel the two are mutually
exclusive.

Comment by Ed Burns [ 28/Oct/10 ]

Committed revision 8688.

Comment by Ed Burns [ 28/Oct/10 ]

Marking fixed.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-802] Ajax fileupload capabilities Created: 17/May/10  Updated: 23/Dec/13  Resolved: 30/Apr/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Critical
Reporter: werpu12 Assignee: Ed Burns
Resolution: Fixed Votes: 10
Labels: None
Remaining Estimate: 6 days, 8 hours, 3 minutes
Time Spent: 15 hours, 57 minutes
Original Estimate: 1 week
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File 20110613-i_spec_802_mods.txt     Text File 20111208-i_spec_802-mods.patch     File 20121102-werpu-AjaxFileupload.odt    
Issue Links:
Dependency
depends on GLASSFISH-16740 Unable to get "multipart/form-data" r... Resolved
depends on JAVASERVERFACES_SPEC_PUBLIC-149 Provide way to discover the JSF spec ... Closed
blocks JAVASERVERFACES-2573 Implement "ajax" file upload Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1197 Support multiple attribute on h:input... Open
is related to JAVASERVERFACES-3122 Migrate test for spec issue #802 to t... Closed
Issuezilla Id: 802
Status Whiteboard:

size_medium importance_large draft

Tags: adf

 Description   

The main issue with the current implementation is, that fileupload the ajax way
is not working properly.

The problem simply is, that fileupload component and multipart form requests
both are a second class citizen in the JEE world and html generally.
There is no way to submit a fileupload via ajax currently, however there is an
iframe based method to do it.

But for that an iframe transport layer is missing, since the current spec only
talks abut queued asynchronous xhr requests.

see http://www.openjs.com/articles/ajax/ajax_file_upload/

for more information....



 Comments   
Comment by Ed Burns [ 24/May/10 ]

New features, 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 08/Jun/10 ]

Comments from issue 647 Note that from a spec perspective, I believe that the main issue is that
jsf.ajax.response() expects a XHR
object, which it uses to grab the responseXML. However, XHR cannot be used in the multi-part form case
(requires iframe-based postback), and as such no XHR object is available to pass off to jsf.ajax.response().

Comment by Ed Burns [ 08/Jun/10 ]
      • Issue 647 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 08/Jun/10 ]

adf keyword

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 30/Jun/10 ]

triage - Folks have been asking for this.

Comment by ganeshpuri [ 30/Jun/10 ]

would be great to be able to do AJAX uploads with 2.1

Comment by werpu12 [ 09/Jul/10 ]

Ok I am doing some prototyping on this issue within the realms of myfaces (since
I am not allowed to do that for Mojarra)
So far I have something preliminary up and running which has yet to be committed
which pushes the current lifecycle over iframes insteas of xhr. However I found
something in the spec which is some sort of a blocker. The spec requires for a
valid ajax request that Faces-Request:partial/ajax is set in the request header.
I do not think you can tamper on form level (which in fact the iframe solution
is) with that. The result of leaving it out is that the impl thinks this is not
an ajax request and then renders the full page instead of the response xml.

I am going to investigate further if setting the request header is possible on
the iframe solution. Otherwise we have to revamp the spec here a little bit.

Comment by werpu12 [ 14/Jul/10 ]

Ok the issue with the current specification in the ajax dection and triggering
of the partial mechanisms is following. I was able to patch the
PartialViewHandler up so that the entire lifecycle works with the iframe transport.

The problem really is we currently have two mechanisms, one identifying that it
is a partial request, the other one, that it is an Ajax request.
Both work over request headers, for the iframe case we have to weaken the spec
here a little bit to allow the same over
request parameters, since there seems to be no way to submit a new header param
via a normal form submit.

The idea is following, introduce a third type, iframe request, and allow both
ajax request, iframe request and partial request also be submitted over simple
request parameters instead of header params (so both type of values can trigger
a valid partial lifecycle a request header parameter or a normal request parameter)
Once a valid iframe request can trigger the partial lifecycle everything else
behaves just as it would in the xhr case (for the server both usecases are just
post requests)

As for the proposed mechanism. My personal idea is to enqueue an iframe request
just like we would a normal xhr post request in our asynchronous queue and just
treat it from outside like we we an xhr request. I have this running for most
browsers already I just have a sync issue for heavy load on IE6, which I will
investigate later into, but the pattern looks good to me that it might be
implementable.

(see the preliminary snapshot code here http://www.pastebin.org/396667 and
http://www.pastebin.org/396646 from my myfaces based prototype)
The reason for this is synchronisation issues which the queue eliminates.

As how and when we trigger the mechanism is a little bit unclear to me still, my
personal guess is that an auto switch between xhr and iframe in case of an
embedded executed fileupload might make the most sense to keep the api simple),
I will try to find out more once my prototype can finally do the fileupload.

Comment by Ed Burns [ 28/Jul/10 ]

Please make sure to look at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?
id=690

Comment by Ed Burns [ 28/Jul/10 ]

Also make sure to look at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=861

Comment by Ed Burns [ 29/Jul/10 ]

Werner suggests the attribute set for t:inputFileUpload as a guide

http://www.jsftoolbox.com/documentation/tomahawk/09-TagReference/tomahawk-inputFileUpload.html

Comment by Ed Burns [ 02/Sep/10 ]

Even though Werner has done most of the preparatory work on this issue, I still have to move it to JSF
2.2.

Comment by markcolletteice [ 14/Apr/11 ]

In ICEfaces ACE, the fileEntry component uses the [hidden] iframe technique. We have to fake out the partial/ajax request, as well as extract the uploaded file(s) and translate the multi-part request to not be multi-part, so that JSF will run. And then in the browser, when handling the response, we have to fake out the XHR response object, using what we get from the iframe response, so that page updates will be handled.

It would be nice to collaborate on moving parts of this into JSF, so that everyone's different file upload components could be built on a common infrastructure.

One critical issue to us is that we don't follow the pattern of simply sticking the file contents into a temporary byte[] or file, like the other component frameworks do. We allow for either directly writing the file to the end file-system destination that the application specified, or using a callback interface for chunking the file data, without buffering the whole file, to the application, so that it can virus scan the file contents, or re-transmit it to another server via a socket, or write it to a database. So, we'd like the file processing to be custom for the component framework, that way we're not limited by a lowest common denominator handling of file data.

http://wiki.icefaces.org/display/ICE/FileEntry
http://www.icefaces.org/docs/v2_latest/ace/tld/ace/fileEntry.html
http://wiki.icefaces.org/display/ICE/Incremental+Upload+Processing+Using+FileEntryCallback

Comment by Neil Griffin [ 19/Apr/11 ]

I'm very happy to see that Ajax-based file upload is being discussed. But for the sake of completeness, I think that the old Web 1.0 multipart/form-data technique should be supported, as was discussed in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-690

In my comments there,mentioned that I implemented a solution in the PortletFaces Bridge. It's working quite nicely – no need for Servlet 3.0, no need for a filter. Everything works great. Making this work in a Servlet-based JSF like Mojarra should be a piece of cake.

Comment by tedgoddard [ 21/Apr/11 ]

The approach to resolving this should be to provide additional APIs that make it possible to plug different transports into the JSF request/response cycle:

  • allow a partial response to be requested without a custom HTTP header
  • support new HTML5/XMLHttpRequest features that include file parts
  • expose JSF form serialization to String as JavaScript API
  • ensure that jsf.ajax.response can easily be called by external code (context and jsfResponse do not seem to be entirely public parameters)
Comment by werpu12 [ 21/Apr/11 ]

Actually that is how we prototyped it for myfaces. We dont have an official api, but we have configuration options which allow to choose a certain transport type.

So you can define jsf.ajax.request with additional myfaces:

{transportType: "iframeRequest"}

etc.. options to force the system into an iframe request.

We also allow an auto transport option where the system changes from the default xhr level1 into iframe if a multipart file upload situation is detected.

The problem with xhr level3 simply is or was the last time I looked at it that most browsers issued multipart requests without length attributes which rendered most fileupload libraries useless (and broke one of the two related specs in that area)
so an auto fallback to xhr level3 is definitely given the state of affairs a no go.

But as I see it xhr level3 is a good option if you can support it properly because it also allows some kind of progress notification so if this issue is started we also should opt for xhr level3 optionally.

The http header issue was another one. Currently the jsf ajax cycle is determined over custom http header, which is a no go in an iframe scenario because you only can send parameters, this needs to be fixed (and I did an internal fallback in myfaces to fix this but this is currently an implementation detail.

the jsf.ajax.response is another issue relatively unrelated, in myfaces we have some internal params which fix some internal issues, like how do you fix the issue of having an update and your original element is detached as well as its parent form. Those kind issues simply have to be taken care of in the official spec then I guess the jsf.ajax.response is really public.
I guess mojarra has 1-2 of those extra bugfix params as well.
But actually in case of myfaces I just got this bugreport in and it indeed is a bug in our impl because the call to the jsf.ajax.response should work without any extra params.

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 08/Dec/11 ]

Neil committed his version of the work to https://svn.java.net/svn/mojarra~svn/branches/FILE_UPLOAD

These are the files that differ from the state of the tree when he created that branch.

These files were committed in r9162.

Index: common/ant/dependencies.xml
Index: jsf-api/doc/file-props.xml
Index: jsf-api/doc/standard-html-renderkit-base.xml
Index: jsf-api/doc/standard-html-renderkit.xml
Index: jsf-api/src/main/java/javax/faces/component/UploadedFile.java
Index: jsf-ri/conf/share/html_basic.taglib.xml
Index: jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapMultiPartImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapFactory.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterValuesMapMultiPartImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlDecorator.java
Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlLibrary.java
Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/FileRenderer.java
Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/TextRenderer.java
Index: jsf-ri/src/main/java/com/sun/faces/component/UploadedFileImpl.java
Index: jsf-ri/src/main/resources/com/sun/faces/standard-html-renderkit-impl.xml

Comment by Ed Burns [ 08/Dec/11 ]

Notes from merging in Neil's work.

Comment by Ed Burns [ 08/Dec/11 ]

In progress patch.

Comment by Ed Burns [ 09/Dec/11 ]

muellermi
@edburns Will JSF's AJAX file upload offer functions to display progress? Or suport multi-file uploads?

Comment by werpu12 [ 09/Dec/11 ]

Progress is not possible with existing html means, XHR Level 2 in the long run will support it. Not sure if the spec can specifiy a progress event which if supported can be fired and if not does nothing except to go from 0 to 100, it would make sense. Same I think goes for multiple file uploads.
(Cannot remember if the existing iframe method supports multiple file uploads)

Comment by Ed Burns [ 16/Dec/11 ]

Move to Sprint 10, but at leas we have the non-Ajax portion committed.

Comment by Ed Burns [ 03/Feb/12 ]

Move to sprint 11

Comment by robweaver [ 13/Apr/12 ]

Just updated to 3.1.2 (Build 23) and the FileUpload on PrimeFaces broke (I think due to this issue).

Upload widget acts as if the upload is working, but never hits the back end event handler.

Reverting to 3.1 with no changes to WAR and the file upload works again.

Would be glad to help diagnose this issue.

Any target date for the fix, and is there a workaround ?

Comment by Ed Burns [ 13/Apr/12 ]

Hello robweaver,

Can I ask you please to file this in the GLASSFISH JIRA? I know some multipart upload changes were done in GlassFish 3.1.2 and t's quite possible this has nothing to do with Mojarra JSF implementation. At any rate, it certainly doesn't have anything to do with the spec.

http://java.net/jira/browse/GLASSFISH

Thanks,
Ed

Comment by robweaver [ 15/Apr/12 ]

Thanks, I thought I was entering it on the GlassFish issue, sorry see http://java.net/jira/browse/GLASSFISH-18444 which appears to be my issue.

Apologies for the incorrect entry.

Comment by rogerk [ 23/May/12 ]

There currently is a bug in the implementation - see: http://java.net/jira/browse/JAVASERVERFACES-2420. However, if the page author specifies a "value" attribute it should be rendered.

Comment by Ed Burns [ 15/Oct/12 ]

Werner prepared this document prior to a 60 minute Google+ hangout we had today. We edited the document during the meeting.

Comment by Ed Burns [ 16/Oct/12 ]

See < http://tim-vm9.us.oracle.com:7070/hudson/job/trunk-test-glassfish-4_0/442/ >.

Comment by Ed Burns [ 06/Nov/12 ]

Werner had some additional feedback.

Comment by arjan tijms [ 30/Apr/13 ]

As JSF 2.2 went final, shouldn't this issue be closed?

Comment by rogerk [ 30/Apr/13 ]

Fixed for 2.2

Comment by jid1 [ 03/Jun/13 ]

Did the "multiple" attribute make it into the spec?

Comment by Ed Burns [ 10/Jun/13 ]

Well, yes and no. I just tested it.

Here's the yes part.

You can say this:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
      xmlns:f="http://xmlns.jcp.org/jsf/core"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:p="http://xmlns.jcp.org/jsf/passthrough">
    <h:head></h:head>

    <h:form id="form" enctype="multipart/form-data" prependId="false">
        
        <p><h:inputFile id="file" value="#{fileUploadBean.uploadedFile}" p:multiple="multiple"> 
             <f:validator validatorId="FileValidator" />
           </h:inputFile>
        </p>
...

and it renders correctly:

        <p><input id="file" type="file" name="file" multiple="multiple" />

but the no part is that each of the files in the multiple list is overwritten when the next one is processed.

Comment by Ed Burns [ 10/Jun/13 ]

I have filed < https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1197 > to cover this. We'll get to it in 2.3.





[JAVASERVERFACES_SPEC_PUBLIC-791] composite:clientBehavior Not Documented In VDL Created: 10/May/10  Updated: 01/Aug/14  Resolved: 22/Oct/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 791
Status Whiteboard:

cat1 size_small importance_large


 Description   

There is a <composite:clientBehavior> tag in the 2.0 version of JSF that comes
with GlassFish, and it appears to work as advertised by Alexandr and Andy below.

But, as Alexandr points out, it’s not documented in the PDL docs, nor could I
find any mention of it in the spec (or Ed’s book, either).

This is a vital tag that lets page authors attach ajax functionality to
components within composite components. I see no reason why it should not be
documented.

Does anyone know why this tag was not documented in the first place, or what the
plans are for its future? Anyone know if it works with MyFaces 2.0?

If there’s not a compelling reason for blacklisting it from the docs, can we
document it?

Thanks,

david



 Comments   
Comment by Ed Burns [ 10/May/10 ]

cat1

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 28/May/10 ]

This is in the impl, but not in the spec. It should be in the spec, but because it is new behavior, it has to
wait until 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 ]

Move these to 2.2

Comment by Ed Burns [ 22/Oct/10 ]

Duplicate of issue 853

      • This issue has been marked as a duplicate of 853 ***
Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-787] Restore ViewScope before templates are processed with buildView Created: 23/Apr/10  Updated: 10/Dec/12  Resolved: 16/Aug/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Critical
Reporter: Hanspeter Duennenberger Assignee: Hanspeter Duennenberger
Resolution: Fixed Votes: 2
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle-787-workaround.txt     Text File changebundle.txt     Text File changebundle.txt     Text File JAVASERVERFACES_SPEC_PUBLIC-787-restore-ViewScope-before-buildView.patch     Zip Archive JAVASERVERFACES_SPEC_PUBLIC-787.zip    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1032 UIForm.createUniqueId() does not crea... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1034 disentangle ViewScope state handling ... Open
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-1034 disentangle ViewScope state handling ... Sub-task Open  
Issuezilla Id: 787
Status Whiteboard:

size_medium importance_large draft


 Description   

Restoring the view with partial state saving enabled, the state is attached to
the component tree after the view-definition is processed (aka the tree is built
from the template). But sometimes the application of the view-definition might
depend on state from the previous request. An example: we have a dialog system
which remembers across requests which dialog is active.

So, to be backwards compatible with JSF 1.2, we need a way to store this state
across requests - it can not be part of the component state, cause the component
state is applied too late.

Our solution - and also recommendation for the next version of the spec - is
that the ViewScope (or the complete state of the ViewRoot component, but
ViewScope is sufficient) is restored before buildView() is called. That would
allow components with dynamic behavior to keep state in the ViewScope.

best regards,

Martin and Hanspeter

=====================

Here what we do currently: we decorated ViewDeclarationLanguage.buildView like
this (ok, for simplification we restored complete ViewRoot state):

public void buildView(FacesContext context, UIViewRoot root) throws
IOException {

if(context.getCurrentPhaseId()== PhaseId.RESTORE_VIEW)

{ //restore the view-scope (part of the UIViewRoot state-saving process) //_before_ we run the templates RenderKit renderKit = context.getRenderKit(); ResponseStateManager rsm = renderKit.getResponseStateManager(); Object[] rawState = (Object[]) rsm.getState(context, root.getViewId()); //noinspection unchecked final Map<String, Object> state = (Map<String,Object>) rawState[1]; Object viewRootState = state.get(root.getClientId()); root.restoreState(context, viewRootState); }

delegate.buildView(context, root);
}



 Comments   
Comment by Ed Burns [ 19/May/10 ]

I talked to Martin and Hanspeter about this. I agree with restoring the ViewMap first, but I don't know
if it will be possible in practice. Marking as P2 to make sure we get to it.

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

Behavior change, move to 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Hanspeter Duennenberger [ 14/Nov/10 ]

Created an attachment (id=337)
Proposed patch to restore viewScpe before buildView

Comment by Hanspeter Duennenberger [ 14/Nov/10 ]

Hi Ed.

Finally I found some time to develop a patch for this. It works fine with CS JSF.
Please have a look at it (I hope you find some time for that .

regards
Hanspeter

Comment by Hanspeter Duennenberger [ 26/May/11 ]

taking ownership to develop patch for review and commit.

Comment by Hanspeter Duennenberger [ 07/Jun/11 ]

Hello.

This is a reworked patch to restore ViewScope before the templates are processed in buildView().

Until now the full state including ViewScope is restored in UIViewRoot.restoreState(). But this method must only be called after the templates have been processed. To allow restore of ViewScope before processing the templates, I introduced a new method called UIViewRoot.restoreViewScopeState(FacesContext fc, Object state) to restore ViewScope only. In UIViewRoot.restoreState(..) viewScope will only be restored if not done before.

I am aware that it seems weird that ViewScope is state saved in the normal UIViewRoot.saveState(..) method and restored with restoreViewScopeState(..). But for saving the state there was no need to change the behaviour unless we want to redesign this in more depth which would involve a pair of method to save/restore ViewScope.

We use this solution in CS JSF since about 1/2 year and it worked with partial- and full state saving.

regards
Hanspeter

Comment by Ed Burns [ 08/Jun/11 ]

This is a nice and simple patch. Naturally, I wonder if there is a root problem (no pun intended) not specific to just the UIViewRoot, where a component needs to have some state restored to it after the tree has been built from the template, but before the partial state restoration traversal. If the UIViewRoot has this problem, then perhaps other components may have it as well?

Do we need to generalize this or is it sufficient to handle the view scope alone?

Arguments in favor of accepting the special case approach directly from
Hanspeter's 20110607 patch.

1. The manner in which the pre-restoration-traversal state is obtained
is specific to the implementation of the component. Therefore, we
must own the implementation of the component. In the case of
UIViewRoot, we do. If we wanted to generalize it, we would need
additional API and the state management API is already too complex.

2. An other use-case for pre-restoration-traversal state is dynamic
components. However, these are handled specifically elsewhere in the
implementation.

3. The UIViewRoot is unique among all other components in that you don't
need a template to obtain a reference to it. This uniqueness
warrants special case API.

Arguments in favor of denying Hanspeter's 20110607 patch in favor of a
request for a more general solution.

1. The additional API required would not be that large. Here is a sketch.
Introduce a new ComponentSystemEvent: PreRestoreStateEvent. Modify
the contract of the existing UIComponent.processEvent() to handle
this event. Override it in the case of UIViewRoot to do the action
currently impleneted in Hanspeter's 20110607 patch.

Hanspeter, can you please cook up a version of the patch that uses the
PreRestoreStateEvent approach?

Comment by Ed Burns [ 08/Jun/11 ]

For what it's worth, all 2160 automated tests passed with this patch applied.

Comment by Hanspeter Duennenberger [ 08/Jun/11 ]

Hi Ed.

Interesting considerations and I really like more generalized solutions, but I think UIViewRoot is unique for this matter:

1. UIViewRoot is not created from templates and there is also no possibility to do special work in a UIViewRootTagHandler.

2. The state in question is the ViewScope - all other components don't have theyr own scope to restore.

3. PreRestoreStateEvent on the component would be about the same time as PostAddToViewEvent on the component. It's after component was constructed and added to the view but before restore state is processed - restore state is processed after the full component tree was built.

4. In my opinion there is no way to restore some component state before the component is created - and during component creation TagHandler may be used for such action or directly after component construction PostAddToView component event may be used.

5. PreRestoreStateEvent processing would probably cause another tree walk, which some of the EG members will not like.

Ed, I don't see the need for that elaboration.

Regards
Hanspeter

Comment by Ed Burns [ 08/Jun/11 ]

Ok, thanks for considering the alternate idea.

I'm r=edburns for adding this to the trunk.

Comment by Hanspeter Duennenberger [ 08/Jun/11 ]

final changebundle before commit

Comment by Ed Burns [ 09/Jun/11 ]

r=edburns. Please add the output from svn commit, including all the "Sending..." lines and the line containing the svn revision number to this issue.

Ed

Comment by Hanspeter Duennenberger [ 09/Jun/11 ]

Committed to trunk.

Sending jsf-api/src/main/java/javax/faces/component/UIViewRoot.java

Sending jsf-api/src/test/java/javax/faces/component/UIViewRootTestCase.java

Sending jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java

Transmitting file data ......

Committed revision 9139.

(had to reproduce this manually - next time I know)

Comment by Ed Burns [ 10/Jun/11 ]

Additional attribution and spec language

Comment by Ed Burns [ 10/Jun/11 ]

Sending jsf-api/src/main/java/javax/faces/component/UIViewRoot.java
Sending jsf-api/src/main/java/javax/faces/view/StateManagementStrategy.java
Sending jsf-api/src/main/java/javax/faces/view/package.html
Transmitting file data ...
Committed revision 9149.

Comment by Rinner23 [ 14/Jul/11 ]

Before I try a merge do you think this would be safe to work into 2.0.4b9? This would be a great feature for us as it would allow viewscope to be used instead of Session in some of our nasty dynamic components

Cheers!

Matt

Comment by Hanspeter Duennenberger [ 14/Jul/11 ]

Hi Matt,

we used that on our custom built JSF RI 2.0 before 2.0.4 without any problem. So you should be save doing the same.

regards
Hanspeter

Comment by Rinner23 [ 18/Jul/11 ]

Actually, this change does appear to have a problem on 2.0.4b9. After applying the patch, we do have the viewscope at the correct time, but for some reason we are seeing two PostAddToViewEvents being fired during RENDER_RESPONSE but only during the very first time the page is requested.

The second PostAddToViewEvent has the component in a bad state, with no children.

If I refresh the page, everything works as normal. The only way to cause the problem again is to bounce the server, and again on the first page refresh the additional PostAddToViewEvent is fired.

Matt

Comment by Rinner23 [ 26/Jul/11 ]

Any thoughts on this? I've tried looking through the source code, but I'm currently really too ignorant of the details of the system to figure out why this might happen...

I think it must be related to how the system deals with the templates for the first time, like when it compiles/caches(correct?) them or something its throwing that additional PostAddToViewEvent. I've confirmed that if I remove the code, the additional event goes away as expected.

To work around this, I'm serializing my object graph into a hidden input field and restoring on the decode() of my custom composite component (manually grabbing the value from request).

This seems to work, and allows us to then dynamically create our component tree during PostAddToView based on the data serialized in that field from request to request (which can change).

Thanks for any input on this!

Regards,

Matt

Comment by Hanspeter Duennenberger [ 26/Jul/11 ]

Hi Matt,
sorry, I did not have time to look into that.

The changes from this issue only affect restoreState in UIViewRoot and restoreView in StateManagementStrategyImpl - so I can hardly believe it affects the first time a page is rendered. I assume the double delivered PostAddToViewEvent is due to something else.

Debug into your PostAddToViewEvent handling will show where the event comes from. Make sure the second one is not from a resource request - which would explain why the component delivered by the event does not have any children or parent.

regards
Hanspeter

Comment by Rinner23 [ 26/Jul/11 ]

I did check this, and there are no resources being requested.. It is simply a custom composite component in an otherwise empty page. Now, I am registering for the PostAddToViewEvent inside my components constructor, not in any page backing bean.

It is strange, that when I revert the changes and re-compile the extra event goes away with the exact same page.

As noted above I'm still very new to this technology having come across from ASP.NET, but it does have some similarities and I am working hard to get a better understanding.

Thanks,

Matt

Comment by rogerk [ 27/Jul/11 ]

This patch breaks a fundamental dynamic components test. Here it is (and the exception):

Test Case: Simple View

<h:form prependId="false" id="dynamicForm">

<h:panelGroup id="group">
<h:commandButton value="Add Component" action="#

{testManagedBean.addComponent}

"/>
</h:panelGroup>

</h:form>

The action in the managed bean dynamically created an HTMLOutputText component and adds it as a child to the panelGroup ("group"):

public void addComponent()

{ FacesContext ctx = FacesContext.getCurrentInstance(); UIComponent group = ctx.getViewRoot().findComponent("dynamicForm" + UINamingContainer.getSeparatorChar(ctx) + "group"); HtmlOutputText output = new HtmlOutputText(); output.setValue("OUTPUT"); group.getChildren().add(output); }

The first button click adds it fine (after the button). The next button click produces the following exception:

java.lang.ClassCastException: com.sun.faces.application.view.StateHolderSaver cannot be cast to [Ljava.lang.Object;
at javax.faces.component.UIViewRoot.restoreViewScopeState(UIViewRoot.java:1693)
at com.sun.faces.application.view.StateManagementStrategyImpl.restoreView(StateManagementStrategyImpl.java:240)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:211)
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:452)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:148)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:635)

Comment by rogerk [ 27/Jul/11 ]

The problem is that dynamic components are saved as StateHolderSaver objects.
You can see that logic in StateManagementStrategyImpl class (saveView method).
And in UIViewRoot.restoreViewScopeState (line 1693) we are blindly casting that to Object[]..
So, in this case, the first button press creates the dynamic component and it is saved as
a StateHolderSaver.

Comment by rogerk [ 27/Jul/11 ]

Reopening as this has issues with dynamic components.

Comment by rogerk [ 27/Jul/11 ]

Changes for workaround.

Comment by rogerk [ 27/Jul/11 ]

I've committed the workaround to the trunk:
Sending jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java
Transmitting file data .
Committed revision 9226.

Comment by Hanspeter Duennenberger [ 28/Jul/11 ]

Hi Roger,

thanks for that update - but I think the workaround is really just a workaround. I wonder why the dynamically added component changes the state structure. In UIViewRoot.saveState() - the saved state is an Object array with size 2 - element 0 is assigned with super.saveState() and element 1 is storing the viewScope as attachedState. But in case of the dynamically added component that seems no longer true - so that would mean the dynamically added component corrupts the state structure on UIViewRoot level.

I'll try to reproduce that problem and analyse it - hope I find time for it.

regards
Hanspeter

Comment by rogerk [ 28/Jul/11 ]

I spoke incorrectly when I said dynamic components were saved as StateHolderSaver objects - obviously that is not true. StateHolderSaver is a helper class in Mojarra. During saveView, dynamic components are added to the state map as StateHolderSaver objects. You can see this in StateManagementStrategyImpl.saveView.
So StateHolderSaver is used to save/restore state for dynamic components.
In restoreView, dynamic components are handled after non-dynamic components. The state map will also contain StateHolderSaver objects (used for the restoration of dynamic components). So, at the time you call:
viewRoot.restoreViewScopeState(context, stateObj);
you cannot assume stateObj will always be the state object itself.

Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

Hi Ed and Roger.

I tried to reproduce the error with the example Roger has given - but was not able to reproduce the exact same problem. But I have realized that h:form prependId="false" may lead to duplicate id's - see http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1032.

Looking at what tree visitor does in StateManagementStrategyImpl.saveView I somewhat understood the problem - in case a certain component was added dynamically, it's state is packed into a StateHolderSaver. But to cause the problem that Roger has pointed out it would be necessary to dynamically add UIViewRoot - is that possible at all or are we hunting a phantom problem?

I think the problem Roger ran into was based on the problem that UIForm with prependId="false" generated an id for the dynamically added component that was the same as the UIViewRoot's id. Then of course the saveView() treeVisitor assumes UIViewRoot was added dynamically and wraps it's state within a StateHolderSaver - and voila - we have the problem. However, I was not able to reproduce that.

Big question: is it possible to have UIViewRoot as a dynamically added component?

I was not able to reproduce the problem - if Roger can reproduce it, please provide me exact information of how to reproduce.

Unfortunatley on my windows machine I cannot run test.with.container.refresh anymore ...

Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

Testcase I tried to reproduce the problem - no success so far.

Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

Finally with some help from Roger I was abler to reproduce the problem - but only after removing the patch for http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1032 UIForm.createUiqueId() which may produce non-unique clientId's in case prependId is false.

The dynamically added component is actually added to a panelGroup - and get's the clientId "j_id1" - which is the same as teh UIViewRoot's clientId. Now StateManagementStrategyImpl gets confused and handles UIViewRoot as a dynamically added component - and wraps it's state into a StateSaveHolder. And then next restoreState fails.

Comment by rogerk [ 15/Aug/11 ]

Tests ran successfully on my hosted machine.

r=rogerk

Comment by Hanspeter Duennenberger [ 16/Aug/11 ]

resolved as of JAVASERVERFACES_SPEC_PUBLIC-1032 - see there

Comment by Ed Burns [ 19/Oct/11 ]

Marking closed per most recent comments.

Comment by Ed Burns [ 06/Apr/12 ]

Sending jsf-api/src/main/java/javax/faces/component/UIViewParameter.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/config/processor/FaceletTaglibConfigProcessor.java
Transmitting file data ...
Committed revision 9814.

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1063 http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-787 http://java.net/jira/browse/JAVASERVERFACES-2369

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java

  • in restoreView(), note that the state map will never be null due to
    the assignment statement at the top of the method. Therefore, we
    shouldn't test for null to determine the presence or absence of a
    pre-existing state map.

M jsf-ri/src/main/java/com/sun/faces/config/processor/FaceletTaglibConfigProcessor.java

  • in createMethod(), replace one or more whitespace with a single whitespace.

M jsf-api/src/main/java/javax/faces/component/UIViewParameter.java

  • in getSubmittedValue(), remove unnecessary cast to String.
Comment by fabmars [ 24/Nov/12 ]

UIViewRoot#restoreViewScopeState isn't called from anywhere anymore.

Probably this has to do with the big rework/split of StateManagementStrategyImpl in http://java.net/jira/browse/JAVASERVERFACES-2373

Comment by Hanspeter Duennenberger [ 10/Dec/12 ]

After looking at the code on trunk I think UIViewRoot#restoreViewScopeState is no longer needed since ViewScope is now kept on session and only the viewScopeId becomes part of the View's state.
This last change came from http://java.net/jira/browse/JAVASERVERFACES-2561 and completely makes sense - only think remaining - the UIViewRoot#restoreViewScopeState method could be removed or at least made deprecated.

Comment by lu4242 [ 10/Dec/12 ]

I think UIViewRoot#restoreViewScopeState still has a lot of sense, and should not be marked as deprecated or removed, because it enforces the condition of restore the view scope state before restore the view state. If a side effect of ViewScope implementation is make this method not necessary, does not means that the method is not valid for other alternate implementations of ViewScope. In other words, it is not a good idea to rely on a implementation detail for something that should be enforced by spec.

Comment by Hanspeter Duennenberger [ 10/Dec/12 ]

Hi Leonardo,
you are right about the spec aspect. On the other hand there is no counterpart like saveViewScopeState() to complete the state handling for ViewScope. Also with support for CDI or other Scope Managers these methods might not really fit.
Currently it seems this restoreViewScopeState() method is a relict because it's never ever called in JSF RI.
That is what needs to be resolved - I don't mind if this method is no longer used as long as the handling of ViewScope is clearly specified - at least the fact that ViewScope must be present before buidView() is called. I just don't know now if that is still specified.
Best regards
Hanspeter

Comment by lu4242 [ 10/Dec/12 ]

Hi Hanspeter

Ok, I see. It is clear restoreViewScopeState() is necessary for jsf 2.0 view scope, because in this case, JSF stores the view scope with the view state, but the question is how is really handle scopes in CDI, or in other words, how CDI recognize a specific "context". For example, how CDI knows that a view scope is for an specific bean. Does it uses the viewId? a combination of the windowId/viewId? a generated identifier stored in UIViewRoot?. In my understanding, MyFaces CODI/Openwebbeans uses a combination of the windowId/viewId.

In my opinion, the flaw in the spec and the reason of the discussion over restoreViewScopeState() is more related to how JSF defines a "view context" and expose that information to the external context like CDI-JSF integration module or any other bean container. In the current design, CDI is responsible to handle the beans and all issues related to them (injection, serialization, ...), so JSF should not do operation to save / restore bean stated directly, and instead let CDI to do its magic under curtains.

So, what has sense here is enforce that any view scope or the "view context" should be defined before restore the view state, which means in PSS context, call vdl.buildView and apply the state to the created component tree.

In theory restoreViewScopeState() is not implemented directly by UIViewRoot, but it has sense to override UIViewRoot and implement it cases like portlets or even with plain CDI, because this method gives the chance to initialize the context properly, no matter which trick is used to define the "view context".

Note I don't know the details behind CDI-JSF integration, but with the current spec, I suppose/guess the intention is do something like that.

best regards,
Leonardo





[JAVASERVERFACES_SPEC_PUBLIC-784] Over-specification of component push/pop behavior Created: 12/Apr/10  Updated: 22/Mar/11  Resolved: 22/Mar/11

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

Type: Bug Priority: Major
Reporter: aschwart Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 784
Status Whiteboard:

adf adf_medium size_small importance_large


 Description   

UIComponent defines the following type-safe methods for retrieving the "current"
component and composite component:

public static UIComponent getCurrentComponent(FacesContext context);
public static UIComponent getCurrentCompositeComponent(FacesContext context)

In addition, UIComponent also defines two related constants:

public static final String CURRENT_COMPONENT =
"javax.faces.component.CURRENT_COMPONENT";
public static final String CURRENT_COMPOSITE_COMPONENT =
"javax.faces.component.CURRENT_COMPOSITE_COMPONENT";

And specifies that these constants may be used to retrieve the current
component/composite component from the FacesContext attribute map.

These constants assume that a particular implementation is used for
pushing/popping the current component to EL - ie. one that happens to store the
current component/composite component on the FacesContext attribute map.
However, this is a bad assumption for the specification to make, since a more
obvious implementation choice would be to managed the current component info in
a stack.

The spec should be changed to either:

  • Remove these constants. Or...
  • Remove the requirement that implementations must publish the current
    component/composite component via these constants.

To allow for more reasonable implementations.

Other reasons for de-supporting these constants include:

1. They provide no advantage over the type safe methods that provide access to
the same information.
2. They expose an implementation detail which could lead to dangerous code - ie.
no code other than pushComponentToEl/popComponentToEL should be able mess with
these values.
3. The requirement that the FacesContext attributes must be set adds overhead to
implementations which choose to use a stack for managing the current
component/composite component.

Note that Mojarra should be switching over to a stack-based implementation soon
and as such #3 will soon mean unnecessary overhead for both Mojarra and MyFaces.
(MyFaces already uses the stack approach and must take extra steps to publish
the current component/composite component values in order to comply with the spec.)



 Comments   
Comment by Ed Burns [ 13/Apr/10 ]

2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 27/Aug/10 ]

For now re-target for 2.2.
If time permits may revisit for 2.1.

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 22/Mar/11 ]

Fixed in trunk. This is a 2.2 API change and must not be back-ported to the 2.1 branch.

Adding (bin) jsf-api/doc/changed_added_2_2.png
Adding (bin) jsf-api/doc/changed_added_2_2_cursor.cur
Adding (bin) jsf-api/doc/changed_deleted_2_2.png
Adding (bin) jsf-api/doc/changed_deleted_2_2_cursor.cur
Adding (bin) jsf-api/doc/changed_modified_2_2.png
Adding (bin) jsf-api/doc/changed_modified_2_2_cursor.cur
Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Sending jsf-api/src/main/java/javax/faces/component/package.html
Sending jsf-api/src/main/java/javax/faces/context/FacesContext.java
Sending jsf-api/src/main/resources/jsf-api.css
Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Sending jsf-tools/src/main/resources/com/sun/faces/generate/facesdoc/stylesheet.css
Transmitting file data ............
Committed revision 8944.





[JAVASERVERFACES_SPEC_PUBLIC-781] Expose TemplateClient api to make gracelets work with jsf 2.0 Created: 31/Mar/10  Updated: 01/Aug/14  Resolved: 19/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: lu4242 Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 781
Status Whiteboard:

size_large importance_medium


 Description   

This message is on behalf of Lewis Gass.

I am writing in relation to a particular use case which reveals that the
current JSF 2.0 public API is defficient. This is in relation the open
source project Gracelets (http://gracelets.sourceforge.net/) and the new
effort to integrate JSF 2.0 with Groovy. In order for people to use Groovy
as an alternative View Langauge they need
to have access to the all the Facelets tag libraries and participate in the
Templating framework that Facelets provides. Much of this is tied to the
TagLibrary and
TemplateClient API's. Before, with JSF 1.2, there was a single Facelets
"API" and/or implementation. So integrating with it was much simpler, as is
shown by previous Gracelets
versions. With JSF 2.0, part of the Facelets library was divided into public
API and another as JSF 2.0 specific implementation.

However, basic concepts such as Templating (TemplateClient and
TemplateManager) are not considered public API, which means that a
technology such as Gracelets
must rely on a per JSF implementation integration library which is volatile
in nature. The FaceletContext class is public API, but implementations are
not required to support
third party implementations of such, and there is no standard way to access
the TagLibrary used by facelets so that third part View Languages can
harness them.

Thus this message has the purpose of requesting such parts of the old
Facelets library, namely, the TagLibrary, TemplateClient and the related
FaceletContext methods (popClient(),
pushClient(), extendClient() and applyDefinition()) to be part of the public
JSF 2.0 API, while at the same time requiring JSF 2.0 implementors to
support third party implementations
of the same classes/API's.

Respectfully,
Lewis Gass
Gracelets Coder
sestechllc@gmail.com



 Comments   
Comment by lu4242 [ 13/May/10 ]

Comments from this discussion: [jsr-314-open]
javax.faces.view.facelets.ResourceResolver cannot be fully overriden

Checking this issue on myfaces:

https://issues.apache.org/jira/browse/MYFACES-2628

It was notice there is a way to override the default ResourceResolver, used to
load facelets templates, but the algorithm related to ViewHandler (spec pdf
section 7.5.2) says that if the physical resource exists with the name
requestViewId let that value be viewId, otherwise return null. So, if some user
try to load templates from other sources, the ViewHandler just will not work.

The problem is there is no standard way to retrieve the current ResourceResolver
object, so the ViewHandler just can't find them. In myfaces, this one is
instantiated on facelets vdl object, when it is initialized.

One idea to solve this one could be expose this object through vdl interface
(maybe a public method called getResourceResolver()?).

Since this issue is related to other ones that requires expose facelets api
objects, I'll not create an issue on the spec jira, but if it is necessary I can
create it.

Comment by Ed Burns [ 19/May/10 ]

Move to 2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 19/Dec/13 ]

We are considering extracting Facelets out of JSF for use outside of JSF as well as inside. This would have to be addressed in that case.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-774] Request for enhancement: Dynamic configuration changes Created: 19/Mar/10  Updated: 01/Aug/14  Resolved: 19/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Improvement Priority: Major
Reporter: werpu12 Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh
URL: http://people.apache.org/~werpu/Proposal%20Configuration.pdf


Issuezilla Id: 774
Status Whiteboard:

size_large importance_large draft


 Description   

As of now the JSF configuration is static with limited possibility to alter it
from the scope of an extension framework or application. This (see url included)
tries to fix this problem by introducing a central configuration singleton
object which allows read and write access on the configuration and a set of
system events which are used to allow implementations and extension frameworks
to perform the necessary steps upon the configuration change request.

Below is the link to the proposal from my side which should give an initial
start to the discussion.

http://people.apache.org/~werpu/Proposal%20Configuration.pdf



 Comments   
Comment by werpu12 [ 19/Mar/10 ]

changed rev to 2.1

Comment by Ed Burns [ 24/Mar/10 ]
      • Issue 241 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 24/Mar/10 ]

From issue 241

AJ> I would like to see a MBean to query an applications runtime setup
AJ> (in relation to JSF). Basically this would be read-only.

AJ> Exception: ManagedBean-Attributes. The configured attributes of a
AJ> managed bean with scope application should be editable. this would
AJ> allow to have some control-values in managed beans and be able to
AJ> control it in a standard way and access it in an easy way in the
AJ> views.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 19/Dec/13 ]

This sort of thing might be the domain of the new Configuration JSR, tentatively lead by Antatole Tesch of Credit Suisse.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-773] Request for enhancement: Dynamic configuration changes Created: 19/Mar/10  Updated: 01/Aug/14  Resolved: 19/Dec/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: werpu12 Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh
URL: http://people.apache.org/~werpu/Proposal%20Configuration.pdf


Issuezilla Id: 773
Status Whiteboard:

size_large importance_medium


 Description   

As of now the JSF configuration is static with limited possibility to alter it
from the scope of an extension framework or application. This (see url included)
tries to fix this problem by introducing a central configuration singleton
object which allows read and write access on the configuration and a set of
system events which are used to allow implementations and extension frameworks
to perform the necessary steps upon the configuration change request.

Below is the link to the proposal from my side which should give an initial
start to the discussion.

http://people.apache.org/~werpu/Proposal%20Configuration.pdf



 Comments   
Comment by Ed Burns [ 18/May/10 ]

Move to unscheduled.

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 19/Dec/13 ]

Duplicate of JAVASERVERFACES_SPEC_PUBLIC-774.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-762] Only short-circuit a non-faces request to render response if view metadata has no children Created: 06/Mar/10  Updated: 01/Aug/14  Resolved: 08/Jun/11

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

Type: Bug Priority: Critical
Reporter: mojavelinux Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 22 hours, 11 minutes
Time Spent: 1 hour, 49 minutes
Original Estimate: 1 day
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Zip Archive JAVASERVERFACES_SPEC_PUBLIC-762.zip    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-758 Support view actions that execute bef... Closed
Related
is related to JAVASERVERFACES-3118 Migrate test for spec issue 762 to te... Closed
Issuezilla Id: 762
Status Whiteboard:

size_medium importance_medium


 Description   

Currently, on an non-faces request, the Restore View short-circuits to the
Render Response if the view metadata contains no UIViewParameter children. The
exclusive check in this logic breaks the whole extensibility of the view
metadata feature.

Consider that a component author creates a custom component to be used in the
view metadata. Now, the page author has to add add least one (perhaps arbitrary)
UIViewParameter in the view metadata in order for view metadata to go through
the full JSF lifecycle, and the custom component activated, on an initial
request.

Here is the correct logic for the Restore View phase:

viewRoot = metadata.createMetadataView(facesContext);
// Only skip to render response if there are no child components
UIComponent metadataFacet = viewRoot.getFacet(UIViewRoot.METADATA_FACET_NAME);
if (metadataFacet.getChildCount() == 0) {
facesContext.renderResponse();
}

As a workaround, a component author could decorate the createMetadataView call
and add a artificial UIViewParameter if other children are present (though
setting it up would require a lot of work).



 Comments   
Comment by Ed Burns [ 17/May/10 ]

Move to 2.1

Comment by Ed Burns [ 22/Jun/10 ]

sheetalv

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 08/Jun/11 ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/lifecycle/RestoreViewPhase.java
Sending jsf-ri/systest/build-tests.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces/regression/i_spec_762
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces/regression/i_spec_762/Issue762PhaseListener.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces/regression/i_spec_762/UserBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp/main.xhtml
Sending jsf-test/build.xml
Transmitting file data ..........
Committed revision 9143.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-758] Support view actions that execute before tree is built w/ navigation support Created: 03/Mar/10  Updated: 10/May/13  Resolved: 10/May/13

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

Type: Improvement Priority: Blocker
Reporter: mojavelinux Assignee: Ed Burns
Resolution: Fixed Votes: 10
Labels: None
Σ Remaining Estimate: 1 week, 2 days, 23 hours, 10 minutes Remaining Estimate: 1 week, 2 days, 23 hours, 10 minutes
Σ Time Spent: 11 hours, 4 minutes Time Spent: 11 hours, 4 minutes
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://seamframework.org/Documentation/JSFEnhancementViewActions


Attachments: Text File 20110615_i_spec_758.patch     Text File 20110729-01-i_spec_758.patch     Text File 20110810-i_spec_758.patch     Text File 20110812-i_spec_758.patch     Text File 20110818-i_spec_758.patch     Text File changebundle.txt     Text File diffs.patch     Text File diffs.patch     Zip Archive i_spec_758_war.zip     Zip Archive newfiles.zip    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-762 Only short-circuit a non-faces reques... Closed
depends on JAVASERVERFACES-2165 Verify that an <f:viewAction> with ne... Closed
depends on JAVASERVERFACES-2269 Verify implementation of CSRF protection Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-340 Portlet Bridge Issue: Add ability to ... Sub-task Closed javaserverfowner  
JAVASERVERFACES_SPEC_PUBLIC-968 Improve Event Handling Sub-task Resolved  
JAVASERVERFACES_SPEC_PUBLIC-975 Provide response headers in Event Dat... Sub-task Open  
Issuezilla Id: 758
Status Whiteboard:

size_medium importance_large 20110201-tag


 Description   

JSF should provide a view metadata component that defines a method expression to
be invoked before the component tree is built (or restored), with support for
navigating to an alternative view afterward using navigation rules. Navigation
may be the result of a constraint violation, a security restriction, or because
the request was for a pseudo-view.

As an example, the developer might use a view action to load a blog entry before
the view is displayed. If the entry cannot be found, the user would be
redirected to another page using a navigation rule.

<f:view>
<f:metadata>
<f:viewParam name="id" value="#

{blogController.id}

"/>
<f:viewAction execute="#

{blogController.loadEntry}" onPostback="false"/>
</f:metadata>
</f:view>

<navigation-case>
<from-action>#{blogController.loadEntry}

</from-action>
<from-outcome>false</from-outcome>
<to-view-id>/entries.xhtml</to-view-id>
<redirect/>
</navigation-case>

This feature relates to view parameters, as the example suggests. View
parameters were introduced in JSF 2.0 to provide a declarative value binding
between query string parameters and model properties. They go a long way towards
accommodating the action-oriented scenario in JSF. But view actions are a
necessary part of the equation.

<f:event type="preRenderView"> is similar to <f:viewAction>, but is insuffient
as a front controller. <f:event> gets you by if the purpose is to perform
processing at the start of the request. <f:viewAction> is intended for when you
have to perform logic to verify that the view can even be rendered. View-level
security is one example. Another is verifying that preconditions are met. And
the key is to make navigation away from the view an integrated part when it's
determined that the view cannot and should not be rendered.



 Comments   
Comment by mojavelinux [ 03/Mar/10 ]

Change target milestone.

Comment by mojavelinux [ 03/Mar/10 ]

Andy Schwartz clarifies:

1. View actions would be processed during invoke application phase.
PreRenderView events are delivered during the render response phase.

2. View actions would be integrated with the navigation system (allow navigation
rules to be applied). PreRenderView events require programmatic interaction with
the NavigationHandler.

3. View actions would be part of the view metadata (like view parameters) and
thus would be available before the full component tree has been created.
PreRenderView event listeners are registered (via <f:event>) when the full
component tree is created.

Comment by Ed Burns [ 22/Jun/10 ]

sheetalv

Comment by Ed Burns [ 03/Aug/10 ]

Lincoln also shared http://docs.jboss.org/seam/3/faces/reference/snapshot/en-US/html_single/#viewaction

Comment by Jan-Kees van Andel [ 04/Aug/10 ]
      • Issue 867 has been marked as a duplicate of this issue. ***
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 09/Jun/11 ]

Move viewParameters automated test to jsf-test

Comment by Ed Burns [ 09/Jun/11 ]

In progress.

Comment by Ed Burns [ 14/Jun/11 ]

Brian, if you could please hack upon this and make it a simple sample of s:viewAction, I'd really appreciate it.

Comment by Ed Burns [ 14/Jun/11 ]

Brian, if you could please simply hack upon this and turn it into a simple example of s:viewAction, that would be great.

Comment by Ed Burns [ 16/Jun/11 ]

Sending jsf-api/build.xml
Adding jsf-api/doc/expert-draft-bg.graffle
Adding jsf-api/doc/expert-draft-bg.png
Adding jsf-api/doc/jsdoc-template
Adding jsf-api/doc/jsdoc-template/static
Adding jsf-api/doc/jsdoc-template/static/default.css
Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-api/doc/standard-html-renderkit.xml
Adding jsf-api/doc/uiviewaction-props.xml
Adding jsf-api/src/main/java/javax/faces/component/UIViewAction.java
Sending jsf-api/src/main/java/javax/faces/context/ExternalContextWrapper.java
Sending jsf-api/src/main/java/javax/faces/event/PhaseId.java
Sending jsf-api/src/main/resources/jsf-api.css
Sending jsf-demo/build.xml
Sending jsf-ri/build.xml
Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
Sending jsf-ri/conf/share/facelets_jsf_core.tld
Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentSupport.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/core/CoreLibrary.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/Issue758TestCase.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsIndex.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsReader.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsStory.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/events.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page01.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page02.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page03.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/template.xhtml
Sending jsf-test/build.xml
Sending jsf-tools/src/main/resources/com/sun/faces/generate/facesdoc/stylesheet.css
Transmitting file data ................................
Committed revision 9173.

Checkpoint. Specified but not implemented.

Comment by Ed Burns [ 29/Jul/11 ]

snapshot. Brian Leathem's simple testcase works.

Comment by Ed Burns [ 10/Aug/11 ]

Snapshot, sample app based on Dan Allen's original NewsReader testcase works.

Comment by Ed Burns [ 11/Aug/11 ]

Snapshot to run automated tests on ADC machine.

Comment by Ed Burns [ 11/Aug/11 ]

The i_spec_915 testcase caught a mod in this changebundle that introduced breakage. The jsf-ri-config.xml does not need to be modified and I'm not sure why it was. Victory for automated tests.

Comment by Ed Burns [ 12/Aug/11 ]

Resolution attempt one realized http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-758

SECTION: Modified Files
----------------------------
M applicationIntegration.fm

  • 7.4.2 Rewrite the paragraph on how to handle a redirect as follows.

If a matching <navigation-case> element was located, and the
<redirect/> element was specified in this <navigation-case>

+ or a call to UIViewAction.isProcessingBroadcast() returns true,

call getRedirectURL() on the ViewHandler, passing the current
FacesContext, the <to-view-id>, any name=value parameter pairs
specified within <view-param> elements within the <redirect> element,
and the value of the include-view-params attribute of the <redirect />
element if present, false, if not. The return from this method is the
value to be sent to the client to which the redirect will occurr. Call
getFlash().setRedirect(true) on the current FacesContext. Cause the
current response to perform an HTTP redirect to this path.

+ If the preceding call to UIViewAction.isProcessingBroadcast() had
+ returned true, also call setKeepMessages(true) on the flash.

Call responseComplete() on the FacesContext instance for the current
request. If the content of <to-view-id> is a value expression, first
evaluate it to obtain the value of the view id.

M jsf-api/src/main/java/javax/faces/component/UIViewAction.java

  • complete spec for this feature
  • rename "if" attribute of f:viewAction to "rendered".

M jsf-ri/conf/share/facelets_jsf_core.tld

  • rename "if" attribute of f:viewAction to "rendered".

M jsf-ri/src/main/java/com/sun/faces/application/NavigationHandlerImpl.java

  • implement changes to 7.4.2

M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/build.xml
M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsReader.java
M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page02.xhtml

A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war/ViewActionTestBean.java
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/main.xhtml
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF/web.xml
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/result.xhtml
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/pom.xml
A + jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/Issue758SimpleTestCase.java

Comment by Ed Burns [ 12/Aug/11 ]

Sending jsf-api/src/main/java/javax/faces/component/UIViewAction.java
Sending jsf-ri/conf/share/facelets_jsf_core.tld
Sending jsf-ri/src/main/java/com/sun/faces/application/NavigationHandlerImpl.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/Issue758SimpleTestCase.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war/ViewActionTestBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/main.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/result.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsReader.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page02.xhtml
Transmitting file data ............
Committed revision 9254.

Sending applicationIntegration.fm
Sending preface.fm
Transmitting file data ..
Committed revision 1027.

Committed to trunk.

Comment by Ed Burns [ 18/Aug/11 ]

snapshot

Comment by Ed Burns [ 18/Aug/11 ]

Corner cases on using viewAction to go back to the same page http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-758

SECTION: Modified Files
----------------------------
M applicationIntegration.fm

  • 7.4.2 now has this text

If a matching <navigation-case> element was located, proceed as follows.

+ * If UIViewAction.isProcessingBroadcast() returns true, call
+ getFlash().setKeepMessages(true) on the current FacesContext. Compare
+ the viewId of the current viewRoot with the <to-view-id> of the
+ matching <navigation-case>. If they differ, take any necessary actions
+ to effec