[JAVASERVERFACES_SPEC_PUBLIC-1433] Add Option to expand meaning of required="true" for UIInput Created: 29/Nov/16  Updated: 29/Nov/16

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

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


 Description   

When you say required="true" on a UIInput component, the validation
must always take place, even when there is no entry in the request
corresponding to that component.

Background:

Consider this login page:

<h:inputText id=“userName” required=“true” 
             value=“#{backingBean.userName}” />

<h:inputSecret id=“password” required=“true” 
               validator=“#{backingBean.validatePassword}” 
               value=“#{backingBean.password}” />

<h:commandButton action=“/views/authenticatedUser.xhtml” />

If the postback is hacked such that the userName is present as a request
parameter, but the password is not, the password validator would be
bypassed. If the password validator is used as the entry point to
perform authentication, this could cause problems.

Now, it must be said that using a validator on a password field as the
entry point to perform authentication is a particular design choice.
This design choice runs a bit counter to the stated purpose of the
validation system, which is to ensure syntactic and some level of
semantic validity of fields. There are other ways to perform
authentication that do not rely on the validation system for this
purpose.

Nonetheless, we would like to accomodate this use case.

Proposal:

For JSF 2.3, I propose the following.

Modify PDF section 3.5.4 to read:

Spec> *The render-independent property required is a shorthand for the
Spec> function of a required validator. If the value of this property is
Spec> true, **there is an entry in the request payload corresponding to
Spec> this component**, and the component has no value, the component is
Spec> marked invalid and a message is added to the FacesContext
Spec> instance.*

Modify the JavaDoc for UIInput.validate(). Modify the first bullet
point to read:

Spec> Retrieve the submitted value with getSubmittedValue(). If this
Spec> returns null, and the
Spec> javax.faces.component.UIInput.ALWAYS_PERFORM_VALIDATION_WHEN_REQUIRED_IS_TRUE
Spec> context-parameter is set to true (ignoring case), examine the
Spec> value of the "required" property. If the value of "required" is
Spec> true, continue as below. If the value of "required" is false, the
Spec> "required" attribute is not set not set, exit without further
Spec> processing. If the context-paramater is not set, or is set to
Spec> false (ignoring case) exit without further processing. (This
Spec> indicates that no value was submitted for this component.)

With these changes, the javadoc for UIInput.validateValue() can remain
unchanged.






[JAVASERVERFACES_SPEC_PUBLIC-1432] Make h:outputFormat support outputting to a request scope variable defined by a new var attribute Created: 22/Oct/16  Updated: 22/Oct/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: rdelaplante Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See the OmniFaces o:outputFormat for examples and description:

http://showcase.omnifaces.org/components/outputFormat

I've used this feature for building formatted text to use on h:commandLink buttons, and also to automatically escape URL parameter values that end up being used in my template when referencing CSS files (path parameters). When the URL parameter values are used without o:outputFormat we're able to execute XSS attacks. It would be really great if this feature were part of the 2.3 spec.






[JAVASERVERFACES_SPEC_PUBLIC-1431] Make f:param a ValueHolder so that a converter can be used on the value Created: 22/Oct/16  Updated: 22/Oct/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: rdelaplante Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Here's an easy one for 2.3 (hopefully). It has already been solved in OmniFaces.

Language file:

footer.copyright=&#169; {0} Company, LLC. All Rights Reserved.

Facelet template:

<h:outputFormat value="#{messages['footer.copyright']}" escape="false">
    <f:param value="#{now}">
        <f:convertDateTime pattern="yyyy" type="date"/>
    </f:param>
</h:outputFormat>

Intended output:

© 2016 Company, LLC. All Rights Reserved.

Error that I get instead:

<f:convertDateTime> Parent not an instance of ValueHolder: javax.faces.component.UIParameter@10e350f

When I change f:param to o:param (OmniFaces), problem solved.

http://showcase.omnifaces.org/components/param






[JAVASERVERFACES_SPEC_PUBLIC-1426] @NaviationMode on the action method Created: 29/Jun/16  Updated: 29/Jun/16

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

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


 Description   

If you handle navigation via a action-method return value, there are actually 2 possible navigation modes:

Forward:
return "index.xhtml"

Redirect:
return "index.xhtml?faces-redirect=true"

As "faces-redirect=true" is not a modern way to handle the mode, i would introduce something like this:

@NavigationMode(NavigationMode.Mode.REDIRECT)
public String login()

{ return "index.xhtml"; }




[JAVASERVERFACES_SPEC_PUBLIC-1421] Modify the requirements of the jsf.ajax.response JavaScript documentation to enable portlet compatibility Created: 10/Jun/16  Updated: 14/Jun/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: 2.3

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

Portlets



 Description   

The jsf.ajax.response JavaScript documentation contains requirements that are not compatible with portlet environments.

Portlet Incompatibility #1

If an <update> element is found in the response with the identifier javax.faces.ViewRoot:

<update id="javax.faces.ViewRoot">
   <![CDATA[...]]>
</update>

Update the entire DOM replacing the appropriate head and/or body sections with the content from the response

Portlet Incompatibility #2

If an <update> element is found in the response with the identifier javax.faces.ViewBody:

<update id="javax.faces.ViewBody">
   <![CDATA[...]]>
</update>

update the document's body section with the CDATA contents from the response.

These requirements assume that the RENDER_RESPONSE phase of the JSF lifecycle was responsible for generating the entire HTML document including the following tags:

<html>
    <head>
        ...
    </head>
    <body>
        ...
    </body>
</html>

The requirements further assume that the renderer associated with the h:body component tag renders the <body> starting tag and </body> end tag, and that the <f:view> (UIViewRoot) corresponds to the body section of the document.

In a portlet environment, the JSF Portlet Bridge ensures that object returned by FacesContext.getCurrentInstance().getViewRoot() to be an instance of javax.portlet.faces.component.PortletNamingContainerUIViewRoot. Since it extends javax.faces.component.NamingContainer, the UIViewRoot becomes "namespaced" with the portlet namespace.

The JSF Portlet Bridge also overrides the renderer associated with the h:body component and renders a <div>...</div> section instead of a <body>...</body> section. In addition, the div has an id attribute with the namespaced clientId of the view root.

The JSF Portlet Bridge also overrides the renderer associated with the h:head component so that it can inform the portlet container of required JSF resources. The renderer does not render a <head>...</head> section in a portlet environment.

For example, given the following JSF view:

<f:view>
    <h:head />
    <h:body>
        <h:form id="f1">
            <h:inputText id="foo" value="#{backingBean.foo}" />
            <h:commandButton />
        </h:form>
    </h:body>
</f:view>

On Apache Pluto the portlet div section might look something like this:

<div id="Pluto_myPortlet_1__24955534_0_">
    ...
    <form id="Pluto_myPortlet_1__24955534_0_:f1">
        <input type="hidden" name="Pluto_myPortlet_1__24955534_0_:f1" value="Pluto_myPortlet_1__24955534_0_:f1">
        <input id="Pluto_myPortlet_1__24955534_0_:f1:foo" type="text" name="Pluto_myPortlet_1__24955534_0_:f1:foo">
        <input type="submit">
        <input type="hidden" name="Pluto_myPortlet_1__24955534_0_javax.faces.ViewState" id="Pluto_myPortlet_1__24955534_0_:javax.faces.ViewState:0" value="-7034168008597714894:-3199096175767081201" autocomplete="off">
    </form>
</div>

The requirements need to be updated so that they enable portlet compatibility by replacing the <div>...</div> section associated with the UIViewRoot rather than the <body>...</body> section of the document when running in a portlet environment.



 Comments   
Comment by balusc [ 11/Jun/16 ]

This seems to be already implemented since Mojarra 2.2.0. It only uses getClientId() instead of getContainerClientId(), but it shouldn't make any difference on the root component.

In other words, when render="@all" is used, it will already not anymore write out <update id="javax.faces.ViewRoot">. It's only left unspecified in the spec. All in all, when also considering issue 790, I think it makes sense to propose the following change to be as transparent as possible (i.e. do not mention Portlet specifics and do not change JavaScript):

Update PartialViewContext#processPartial() to specify that during render response phase, when the <update> for javax.faces.ViewRoot will be written, and the UIViewRoot is an instance of UINamingContainer, then write id attribute with value of UIViewRoot#getContainerClientId(), else write value of PartialResponseWriter#RENDER_ALL_MARKER.

This way, we can also remove the Util.isPortletRequest() check from the current implementation.

The javax.faces.ViewBody is nowhere considered in JSF API nor in Mojarra impl, it's only mentioned in JS API. It's internally treated exactly the same way as javax.faces.ViewRoot. I guess it's a leftover, so we can ignore it for now. Perhaps it should better be removed from JS API, but that's a different issue.

Comment by Neil Griffin [ 14/Jun/16 ]

@balusc: Please forgive, but I simply didn't remember that I had created JAVASERVERFACES_SPEC_PUBLIC-1069 back in 2012. This resulted in the following paragraph being modified in section 2.2.6.1 of the Spec titled "Render Response Partial Processing":

If isRenderAll() returns true and this is not a portlet request, call startUpdate(PartialResponseWriter.RENDER_ALL_MARKER) on the PartialResponseWriter. For each child of the UIViewRoot, call encodeAll(). Call endUpdate() on the PartialResponseWriter. Render the state using the algorithm described below in Section “Partial State Rendering”, call endDocument() on the PartialResponseWriter and return. If isRenderAll() returns true and this is a portlet request, treat this as a case where isRenderAll() returned false, but use the UIViewRoot itself as the one and only component from which the tree visit must start.

Thanks for pointing out the code in com.sun.faces.context.PartialViewContextImpl – This functionality was introduced into Mojarra 2.2 by Manfred via commit e25abcae and 0e42795e.

I did some research and the reason why ResponseWriterBridgeImpl.java still contains a workaround is because the MyFaces PartialViewContextImpl. processRenderAll(UIViewRoot,PartialResponseWriter) method does not yet implement the requirements outlined in section 2.2.6.1 of the Spec. I just created MYFACES-4053 and will try to contribute a fix soon.

I really like your idea of using language like "if UIViewRoot is an instance of UINamingContainer" rather than "if this is a portlet request" and would recommend that section 2.2.6.1 of the Spec be updated.

Finally, I agree with your assessment regarding javax.faces.ViewBody. After studying the JavaScript documentation more today, I also noticed javax.faces.ViewHead. I think that the Bridge Spec can simply state that bridge implementations should ignore these features since they are inherently incompatible with portlet environments.





[JAVASERVERFACES_SPEC_PUBLIC-1420] Provide portable way to attach behaviors to a composite / base implementation for behaviors Created: 07/Jun/16  Updated: 07/Jun/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript, Components/Renderers, Facelets/VDL
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: tandraschko Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Implementing behaviors in a component library is currently not as easy as implementing components.

1) There is no abstract behavior base available
2) No common way to handle state saving like the StateHelper
3) No common way to attach a behavior to a component
4) No common, portable and easy way to attach a behavior to a composite

It would be a great goal to create a abstract base for behaviors, which fixes the common problems.
In PrimeFaces, i developed it via:

  • AbstractBehavior; base class which handles the attributes and state saving - similar to getStateHelper and PropertyKeys

https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java

  • AbstractBehaviorHandler; attach the behavior to the target component or composite; currently with a hack for Mojarra and MyFaces

https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/base/AbstractBehaviorHandler.java

Example implemtation of p:ajax:
https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/ajax/AjaxBehavior.java
https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/ajax/AjaxBehaviorHandler.java






[JAVASERVERFACES_SPEC_PUBLIC-1419] Support new Html5 events like oninput Created: 07/Jun/16  Updated: 30/Jul/16

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

Type: New Feature Priority: Major
Reporter: tandraschko Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

e.g. HtmlInputText#EVENT_NAMES should contain oninput

We should actually check the list, all JSF components and add missing events:
http://www.tutorialspoint.com/html5/html5_events.htm

IMO it's important for 2.3 to be more compliant with HTML5.



 Comments   
Comment by WarriorDog [ 30/Jul/16 ]

I"d suggest this one http://www.w3schools.com/tags/ref_eventattributes.asp





[JAVASERVERFACES_SPEC_PUBLIC-1418] CDI replacement for @ManagedProperty Created: 26/May/16  Updated: 01/Jun/16

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: EL
Affects Version/s: None
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-4149 Implement CDI replacement for @Manage... In Progress

 Description   

In JAVASERVERFACES_SPEC_PUBLIC-1417 the javax.faces.bean was deprecated. Pretty much everything in that package has a replacement elsewhere, except for @ManagedProperty.

Therefor I'd like to propose providing a CDI based replacement for @ManagedProperty. This should effectively evaluate an EL expression (using the JSF native EL facility) and inject the result into the target injection point.






[JAVASERVERFACES_SPEC_PUBLIC-1416] Introduce annotation/class based configuration Created: 15/Apr/16  Updated: 15/Apr/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping
Affects Version/s: 2.3
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In JSF 2.2 the way to automatically enable JSF in a project is having either a class on the class path annotated with one of the JSF native annotations, or having a /WEB-INF/faces-config.xml file present.

With the world moving to CDI, the JSF native annotations (specifically @MangedBean) are not so much used anymore. This way to enable JSF is therefor not longer practical.

A faces-config.xml file is still a simple way, if it wasn't for the fact that officially it can't be just an empty file like CDI's bean.xml. Looking up the right schema for trivial applications is a bit of a hassle.

Therefor it might be worth looking into a JSF annotation that is specifically intended to enable JSF.

E.g.

@FacesConfig
public class JustAClass {

}

In the simplest version this will just activate JSF like @ManagedBean does, but without the side effect of also creating a (potentially unused) managed bean.

One step further may be to add some configuration options, potentially the annotation variant of the various web.xml settings.

E.g.

@FacesConfig(
    stateSavingMethod = "server"
)

Or a new option, to indicate the JSF version:

@FacesConfig(
    version = "2.3" // enables all JSF 2.3 features
)
@FacesConfig(
    version = "2.2" // behaves as much as possible as 2.2 did
)

This mechanism can also be used for simple configuration sets. Namely, if the class on which @FacesConfig appears is a CDI bean, CDI alternatives can be used to switch configuration.

Going another step further the class could (optionally) implement methods that return config programmatically.

E.g.

@FacesConfig 
public class MyConfig {

    public String getStateSavingMethod() {
        return ... ? "server" : "client";
    }
}

But that really is an optional proposal. The main proposal is just having the annotation.

Note that the class on which the annotation is put doesn't matter that much; it only has to be on the class path such that the runtime code (e.g. via a CDI extension) can pick it up.






[JAVASERVERFACES_SPEC_PUBLIC-1415] Broken link in JSF vdldocs, to "General Notes on Encoding" Created: 27/Mar/16  Updated: 27/Mar/16

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

Type: Bug Priority: Minor
Reporter: Arend v. Reinersdorff Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I noticed a a broken link in the JSF vdldocs documentation.

On the JSF 2.2 vdldocs documentation page for the h:form element:
http://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/h/form.html

The following link is broken:
Text:
General Notes on Encoding
Wrong link (404):
http://docs.oracle.com/javaee/7/javaserverfaces/2.2/vdldocs/facelets/h/renderkit-summary.html#general_encoding
Should be:
https://docs.oracle.com/javaee/7/javaserver-faces-2-2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_encoding

A quick Google search for
site:https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/ "General Notes on Encoding"
shows that this affects the vdldocs documentation pages for the following elements:
h:button
h:form
h:link
h:outputLink

For h:form and h:outputLink this affects also the vdldocs-jsp documentation:
http://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-jsp/h/form.html

This also affects the JSF 2.1 vdldocs documentation. For the h:form element:
https://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/vdldocs/facelets/h/form.html

Wrong link (404):
https://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/vdldocs/facelets/h/renderkit-summary.html#general_encoding
Should be:
http://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_encoding

The link is OK in the JSF 2.0 vdodocs documentation:
http://docs.oracle.com/javaee/6/javaserverfaces/2.0/docs/pdldocs/facelets/h/form.html






[JAVASERVERFACES_SPEC_PUBLIC-1414] f:validateWholeBean should allow the user to select the copy strategy (a copier attribute) Created: 12/Feb/16  Updated: 12/Feb/16

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

Type: Improvement Priority: Critical
Reporter: anghelleonard Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Payara 4.1






[JAVASERVERFACES_SPEC_PUBLIC-1413] Allow multiple validator tags of the same type on one element (for example, f:validateRegex) Created: 20/Jan/16  Updated: 20/Jan/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: kithouna Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I need to validate input against multiple regular expressions. I have a component similar to this:

<input jsf:value="#{cc.attrs.valueHolder}">
	<f:validateRegex pattern="^[^\r\n]*$"/>
	<f:validateRegex pattern="#{cc.attrs.regex}"/>
</input>

Unfortunately only the first regular expression is checked. After reading JSF 2.2 specification section 9.4.16, I think it is because both tags use the same validatorId.






[JAVASERVERFACES_SPEC_PUBLIC-1411] Duplicate detail and summery message in f:messages tag for input fields Created: 17/Dec/15  Updated: 17/Dec/15

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

Type: Improvement Priority: Minor
Reporter: belal.galal Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apache Tomcat 8.0.26, Mojarra implementation for JSF 2.2.8, Windows OS, Eclipse IDE



 Description   

When adding the attribute required="true" and then added a value to the attribute requiredMessage for input fields,for example, in a form that contains <h:messages>, the error messages will contain a duplicate detail and summary messages for the required input field. I wonder if the requiredMessage can be divided to be requiredMessageDetail and requiredMessageSummary in the input components.






[JAVASERVERFACES_SPEC_PUBLIC-1410] Define the result when the same namespace is used in annotation defined and tag library defined components. Created: 04/Nov/15  Updated: 04/Nov/15

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

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


 Description   

I cannot see anywhere in the specification that defines what should happen when the same namespace is used to define components using both the javax.faces.component.FacesComponent annotation and also in a tag library *.taglib.xml file.

For example:

@FacesComponent(value="xforms.input", createTag=true, namespace="http://www.w3.org/2002/xforms", tagName="input")
public class Input ...
<facelet-taglib version="2.2"
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee   http://xmlns.jcp.org/xml/ns/javaee/web-facelettaglibrary_2_2.xsd">

    <namespace>http://www.w3.org/2002/xforms</namespace>

    <tag>
        <tag-name>model</tag-name>
        <handler-class>my.custom.xforms.ModelTagHandler</handler-class>
    </tag>

</facelet-taglib>

See this Stack Overflow question for the full example.

The observed behaviour in Mojarra 2.2.12 is that the tag library defined components are available but the annotation defined ones are not. Reading the comments on the SO issue, the MyFaces implementation appears to make both components avaiable.

I think the specification should clearly define what should happen in this case.

From there, I'd suggest that the MyFaces behaviour of making both components available is more intuitive. If there is a conflict then the taglib version should probably win.






[JAVASERVERFACES_SPEC_PUBLIC-1409] CDI @ViewScoped storage size context-param Created: 05/Oct/15  Updated: 05/Oct/15

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

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


 Description   

This maximum number of active views in the CDI @ViewScoped storage should be configurable via a context-param setting, because they have a high impact on memory usage.

See discussion in: https://java.net/jira/browse/JAVASERVERFACES-3869






[JAVASERVERFACES_SPEC_PUBLIC-1408] Query parameters added through f:param are encoded twice without use percent encoding Created: 11/Sep/15  Updated: 11/Sep/15

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

Type: Bug Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Reported in:

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

We have an interesting behaviour when rendering h:outputLink with nested f:param elements: in the param data, the output href string has spaces encoded with a "+" rather than the expected "%20". For example:

<h:outputLink value="login.xhtml"><h:outputText value="Login page" /><f:param name="username" value="This is a test" /></h:outputLink>
creates the following:
<a href="login.xhtml?username=This+is+a+test">Login page</a>

This already seems to have been discussed in https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1019

I tried some examples with Mojarra 2.2.12 and it renders the same as MyFaces, but I notice that in this case:

<h:outputLink value="box1.xhtml?id=some value">

the space is percent encoded (space replaced by %20).

But the query params coming from f:param for h:link, h:outputLink and h:commandLink are encoded using java.net.URLEncoder.encode(...).

In JSF 2.2 spec renderkit doc for component-family: javax.faces.OutcomeTarget renderer-type: javax.faces.Button there is a section titled:

"Algorithm to obtain the url to which the user-agent should issue a GET request when clicked"

It says this:

"... The entire target URL string must be processed by a call to the encodeResourceURL() method of the ExternalContext. The name of the UIParameter goes on the left hand side, and the value of the UIParameter on the right hand side. The name and the value must be URLEncoded. Each UIParameter instance is separeted by an ampersand, as dictated in the URL spec. ..."

In this case we have a situation where the same string is encoded multiple times:

  • Call to URLEncoder.encode(...) or similar for each parameter provided by f:param tag
  • In ResponseWriter.writeURIAttribute(...)

ExternalContext.encodeResourceURL() internally calls httpServletResponse.encodeURL(...), but this is not used to do the url encoding (it is called later on the same algorithm, so that part is fine).

This issue needs to be discussed at spec level.

The problem is the call to URLEncoder.encode(...) do the same as writeURIAttribute(...), so the same code is executed twice for the same task. It looks like the first call to URLEncoder.encode(...) is not necessary (at least in MyFaces calls this method, probably by historical reasons). It is not clear who is responsible to do the character encoding for the URL. At the end all this happens on the Renderer class, so the clarification is about the moment where the URL encoding should happen.






[JAVASERVERFACES_SPEC_PUBLIC-1407] Options for @ViewScoped to specify where associated state is saved Created: 10/Sep/15  Updated: 10/Sep/15

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

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

Tags: state, state_saving, state_saving_method

 Description   

The current implementation of @ViewScoped in JSF 2.2 is tied to the session scope, which is a server side storage.

I'd like to propose to have several options for @ViewScoped to specify where the state associated with it is saved.

The options can be as follows:

  • Follow the state saving setting applicable for that view (this is approximately the JSF 2.1 and earlier behavior)
  • Always session (this is the JSF 2.2 behavior)
  • Always client (new option)





[JAVASERVERFACES_SPEC_PUBLIC-1406] Unify pseudo state save method "none" (stateless) with modes "server" and "client" Created: 10/Sep/15  Updated: 10/Sep/15

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

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

Tags: state, state_saving, state_saving_method, stateless

 Description   

In JSF the user can choose to save state on the server or the client via the javax.faces.STATE_SAVING_METHOD context parameter. This is a global setting that applies to all views (URLs) in the application.

At the same time there's effectively a "none" setting, which is what happens when a view root (e.g. via the f:view tag) is set to transient. This is also called "stateless".

I'd like to propose that in addition to the current mechanism used to set a single view to stateless, the range of values for javax.faces.STATE_SAVING_METHOD context parameter is extended with a "none" option.

The intended purpose of this option is to globally set all views in the application to stateless.






[JAVASERVERFACES_SPEC_PUBLIC-1405] Set state save method per pattern Created: 10/Sep/15  Updated: 10/Sep/15

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

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

Tags: state, state_saving, state_saving_method

 Description   

In JSF the user can choose to save state on the server or the client via the javax.faces.STATE_SAVING_METHOD context parameter. This is a global setting that applies to all views (URLs) in the application.

I would like to propose to additionally make it possible to set this per URL pattern (using the pattern syntax as used by Servlet to map and/or protect URLs).

Setting the state saving method per URL pattern then overrides the global setting. If a given URL is not covered by the URL pattern, the global setting comes into effect.






[JAVASERVERFACES_SPEC_PUBLIC-1400] ui:repeat does not resolve (nested structures of) map.values Created: 19/Aug/15  Updated: 23/Oct/16

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

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

Checked with Windows 6.1 "7" and 6.3 "8.1"
and Java 1.8 "8"



 Description   

Given a class containing a map

Map<Integer, AccountNode> _children = new LinkedHashMap<>();

AccountNode wraps an object Account inside, which can be obtained by a getter.

The values of this map might be accessed by this getter

public Collection<AccountNode> getChildren() {
    return _children.values();
}

This should be used from facelets like in following code

 <c:forEach items ="#{treeController.rootNode.children}" var="child">
    <p>#{child.account.name}</p>
</c:forEach>

Using the tag handler "forEach", everything is fine.
But moving on to the component "repeat", the app fails.

<ui:repeat value ="#{treeController.rootNode.children}" var="child">
    <p>#{child.account.name}</p>
</ui:repeat>

"/index.xhtml: The class 'java.util.LinkedHashMap$LinkedValues' does not have the property 'account'."

Workaround: If the values get copied into another list, "repeat" works fine too.

public Collection<AccountNode> getChildren() {
    return new ArrayList<AccountNode>(_children.values());
}


 Comments   
Comment by muellermi [ 23/Oct/16 ]

Will this become obsolete due to the extended collection / map handling?





[JAVASERVERFACES_SPEC_PUBLIC-1398] Cleanup for unused Flows Created: 16/Aug/15  Updated: 01/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2, 2.3
Fix Version/s: None

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


 Description   

One thing missing from the faces flow spec that exists with @ConversationScoped are access timeouts after which the current scope is invalidated and destroyed.

Consider the case where a flow is not exited through the flow return, but instead simply abandoned by the user (via the back button, bookmarks or after closing a window). In this case the flow scoped beans will stay in the session, until the session is destroyed. In a web application with flows that is used intensively by its users for a long time it's easily possible that 100s of flow instances stay in the session before they are cleaned up and thus wasting a lot of memory.

To solve this problem either

  • a timeout could be introduced - similar to Conversations. This timeout could be specified for all flow as a web context param or on a flow level in the flow definition.
  • or alternatively a maximum of client window instances per flow could be set globally (implemented like ViewMaps by a LRU Map).


 Comments   
Comment by lu4242 [ 01/Sep/15 ]

Implemented in MyFaces. See: https://issues.apache.org/jira/browse/MYFACES-3938





[JAVASERVERFACES_SPEC_PUBLIC-1397] Provide documentation and tuning options for activeViewMaps Created: 13/Aug/15  Updated: 13/Aug/15

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

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


 Description   

We are using JSF 2.2.12 with server side state saving and plenty of ViewScoped ManagedBeans. After investigating our load tests it turned out that the data in our ViewScoped Beans is kept in session memory for quite some time. We were debugging Mojarra and found that the ViewScopeManager holds all ViewScoped beans of the last 25 used views. Even when you set numberOfLogicalViews to 1, it will still keep the last 25.

Now there is also an undocumented parameter com.sun.faces.application.view.activeViewMapsSize. When tuning JSF applications it would be very interesting to know why 25 and which impact this parameter has in conjunction with numberOfLogicalViews and numberOfViewsInSession.

I created also a stackoverflow post about this: http://stackoverflow.com/questions/31959982/jsf-2-2-memory-consumption-why-does-mojarra-keep-the-viewscoped-beans-of-the-la



 Comments   
Comment by fischermatte [ 13/Aug/15 ]

sorry, this issue belongs to mojarra not to spec. unfortunately i am not allowed to delete or move this issue here. I created the same here for mojarra now: https://java.net/jira/browse/JAVASERVERFACES-4015





[JAVASERVERFACES_SPEC_PUBLIC-1396] Standardize WebSocket integration with f:websocket Created: 12/Aug/15  Updated: 27/Oct/16

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: balusc
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 8 minutes
Original Estimate: Not Specified

Attachments: Text File JAVASERVERFACES_SPEC_PUBLIC-1396.patch    

 Comments   
Comment by balusc [ 10/Dec/15 ]

Attached a git patch with initial commit of a functional f:socket tag.

As discussed, I dropped SSE support as it isn't standardized and has less browser support (no Microsoft IE/Edge), while WS is standardized, even in Java EE (JSR356), and has better browser support and is more efficient (no persistent open connection).

Comment by balusc [ 14/Dec/15 ]

After testing on various servers I have futher improved the script and logic. Also a new context param is added to explicitly enable the push (lazy initialization turned out to not work on Tyrus WS implementation).

Comment by balusc [ 19/Dec/15 ]

Proposal for PartialViewContext#getEvalScripts() has been splitted to https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1412

Comment by balusc [ 14/Jan/16 ]

Replaced git patch with current f:websocket tag.

Comment by balusc [ 28/Jan/16 ]

Replaced git patch with current f:websocket tag, now with session scope support

Comment by balusc [ 04/Mar/16 ]

Replaced git patch with current f:websocket tag, now with view scope, user-target and CDI event support.

Comment by balusc [ 10/Mar/16 ]

Replaced git patch with current f:websocket tag, now with test case.

Comment by balusc [ 10/Mar/16 ]

Committed and pushed:

https://java.net/projects/mojarra/sources/git/revision/598058f425f8894683f1d68796b0474e54cfea9e

Comment by balusc [ 10/Mar/16 ]

<f:websocket> has been added, along with 2 testcases (one to test context param and another to test three different push channels (app/session/view))

Comment by balusc [ 14/Mar/16 ]

(reopened accidentally closed issue)

Commited improvement as to handling of jsf.js script (refactored utility from AjaxHandler into RenderKitUtils so it can be reused by WebsocketHandler's WebsocketFacesListener). Initial implementation broke state saving.

https://java.net/projects/mojarra/sources/git/revision/ac4253639ed23eace38451fff3c33c6e9780be2b

Comment by balusc [ 14/Mar/16 ]

Test case failed on Hudson with development stage enabled; it has now been fixed.

https://java.net/projects/mojarra/sources/git/revision/9c65817db3c9e80421911692e83319ad8c97ac1e

Comment by balusc [ 18/Mar/16 ]

All tests have passed. Closing out issue.

Comment by balusc [ 27/Oct/16 ]

Reopening to improve spec further.

1. f:websocket needs to be an UIComponent implementing ClientBehaviorHolder
2. jsf.push.init needs to take clientID + full URL
3. jsf.push.open/close needs to take clientID instead of channel
4. ViewHandler should have a getWebsocketURL() or something like that





[JAVASERVERFACES_SPEC_PUBLIC-1395] Support request parameters in StylesheetRenderer Created: 09/Aug/15  Updated: 09/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.3
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: mpkorstanje Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using request parameters in h:outputStylesheet results in a RES_NOT_FOUND, for example:

<h:outputStylesheet name="stylesheet/biggest.css?version=#" media="screen"/>

This can be solved by taking the code from com.sun.faces.renderkit.html_basic.ScriptRenderer that strips the query part from the resource name before creating the resource and applying it to com.sun.faces.renderkit.html_basic.StylesheetRenderer.

The use case: Using request parameters is useful for CSS cache busting when library versioning can't be used for legacy reasons.

Where can I submit the tests?

Patch:

# This patch file was generated by NetBeans IDE
# Following Index: paths are relative to: /home/mpkorstanje/Projects/Mojarra/trunk/jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic
# This patch can be applied using context Tools: Patch action on respective folder.
# It uses platform neutral UTF-8 encoding and \n newlines.
# Above lines and this line are ignored by the patching process.
Index: StylesheetRenderer.java
--- StylesheetRenderer.java Base (BASE)
+++ StylesheetRenderer.java Locally Modified (Based On LOCAL)
@@ -97,6 +97,17 @@
         }
         contextMap.put(key, Boolean.TRUE);
         
+        
+        // Special case of css that has query strings.
+        // The query part is used to add a version to force browsers to fetch
+        // a fresh version so we don't need the resource to know about them
+        int queryPos = name.indexOf("?");
+        String query = null;
+        if (queryPos > -1 && name.length() > queryPos) {
+            query = name.substring(queryPos+1);
+            name = name.substring(0,queryPos);
+        }
+        
         Resource resource = context.getApplication().getResourceHandler()
               .createResource(name, library);
 
@@ -120,9 +131,9 @@
             resource = null;
         }
         
-        if (resource != null) {
-        	resourceUrl = context.getExternalContext().encodeResourceURL(resource.getRequestPath());
-        } else if (context.isProjectStage(ProjectStage.Development)) {
+        if (resource == null) {
+            
+            if (context.isProjectStage(ProjectStage.Development)) {
             String msg = "Unable to find resource " + (library == null ? "" : library + ", ") + name;
             context.addMessage(component.getClientId(context),
                                new FacesMessage(FacesMessage.SEVERITY_ERROR,
@@ -130,6 +141,16 @@
                                                 msg));
         }
         
+        } else {
+            resourceUrl = resource.getRequestPath();
+            if (query != null) {
+                resourceUrl = resourceUrl +
+                        (resourceUrl.contains("?") ? "&amp;" : "?") +
+                        query;
+            }
+            resourceUrl = context.getExternalContext().encodeResourceURL(resourceUrl);
+        }
+        
         writer.writeURIAttribute("href", resourceUrl, "href");
         if (media != null) {
             writer.writeAttribute("media", media, "media");





[JAVASERVERFACES_SPEC_PUBLIC-1381] Specify forbidding of use of EL expressions in query params Created: 24/Jul/15  Updated: 24/Jul/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to JAVASERVERFACES-3832 Re-evaluation on EL expressions in JS... Closed
is related to JAVASERVERFACES-3997 Side effect of the fix of JAVASERVERF... Closed

 Description   

The resolution of Mojarra issue JAVASERVERFACES-3832 is to sanitize rhs of query params to not have EL expressions. If an EL expression is encountered, the whole rhs is replaced with the empty string and an INFO message is logged.

This needs to be included in the specification of 7.4.2 Default NavigationHandler Algorithm.



 Comments   
Comment by Ed Burns [ 24/Jul/15 ]

Section 7.4.2 Default NavigationHandler algorithm must also be fixed to replace <view-param> within <redirect> with <redirect-param>.

Also, EL expressions as the <value> of a <redirect-param> should be permitted since these are safe because they can never come from user input, whereas query params can come from user input.





[JAVASERVERFACES_SPEC_PUBLIC-1380] Utilize @FacesDataModel for existing DataModel wrappers Created: 19/Jul/15  Updated: 10/Sep/15

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

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved 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-1078 Have DataModel implementations regist... Reopened

 Description   

JAVASERVERFACES_SPEC_PUBLIC-1078 introduced a mechanism to register and lookup DataModel wrappers for (collection) types.

The components UIData and UIRepeat only utilize this mechanism as a "last resort". Meaning that a type that needs wrapping is first checked against a chain of types for which build-in wrappers are available. Only if none of these match is the @FacesDataModel mechanism consulted.

To have a more consistent model and most importantly allow overrides of build-in wrappers @FacesDataModel should always be consulted and there should be no build-in wrappers anymore.

Since this has backwards compatibility consequences, the best course of action may be to put this new behavior behind a switch and retain the old behavior as well.






[JAVASERVERFACES_SPEC_PUBLIC-1378] Clear the view map on session destroy or when the ACTIVE_VIEW_MAPS_SIZE is reached and a view map is thrown away Created: 04/Jun/15  Updated: 04/Jun/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: EL, Lifecycle, Managed Beans
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mauromol Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The full discussion is at JAVASERVERFACES-3947.
In brief: when the session is destroyed, the beans of all the active view maps are destroyed, however the view maps themselves are not cleared (hence, no PreDestroyViewMapEvent is fired).
The same happens when the eldest view map is thrown away because the ACTIVE_VIEW_MAPS_SIZE is reached.

However, when JSF is integrated with other CDI-like frameworks, like the Spring Framework, for instance through an appropriate EL resolver (org.springframework.web.jsf.el.SpringBeanFacesELResolver in this case) and appropriate hooks on the PostConstructViewMapEvent}}s and {{PreDestroyViewMapEvent}}s, view-scoped beans created by the external framework won't be cleared on the above cases because no {{PreDestroyViewMapEvent is fired (the Mojarra ViewScopeManager takes care of just destroying view-scoped beans managed by JSF BeanManager itself).

Manfred Riem says this is a specification problem, because no strict requirement is stated on this.






[JAVASERVERFACES_SPEC_PUBLIC-1376] Missing StateHolder in Behaviour API for usage in dataTable and alike Created: 22/May/15  Updated: 22/May/15

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

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


 Description   

Recently I came across the fact that the Behaviour API is not using the StateHolder.

This means that EL Expressions in attributes of custom ClientBehaviours are executed during the buildView step and not during the 'rendering' (getScript() ) of the clientBehaviour.

As a consequence, the EL can't reference a var defined in the dataTable.






[JAVASERVERFACES_SPEC_PUBLIC-1375] Faces Flows CDI Bean Defining Annotations Clarification Created: 19/May/15  Updated: 02/Jul/15

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

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


 Description   

The Faces Flow annotation @FlowScoped is clearly defined as a CDI scope. In the CDI spec, however, it's not defined as a "bean defining annotation" http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations

The default bean discovery mode is "annotated", so it seems that with the default CDI configuration @FlowScope beans aren't discovered. The beans are discovered correctly with a bean-discovery-mode="all", which is set via beans.xml

Is it desirable to require this kind of explicit configuration, which can possibly lead to confusion?



 Comments   
Comment by wtlucy [ 02/Jul/15 ]

I've misunderstood the issue here. @FlowScoped is, in fact, a "bean defining annotation" as per the mentioned CDI spec: it falls under the "all other normal scope types" category. From the FlowScoped annotation documentation http://docs.oracle.com/javaee/7/api/javax/faces/flow/FlowScoped.html :

@NormalScope
@Inherited
@Documented
@Target(value=TYPE)
@Retention(value=RUNTIME)
public @interface FlowScoped

So, explicit configuration of the CDI bean-discovery-mode should not be required.





[JAVASERVERFACES_SPEC_PUBLIC-1374] Disable client window through parameter Created: 18/May/15  Updated: 18/May/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Xavier Dury Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When exiting a flow, I sometimes need to redirect the user to some page where the client window id is not relevant anymore. It would be nice if the jfwid parameter could be dropped by simply adding "disable-client-window=true" in the url.

flowBuilder.returnNode("returnFromFlow").fromOutcome("/index.xhtml?faces-redirect=true&disable-client-window=true");





[JAVASERVERFACES_SPEC_PUBLIC-1373] @FlowScoped should be allowed on method and annotation Created: 14/May/15  Updated: 14/May/15

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

Type: Improvement Priority: Major
Reporter: Xavier Dury Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, @FlowScoped annotation can only target types. This makes it impossible to create flowscoped beans through @Produces methods or use @FlowScoped on a @Stereotype annotation.






[JAVASERVERFACES_SPEC_PUBLIC-1372] f:ajax doesn't validate client ID anymore - confusing to starters Created: 20/Mar/15  Updated: 19/Jul/16

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: balusc Assignee: balusc
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Trigger: https://java.net/jira/browse/JAVASERVERFACES-2958

Being able to reference a specific ui:repeat/h:dataTable item via f:ajax render is absolutely a major step forward.

However, the change is a bit overzealous. The f:ajax does not throw an exception anymore on a really invalid ID. This is confusing to starters. This check should be brought back. Instead, the algorithm should be changed to strip any iteration index from the given client ID using the following helper method before scanning the component tree:

private static String stripIterationIndexFromClientId(String clientId) {
	String separatorChar = Character.toString(UINamingContainer.getSeparatorChar(FacesContext.getCurrentInstance()));
	String quotedSeparatorChar = Pattern.quote(separatorChar);
	return clientId.replaceAll(quotedSeparatorChar + "[0-9]+" + quotedSeparatorChar, separatorChar);
}

If the component is still not found, then throw the FacesException as it did before.

It would be great to also specify it somewhere in the spec as e.g. MyFaces <f:ajax> and PrimeFaces <p:ajax> doesn't implement it.



 Comments   
Comment by Manfred Riem [ 24/Mar/15 ]

Validating the client ids for f:ajax does not seem to be specified by any spec requirements. While I agree it would be good to determine what needs to be done this should be addressed by a specification issue, before we continue. Can you please file the associated issue and discuss it in the EG?

Comment by balusc [ 26/Aug/15 ]

We could alternatively improve findComponent() spec and algorithm to cover the iteration index.





[JAVASERVERFACES_SPEC_PUBLIC-1371] 11.4.3.3 (Packaging Flows in Directories) ambiguity Created: 04/May/15  Updated: 02/Sep/15

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3883 faces flow "containing directory" con... Open

 Description   

SH> The relevant spec is JSF 2.2 11.4.3.3 (Packaging Flows in Directories): there it says "The following conventions apply to
SH> flows defined in this manner. Any flow definition in the
SH> corresponding -flow.xml
SH> file will override any of the conventions in the case of a conflict.
SH> Every vdl file in that directory is a view node of that flow.
SH> The start node of the flow is the view whose name is the same as the name of the flow.
SH> ..."
SH> (note the ambiguity - "Every vdl file in that directory" ... which directory?)

EB> "that directory" is the directory containing the corresponding
EB> -flow.xml file. For example, in the case of the following
EB> convention match, "bounded-task-flow/bounded-task-flow-flow.xml",
EB> "that directory" is "bounded-task-flow/".



 Comments   
Comment by Ed Burns [ 05/May/15 ]

Ok, I looked at the built multipagewebinf WAR and see the following
files:

Archive: ./dist/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/jsf_flows_multipagewebinf_web.war
testing: META-INF/ OK
testing: META-INF/MANIFEST.MF OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/classes/com/ OK
testing: WEB-INF/classes/com/sun/ OK
testing: WEB-INF/classes/com/sun/ts/ OK
testing: WEB-INF/classes/com/sun/ts/tests/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/beans/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/beans/FlowBean.class OK
testing: WEB-INF/bounded-task-flow/ OK
testing: WEB-INF/bounded-task-flow/bounded-task-flow-flow.xml OK
testing: WEB-INF/beans.xml OK
testing: bounded-task-flow/ OK
testing: bounded-task-flow/bounded-task-flow.xhtml OK
testing: bounded-task-flow/next_a.xhtml OK
testing: bounded-task-flow/next_b.xhtml OK
testing: index.xhtml OK
testing: nonFlow.xhtml OK
testing: return1.xhtml OK
testing: WEB-INF/web.xml OK

This is indeed strange that there is both a

testing: WEB-INF/bounded-task-flow/ OK

and a

testing: bounded-task-flow/ OK

directory. The spec doesn't say what to do in that case, but it is
clear that in this specific case MyFaces is behaving correctly while
Mojarra is not.

Comment by ren.zhijun.oracle [ 02/Sep/15 ]

Hi Ed,

Can you make this more clear to me? you mean the work flow can be defined both under webapp / directory and WEB-INF/ and that defined in the webapp / should take higher priority, right? what's the current behavior of Mojarra?

BR,
Zhijun





[JAVASERVERFACES_SPEC_PUBLIC-1369] <protected-views><url-pattern> does not work as per Servlet 12.1 and is compared against JSF view ID instead of request URL Created: 18/Mar/15  Updated: 26/Aug/15

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

Type: Bug Priority: Major
Reporter: balusc Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Trigger: http://stackoverflow.com/q/29104597/157882

Problem 1: <protected-views><url-pattern> does not work as per Servlet 12.1. It does merely an exact match and wildcards are not supported. It's also nowhere in JSF 2.2 specification documented how exactly this should be used in faces-config.xml.

Problem 2: During generating action URL, <protected-views><url-pattern> is not compared against final action URL, but against JSF view ID, causing failures when there's a virtual URL based mapping like *.faces or /faces/*.

Another non-related problem 3: the current approach is inefficient. It's for every single view checked on a per-request basis while it could easily be (lazily) checked and stored in view/facelet metadata on an application wide basis.






[JAVASERVERFACES_SPEC_PUBLIC-1368] Static EL Resolution Doesn't Work Created: 28/Apr/15  Updated: 28/Apr/15

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

Type: Bug Priority: Major
Reporter: wtlucy Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

EL 3.0 static field resolution on imported classes does not currently work in any JSF implementation, and it seems to come down to a spec issue. For example, the expression

<h:outputText value="#

{Boolean.TRUE}

" />

Prints out nothing, while it should print "true". Since ScopedAttributeELResolver must be the last resolver in the chain, modifying that resolver to resolve classes (via the importhandler, for example) allows these expressions to be resolved properly.

That fix was implemented by the Tomcat project here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57141
Related Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3362
Related UEL issue: https://java.net/jira/browse/UEL-40






[JAVASERVERFACES_SPEC_PUBLIC-1366] Within Resource Identifier, allow resourceName to have path separator Created: 05/Mar/15  Updated: 03/Feb/16

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

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

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1141 Specify that all parts of a resource ... Closed

 Description   

The expert group discussion for JAVASERVERFACES_SPEC_PUBLIC-1141 concluded that resourceName should be allowed to contain path separators.

An insufficient response to this conclusion was the following change to ResourceHandler.createResource()

  • Added this text to createResource(string)

For historical reasons, this method operate correctly when the
argument resourceName is of the form libraryName/resourceName, even
when resourceName contains '/' characters.

The following additional spec actions must be taken.

1. Fix the wording of the text of createResource() to be:

For historical reasons, this method must operate correctly when the argument resourceName is of the form libraryName/resourceName, even when resourceName contains '/' characters.

2. In section 2.6.1.3 modify the sentence starting with "The set of characters..." to be:

The set of characters that are valid for use in the localePrefix, libraryName, libraryVerison, resourceName and resourceVersion segments of the resource identifier is specififed as XML NameChar excluding the path separator and ‘:’ characters, with the exception of resourceName, which may contain the path separator character.



 Comments   
Comment by Arend v. Reinersdorff [ 18/Mar/15 ]

If resourceName may contain path separators, could that not create ambiguity with libraryVersion or resourceVersion?

For example the resourceIdentifier "libName/1_0/resName/2_0" might mean
libraryName=libName, libraryVersion=1_0, resourceName=resName, resourceVersion=2_0
or
libraryName=libName, libraryVersion=<empty>, resourceName=1_0/resName/2_0, resourceVersion=<empty>

libraryName is restricted to prevent ambiguity with libraryVersion (JSF 2.2 Spec, page 78). Maybe resourceName should have a similar restriction?

Or maybe this ambiguity is already dealt with elsewhere? For instance I didn't read through the whole algorithm in 2.6.1.4.

Comment by Arend v. Reinersdorff [ 18/Mar/15 ]

Other possible problems:

  • path separator charactar at the beginning or end "/resName/"
  • multiple path separators "res//Name"
Comment by Arend v. Reinersdorff [ 03/Feb/16 ]

Not addressed by JSF 2.3 Early Draft Review.





[JAVASERVERFACES_SPEC_PUBLIC-1363] Add cols attribute to selectManyCheckbox Created: 12/Feb/15  Updated: 12/Feb/15

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

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


 Description   

If a bigger list of checkboxes should be displayed, either the page gets very wide or height. It would be useful to display two or more columns of checkboxes. Frankly, the layout should be restricted to a spcified number of columns and automatically gets extended in height.

add attribute "cols" of type int to selectManyCheckBox. If omitted, assume a default of 1.

If layout="pagedirection" (vertical) than cols > 2 creates multiple cols of checkboxes. The checkboxes will be created from left to right until a count of "cols" is reached. Then the layout continues with the next line. Thus, the total height is apx. n/cols.

If layout="linedirection", than cols is ignored. Optionally, an attribute lines is used for this layout. Now n/lines cols will be created.



 Comments   
Comment by muellermi [ 12/Feb/15 ]

example:

layout="pagedirection"
[] item1
[] item2
[] item3
[] item4
[] item5

layout="pagedirection" cols="2"
[] item1 [] item2
[] item3 [] item4
[] item5

ayout="linedirection" lines="2"
[] item1 [] item2 [] item3
[] item4 [] item5





[JAVASERVERFACES_SPEC_PUBLIC-1360] Address corner cases as a result of issue #1127 Created: 03/Feb/15  Updated: 26/Aug/15

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

Type: Bug Priority: Critical
Reporter: Manfred Riem Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The issue here is that the optimization intended by 1127 cannot be guaranteed in light of two important cases.

case_Ajax

Multiple rapid Ajax submits cause the view tree to be shared across multiple concurrent requests.

case_MultiSubmit

Multiple rapid non-Ajax submits cause the view tree to be shared across multiple concurrent requests.






[JAVASERVERFACES_SPEC_PUBLIC-1359] Resolve views from dedicated folder Created: 02/Feb/15  Updated: 21/Aug/15

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: Ed Burns
Resolution: Unresolved 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-1099 Resolve views by convention from dedi... Closed
is related to JAVASERVERFACES-3791 Implement JAVASERVERFACES_SPEC_PUBLIC... Open

 Description   

The Facelets VDL will by default try to resolve a view in the root of a web application or in META-INF/resources of a jar file (where the jar location automatically follows from using ServletContext#getResource)

In addition to this primary location I would like to propose loading views from a dedicated folder called "/views". This should be done in analogy to how contracts are loaded from "/contracts" and resources from "/resources", including the ability to let a user configure an alternative location.

The use case for this is letting the user easily configure a simple alternative location from where views are loaded and opening up more advanced processing by the runtime.

This more advanced processing is not part of this issue. This issue is strictly about providing a folder from which views (and only views) can be loaded.

Note that this issue is split-off from JAVASERVERFACES_SPEC_PUBLIC-1099, which asked about this folder but also asked about the advanced processing.



 Comments   
Comment by arjan tijms [ 03/Feb/15 ]

Sort of sub-issue of 1099





[JAVASERVERFACES_SPEC_PUBLIC-1358] Enhance conversation handling Created: 02/Feb/15  Updated: 03/Feb/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: 2.3
Fix Version/s: None

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


 Description   

During a process flow, using @ConversationScoped beans, sometime it is useful to start a new (second, third, ...) conversation.
Using the standard postback navigation, JSF always injects the same conversation instance.
One approach to force a fresh conversation is to use <h:link ...> instead of <h:commandLink...>
Since the outcome of link is computed whilst rendering the page, navigation is static.
commandLink on the other hand allows to compute the navigation on click.
I propose these enhancements:

<h:commandLink createConversation="true" ...>

With this optional argument JSF does not inject the existing instance of a session but a fresh one.

<h:link output="#{...}" lazyCalculation="true" ...>

This renders a link without target <a href="" onclick="#{bean.navigationFunction}">...</a> and an onclick handler.
The handler's duty is to perform a partial request, retrieve the result of bean.navigationFunction (return value is String) and then perform a get navigation, e.g. by window.location.href = navOutcome;






[JAVASERVERFACES_SPEC_PUBLIC-1357] Make enum constants accessible from EL. Created: 01/Feb/15  Updated: 01/Feb/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: EL
Affects Version/s: 2.3
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: muellermi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Enum constants shall be accessible

Let me explain this by an example. Given an enum

public enum Page {

  Welcome("/welcome"),
  // many more...
  AdminWelcome("/admin/welcome");
  
  private Page(String url) {
    _url = url;
  }
  private final String _url;

  public String getUrl() {
    return _url + ".xhtml";
  }

  public String getRedirectUrl() {
    return _url + ".xhtml?faces-redirect=true";
  }
}

The goal is to access an URL of a specific member of that enum from an EL.

Declaring the enum as a named CDI bean (@Named) grants access to the methods, but the constants.

By now, there is an ugly workaround by mapping all entries and delegating from another bean to this

{enum Page)

  private static Map<String, String> _pages;

  public static Map<String, String> getPages() {
    if (_pages == null) {
      _pages = new HashMap<>();
      for (Page page : Page.values()) {
        _pages.put(page.name(), page.getUrl());
      }
    }
    return _pages;
  }

(otherBean)

  public Map<String, String> getPages() {
    return Page.getPages();
  }

Now access within EL is possible:

#{otherBean.pages.AdminCategoryEditor}}

--> The goal is to directly access the enum

#{page.AdminCategoryEditor.url}

The enum is used in a method

(otherBean)

  public String navigate(String topic) {
    // perform some useful stuff
    return topic;
  }

This can be used from EL

#{otherBean.navigate(otherBean.pages.AdminWelcome)}

It would be preferred to use an enum in the navigation method:

(otherBean)

  public String navigate(Page page) {
    // perform some useful stuff
    return page.getUrl();
  }

--> The goal is to directly access the enum

#{otherBean.navigate(page.AdminWelcome)}


 Comments   
Comment by muellermi [ 01/Feb/15 ]
{otherBean.navigate(AdminWelcome)}

should be

{otherBean.navigate(page.AdminWelcome)}




[JAVASERVERFACES_SPEC_PUBLIC-1354] Allow specify node-on-return in flow call node Created: 23/Jan/15  Updated: 23/Jan/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: None
Fix Version/s: None

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


 Description   

Nested flow has to know where to go (name of node in calling flow) when returning back to calling flow.
To encapsulate nested flow we should allow to specify node where to go after return from nested flow in the flow-call-node.

Conversation from another Jira issue:
Ed>You mean you'd like the "where to go after return" to be specified in
Ed>the flow-call node? That's not a bad idea. I can see adding that,
Ed>making it trump whatever value is returned from the called flow. Would
Ed>that satisfy?

Yes, that would be great. The nested flow would be encapsulated and it wouldn't have to know anything about calling flow's node names. It would be like when calling nested flow - you specify nested flow name, but not node name in nested flow.






[JAVASERVERFACES_SPEC_PUBLIC-1352] More clearly define requirements for one request cycle especially with respect to concurrency Created: 21/Jan/15  Updated: 26/Aug/15

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

Type: Improvement Priority: Major
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3690 Possible Concurrency Issues in UIRepeat Closed




[JAVASERVERFACES_SPEC_PUBLIC-1348] Better define usage of Flash, specifically with respect to response buffer size Created: 12/Jan/15  Updated: 30/Nov/16

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

Type: Improvement Priority: Major
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1320 Expose Flash for use from MVC Closed

 Comments   
Comment by Manfred Riem [ 30/Nov/16 ]

As this is not adding any value beyond clarification I am lowering its priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1342] Support @Inject of current flow like "@Inject Flow currentFlow" Created: 12/Dec/14  Updated: 10/Aug/15

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CDI Conversation scope is injectable into @ConversationScoped beans like this:

@Inject
Conversation currentConversation

The same should be true for the current Flow for @FlowScoped beans.






[JAVASERVERFACES_SPEC_PUBLIC-1341] Default value for viewParam Created: 10/Dec/14  Updated: 19/Jun/15

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

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


 Description   

What about allowing the definition of a default value for a view-parameter?

Example

Defining number of displayed items (pagination feature) as a view-parameter but still keeping default value within xhtml and not java bean.

Following example is a very clean approach provinding a default value.

<f:viewParam name="pageSize" value="#{bean.pageSize}" default="10"/>
<p:dataTable rows="#{bean.pageSize}"/>

Currently there are two workarounds which have no clean separation between markup and java code:

Workaround 1

Passing the default value to bean.

<f:viewParam name="pageSize" value="#{bean.pageSize}"/>
<f:event type="preRenderView" listener="#{bean.initPreRenderView(10)"/>
<p:dataTable rows="#{bean.pageSize}"/>
private int pageSize;

public void initPreRenderView(int pageSize)
{
	if (this.pageSize == 0)
		this.pageSize == pageSize;
}

Workaround 2

Hardcoding the default value in bean. But markup should be responsible and not bean.

<f:viewParam name="pageSize" value="#{bean.pageSize}"/>
<p:dataTable rows="#{bean.pageSize}"/>
private int pageSize = 10; 


 Comments   
Comment by djmj [ 19/Jun/15 ]

When using `ìncludeViewParams=true` on a link or command or using programmatically `getBookmarkableURL` the view parameters who's value equal their default value can be ignored.

This solves the problem of irrelevant parameters appended to link components. This behavior can be optional or optionally be deactivated using a param like `index.xhtml?appendDefaultValues=true`

A `<h:link>` with `<f:param name="pageSize" value="10">` can be ignored in the final URL.





[JAVASERVERFACES_SPEC_PUBLIC-1340] Allow ViewHandler to be injectable Created: 04/Dec/14  Updated: 26/Aug/15

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

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





[JAVASERVERFACES_SPEC_PUBLIC-1339] Clarify search requirements for resourceHandler.createResource with respect to the web app root. Created: 03/Dec/14  Updated: 03/Dec/14

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

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved 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-1338 Clarify pseudo code in 2.6.1.4 Librar... Resolved

 Description   

Issue JAVASERVERFACES-3428 is about the Locale prefix for contracts. Turns out the fix for this intersects with JAVASERVERFACES_SPEC_PUBLIC-719 in an undesirable way.

Please consider this diff:

--- jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceManager.java	(revision 9751)
+++ jsf-ri/src/main/java/com/sun/faces/application/resource/ResourceManager.java	(revision 9752)
@@ -354,8 +354,10 @@
      * specified <code>arguments</code>.
      * <p/>
      * <p> The lookup process will first search the file system of the web
-     * application.  If the library is not found, then it processed to
-     * searching the classpath.</p>
+     * application *within the resources directory*.  
+     * If the library is not found, then it processed to
+     * searching the classpath, if not found there, search from the webapp root
+     * *excluding* the resources directory.</p>

The last part, "search from the webapp root excluding the resources
directory" is the part that Frank's initial two patches for JAVASERVERFACES-3428 invalidated.

This part is also represented in the changebundle that implemented JAVASERVERFACES_SPEC_PUBLIC-719: https://java.net/jira/secure/attachment/49497/changebundle.txt

EB> Usage4: When trying to serve up a resource request from the filesystem.

Implicitly done.






[JAVASERVERFACES_SPEC_PUBLIC-1336] ViewScope and client side state saving is broken Created: 04/Nov/14  Updated: 04/Nov/14

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

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


 Description   

Easy to reproduce: use CS state saving... store something in view scope... stop your server (ensure it doesn't restore sessions)... start server and observe viewScope data is lost.



 Comments   
Comment by lu4242 [ 04/Nov/14 ]

JSF 2.2 javadoc of UIViewRoot.getViewMap(boolean create) says this:

"... For reasons made clear in ViewScoped, this map must ultimately be stored in the session. For this reason, a true value for the create argument will force the session to be created with a call to ExternalContext.getSession(boolean). ..."

Before JSF 2.2, view scope was stored with the view state on client side state saving.





[JAVASERVERFACES_SPEC_PUBLIC-1330] Allow flexible resource mapping for .js or .css or other files served by ResourceHandler Created: 23/Oct/14  Updated: 31/Oct/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From EG list discussion:

I just wanted to note an issue that has been around for some time and
it is related. Sometimes you have a bunch of .js or .css files and you
want to group all of them into a single file. To do that, you can
create a custom ResourceHandler and redirect the resource requests to
the suggested resource that joins all the files or use some library
that has already that logic.

It would be great if JSF by default could handle that "alias" logic.
If the project stage is Development then load the uncompressed files,
but if it is Production use this compressed javascript. That would
improve performance and has been mentioned in the past. Some people
has already provided solutions.

Please note this logic can be made to override jsf.js javascript as
well. But from design perspective I don't feel very good about have
alternate versions of jsf.js, instead I would like to make jsf.js work
even with portlets.

It is a fact that JSF is very pluggable from the java perspective, but
the fact that you cannot customize the behavior of jsf.js (pass config
params on initialization like project stage and others) becomes a
problem.

In MyFaces for example, there is a code
that according to the project stage (dev or prod) it uses the
uncompressed or the compressed version of the file.

In MyFaces we have two paths:

/META-INF/internal-resources (for uncompressed versions of the js files)
/META-INF/resources (for compressed and production-ready versions of
the js files)

and a custom resource handler that uses internal-resources if project
stage is development.

The central point is sometimes you need to override the resources, and to
do that you need to create custom implementations of ResourceHandler,
so you end with a similar logic scattered across multiple libraries.

Suppose this example:

a.css
b.css

And you create

a_b.css

Now you have these lines:

<h:outputStylesheet name="a.css"/>
<h:outputStylesheet name="b.css"/>

The idea is when a.css or b.css is resolved, it returns a Resource
instance that represents a.css or b.css, but in fact it is holding
a_b.css, so it should be only one link entry rendered on the
response.






[JAVASERVERFACES_SPEC_PUBLIC-1329] @NotNull for f:viewParam is not triggered when the parameter is missing in the query string Created: 21/Oct/14  Updated: 28/Aug/15

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: balusc Assignee: Ed Burns
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 25 minutes
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVASERVERFACES-3339 @NotNull for f:viewParam is not trigg... Closed

 Description   

@NotNull bean validation isn't being considered for <f:viewParam> whereas its own required="true" and a nested <f:validateRequired> (as per issue 3058) are correctly being considered.

I'd expect the @NotNull also being considered the same way.



 Comments   
Comment by Ed Burns [ 26/Aug/15 ]

Not enough information in the bug report to take action.

Comment by Ed Burns [ 27/Aug/15 ]

Some automated tests are failing. Revert to see if they clear out. The failures don't seem related, though.





[JAVASERVERFACES_SPEC_PUBLIC-1321] Leverage HTTP2 Server Push from JSF Created: 13/Oct/14  Updated: 08/Aug/16

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

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


 Description   

Because JSF 2.3 is allowed to depend on Java EE 8, we can take advantage of Servlet 4.0 features such as server push.



 Comments   
Comment by balusc [ 08/Aug/16 ]

Currently, JSF 2.3 already features JSR356 websocket based push as per https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1396





[JAVASERVERFACES_SPEC_PUBLIC-1317] Clarify how h:link should encode the URL for UIParameters which resolve to a null-value Created: 11/Oct/14  Updated: 31/Oct/14

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

Type: Improvement Priority: Minor
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the tag spec for h:link does not say what happens if a h:link has a f:param child whose value resolves to null; for example:

<h:link outcome="test">
<f:param name="testParam" value="#

{myBean.testValue}"/>
<f:param name="testParam2" value="testValue"/>
</h:link>

If f:param should work inverse to f:viewParam, then any f:param with a null value should be skipped completely, so the above example should render a href attribute with value "test.xhtml?testParam2=testValue" when #{myBean.testValue}

resolves to null.

In fact this was the (unspecified) behavior of Mojarra 2.1.x, while 2.2.x now throws a null pointer exception (https://java.net/jira/browse/JAVASERVERFACES-3355).

This clarification would be a huge advantage when using GET parameters in JSF, especially in conjunction with View Parameters. If a View Parameter is omitted its value will be null. If you want to pass it to another page using f:param currently in 2.2 you always have to write custom code that makes sure it does not resolve to null to prevent runtime exceptions.






[JAVASERVERFACES_SPEC_PUBLIC-1316] Support @Inject on JSF artifacts Created: 09/Oct/14  Updated: 08/Aug/16

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

Type: New Feature Priority: Critical
Reporter: Manfred Riem Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVASERVERFACES_SPEC_PUBLIC-527 Support @Inject for FacesContext Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1309 Support @Inject for ExternalContext Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1323 Support @Inject for the applicationMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1327 Verify @Inject HttpSession support Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1333 Support @Inject for UIViewRoot Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1335 Support @Inject for the viewMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1345 Support @Inject for the sessionMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1349 Support @Inject for FacesConverter Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1350 Support @Inject for FacesValidator Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1351 Support @Inject for FacesBehavior Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1353 Support @Inject for RequestCookieMap Resolved
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1283 Allow for injection on UIComponent, C... Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-763 Web Container injection support shoul... Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is related to JAVASERVERFACES_SPEC_PUBLIC-1287 Make @javax.faces.bean.ManagedBean me... Closed

 Comments   
Comment by Manfred Riem [ 15/Oct/14 ]

Make sure the following artifacts are mentioned in the spec PDF when describing @Inject support

  • applicationMap
  • externalContext
  • facesContext
  • session (delegating that responsibility back to default CDI runtime)
  • sessionMap
  • view
  • viewMap
  • converters annotated with @FacesConverter (and managed = true)
  • validators annotated with @FacesValidator (and managed = true)
  • behaviors annotated with @FacesBehavior (and managed = true)
  • requestCookieMap
Comment by Ed Burns [ 14/Jan/15 ]

Do you have any plans to support Component, Behavior and Validator?

Comment by Manfred Riem [ 14/Jan/15 ]

In Progress

Comment by Manfred Riem [ 15/Jan/15 ]

Note @Inject on UIComponent instances will not be done as the view state is managed outside of CDI.

Comment by arjan tijms [ 30/Jul/15 ]

Note @Inject on UIComponent instances will not be done as the view state is managed outside of CDI.

IFF there would be an @ComponentScope then as a side-effect of that it may became feasible to allow injection of the UIComponent instances.

Comment by balusc [ 08/Aug/16 ]

Injection of @FacesContext is currently not done properly. It's currently request scoped, but it should actually be "faces context scoped", as an (error) dispatch can create a new FacesContext within the very same request. The current approach will throw ISE from assertNotReleased() when the FacesContext is being referenced in EL.





[JAVASERVERFACES_SPEC_PUBLIC-1315] Simplify EL resolver chain by using CDI Created: 08/Oct/14  Updated: 20/Aug/15

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

Type: Improvement Priority: Critical
Reporter: Manfred Riem Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Blocks
is blocked by JAVASERVERFACES-3478 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1386 Let CDI handle #{flowScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1387 Let CDI handle #{header} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1388 Let CDI handle #{headerValues} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1389 Let CDI handle #{initParam} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1390 Let CDI handle #{param} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1391 Let CDI handle #{paramValues} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1392 Let CDI handle #{request} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1393 Let CDI handle #{requestScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1394 Let CDI handle #{resource} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1311 Let CDI handle #{facesContext} EL res... Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1322 Simplify #{externalContext} to use Ex... Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1325 Let CDI handle #{applicationScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1328 Let CDI handle #{session} EL resolving Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1331 Let CDI handle #{application} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1332 Let CDI handle #{view} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1334 Let CDI handle #{viewScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1383 Let CDI handle #{cc} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1384 Let CDI handle #{component} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1385 Let CDI handle #{flash} Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open

 Comments   
Comment by Manfred Riem [ 15/Oct/14 ]

Make sure the appropriate spec text is added for:

application - describe that this only does EL resolving
applicationScope
externalContext
facesContext
session - describe that this only does EL resolving (core CDI does the @Inject for session)
view
viewScope

Comment by arjan tijms [ 30/Jul/15 ]

This is the current overview of the EL implicit variables handled by CDI:

* application
*+ applicationScope (applicationMap)
cc
component
+ cookie (requestCookieMap)
*+? externalContext
*+ facesContext
flash
flowScope
header
headerValues
initParam
param
paramValues
request
requestScope
resource
* session
+ sessionScope (sessionMap)
*+ view (view root)
*+ viewScope (viewMap)

* = Implemented via issue 1315 (this issue)
+ = Implemented via issue 1316
? = new implicit EL variable

Preliminary implementation of entries not yet committed in the 2.3 trunk: https://github.com/omnifaces/mojarra/commit/1fa3ad6f0919eedc613cf21d4390a9d20c80e39c

Comment by Manfred Riem [ 20/Aug/15 ]

r=mriem

Comment by arjan tijms [ 20/Aug/15 ]

Applied to 2.3 trunk:

svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1315, moved qualifiers to new annotation package. r=mriem"
Adding jsf-api/src/main/java/javax/faces/annotation
Adding jsf-api/src/main/java/javax/faces/annotation/ApplicationMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/RequestCookieMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/SessionMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/ViewMap.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/ApplicationMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/RequestCookieMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/SessionMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/ViewMapAnnotationLiteral.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectApplicationMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectApplicationMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectRequestCookieMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectRequestCookieMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectSessionMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectSessionMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectViewMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectViewMapBean.java
Transmitting file data ................
Committed revision 15029.





[JAVASERVERFACES_SPEC_PUBLIC-1314] Change @FacesConverter to handle both value and forClass attributes Created: 03/Oct/14  Updated: 31/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping, Validation/Conversion
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Hanspeter Duennenberger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    

 Description   

The Javadoc of @FacesConverter contains this text:

 * <p>The preceding text contains an important
 * subtlety which application users should understand.  It is not
 * possible to use a single {@code @FacesConverter} annotation to
 * register a single {@code Converter} implementation both in the {@code
 * by-class} and the {@code by-converter-id} data structures.  One way
 * to achieve this result is to put the actual converter logic in an
 * abstract base class, without a {@code @FacesConverter} annotation,
 * and derive two sub-classes, each with a {@code @FacesConverter}
 * annotation.  One sub-class has a {@code value} attribute but no
 * {@code forClass} attribute, and the other sub-class has the converse.</p>

This limitation seems arbitrary. If both attributes of the annotation would be handled, the workaround mentioned as in above cited Javadoc would not be necessary.
The required changes in ConverterConfigHandler.java are small.



 Comments   
Comment by Ed Burns [ 26/Aug/15 ]

The distinction is not arbitrary. If you have both converterId and forClass, the system will normally never use the converterId to cause the converter to be created because the forClass creation case happens first in the common case of a ValueExpression bound property. I suppose your proposed change would be useful in the case of non-ValueExpression bound properties, such as just using local values on a component.

I'll investigate it, but it will have to go behind the 2.3 opt-in switch.

Comment by Ed Burns [ 26/Aug/15 ]

I talked this over with Manfred and he suggested an alternate approach.

What about if we added forClass as an attribute for <f:converter>? Then you could use @FacesConverter(forClass=Foo.class) and cover both the following cases:

1. Use a converter by class

<h:inputText value="#

{bean.fooProperty}

" />

2. Use the same converter using the <f:converter> tag

<h:inputText > <!-- local value, no ELExpression -->
<f:converter forClass="Foo.class" />
</h:inputText>

It's not exactly what you want, but it does allow you to use the converter in both usages.

Will this satisfy?

Comment by Hanspeter Duennenberger [ 31/Aug/15 ]

Hi Ed.

On a first look I liked the idea of <f:converter forClass="Foo.class" />.
On the other side one could say the converter-Id is just a shorter name for the converter class name.
In real life the fully qualified converter class name can become very long ...

I was also thinking of how converter can be configured in faces-config.xml.
There it is possible to define in two converter elements the same converter-class with a converter-id and with the converter-for-class construct.
The same possibility is not given with the @FacesConverter annotation. If I need both kind of converter configuration I must either define both in faces-config.xml, or one in faces-config.xml and one with the @FacesConverter annotation.
If I want to do it without faces-config,xml converter elements I would need to subclass the Converter class just to have a place to put the second @FacesConverter annotation.

Sometimes it is needed to have a less strong typed attribute on a bean and then the converter-for-class is not exact enough - then it should be possible to use the converter-id.

The <f:converter forClass="the.absolute.name.of.the.Converter" /> is just yet another notation to select a Converter - but converter-id and converter-for-class would be enough already.

The Issue was just about allowing to configure one Converter class for both use case, with converter-id and with the converter-for-class selection using the @FacesConverter annotation.

Best regards
Hanspeter





[JAVASERVERFACES_SPEC_PUBLIC-1313] EL support in faces-config.xml for dynamic contracts Created: 29/Sep/14  Updated: 31/Oct/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping, EL
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: smutje Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Motivation
------
Introducing dynamic contracts is a tedious task because one has to change every view (http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/ResourceLibraryContract/resourceLibraryContract.html, "Changing Templates Dynamically") and the introduction of EL support for the faces-config would centralize this behavior in one place.

Proposal
------
Support the use of EL in the faces-config, e.g. to set the value of a "contracts" node of a "contract-mapping" similar to the following:

<faces-config version="2.2" xmlns="http://xmlns.jcp.org/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
    http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd">
    <application>
        <resource-library-contracts>
            <contract-mapping>
                <url-pattern>/*</url-pattern>
                <contracts>#{contracts.contract}</contracts>
            </contract-mapping>
        </resource-library-contracts>

    <!-- ... --->

Where contracts is a bean holding the contract string as contract property.






[JAVASERVERFACES_SPEC_PUBLIC-1308] UISelectOne and UISelectMany should validate arrays deeply. Created: 08/Sep/14  Updated: 08/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Spomf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

According to the specification, UISelectOne and UISelectMany shall extend the standard validation behavior of UIInput by ensuring that the selected value is equal to the available options. I propose that the selected value must be deeply equal instead. In that way, the options may be arrays.






[JAVASERVERFACES_SPEC_PUBLIC-1303] Add configuration to retrieve locale Created: 30/Aug/14  Updated: 30/Aug/14

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

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


 Description   

Goal: implement a language switcher for a session

It's quite easy to switch the language:

FacesContext.getCurrentInstance().getViewRoot()
.setLocale(new Locale(languageCode));

But, as the spec says, JSF will determine the language on every request by the browser defaults. Thus, the selected value will be overwritten on every request. To keep the selected language for a session, it is needed to restore the chosen local on every request by the memorized selection.This is technical no problem but an annoying job.

The request is to specify an optional configuration property like 'keepLocale'.(="session"). If not defined, the locale will be determined as is, to be compatible to the existing behavior. If set to session, the locale will be kept for the whole session until it is changed programmatically.






[JAVASERVERFACES_SPEC_PUBLIC-1302] Add JavaScript Hooks to fileUpload Created: 29/Aug/14  Updated: 29/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: muellermi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Allow to add a listener for "progress",
(and "complete", "error", "abort")

The idea is to be able to implement a progress bar without any need to write an own upload servlet.






[JAVASERVERFACES_SPEC_PUBLIC-1299] jsf.ajax.response should not send 'success' events in case of an error Created: 14/Aug/14  Updated: 14/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

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


 Description   

This is a followup of JAVASERVERFACES-3103.

If the ajax response contains an error the clientside JS (jsf.ajax.response) sends an "serverError" event to the registered listeners AND just after this an "success" event to registered listeners. This leads to malfunctions if the application depends on both of these events. The "success" event is unexpected in the server side error (e.g. Exception in the triggered ajax listener) case here.

jsf.js
line 2255: sendError(request, context, "serverError", null, errorName, errorMessage);
line 2256: sendEvent(request, context, "success");

At the moment this behavior is by design but it does not make sense:
Two concerns are mixed up here: processing the response on the client side and processing the request on the server side.

The response is indeed successfully processed on the client side. But the client side does not need to be notified by this explicitly in that case. The processed result is already available in the onerror event handler.
There is no more information available in the "success" event and this behaviour makes it complicated to handle server side errors on the client.

For the enduser the result of a failed processed request or a successfully proccessed server side error is the same: there is an error not a successfully performed action.

So how can one dedect a "success" event in a server error case at the moment:

  • explicitly analyse the data transmitted
  • remember there was already an error event before

Both options are not necessary if the spec would not require to send the "success" event in a server error case.

Manfred Riem agrees with me.






[JAVASERVERFACES_SPEC_PUBLIC-1298] Resolve backward incompatible change regarding PartialResponseWriter.writePreamble() Created: 11/Aug/14  Updated: 10/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

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

Issue Links:
Related
is related to JAVASERVERFACES-3366 Fix ResponseWriter backwards compatib... Closed

 Description   

Issue JAVASERVERFACES_SPEC_PUBLIC-1069 was introduced to cover a problem with jsf.js and Portets. Unfortunately, the resolution was backward incompatible for parties that implement ResponseWriter.



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

These were done at the request of the portlet community:

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

And in fact Blake did weigh in on this way back then:

https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/49

B> I guess I would question whether any fixes for 1) or 2) are
B> necessary. The proposal before is to make non-backwards compatible
B> behavior changes. For such a change, I would want to see some clear
B> benefits. In this case, the Bridge has a work-around. It doesn't
B> sound like the work-around is hurting performance--nor does it sound
B> like the Bridge is being asked to do something outside of its
B> purview--which in this case is turning a document-oriented page into
B> a fragment.

And Neil Griffin replied with a justification:

https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/57

But there the discussion appears to have ended. It looks like we ended
up going with Neil's suggestions.

Comment by Ed Burns [ 11/Aug/14 ]

Let me clarify why Blake asserts this is a backward incompatible change.

In JSF 2.1, the writing of the XML preamble was the responsibility of the PartialResponseWriter.startDocument().

In JSF 2.2, we moved that out into PartialResponseWriter.writePreamble(), removing it from PartialResponseWriter.startDocument(). This means that any code that was counting on the XML preamble having been written based on a JSF 2.1 runtime will fail when running against a JSF 2.2 runtime.

Comment by btsulliv [ 14/Aug/14 ]

To clarify further, this change was guaranteed to be incompatible because all pre-2.2 code had to rely on startDocument() writing any necessary XML declaration or docType as the new methods:

writePreamble

public void writePreamble(String preamble)
throws IOException
Write a string containing the markup specific preamble. No escaping is performed. The default implementation simply calls through to Writer.write(java.lang.String) .

The implementation makes no checks if this is the correct place in the response to have a preamble, nor does it prevent the preamble from being written more than once.

Parameters:
preamble - Text content of the preamble
Throws:
IOException - if an input/output error occurs
Since:
2.2
writeDoctype

public void writeDoctype(String doctype)
throws IOException
Write a string containing the markup specific doctype. No escaping is performed. The default implementation simply calls through to Writer.write(java.lang.String) .

The implementation makes no checks if this is the correct place in the response to have a doctype, nor does it prevent the doctype from being written more than once.

Parameters:
doctype - Text content of the doctype
Throws:
IOException - if an input/output error occurs
Since:
2.2

Did not exist before 2.2 and therefore could never have been called. This reason should have been sufficient on its own to have precluded the current design as minor releases are not allowed to break compatibility and even major releases should have a could have a good reason for doing so. In this cases, even the justification was sorely lacking:

"For JSF 2.2 portlet alignment, I think it's important (from a design perspective) to fix servlet environment assumptions in the JSF API or Spec. If such assumptions are present in a JSF implementation, then the portlet bridge can simply perform overrides at the proper extension points. The solutions below seem reasonable to me, since they appear to be implementation details that do not affect existing JSF applications."

It should be pointed out that:
1) The rationale is incorrect--the problem in this case wasn't that the JSF ResponseWriter was servlet-oriented, but rather, that the ResponseWriter assumed that startDocument() would actually begin writing a new document. In the Portlet case, the bridge wanted to write its own envelope content and then embed the payload from the wrapped writer inside this content. When the envelope was XML, the XML declaration and doctype caused problems.

2) The bridge had already worked around this problem by parsing the beginning of the wrapped content and discarding the XML declaration and docType. Since this content was at the beginning of the output of the wrapped content, this was actually pretty fast. The advantage of the change was that it made this aspect of the Portlet bridge easier to re-implement and faster (though this part isn't performance critical).

To make this worse, the rest of the design was messed up:

1) the two new methods should never have been public as an application calling these methods can only cause harm. This is because
a) In order to pass the correct parameters, the application would have to know the implementation of the ResponseWriter
b) If the application passes different parameters than the ResponseWriter expects, bad things can happen

The point of adding these methods as hooks for a ResponseWriter implementation could have been met with protected methods, thus avoiding potential new sources of error.

These problems are compounded by the lack of documentation surrounding the new contract in the javadoc for the class.

While it is clear that we should have never added these methods in the first place, let alone in the current fashion, we are stuck with trying to make these work the best we can. To that end we have two approaches:

Simple:

Admit that this was a bad idea. Make the new methods no-ops, go back to the old behavior and put the portlet bridge code back as well. This is by far the smallest change.

Change the incompatibility from the callers of the ResponseWriters (application developers) to the ResponseWriter implementations. This is actually less compatible than making the apis no-ops.

1) Document that while writeDocType and writePreamble are public, they should only be called by ResponseWriter implementations. Application developers should continue to only call startDocument
2) Document that neither writeDocType not writePreamble should be called after startDocument, that writePreamble should preceed any call to writeDocType and implementations are allowed, but not required to throw an IllegalStateException if this occurs.
3) Require that ResponseWriter implementations call writePreamble if writeDocType is called without a preceeding call to writePreamble and both
a) This ResponseWriter supports docTypes
b) This ResponseWriter supports a preamble
4) Require that ResponseWriter implementations call writeDocType if startDocument is called without a preceeding call to writeDocType (which will then cause the correct preamble to be written, if necessary)
5) Allow the ResponseWriter to throw IllegalArgumentExceptions if the parameters passed to writePreamble or writeDocument

This is still an incompatible change for ResponseWriter implementors, who now need to maintain state. Note that if we had made the new methods protected and simply requried that the ResponseWriter implementations call these methods from startDocument, the change would have still been incompatible (as we are placing a new requriement on ResponseWriter implemetors), but much simpler overall, as the expectations for subclassers calling things correctly are less sever than for application developers.

Comment by Ed Burns [ 05/Sep/14 ]

This is still an incompatible change for ResponseWriter implementors, who now need to maintain state. Note that if we had made the new methods protected and simply requried that the ResponseWriter implementations call these methods from startDocument, the change would have still been incompatible (as we are placing a new requriement on ResponseWriter implemetors), but much simpler overall, as the expectations for subclassers calling things correctly are less sever than for application developers.

Looking at the Java EE compatibility guidelines < https://java.net/projects/javaee-spec/pages/CompatibilityRequirements >, I don't see anything that forbids making formerly public methods protected. Blake, if we were to do this and required your steps 1) and 2) above, would that be sufficient?





[JAVASERVERFACES_SPEC_PUBLIC-1297] Improvements over Facelet Functions Created: 02/Aug/14  Updated: 02/Aug/14

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

Type: Improvement Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There are some possible improvements that can be done about define facelet functions:

  • First of all, you need to register them in a .taglib.xml file. Example:

<function>
<function-name>formatMessage</function-name>
<function-class>net.myproject.view.util.JSFFunctions</function-class>
<function-signature>
java.lang.String formatMessage(java.lang.String, java.util.Locale, java.lang.String)
</function-signature>
</function>

Shouldn't be more simple to use annotations?

@FaceletLibrary(namespace="http://...")
public class MyLib {

@FaceletFunction
public static String joinWithSpaceDelim(String ...with) {

}

}

  • The function signature cannot receive optional parameters or arrays because internally facelets parse the method signature and only allow classes.

Other possible idea to consider is allow to define facelet functions in a similar way to the component/renderer pattern (facelet function component???). Example:

In the page:

#

{mylib:renderInformation('hello', 'world')}

@FaceletLibrary(namespace="http://...", renderKitId="RenderKitA")
CustomFaceletRendererA

@FaceletFunction
public String renderInformation(String a, String, b)

{ return "<p>"+a+" "+b+"</p>"; }

@FaceletLibrary(namespace="http://...", renderKitId="RenderKitA")
CustomFaceletRendererB

@FaceletFunction
public String renderInformation(String a, String, b)

{ return a+","+b; }

It is another way to define a "component". It is simpler and more limited, but easy to understand and very light.






[JAVASERVERFACES_SPEC_PUBLIC-1296] Clarify when it is valid to instantiate and use a PartialResponseWriter Created: 30/Jul/14  Updated: 13/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3358 Allow for creation of PartialViewCont... Closed

 Description   

The spec makes an implicit assumption about when it is valid to instantiate a PartialViewContext(). This assumption is: the current execution context must have FacesServlet.service() above on the callstack, which implies the existence of a FacesContext.



 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-1295] Add default implementation for UIComponent#getFamily() Created: 20/Jul/14  Updated: 01/Aug/14

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

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use, ease_of_development

 Description   

Custom components inheriting from UIComponentBase are currently required to provide an implementation for UIComponent#getFamily() as it's an abstract method.

This is a small nuisance for simple custom components (e.g. ones used internally by some application), which rarely have any need for distinguishing components based on family.

Typically those components just return the empty string or null (JAVASERVERFACES_SPEC_PUBLIC-1267) or some nonsense string like "whatshouldido.with.this".

If developers are not providing any meaningful return value for this method, I guess JSF might just as well provide a default implementation in UIComponentBase (e.g. a method just returning null), thereby making custom components yet again a tiny bit easier to create.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1293] Add onload and unload support for jsf:element. Created: 15/Jul/14  Updated: 01/Aug/14

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

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


 Description   

LU> The second problem is related to the attributes declared for
LU> jsf:element. The taglib javadoc of jsf:element has these
LU> attributes:

[...]

LU> It should be something that allows you to customize this part, but
LU> at least the following attributes should be there too:

LU> * onload (supported by <body>, <frame>, <frameset>, <iframe>, <img>,
LU> <input type="image">, <link>, <script>, <style>)
LU> * onunload (supported by <body>, <frameset>)

LU> Theoretically it doesn't matter if all valid names for html event
LU> are part of jsf:element. I have added onload/onunload in MyFaces
LU> 2.2.2, since it is quite easy to do so and it doesn't affect
LU> anything.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1291] RFE: Ability for h:messages to display a single custom message whenever the component has received any faces message. Created: 11/Jul/14  Updated: 01/Aug/14

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

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

Attachments: PNG File single message.png    

 Description   

In OmniFaces you can use h:messages to display a single message at the top of the screen such as "There are validation errors. Please fix them.", and then display component specific messages beside the components. They have added a "for" attribute to h:messages that points to the form component, and a "message" for the message to display. I will attach a screenshot.

http://showcase.omnifaces.org/components/messages

I've had customers ask me to do this very thing in our production applications.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1290] RFE: Add a var attribute to h:messages that enables the developer to fully control output styling Created: 11/Jul/14  Updated: 13/Aug/14

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

Type: Improvement Priority: Major
Reporter: rdelaplante Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Please see the OmniFaces messages component:

http://showcase.omnifaces.org/components/messages

"Control iteration markup fully by the new var attribute which sets the current FacesMessage in the request scope and disables the default table/list rendering."

<o:messages var="message">
<li class="#

{fn:toLowerCase(message.severity)}

">#

{message.summary}

</li>
</o:messages>



 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-1289] RFE: When the required attribute of a checkbox is set to true, a validation error should occur when the form is submitted and the checkbox is not checked Created: 11/Jul/14  Updated: 01/Aug/14

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

Type: Improvement Priority: Major
Reporter: rdelaplante Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See the RequiredCheckboxValidator in OmniFaces for a discussion of the issue:

http://showcase.omnifaces.org/validators/RequiredCheckboxValidator

The default behavior in JSF is non-intuitive and causes seemingly unnecessary work to be required in the action method.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1288] Clarify that default locale is implicitly a supported locale Created: 10/Jul/14  Updated: 13/Aug/14

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

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


 Description   

Section "2.5.2.1 Determining the active Locale"

gives an example of locale configuration:

This application’s default locale is en, but it also supports de, fr, and es locales. These elements cause the Application instance to be populated with Locale data. Please see the javadocs for details.

This seems to imply that the default locale is implicitly a supported locale. I think we should state this explicitly.



 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-1285] f:selectItems ignore itemDescription within h:selectOneListbox and related components Created: 19/Jun/14  Updated: 01/Aug/14

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

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


 Description   

Facelets tag lib documentation shows the following properties as valid for f:selectItems:

itemValue
itemLabel
itemDescription
itemDisabled
itemLabelEscaped
...

But in both Mojarra and MyFaces the attribute itemDescription, itemDisabled, itemLabel are ignored.

But taking a look at the renderkit spec javadoc of javax.faces.SelectMany/javax.faces.Listbox in the section "Rendering the "option" elements" it says this:

"... If the current child is a UISelectItem create a SelectIteminstance from its itemValue, itemLabel, itemEscaped, and itemDescription properties, add it to the list. If the current child is a UISelectItems instance, call its getValue() method. If the result is a SelectItem bean, add it to the list. If the result is an array of SelectItem beans, add each one to the list. If the result is a Collection of SelectItem beans, add each one to the list. If the result is a Map, create a SelectItem bean for each entry in the Map using the key as the label, the value as the value, and null as the description. ..."

So, these properties are supposed to be used with f:selectItem, not with f:selectItems. But the user perceive this as a bug, which is something logic. See:

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

In JSF 2.2 with HTML5 friendly markup, it is supposed that f:selectItems can have passthrough attributes. See:

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

But in MyFaces we found that it doesn't work for h:selectOneRadio or h:selectManyCheckbox.

The thing is the fix for this issue is pretty similar for the one that needs to be done for HTML5 friendly markup.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1282] CSRF improvements Created: 04/Jun/14  Updated: 13/Aug/14

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

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


 Description   

Improvements to JAVASERVERFACES_SPEC_PUBLIC-869.

JSF> If the values do not match, throw ProtectedViewException.

B> The specification should note that this means that these URLs can not
B> be bookmarked or sent to others. An improvement on this would be to
B> not throw the exceptions if the GET results in a new session, since
B> there is no session to forge in that case.



 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-1281] Extend vdl.createComponent with support of ui:includes and user tags Created: 31/May/14  Updated: 21/Aug/14

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

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


 Description   

Myfaces implementation extends their vdl.createComponent with support of ui:include and custom or composite tags. This great solution completely replace a set of strange workarounds from network or OpenFaces.

Mojarra in vdl.createComponent and DefaultFaceletFactory._createComponent supports only standard UIComponents and tags from api. There is no reason to support only tags from api.
Problem was registered as https://java.net/jira/browse/JAVASERVERFACES-3281 but unfortunately closed.

Test examples
-mojarra-2.2.6\test\agnostic\component\programmaticComponentCreation\src\main\java\com\sun\faces\test\agnostic\component\programmaticComponentCreation\CreateComponentBean.java
-http://svn.apache.org/repos/asf/myfaces/core/trunk\impl\src\test\java\org\apache\myfaces\view\facelets\pool\
-http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/test/java/org/apache/myfaces/view/facelets/pss/acid



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by krokodylowy3 [ 21/Aug/14 ]

This extension is also performance improvement. We no longer need use a set of permanent includes and tags for temporary visible popups and views which was a old headache of jsf framework. Code can be truly dynamic and well separated.





[JAVASERVERFACES_SPEC_PUBLIC-1278] UIInput.validateValue() oversteps its authority Created: 15/May/14  Updated: 13/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3267 UIInput.isEmpty returns false for Sets Closed

 Description   

Consider this text from UIInput.validateValue():

ensure that the local value is not empty (where "empty" is defined as null or a zero-length String).

JAVASERVERFACES-3267 argues that it is a custom converter's responsibility to determine what is meant by "empty", rather than UIInput.



 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-1276] FacesEvent not serializable with PhaseId Created: 01/May/14  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 1.1, 1.2, 2.0, 2.1
Fix Version/s: None

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


 Description   

FacesEvent (and its derivative objects) are marked as serializable, yet they are not if a phaseId is provided. The following test class:

public class Test
{
public static void main(String[] argv)
{
ActionEvent event = new ActionEvent(new UIOutput());
event.setPhaseId(PhaseId.APPLY_REQUEST_VALUES);

ByteArrayOutputStream out = new ByteArrayOutputStream();
ObjectOutputStream oout;
try

{ oout = new ObjectOutputStream(out); oout.writeObject(event); }

catch (IOException e)

{ e.printStackTrace(); }

}
}

Yields the following error:

java.io.NotSerializableException: javax.faces.event.PhaseId
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1165)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1535)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1413)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1159)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:329)
at test.Test.main(Test.java:31)

This is because PhaseId is not serializable. Regardless of PhaseId's ability to be serialized, FacesEvent must honor the serializable contract and be able to be serializable.



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

Unfortunately, because PhaseId is a javax.faces class, we cannot change its signature without revising the JSF specification. We will tackle this in 2.3.

Comment by Ed Burns [ 01/May/14 ]

I may be able to come up with a workaround to make this work in the meantime.

Comment by Hanspeter Duennenberger [ 12/May/14 ]

Would below change affect signature as well?
As workaround this would use the PhaseId ordinal as serialized value in FacesEvent:

Index: jsf-api/src/main/java/javax/faces/event/FacesEvent.java
===================================================================
--- jsf-api/src/main/java/javax/faces/event/FacesEvent.java	(revision 13233)
+++ jsf-api/src/main/java/javax/faces/event/FacesEvent.java	(working copy)
@@ -86,7 +86,9 @@
 
     }
 
-    private PhaseId phaseId = PhaseId.ANY_PHASE;
+    private int phaseOrdinal = PhaseId.ANY_PHASE.getOrdinal();
+
+    private transient PhaseId phaseId = PhaseId.VALUES.get(phaseOrdinal);
 
     /**
      * <p>Return the identifier of the request processing phase during
@@ -112,6 +114,7 @@
 	    throw new IllegalArgumentException();
 	}
 	this.phaseId = phaseId;
+	this.phaseOrdinal = phaseId.getOrdinal();
     }
 

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-1271] Simplify overriding a component's renderer Created: 27/Mar/14  Updated: 01/Aug/14

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

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A component in JSF can be customized by overriding its renderer and creating a new tag for it, e.g as demonstrated here: https://weblogs.java.net/blog/mriem/archive/2013/11/07/jsf-tip-34-override-jsf-renderer-and-create-new-tag-it

This however requires a small but tedious amount of XML. As an analogy to the createTag attribute of FacesComponent a similar attribute on @FacesRenderer could simplify this task and provide a greater ease of use. E.g. the XML in the above referenced example could be replaced by the following:

@FacesRenderer(forComponentType="javax.faces.HtmlOutputText" tagName="myOutputText")
public class MyTextRenderer extends Renderer {
    // ...
}

Overriding the render of a component and keeping its existing tag requires roughly the same amount of XML, but less straightforward. It requires the user to find out what the render-kit-id, component-family and renderer-type is of the component for which they want to override. This is demonstrated e.g. here: https://weblogs.java.net/blog/mriem/archive/2013/11/05/jsf-tip-32-override-jsf-renderer

It would be great if this could be simplified to just this:

@FacesRenderer(forComponentType="javax.faces.HtmlOutputText")
public class MyTextRenderer extends Renderer {
    // ...
}

As a user often primarily knows a component by its namespace and tag name, it might be worthwhile to let the user alternatively reference the component via this kind of naming. E.g.

@FacesRenderer(forComponentTag="http://java.sun.com/jsf/html:outputText")
public class MyTextRenderer extends Renderer {
    // ...
}


 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1265] Clarify that a piece of text in the navigation handler section of the spec only pertains when inside of a flow. Created: 07/Feb/14  Updated: 04/Sep/15

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

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3130 NavigationHandlerImpl differs from sp... Closed

 Description   

Consider this spec text, from section 7.4.2:

If the <to-view-id> element is a non-view flow node, resolve it to a vdl view identifier by following the algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call Nodes other than ViewNodes".

That text only pertains to navigation within a flow. This restriction must be explicitly called out.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1264] allow use of Servlet init parameter Created: 10/Jan/14  Updated: 13/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Sometimes it is useful to configure multiple FacesServlet instances with some common and some distinct configuration.
Currently this is not possible - ExternalContext.getInitParameter(name) only provides access to ServletContext init parameters, but not to ServletConfig init parameters.

web.xml allows <context-param>s within <web-app> but also also <init-param>s within <servlet>.
The current ExternalContext interface provides no access to Servlet init-params. It would also be problematic to expose Servlet-init-param explicitly since Portlet API would not match.

A simple solution though would be that ExternalContext.getInitParameter(name) would first consult the Servlet <init-param> and second the web-app <context-param>s.
It would then also make sense to cache the so resolved parameters on FacesContext to optimize multiple access to the same init-parameter.

This proposal most likely affects the SPEC - if accepted create a SPEC issue as well.

regards
Hanspeter



 Comments   
Comment by Manfred Riem [ 06/Feb/14 ]

As this indeed has a major specification impact it has been moved to the spec issue tracker

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-1263] Add rowStatePreserved property to com.sun.faces.facelets.component.UIRepeat, exactly the same as javax.faces.component.UIData Created: 14/Oct/13  Updated: 01/Aug/14

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Dependency
blocks JAVASERVERFACES-2633 UIInput component state incorrect whe... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1230 VDLDoc for <ui:repeat> does not have ... Closed

 Description   

This is the implementation work for JAVASERVERFACES_SPEC_PUBLIC-1230, but it can be done outside of the spec because properties can be added to Facelet backed components without having to change the TLD.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1261] inconsistent behavior with absolute contracts references like /contracts_dir/contract_name/resource.xhtml Created: 03/Feb/14  Updated: 01/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3146 absolute contract reference (e.g. tem... Closed

 Description   

See also https://java.net/jira/browse/JAVASERVERFACES-3146.

Absolute references to resources in contracts is not supported by design. However, with contracts deployed in /webapp_root/contracts_dir/contract_name it is possible to reference such resources using the absolute reference /contracts_dir/contract_name/resource.xhtml. Moving the same contract out to a separate jar this reference cannot be resolved anymore.

Since such absolute references are not supported by design such absolute contracts references must be prevented no mather if the contract is deployed into /webapp_root/contracts_dir or in META-INF/contracts within a jar.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1260] Allow for extensionless mapping of views Created: 31/Jan/14  Updated: 13/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3131 More flexible view mapping Closed

 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-1259] Allow mapping on /* Created: 31/Jan/14  Updated: 01/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3131 More flexible view mapping Closed

 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1256] FacesContextWrapper should call FacesContext.setCurrentinstance(this) in its default constructor Created: 10/Jan/14  Updated: 13/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    

 Description   

A common mistake when wrapping FacesContext is to forget to call FacesContext.setCurrentInstance(this) from within the constructor of the new CustomFacesContext extending FacesContextWrapper. Without that call, FacesServlet will use the wrapped FacesContext, but FacesContext.getCurrentInstance() would only return the wrapped RI's FacesContextImpl, but not the wrapper chain.

The call of FacesContext.setCurrentInstace(this) in the default constructor of FacesContextWrapper would prevent this mistake easily.



 Comments   
Comment by Ed Burns [ 22/Jan/14 ]

r=edburns.

Comment by Manfred Riem [ 22/Jan/14 ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3141, r=edburns, make sure the correct FacesContext is set by a wrapped FacesContext."
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Transmitting file data .
Committed revision 12783.

Comment by Manfred Riem [ 23/Jan/14 ]

Applied to 2.2 branch,

svn commit -m "Reverting as this violates the current TCK"
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Transmitting file data .
Committed revision 12786.

Comment by Manfred Riem [ 23/Jan/14 ]

Issue moved to the SPEC tracker as affecting the current fix violates tests in the TCK. Hence this has to wait for the next SPEC cycle.

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-1253] Consider enabling abandoning a flow directly for another flow Created: 17/Jan/14  Updated: 01/Aug/14

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive i_spec_1253-reproducer.zip     Text File i_spec_1253.patch    

 Description   

Consider an app with this arrangement.

src/main/webapp/WEB-INF/faces-config.xml
src/main/webapp/flowA/flowA-flow.xml
src/main/webapp/flowA/flowA.xhtml
src/main/webapp/flowB/flowB-flow.xml
src/main/webapp/flowB/flowB.xhtml
src/main/webapp/flowC/flowC-flow.xml
src/main/webapp/flowC/flowC.xhtml
src/main/webapp/index.xhtml
src/main/webapp/site-template.xhtml

All .xhtml pages in this app are template clients of
site-template.xhtml. The site-template.xhtml has a row of buttons along
the top that allow immediate navigation to all of the flows. The intent
is that whatever flow you're in, you want to abandon it and enter the
new flow when the corresponding button is clicked. This is not a flow
call, but rather should be treated as an atomic "abandon/enter".

The current specification does not support this cleanly.



 Comments   
Comment by Ed Burns [ 17/Jan/14 ]

Diff of reproducer.

Comment by Ed Burns [ 17/Jan/14 ]

zip of reproducer.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1252] It should be possible to specify Resource Dependencies via XML Created: 14/Jan/14  Updated: 13/Aug/14

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

Type: Improvement Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From the portlet EG mailing list (Neil Griffin and Ed Burns)

NG> @Ed Burns: When you get a chance, could you please shed some light
NG> on why resource dependencies can only be done via JSF annotations,
NG> and not by faces-config.xml? Thx.

EB> I suppose it could be. It turned out to be easier to implement with
EB> annotations. I think you have discovered a wrinkle where our stated
EB> goal of having complete parity of functionality between annotations and
EB> XML is not met.



 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-1249] add "maxRepeats" attribute to ui:repeat. Created: 27/Dec/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

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


 Description   

It would be very handy if there were a "maxRepeats" attribute on ui:repeat such that the repetition would terminate when either of the following two conditions was true.

1. the collection is empty

2. the maxRepeats value has been reached in terms of number of iterations.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1248] Allow EL in ResourceBundles used by JSF. Created: 27/Dec/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator)
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It would be nice if we could allow the use of EL expressions in ResourceBundles used by JSF.



 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.

Comment by Ed Burns [ 13/Aug/14 ]

Bean Validation 1.1 added this, so it's high time we do the same.





[JAVASERVERFACES_SPEC_PUBLIC-1247] Disable implicit navigation within flows on a per-flow basis. Created: 27/Dec/13  Updated: 01/Aug/14

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

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


 Description   

The ease of use of implicit navigation can be a boon for quick development, but it can also make it difficult to reason about flows when they get more complex. Consider adding a configuration element that disables implicit navigation in a flow.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1246] Prevent jumping into a flow without going through the front door. Created: 27/Dec/13  Updated: 13/Aug/14

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

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


 Description   

RS> One observation is with regards to access to flow scoped data. When
RS> using the provided buttons, everything works as it should, i.e. flow
RS> scoped data is created at the point of entering the flow and
RS> destroyed when the flow is exited. However, it is easy to bypass the
RS> entry and exit points. For example I can go directly to a page
RS> associated with a flow without entering the flow, and if the page
RS> tries to access flow data, the result would be
RS> ContextNotActiveException.

One could argue that such an exception is the right response. The
context is indeed not active. However, if you are not using any flow
scoped data, such an exception would not be thrown, and it would give
the impression that the navigation is supported.

I think we can add some language to the spec to detect these "jump in"
cases.



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

Rossen wrote:

When flows are defined under the web application's root, I can easily access
their source from a browser which is a security concern. I can see there is
an example that puts the flow definition under WEB-INF but the pages are
still under the web application root and hence the flow is in two different
places. It would be useful to be able to keep a flow with all its files in a
folder under WEB-INF.

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-1244] Reword requirements for EL expressions inlined in Facelets pages, but outside of components. Created: 19/Dec/13  Updated: 10/Sep/15

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

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days


 Description   

Text copied from JAVASERVERFACES-3094

The JSF spec (2.1) requires in section 10.3.1 that "The runtime must ensure that EL expressions that appear in the page without being the right-hand-side of a tag attribute
are treated as if they appeared on the right-hand-side of the value attribute of an <h:outputText /> element in the http://java.sun.com/jsf/html namespace." This should also work in this case.

This text is problematic with respect to c:set and friends.

I suggest we soften the above language to make it clear that we don't need to have UIOutput instances in the tree. Rather, we just need it to render as if we did.



 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-1240] Ajax behavior renderer automatically/incorrectly quotes client behavior context parameters when building script. Created: 10/Nov/13  Updated: 13/Aug/14

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

Type: Improvement Priority: Minor
Reporter: cduncan Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the AjaxBehaviorRenderer.buildAjaxCommand() method, all ClientBehaviorContext.Parameter parameters are automatically quoted using RenderKitUtils.appendProperty(). This makes dynamicly calculated JavaScript values useless. All other calls to RenderKitUtils.appendProperty specify whether to quote parameters or not. Please do the same for ClientBehaviorContext.Parameter parameters.

The following call in AjaxBehaviorRenderer.java around line 250 should pass false.

for (ClientBehaviorContext.Parameter param : params) {
RenderKitUtils.appendProperty(ajaxCommand,
param.getName(),
param.getValue());
}

I cannot use this very nice way of generating scripts in my custom components until this is fixed. I am currently using jsf.ajax.request, which works fine, but, I would rather use the implementation apis since it is much cleaner.



 Comments   
Comment by cduncan [ 10/Nov/13 ]

The most versatile and unobtrusive solution would be to add a "quoted" member variable to the ClientBehaviorContext.Parameter class. The value could be defaulted to true and referenced in the for loop mentioned above. This would not break existing usage since the for loop defaults to quoted currently. This would allow the developer to choose whether they wanted the quotes or not.

Comment by Manfred Riem [ 11/Nov/13 ]

Can you please tell us which version is affected, what application server you are running? And can you send a reproducing example to issues@javaserverfaces.java.net? That will help us tremendously! Thanks!

Comment by cduncan [ 12/Nov/13 ]

Manfred, I am using the Glassfish 4.0 zip version, which looks to be 2.2.0 according to manifest.mf. My proposed solution in the above comment was looking at the 2.2.4 source.

Thanks!
Chris

Comment by Ed Burns [ 13/Nov/13 ]

Thanks for your response about your version stack. It would help a lot if you could send a reproducer to the list, as suggested by Manfred. Whenever an issue comes in that requests a change in behavior, it is very important that we have the ability to verify that this change does not introduce problems.

Comment by Manfred Riem [ 19/Nov/13 ]

As the code currently in place is working correctly and you are asking for an improvement (by passing it the additional boolean) I am going to re-qualify this as an improvement.

Comment by cduncan [ 24/Nov/13 ]

Manfred, this issue is a show stopper bug for me and not an improvement. I cannot use the client behavior mechanism since it quotes the JavaScript parameters. I will attache the modified files, ClientBehaviorContext.java and AjaxBehaviorRenderer.java. Thanks, Chris.

Comment by cduncan [ 24/Nov/13 ]

/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
  • and Distribution License("CDDL") (collectively, the "License"). You
  • may not use this file except in compliance with the License. You can
  • obtain a copy of the License at
  • https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
  • or packager/legal/LICENSE.txt. See the License for the specific
  • language governing permissions and limitations under the License.
    *
  • When distributing the software, include this License Header Notice in each
  • file and include the License file at packager/legal/LICENSE.txt.
    *
  • GPL Classpath Exception:
  • Oracle designates this particular file as subject to the "Classpath"
  • exception as provided by Oracle in the GPL Version 2 section of the License
  • file that accompanied this code.
    *
  • Modifications:
  • If applicable, add the following below the License Header, with the fields
  • enclosed by brackets [] replaced by your own identifying information:
  • "Portions Copyright [year] [name of copyright owner]"
    *
  • Contributor(s):
  • If you wish your version of this file to be governed by only the CDDL or
  • only the GPL Version 2, indicate your decision by adding "[Contributor]
  • elects to include this software in this distribution under the [CDDL or GPL
  • Version 2] license." If you don't indicate a single choice of license, a
  • recipient has the option to distribute your version of this file under
  • either the CDDL, the GPL Version 2 or to extend the choice of license to
  • its licensees as provided above. However, if you add GPL Version 2 code
  • and therefore, elected the GPL Version 2 license, then the option applies
  • only if the new code is made subject to such option by the copyright
  • holder.
    */

package javax.faces.component.behavior;

import java.util.Collection;
import java.util.Collections;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;

/**

  • <p class="changed_added_2_0"><strong>ClientBehaviorContext</strong>
  • provides context information that may be useful to
  • {@link javax.faces.component.behavior.ClientBehavior#getScript}
  • implementations.
  • </p>
    *
  • @since 2.0
    */
    public abstract class ClientBehaviorContext {

/**

  • <p class="changed_added_2_0">Creates a ClientBehaviorContext instance.</p>
    *
  • @param context the <code>FacesContext</code> for the current request.
  • @param component the component instance to which the
  • <code>ClientBehavior</code> is attached.
  • @param eventName the name of the behavior event to which the
  • <code>ClientBehavior</code> is attached.
  • @param sourceId the id to use as the ClientBehavior's "source".
  • @param parameters the collection of parameters for submitting
  • ClientBehaviors to include in the request.
  • @return a <code>ClientBehaviorContext</code> instance configured with the
  • provided values.
  • @throws NullPointerException if <code>context</code>,
  • <code>component</code> or <code>eventName</code>
  • is <code>null</code>
    *
  • @since 2.0
    */
    public static ClientBehaviorContext createClientBehaviorContext(FacesContext context,
    UIComponent component,
    String eventName,
    String sourceId,
    Collection<ClientBehaviorContext.Parameter> parameters) { return new ClientBehaviorContextImpl(context, component, eventName, sourceId, parameters); }

/**

  • <p class="changed_added_2_0">Returns the {@link FacesContext}

    for

  • the current request.</p>
    *
  • @since 2.0
    */
    abstract public FacesContext getFacesContext();

/**

  • <p class="changed_added_2_0">Returns the {@link UIComponent}

    that is

  • requesting the {@link ClientBehavior} script.</p>
    *
    * @since 2.0
    */
    abstract public UIComponent getComponent();

    /**
    * <p class="changed_added_2_0">Returns the name of the behavior event
    * for which the ClientBehavior script is being requested. </p>
    *
    * @since 2.0
    */
    abstract public String getEventName();

    /**
    * <p class="changed_added_2_0">Returns an id for use as the
    * {@link ClientBehavior}

    source. ClientBehavior implementations that submit back

  • to the Faces lifecycle are required to identify which component
  • triggered the ClientBehavior-initiated request via the
  • <code>javax.faces.source</code> request parameter. In
  • most cases, th source id can be trivially derived from the element
  • to which the behavior's client-side script is attached - ie. the
  • source id is typically the id of this element. However, in components
  • which produce more complex content, the behavior script may not be able to
  • determine the correct id to use for the javax.faces.source
  • value. The {@link ClientBehaviorContext#getSourceId}

    method allows the component

  • to pass this information into the {@link ClientBehavior#getScript}
  • implementation.</p>
    *
  • @return the id for the behavior's script to use as the "source", or
  • null if the Behavior's script can identify the source from the DOM.
    *
  • @since 2.0
    */
    abstract public String getSourceId();

/**

  • <p class="changed_added_2_0">Returns parameters that "submitting"
  • {@link ClientBehavior}

    implementations should include when posting back data

  • into the Faces lifecycle. If no parameters are specified, this method
  • returns an empty (non-null) collection.</p>
    *
  • @since 2.0
    */
    abstract public Collection<ClientBehaviorContext.Parameter> getParameters();

// Little static member class that provides a default implementation
private static final class ClientBehaviorContextImpl extends ClientBehaviorContext {
private FacesContext context;
private UIComponent component;
private String eventName;
private String sourceId;
private Collection<ClientBehaviorContext.Parameter> parameters;

private ClientBehaviorContextImpl(FacesContext context,
UIComponent component,
String eventName,
String sourceId,
Collection<ClientBehaviorContext.Parameter> parameters) {

if (null == context)

{ throw new NullPointerException(); }

if (null == component) { throw new NullPointerException(); }

if (null == eventName)

{ throw new NullPointerException(); }

this.context = context;
this.component = component;
this.eventName = eventName;
this.sourceId = sourceId;

this.parameters = (parameters == null) ?
Collections.<ClientBehaviorContext.Parameter>emptyList() :
parameters;
}

@Override
public FacesContext getFacesContext() { return context; }

@Override
public UIComponent getComponent() { return component; }

@Override
public String getEventName() { return eventName; }

@Override
public String getSourceId() { return sourceId; }

@Override
public Collection<ClientBehaviorContext.Parameter> getParameters() { return parameters; }
}

/**
* <p class="changed_added_2_0"><strong>Parameter</strong> instances
* represent name/value pairs that "submitting" ClientBehavior implementations
* should include when posting back into the Faces lifecycle. ClientBehavior
* implementations can determine which Parameters to include by calling
* ClientBehaviorContext.getParameters().
* </p>
*
* @since 2.0
*/
public static class Parameter {

private String name;
private Object value;
private boolean quoteValue;

/**
* <p class="changed_added_2_0">Creates a Parameter instance.</p>
* @param name the name of the parameter
* @param value the value of the parameter
* @throws NullPointerException if <code>name</code>
* is null.
*
* @since 2.0
*/
public Parameter(String name, Object value) { this(name, value, true); }

/**
* <p class="changed_added_2_0">Creates a Parameter instance.</p>
* @param name the name of the parameter
* @param value the value of the parameter
* @param quoteValue indicator for value quotes.
* @throws NullPointerException if <code>name</code>
* is null.
*
* @since 2.2.6
*/
public Parameter(String name, Object value, boolean quoteValue) {

if (null == name) { throw new NullPointerException(); }

this.name = name;
this.value = value;
this.quoteValue = quoteValue;
}

/**

  • <p class="changed_added_2_0">Returns the Parameter's name.</p>
    *
  • @since 2.0
    */
    public String getName() { return name; }

/**

  • <p class="changed_added_2_0">Returns the Parameter's value.</p>
    *
  • @since 2.0
    */
    public Object getValue() { return value; }

/**

  • <p class="changed_added_2_2_6">Returns the Parameter's quote value indicator.</p>
    *
  • @since 2.2.6
    */
    public boolean getQuoteValue() { return quoteValue; }

    }
    }

Comment by cduncan [ 24/Nov/13 ]

/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
  • and Distribution License("CDDL") (collectively, the "License"). You
  • may not use this file except in compliance with the License. You can
  • obtain a copy of the License at
  • https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
  • or packager/legal/LICENSE.txt. See the License for the specific
  • language governing permissions and limitations under the License.
    *
  • When distributing the software, include this License Header Notice in each
  • file and include the License file at packager/legal/LICENSE.txt.
    *
  • GPL Classpath Exception:
  • Oracle designates this particular file as subject to the "Classpath"
  • exception as provided by Oracle in the GPL Version 2 section of the License
  • file that accompanied this code.
    *
  • Modifications:
  • If applicable, add the following below the License Header, with the fields
  • enclosed by brackets [] replaced by your own identifying information:
  • "Portions Copyright [year] [name of copyright owner]"
    *
  • Contributor(s):
  • If you wish your version of this file to be governed by only the CDDL or
  • only the GPL Version 2, indicate your decision by adding "[Contributor]
  • elects to include this software in this distribution under the [CDDL or GPL
  • Version 2] license." If you don't indicate a single choice of license, a
  • recipient has the option to distribute your version of this file under
  • either the CDDL, the GPL Version 2 or to extend the choice of license to
  • its licensees as provided above. However, if you add GPL Version 2 code
  • and therefore, elected the GPL Version 2 license, then the option applies
  • only if the new code is made subject to such option by the copyright
  • holder.
    */

package com.sun.faces.renderkit.html_basic;

import com.sun.faces.util.FacesLogger;

import java.util.Collection;
import java.util.LinkedList;
import java.util.logging.Level;
import java.util.logging.Logger;

import javax.faces.FacesException;
import javax.faces.component.ActionSource;
import javax.faces.component.EditableValueHolder;
import javax.faces.component.UIComponent;
import javax.faces.component.behavior.AjaxBehavior;
import javax.faces.component.behavior.ClientBehavior;
import javax.faces.component.behavior.ClientBehaviorContext;
import javax.faces.context.FacesContext;
import javax.faces.event.AjaxBehaviorEvent;
import javax.faces.event.PhaseId;
import javax.faces.render.ClientBehaviorRenderer;

import com.sun.faces.renderkit.RenderKitUtils;

/*
*<b>AjaxBehaviorRenderer</b> renders Ajax behavior for a component.

  • It also
    */

public class AjaxBehaviorRenderer extends ClientBehaviorRenderer {

// Log instance for this class
protected static final Logger logger = FacesLogger.RENDERKIT.getLogger();

// ------------------------------------------------------ Rendering Methods

@Override
public String getScript(ClientBehaviorContext behaviorContext,
ClientBehavior behavior) {
if (!(behavior instanceof AjaxBehavior))

{ // TODO: use MessageUtils for this error message? throw new IllegalArgumentException( "Instance of javax.faces.component.behavior.AjaxBehavior required: " + behavior); }

if (((AjaxBehavior)behavior).isDisabled())

{ return null; }
return buildAjaxCommand(behaviorContext, (AjaxBehavior)behavior);
}


@Override
public void decode(FacesContext context,
UIComponent component,
ClientBehavior behavior) {
if (null == context || null == component || null == behavior) { throw new NullPointerException(); }

if (!(behavior instanceof AjaxBehavior)) { // TODO: use MessageUtils for this error message? throw new IllegalArgumentException( "Instance of javax.faces.component.behavior.AjaxBehavior required: " + behavior); }

AjaxBehavior ajaxBehavior = (AjaxBehavior)behavior;

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled()) { return; }

component.queueEvent(createEvent(component, ajaxBehavior));

if (logger.isLoggable(Level.FINE)) {
logger.fine("This command resulted in form submission " +
" AjaxBehaviorEvent queued.");
logger.log(Level.FINE,
"End decoding component {0}", component.getId());
}


}

// Creates an AjaxBehaviorEvent for the specified component/behavior
private static AjaxBehaviorEvent createEvent(UIComponent component,
AjaxBehavior ajaxBehavior) { AjaxBehaviorEvent event = new AjaxBehaviorEvent(component, ajaxBehavior); PhaseId phaseId = isImmediate(component, ajaxBehavior) ? PhaseId.APPLY_REQUEST_VALUES : PhaseId.INVOKE_APPLICATION; event.setPhaseId(phaseId); return event; }


// Tests whether we should perform immediate processing. Note
// that we "inherit" immediate from the parent if not specified
// on the behavior.
private static boolean isImmediate(UIComponent component,
AjaxBehavior ajaxBehavior) {

boolean immediate = false;

if (ajaxBehavior.isImmediateSet()) { immediate = ajaxBehavior.isImmediate(); } else if (component instanceof EditableValueHolder) { immediate = ((EditableValueHolder)component).isImmediate(); } else if (component instanceof ActionSource) { immediate = ((ActionSource)component).isImmediate(); }

return immediate;
}

private static String buildAjaxCommand(ClientBehaviorContext behaviorContext,
AjaxBehavior ajaxBehavior) {

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled()) { return null; }

UIComponent component = behaviorContext.getComponent();
String eventName = behaviorContext.getEventName();

StringBuilder ajaxCommand = new StringBuilder(256);
Collection<String> execute = ajaxBehavior.getExecute();
Collection<String> render = ajaxBehavior.getRender();
String onevent = ajaxBehavior.getOnevent();
String onerror = ajaxBehavior.getOnerror();
String sourceId = behaviorContext.getSourceId();
String delay = ajaxBehavior.getDelay();
Boolean resetValues = null;
if (ajaxBehavior.isResetValuesSet())

{ resetValues = ajaxBehavior.isResetValues(); }

Collection<ClientBehaviorContext.Parameter> params = behaviorContext.getParameters();

// Needed workaround for SelectManyCheckbox - if execute doesn't have sourceId,
// we need to add it - otherwise, we use the default, which is sourceId:child, which
// won't work.
ClientBehaviorContext.Parameter foundparam = null;
for (ClientBehaviorContext.Parameter param : params) {
if (param.getName().equals("incExec") && (Boolean)param.getValue())

{ foundparam = param; }

}
if (foundparam != null && !execute.contains(sourceId))

{ execute = new LinkedList<String>(execute); execute.add(component.getClientId()); }

if (foundparam != null) {
try

{ // And since this is a hack, we now try to remove the param params.remove(foundparam); }

catch (UnsupportedOperationException uoe) {
if (logger.isLoggable(Level.FINEST))

{ logger.log(Level.FINEST, "Unsupported operation", uoe); }

}
}

ajaxCommand.append("mojarra.ab(");

if (sourceId == null)

{ ajaxCommand.append("this"); }

else

{ ajaxCommand.append("'"); ajaxCommand.append(sourceId); ajaxCommand.append("'"); }

ajaxCommand.append(",event,'");
ajaxCommand.append(eventName);
ajaxCommand.append("',");

appendIds(component, ajaxCommand, execute);
ajaxCommand.append(",");
appendIds(component, ajaxCommand, render);

if ((onevent != null) || (onerror != null) || (delay != null) ||
(resetValues != null) || !params.isEmpty()) {

ajaxCommand.append(",{");

if (onevent != null)

{ RenderKitUtils.appendProperty(ajaxCommand, "onevent", onevent, false); }

if (onerror != null)

{ RenderKitUtils.appendProperty(ajaxCommand, "onerror", onerror, false); }

if (delay != null)

{ RenderKitUtils.appendProperty(ajaxCommand, "delay", delay, true); }

if (resetValues != null)

{ RenderKitUtils.appendProperty(ajaxCommand, "resetValues", resetValues, false); }

if (!params.isEmpty()) {
for (ClientBehaviorContext.Parameter param : params)

{ RenderKitUtils.appendProperty(ajaxCommand, param.getName(), param.getValue(), param.getQuoteValue()); }

}

ajaxCommand.append("}");
}

ajaxCommand.append(")");

return ajaxCommand.toString();
}

// Appends an ids argument to the ajax command
private static void appendIds(UIComponent component,
StringBuilder builder,
Collection<String> ids) {

if ((null == ids) || ids.isEmpty())

{ builder.append('0'); return; }

builder.append("'");

boolean first = true;

for (String id : ids) {
if (id.trim().length() == 0)

{ continue; }

if (!first)

{ builder.append(' '); }

else

{ first = false; }

if (id.equals("@all") || id.equals("@none") ||
id.equals("@form") || id.equals("@this"))

{ builder.append(id); }

else

{ builder.append(getResolvedId(component, id)); }

}

builder.append("'");
}

// Returns the resolved (client id) for a particular id.
private static String getResolvedId(UIComponent component, String id) {

UIComponent resolvedComponent = component.findComponent(id);
if (resolvedComponent == null)

{ // RELEASE_PENDING i18n throw new FacesException( "<f:ajax> contains an unknown id '" + id + "' - cannot locate it in the context of the component "+component.getId()); }

return resolvedComponent.getClientId();
}
}

Comment by Manfred Riem [ 25/Nov/13 ]

Hi Chris,

I understand your predicament, unfortunately because your change is in javax.faces.component.behavior which is an API package it would violate the TCK (note adding any method to an API package violates the TCK and thus the JSF specification). If you can do it without changing anything in a javax.faces.* package then I certainly would like to get this in, provided it passes all of our tests.

Comment by cduncan [ 25/Nov/13 ]

Manfred:

Thank you for your timely response to this issue and for clarifying changes to the javax.faces.* packages. I was wondering about that before posting the previous solution. I believe there is a simple solution keeping the improvement within the com.sun.faces.renderkit.RenderKitUtils.AjaxBehaviorRenderer class. I will code it up tonight and post a solution that will not interfere with the current usage and allows overrides by component developers.

Thank you,
Chris

Comment by cduncan [ 26/Nov/13 ]

Manfred:

This version of the method com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.buildAjaxCommand() explicitly sets the quoted value in the RenderKitUtils.appendProperty() call to false. Currently, it is not explicitly set and thus invokes the overloaded version of RenderKitUtils.appendProperty() which sets the value to true. All of the calls to RenderKitUtils.appendProperty() explicitly set the quoted value except this one. I am not sure if this was an oversight. This version needs to be thoroughly tested to make sure it does not cause any unwanted side effects.

There is another solution if this one does not pass all tests. We can overload the com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.getScript() method passing in a boolean indicating whether to quote the value. This boolean will be passed to com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.buildAjaxCommand() for the last RenderKitUtils.appendProperty() call.

Thank you,
Chris

private static String buildAjaxCommand(ClientBehaviorContext behaviorContext,
AjaxBehavior ajaxBehavior) {

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled())

{ return null; }

UIComponent component = behaviorContext.getComponent();
String eventName = behaviorContext.getEventName();

StringBuilder ajaxCommand = new StringBuilder(256);
Collection<String> execute = ajaxBehavior.getExecute();
Collection<String> render = ajaxBehavior.getRender();
String onevent = ajaxBehavior.getOnevent();
String onerror = ajaxBehavior.getOnerror();
String sourceId = behaviorContext.getSourceId();
String delay = ajaxBehavior.getDelay();
Boolean resetValues = null;
if (ajaxBehavior.isResetValuesSet())

{ resetValues = ajaxBehavior.isResetValues(); }

Collection<ClientBehaviorContext.Parameter> params = behaviorContext.getParameters();

// Needed workaround for SelectManyCheckbox - if execute doesn't have sourceId,
// we need to add it - otherwise, we use the default, which is sourceId:child, which
// won't work.
ClientBehaviorContext.Parameter foundparam = null;
for (ClientBehaviorContext.Parameter param : params) {
if (param.getName().equals("incExec") && (Boolean)param.getValue())

{ foundparam = param; }

}
if (foundparam != null && !execute.contains(sourceId))

{ execute = new LinkedList<String>(execute); execute.add(component.getClientId()); }

if (foundparam != null) {
try

{ // And since this is a hack, we now try to remove the param params.remove(foundparam); }

catch (UnsupportedOperationException uoe) {
if (logger.isLoggable(Level.FINEST))

{ logger.log(Level.FINEST, "Unsupported operation", uoe); }

}
}

ajaxCommand.append("mojarra.ab(");

if (sourceId == null)

{ ajaxCommand.append("this"); }

else

{ ajaxCommand.append("'"); ajaxCommand.append(sourceId); ajaxCommand.append("'"); }

ajaxCommand.append(",event,'");
ajaxCommand.append(eventName);
ajaxCommand.append("',");

appendIds(component, ajaxCommand, execute);
ajaxCommand.append(",");
appendIds(component, ajaxCommand, render);

if ((onevent != null) || (onerror != null) || (delay != null) ||
(resetValues != null) || !params.isEmpty()) {

ajaxCommand.append(",{");

if (onevent != null)

{ RenderKitUtils.appendProperty(ajaxCommand, "onevent", onevent, false); }

if (onerror != null)

{ RenderKitUtils.appendProperty(ajaxCommand, "onerror", onerror, false); }

if (delay != null)

{ RenderKitUtils.appendProperty(ajaxCommand, "delay", delay, true); }

if (resetValues != null)

{ RenderKitUtils.appendProperty(ajaxCommand, "resetValues", resetValues, false); }

if (!params.isEmpty()) {
for (ClientBehaviorContext.Parameter param : params)

{ RenderKitUtils.appendProperty(ajaxCommand, param.getName(), param.getValue(), false); }

}

ajaxCommand.append("}");
}

ajaxCommand.append(")");

return ajaxCommand.toString();
}

Comment by cduncan [ 04/Dec/13 ]

It appears the MyFaces 2.2.0 implementation also automatically quotes the JavaScript parameter values when posting back. The following method is from the HtmlAjaxBehaviorRenderer.java class in the myfaces-impl-2.2.0-beta-sources.jar.

private void append(StringBuilder paramBuffer, List<String> parameterList, ClientBehaviorContext.Parameter param)

{ //TODO we may need a proper type handling in this part //lets leave it for now as it is //quotes etc.. should be transferred directly //and the rest is up to the toString properly implemented //ANS: Both name and value should be quoted paramBuffer.setLength(0); paramBuffer.append(QUOTE); paramBuffer.append(param.getName()); paramBuffer.append(QUOTE); paramBuffer.append(COLON); paramBuffer.append(QUOTE); paramBuffer.append(param.getValue().toString()); paramBuffer.append(QUOTE); parameterList.add(paramBuffer.toString()); }

What I take from this is that the JSF specification for the ClientBehaviorContext.Parameter class is not clear in regards to quoting, and as such, the JSF implementations default to automatic quoting.

In my first solution, I added a 'private boolean quoteValue' member variable to the ClientBehaviorContext.Parameter class and defaulted the value to true. This would not cause any side effects since implementations default to true anyway and would give custom component developers the power to decide if they want their JavaScript value params quoted or not.

As Manfred stated, this would require a change to the JSF spec, but from what I have seen, I believe it is the best route. I do realize that this would take some time, so I am writing my own handling of the client behaviors in my custom components. I cannot tightly couple my custom components to a particular implementation.

Please let me know how I can help further.

Thanks,
Chris

Comment by Manfred Riem [ 04/Dec/13 ]

Chris, thank you for doing the extra work you did. As you stated that MyFaces is also doing automatic quoting I think it might be time to move this issue to the spec issue tracker and put it on the radar for the next version of the JSF specification. What do you think?

Comment by cduncan [ 05/Dec/13 ]

Manfred:

I believe this needs a clarification in the JSF specification. A member variable in the ClientBehaviorContext.Parameter would remove all doubt for the JSF implementors on how to handle the value, and possible name parameter. It could be done in a way that would not affect all current implementations, since they default to quoted currently. Please see my original code solution for suggestions for the JSF specification.

Please let me know if I can help further.

Thanks,
Chris

Comment by Manfred Riem [ 05/Dec/13 ]

Chris, I will go ahead and move this issue to the SPEC issue tracker as it is a SPEC issue. Unfortunately that means resolution will have to wait till the next JSF specification. Thank!

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-1238] Enhance component referencing / findComponent Created: 15/Nov/13  Updated: 20/Jun/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript, Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: tandraschko Assignee: Unassigned
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently component referencing with the JSF API is very limited.
Keywords can currently only be used with f:ajax and not for e.g. outputLabel "for" attribute.
Also keywords cant be combined and we dont even have many keywords.

For PrimeFaces, i created a small modular API to enhance the search alogorithm as you can read here:
http://blog.primefaces.org/?p=2740

Noteable features are:

  • keywords can be used for all components
  • combinable keywords like @composite:@parent or @form:myId
  • currently a (limited) pluggable framework to allow new keywords for endusers

For the JSF API, a new artifact for resolving expression for findComponent (like ViewHandler etc.) would be great and can easily be enhanced by component libraries.
Maybe something like "ComponentExpressionResolver".

If its somehow possible, i would like to help to create and finalyze the API.

Sorry for Issue 1237 - please close it.



 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.

Comment by Ed Burns [ 13/Aug/14 ]

This area is very sensitive to performance problems.

Comment by tandraschko [ 26/Sep/15 ]

The performance won't be affected for existing applications as the new search expression logic is only used if the whole expression string contains a "@".
Some expressions are faster, some are slower but the overall performance is very good and i did a lot of optimization for it.

Would great to see it in the next API release. BootsFaces implemented a similiar API.
As i said, i would take care of it and would contribute my ideas to the JSF API.

Comment by stephanrauh [ 26/Sep/15 ]

I agree with Thomas. I consider the advanced search expressions very useful. So useful, that I implemented them in BootsFaces 0.8.0 myself. As for the performance considerations: granted, we should keep the performance in mind. However, I'm using the PrimeFaces search expressions for years now without noting a performance penalty. In particular, the expressions I use most frequently - @parent, @next and @previous - are implemented in a very efficient way.

Comment by balusc [ 20/Jun/16 ]

This is one of the things I'd like to see in JSF 2.3 as well. Community contribution is very welcome.





[JAVASERVERFACES_SPEC_PUBLIC-1237] Enhance component referencing / Created: 15/Nov/13  Updated: 01/Aug/14

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

Type: New Feature Priority: Minor
Reporter: tandraschko Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1236] For Ajax File Uploads: Investigate the use of XMLHttpRequest2 (If available). Created: 31/Jul/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File mojarra-trunk-xhr2-upload.patch    

 Description   

Investigate the use of XMLHttpRequest (Level2) for file uploads (if available) and fall back to iframe if it is not available.



 Comments   
Comment by kfyten [ 10/Sep/13 ]

Reminder that ICEsoft has submitted a patch for this, would be nice if the JIRA reflected this, etc.

Also note that MyFaces has preliminary support for this already, see https://issues.apache.org/jira/browse/MYFACES-2852.

Comment by rogerk [ 30/Sep/13 ]

Contribution From IceSoft

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-1235] better integration of bv-groups Created: 31/Oct/13  Updated: 08/Feb/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: gerhard_petracek Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

in several cases different bv-groups should get used (in the validation-phase) depending on the triggered action.
(if there are e.g. multiple buttons in the same form which should lead to different bv-constraints.)

also see: https://issues.apache.org/jira/browse/EXTVAL-141



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by muellermi [ 08/Feb/16 ]
  • add an attribute validateGroup="someGroup" to the f:validateBean tag,
    e.g.
    <f:validateBean validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Email" validateGroup="de.muellerbruehl.jsf23.Email"/>

At the time, the validator is executed (on submit, immediate if ajaxified), do not validate according to the default group, which is default if validateGroup is missing, but according to the given group. If this group performs a multi field validation, create a copy of the model, apply new values (if applicable) and perform the validation.

Comment by muellermi [ 08/Feb/16 ]

Maybe a "validate" attribute for the f:ajax would be a good place to trigger (multi field) group validation.

<h:message for="ageValidator"/>
<h:inputText id="ageDays" value="#

{grouper.ageDays}

">
<f:validateBean id="ageValidator" validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Age"/>
<f:ajax render="msgAgeDays ageValidator" validate="de.muellerbruehl.jsf23.Age"/>
</h:inputText>
<h:message id="msgAgeDays" for="ageDays"/>

<h:inputText id="ageYears" value="#

{grouper.ageYears}

">
<f:validateBean validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Age"/>
<f:ajax render="msgAgeYears ageValidator" validate="de.muellerbruehl.jsf23.Age"/>
</h:inputText>
<h:message id="msgAgeYears" for="ageYears"/>





[JAVASERVERFACES_SPEC_PUBLIC-1233] Since 'var' is set by name on the request it is very easy to break. Created: 29/Oct/13  Updated: 01/Aug/14

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

Type: Improvement Priority: Minor
Reporter: jid1 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

IMO, composite components that contain tables or repeats that store variable on the request should be scoped as it very easy to get weird behaviour.
In the context of normal xhtml and includes, it could throw an error saying that the variable has already been defined, if user tries to define it again.

The reason behind the distinction is that you might end up with incompatible 3rd party components when you nest them. In addition, devs should pass the value as an attribute to the composite/custom component.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1232] Support for a Flow to start from direct URL path access Created: 28/Oct/13  Updated: 05/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Support for a flow to start when user directly access the flow path from an URL.

If a user points to http://server/app/flow-folder/ the implementation throws an exception saying it couldn't find an index.xhtml page.

Right now, the only way to start a flow is by having the user accessing another page before, outside of the flow, and then an action to the flow (either by link, button, or some javascript to automatically click on something).



 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-1227] Add <f:protectClientWindowOpenInNewTab> JavaScript behavior tag Created: 07/Oct/13  Updated: 17/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days


 Description   

With the introduction of ClientWindow in JSF 2.2, it's possible to protect against multiple tabs being open on the same view. However, components that render links allow the user to do "open in new tab" or "open in new window". This can cause a situation where there are multiple tabs that still have the same ClientWindow, which is incorrect.

This feature proposal asks for the creation of a ClientBehavior tag that, when nested inside of a component that renders as a link, will make it so a new client window is created when the link is clicked.



 Comments   
Comment by Ed Burns [ 07/Oct/13 ]

Here's a sketch for how this could work.

Here's how you'd use it.

<h:link outcome="callB" value="Call B via GET">
<f:protectClientWindowOpenInNewTab />
</h:link>

This would cause the link to be rendered with some javascript that listens for an onclick on the link. In the handler, check if the right mouse button was pressed and take appropriate action.

Comment by Thomas Asel [ 08/Oct/13 ]

I am afraid that this feature would force unintuitive behavior and also advocates a rather patronizing development style.

How about creating a client behavior that creates a window id on demand?
So instead of blocking the contextmenu we could use the oncontextmenu handler to create a new id and append it as a parameter to the link.

Comment by Ed Burns [ 08/Oct/13 ]

Thanks for the feedback, Thomas. We can certainly change the name to be less patronizing.

Please note that the ClientWindow will be created on demand when the request comes in without having one already. This is why it is sufficient for the context menu handler to simply strip it off.

The client behavior for this tag does two things.

1. If the link is clicked without the context menu, no action is taken. The already-existing ClientWindow is allowed to remain on the link, causing the correct ClientWindow to be carried forward.

2. If the link is clicked with the context menu (new tab or new window), the ClientWindow is removed before the browser issues the GET. This will cause a new ClientWindow to be created for the new tab (or window), this is the correct action in this case.

Comment by tandraschko [ 20/Dec/13 ]

@Ed
is it really possible to listen on "onclick" when the link will be openend in new tab via context menu?
I'm sure onclick won't be called.

Maybe we should never render the windowId to a link und just add via onclick.
We could store the windowId globally in a JS varable in in the listener, we could add it to the href.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by muellermi [ 17/Sep/15 ]

The idea behind this issue only protects the browser to open a new tab or window using the same client id.

Sadly the user still is able to copy the url and paste it into a manually opened new tab. What we really need is some information to determine the "right" window.

Comment by muellermi [ 17/Sep/15 ]

Maybe window.name (JavaScript) would be helpful to perform this task.

Comment by tandraschko [ 17/Sep/15 ]

window.name is also used in DeltaSpike.
Please have a look at it: http://deltaspike.apache.org/documentation/jsf.html#AvailableModes
CLIENT_WINDOW is the most complete and 100% working mode.

I will complete the docu these days, LAZY mode is described much more detailed.





[JAVASERVERFACES_SPEC_PUBLIC-1226] Inconsistent handling of null/undeclared attributes, especially with nested components Created: 07/Oct/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Facelets/VDL
Affects Version/s: 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: fabmars Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF3 + JSF 2.1.26 or GF4 with JSF 2.2.3 with JDK7.0_45


Tags: composite, composite-component, null

 Description   

The origin is here: https://java.net/jira/browse/JAVASERVERFACES-2614, but it's mainly worth reading the summary further down here.

The reproducer is on git@github.com:fabmars/JSF2614.git .
We have an outer component:

test1.xhtml
<composite:interface>
<composite:attribute name="val1" type="java.lang.String"/>
<composite:attribute name="val2" type="java.lang.String"/>
<composite:attribute name="val3" type="java.lang.String" default="#{null}"/>
<composite:attribute name="val4" type="java.lang.String" default="#{null}"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<h:outputText value="Outer1: #{cc.attrs.val1 == null ? 'null' : (empty cc.attrs.val1 ? 'empty' : cc.attrs.val1)}" />
<h:outputText value="Outer2: #{cc.attrs.val2 == null ? 'null' : (empty cc.attrs.val2 ? 'empty' : cc.attrs.val2)}" />
<h:outputText value="Outer3: #{cc.attrs.val3 == null ? 'null' : (empty cc.attrs.val3 ? 'empty' : cc.attrs.val3)}" />
<h:outputText value="Outer4: #{cc.attrs.val4 == null ? 'null' : (empty cc.attrs.val4 ? 'empty' : cc.attrs.val4)}" />
</h:panelGrid>
<sr:test2 val1="#{cc.attrs.val1}" val2="#{cc.attrs.val2}" val3="#{cc.attrs.val3}" val4="#{cc.attrs.val4}" /> 
</composite:implementation>

And an inner component:

test2.xhtml
<composite:interface>
	<composite:attribute name="val1" type="java.lang.String"/>
	<composite:attribute name="val2" type="java.lang.String" default="#{null}"/>
	<composite:attribute name="val3" type="java.lang.String"/>
	<composite:attribute name="val4" type="java.lang.String" default="#{null}"/>
</composite:interface>

<composite:implementation>
	<h:panelGrid>
		<h:outputText value="Inner1: #{cc.attrs.val1 == null ? 'null' : (empty cc.attrs.val1 ? 'empty' : cc.attrs.val1)}" />
		<h:outputText value="Inner2: #{cc.attrs.val2 == null ? 'null' : (empty cc.attrs.val2 ? 'empty' : cc.attrs.val2)}" />
		<h:outputText value="Inner3: #{cc.attrs.val3 == null ? 'null' : (empty cc.attrs.val3 ? 'empty' : cc.attrs.val3)}" />
		<h:outputText value="Inner4: #{cc.attrs.val4 == null ? 'null' : (empty cc.attrs.val4 ? 'empty' : cc.attrs.val4)}" />
	</h:panelGrid>
</composite:implementation>

And the actual page:

jsf2614.xhtml
<sr:test1 val1="AAA" val2="BBB" val3="CCC" val4="DDD"/>
<sr:test1/>
<sr:test1 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/>
<sr:test2  val1="DDD" val2="EEE" val3="FFF" val4="GGG"/>
<sr:test2/>
<sr:test2 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/>

When running one can notice a couple of odd things:

1st case:
On <sr:test1 .../>

  • feed <composite:attribute name="val1" type="java.lang.String"/> with null. Result: null
  • feed <composite:attribute name="val3" type="java.lang.String" default="# {null}"/> with null. Result: ""
    The developer, in the second line expects to get String var3 = null in the end. Instead he gets a real value.
    OK this is due to the mechanics of coertion but this is not consistent and imo should be fixed.


    2nd case:
    - Call the OUTER component dry <sr:test1/>. var1 isn't declared, so will be assumed null. In sr:test1 implementation is a call to <sr:test2 val1="#{cc.attrs.val1}"... The INNER(sr:test2) component is awaiting a String as val1 (<composite:attribute name="val1" type="java.lang.String"/>) and our non-declared attribute becomes "" (again) in the end! (see that lines 9 vs 13 of the output). In other words: feed a null to <composite:attribute name="val1" type="java.lang.String"/> directly, it stays null, feed it from a surrounding component, it becomes ""!


    3rd case:
    Calling directly the inner component <sr:test2/> and <sr:test2 val1="#{null}

    " val2="#

    {null}" val3="#{null}

    " val4="#

    {null}

    "/> produce totally different results (see lines 29-32 vs 33-36 of the output). This is confusing for the developer and I'm not even sure this is a "feature".



 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-1224] HTML5 Form Validation Not Performed Before Ajax Submit Created: 30/Aug/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

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


 Description   

Given an HTML5 form, with HTML% input types (such as email), form validation is not performed (for an invalid email entered) if the submit is over ajax.
This is because the current Ajax portion of the specification states specifically to collect form elements and pass on over ajax to server side.
We would need to specify (and implement) something to trigger form validation before even collecting elements for ajax submit.



 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-1223] Facelet ui:param doesn't work in composite components (action) Created: 26/Mar/13  Updated: 01/Aug/14

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

Type: Bug Priority: Major
Reporter: dasago Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1222 ValueChange method in POJO doesn't re... Open

 Description   

If i have a facelet file which includes a composite component and I want to pass ui:params for the action it doesn't work

File a.xhtml includes my template myTemplate.xhtml. I want to pass parameters for an action

<ui:include src="/pages/templates/myTemplate.xhtml">
      <ui:param name="resetAction" value="reset" />
      <ui:param name="bean" value="#{myBean}" />
</ui:include>

Following works / works not in myTemplate.xhtml:

value is displayed

<h:outputText value="Bean: #{bean}" />

value is displayed

<h:outputText value="resetAction: #{resetAction}" />

Action doesn't work if i pass it into a compositeComponent

<myCom:reset resetAction="#{bean[resetAction]}" />

for a commandButton it works.

<p:commandButton value="test reset" action="#{bean[resetAction]}" />

If I don't add my composite component to a facelet tempalte the action also works:

<myCom:reset resetAction="#

{myBean.reset}

" />



 Comments   
Comment by Manfred Riem [ 09/Apr/13 ]

Can you send the entire reproducer (including all the sources) to issues@javaserverfaces.java.net?

Comment by dasago [ 10/Apr/13 ]

I send you an example project.. (maven based, JBoss 6.0 Final, Mojarra 2.1.17, PrimeFaces 3.5, Omnifaces 1.4.1)

First example in reset page works - pass values directly to composite component

Second example in reset page doesn't work - pass values via facelet file to composite component

Third example in reset page works - pass values via facelet file to composite component with a workaround of omnifaces

Comment by Manfred Riem [ 30/Aug/13 ]

You have hit upon an area with respect to composite components and ui:include that has not been ironed out as much as needed. The problem is that the context of the ui:param is not available within a retargetted expression that the action needs to actually work.

I am moving this to the spec issue tracker as the real issue still exists.

Comment by Thomas Lee [ 30/Aug/13 ]

This is probably a better description of the JAVASERVERFACES_SPEC_PUBLIC-1222 issue I filed. Being a POJO or a managed bean is unrelated if I recall correctly.

I've been working around this by placing the ui:param in the view outside of the ui:include so that evaluations can find the ui:param correctly.

<ui:param name="pojoOrManagedBean" value="#{bean}"/>
<ui:include src="innerPageWithCompositeComponentWithTarget"/>
Comment by Ed Burns [ 13/Sep/13 ]

Manfred, do you think we can close 1222 as a duplicate of this one?

Ed

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1222] ValueChange method in POJO doesn't resolve correctly when POJO is a ui:param Created: 09/Apr/13  Updated: 13/Aug/14

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

Type: Bug Priority: Minor
Reporter: Thomas Lee Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS X 10.8.3


Attachments: Zip Archive cc-ui-param.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1223 Facelet ui:param doesn't work in comp... Open

 Description   

Normally a composite component can resolve a valueChange method in a POJO that is a property of managed bean.

This is often used to pass a POJO to a <ui:include>:

<ui:include src="part.xhtml">
    <ui:param name="pojo" value="#{managedColors.unmanaged}"/>
</ui:include>

The using page would be:

<custom:list list="#{pojo.colors}"
             selected="#{pojo.color1}"
             valueChangeListener="#{pojo.onColorChange}">
    <f:ajax event="valueChange" execute="@this" render="@this"/>
</custom:list>

However, when the unmanaged bean (POJO) is passed as a <ui:param>, attempting to change the value will result in the following exception:

javax.faces.event.AbortProcessingException
/part.xhtml @10,62 valueChangeListener="#{pojo.onColorChange}":
The class 'com.custom.beans.PojoColors' does not have the property 'onColorChange'.

The valueChange method seems to only be resolved correctly be writing out the complete EL expression:

<custom:list selected="#{managedColors.unmanaged.color1}"
             list="#{managedColors.unmanaged.colors}"
             valueChangeListener="#{managedColors.unmanaged.onColorChange}">
    <f:ajax event="valueChange" execute="@this" render="@this"/>
</custom:list>

A simple example project for NetBeans has been attached detailing this issue.



 Comments   
Comment by Thomas Lee [ 09/Apr/13 ]

I can attach a sample project reproducing this issue once I have permissions to attach files.

EDIT:
Here's a link to a sample NetBeans project detailing the issue: https://www.dropbox.com/sh/ojdj6mbykzpxr9t/svlgMUzFw4

Comment by Manfred Riem [ 09/Apr/13 ]

Please send your sample zip file to issues@javaserverfaces.java.net. Can you please try it on the latest 2.1 release? Thanks!

Comment by Thomas Lee [ 09/Apr/13 ]

I've sent the sample zip project.

I've also reproduced this issue on the latest 2.1 release, which I believe is Implementation-Version: 2.1.20.

I did this by replacing the 2.1.6-SNAPSHOT version of javax.faces.jar in

/Applications/NetBeans/glassfish-3.1.2.2/glassfish/modules/javax.faces.jar

and confirming the new version 2.1.20 was loading via

FacesContext.class.getPackage().getImplementationVersion();

Thanks for the fast responses!

Comment by Thomas Lee [ 10/Apr/13 ]

Just tried it on the latest javax.faces.jar 2.2.0-m13-SNAPSHOT and got the same type of error of:

The class 'com.custom.beans.PojoColors' does not have the property 'onColorChange'
Comment by Thomas Lee [ 10/Apr/13 ]

Actually this doesn't seem to be a POJO issue, but something wrong with EL resolution on the ui:param in a composite component.

I tried passing a managed bean in a ui:param and got a property not found type of exception as well:

<ui:include src="part.xhtml">
   <ui:param name="managed" value="#{managedColors}" />
</ui:include>
<ui:composition ..>
    <custom:list list="#{managed.colors}"
               selected="#{managed.color1}"
               valueChangeListener="#{managed.onColorChange}">
      <f:ajax event="valueChange" execute="@this" render="@this"/>
  </custom:list>
</ui:composition>

Attempting to change the value results in the same type of error, except now it also occurs for a managed bean:

The class 'com.custom.beans.ManagedColors' does not have the property 'onColorChange'.
Comment by Manfred Riem [ 30/Aug/13 ]

You have hit upon an area with respect to composite components and ui:include that has not been ironed out as much as needed. The problem is that the context of the ui:param is not available within a retargetted method expression. And as such the resolution of the value expression is unable to find the 'pojo' variable.

You are aware that instead of using a ui:include you can pass a bean to a composite component as an attribute and then use the attribute to resolve to the valuenChange method?

I am moving this to the spec issue tracker as the real issue still exists.

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-1221] Please add support for populating data column headers from a list Created: 29/Aug/13  Updated: 01/Aug/14

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

Type: New Feature Priority: Minor
Reporter: pratap_abhinav Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Add support for populating data table headers from a managed bean list.

Eg.
Currently:

<h:datatable var="v" value=#

{mybean.list}

>
<h:column>
<f:facet name="header">
<h:outputText value="col1head"/>
</f:facet>
<h:outputText value=#

{v.col1}

/>
...
</h:column>
</h:datatable>

please add support for coding like this:
<h:datatable var="v" value=#

{mybean}

>
<h:columns>
<f:facet name="header">
<h:outputText value="#

{v.col2headerList}

"/>
</f:facet>
<h:outputText value=#

{v.col1valuelist}

/>

</h:columns>
...
</h:datatable>

or something like that as implemented in rich faces. It would be very useful for admin tool applications.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1220] Please add a attribute pagination="true", maxrows="" in h:datatable component of jsf. This will reduce a lot of coding and reduce dependency on another jsf implementations like primefaces. Created: 29/Aug/13  Updated: 13/Aug/14

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

Type: New Feature Priority: Minor
Reporter: pratap_abhinav Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Please add a attribute pagination="true", maxrows="" in h:datatable component of jsf. This will reduce a lot of coding and reduce dependency on another jsf implementations like primefaces



 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.

Comment by Ed Burns [ 13/Aug/14 ]

This would be a big change for h:datatable, but I expect some people would like it.





[JAVASERVERFACES_SPEC_PUBLIC-1219] Specify behavior in case of abandoned flow. Created: 26/Aug/13  Updated: 01/Aug/14

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

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

Issue Links:
Dependency
depends on JAVASERVERFACES-2997 None flow command actions navigation ... Closed

 Description   

Currently trying to navigate away from a flow by any means other than a flow-return or flow-call node will cause the navigation to silently fail. This approach has the nice property in that it prevents abandoned flows. Unfortunately, as JAVASERVERFACES-2997 shows, this approach is overly restrictive.

This issue calls for the spec to say what should happen when the flow is abandoned.



 Comments   
Comment by Ed Burns [ 26/Aug/13 ]

The fix for JAVASERVERFACES-2997 did the following.

When looking for a navigation match in the midst of the flow, if no other way of finding a match is found, look for an implicit match outside of the flow. If that's not found, look in the root navigation map using the same three step process in normal JSF navigation.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1211] UIOutput.resetValue() and UIInput.resetValue() produce unwanted state that is equal to the default values of the property accessor methods Created: 30/Jul/13  Updated: 01/Aug/14

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

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

Attachments: Text File changebundle-1211.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-2965 UIData performance and state saving i... Closed

 Description   

UIOutput/UIInput resetState() call set methods that cause StateHelper to add state that actually is the same as the default values that would be returned by the respective get-methods.

Proposed state neutral solution is be to remove the state from StateHelper using getStatehelper().remove(PropertyKey.xxx).



 Comments   
Comment by Hanspeter Duennenberger [ 30/Jul/13 ]

if resetValue() would remove the state UIData could make use of UIInput.resetValue() while restoring descendant state iterating the rows.

Comment by Hanspeter Duennenberger [ 30/Jul/13 ]

Added changebundle containing the proposed changes.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1208] Allow page authors to define ordering of resources in the <head> Created: 10/Jul/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Facelets/VDL, Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Right now, developers have no control over the ordering of resources loaded in the HEAD of the document. This can cause problems with ordering of CSS, JavaScript resources, or browser behavior. Something like PrimeFaces' solution (http://blog.primefaces.org/?p=1433) is definitely needed.

I ran into this requirement trying to force IE to use "IE 8 Standards Mode". This requires a <meta> header, but it must be the first element in the <head>. This isn't possible without a custom component or a third-party library like PrimeFaces.. See http://social.msdn.microsoft.com/Forums/ie/en-US/afb57ce6-d149-4a09-8811-63c0645c92e6/force-ie8-to-render-in-ie8-standard-mode.



 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-1206] required attribute is not enforced for inputFile Created: 08/Jul/13  Updated: 13/Aug/14

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

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

glassfish 4.0, Firefox


Issue Links:
Related
is related to JAVASERVERFACES-2923 required attribute is not enforced fo... Closed
Tags: file, file_upload, require

 Description   

When I select file at browser or not, I always have a part at server side. If no file is selected, the Part.size is zero.



 Comments   
Comment by Manfred Riem [ 08/Jul/13 ]

Can you please supply an example that reproduces the problem?

Comment by jasonzhang2002gmailcom [ 09/Jul/13 ]

This can be reproduced easily.


@RequestScoped
@Named
public class Test
{
	Part file;
	String str;
	public String getStr()
	{
		return str;
	}
	public void setStr(String str)
	{
		this.str = str;
	}
	public Part getFile()
	{
		return file;
	}
	public void setFile(Part file)
	{
		this.file = file;
	}
	public String save()
	{
		System.out.println("save is called");
		return null;
	}
}
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://xmlns.jcp.org/jsf/html"
	xmlns:f="http://xmlns.jcp.org/jsf/core"
	xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"
	xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
	
<h:body>
	<h:messages>
	</h:messages>
	<h:form enctype="multipart/form-data">
		<h:inputFile value="#{test.file}" id="file" required="true"></h:inputFile>
		<h:inputText value="#{test.str}" id="string" required="true"></h:inputText>
		<h:commandButton value="submit" action="#{test.save}">
		</h:commandButton>
	</h:form>
</h:body>
</html>
Comment by Ed Burns [ 09/Jul/13 ]

Manfred and I investigated this and determined that UIInput.isEmpty() doesn't correctly handle this case when there is a Part that is empty.

UIInput.isEmpty() was added in support of JAVASERVERFACES_SPEC_PUBLIC-426.

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-1202] cc:attributes type attribute: fallback case: use what the ELResolver returns. Created: 03/Jul/13  Updated: 10/Sep/15

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

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 Description   

JAVASERVERFACES_SPEC_PUBLIC-745 amended the language for the Composite Component Attributes ELResolver's getType() method.

An additional change is needed for correctness to the cc:attribute tag's type attribute. The existing language states:

Declares that this attribute must be a ValueExpression whose expected type is given by the value of this attribute. If not specified, and no "method-signature" attribute is present, java.lang.Object is assumed. This attribute is mutually exclusive with the "method-signature" attribute. If both attributes are present, the "method-signature" attribute is ignored.

This needs to be changed. Instead of assuming java.lang.Object, the system must use the return from the CC attribute ELResolver's getType() method.



 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-1201] Require that the cookie used to store the Flash key is setHttpOnly(true) Created: 02/Jul/13  Updated: 01/Aug/14

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

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

Issue Links:
Dependency
depends on JAVASERVERFACES-2911 For JSF 2.2 and beyond, do setHttpOnl... Closed

 Description   

Require that the cookie used to store the Flash key is setHttpOnly(true)



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1200] Search parent naming containers for component Created: 28/Jun/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: aplossystems Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 15 minutes
Time Spent: Not Specified
Original Estimate: 15 minutes
Environment:

JSF 2.1.24



 Description   

It's logical that when you have a tree of components you shouldn't look in the child naming containers for a relative id name as duplicates are likely to exist. However it doesn't seem logical to not look in the parent container and take the first avaiable component with that relative id as no duplicates will exist in a single layer above.

I've therefore made an simple update in the UIComponentBase that will look in the parent for the component for the relative id. There's a number of places that this will work more intuitively, especailly for people with a more basic knowledge of JSF. The first is when using relative id's within a dataTable or repeat, all of a sudden relative ids no longer work which is quite confusing if you don't know why. The second is that when you pass a relative id into a custom component it won't be able to find it as the custom component will do the find method relative to itself. The other is when using cc.clientId or similar within a custom component (granted you can just easily add a : beforehand in this scenario). I'm sure there's other times as well where this would come in useful.

Below is the code that would need to be put in place of the existing code, there's only about 5 lines of code actually changed, I've already run this through the JSF tests and everything appeared to pass :

[code]

// Identify the base component from which we will perform our search
UIComponent base = this;
UIComponent initialBase = null;
if (expr.charAt(0) == sepChar) {
// Absolute searches start at the root of the tree
while (base.getParent() != null)

{ base = base.getParent(); }

// Treat remainder of the expression as relative
expr = expr.substring(1);
} else if (!(base instanceof NamingContainer)) {
// Relative expressions start at the closest NamingContainer or root
while (base.getParent() != null) {
if (base instanceof NamingContainer)

{ break; }

base = base.getParent();
}
initialBase = base;
}

// Evaluate the search expression (now guaranteed to be relative)
UIComponent result = null;
String[] segments = expr.split(SEPARATOR_STRING);
for (int i = 0, length = (segments.length - 1);
i < segments.length;
i++, length--) {
result = findComponent(base, segments[i], (i == 0));
// the first element of the expression may match base.id
// (vs. a child if of base)
if (i == 0 && result == null &&
segments[i].equals(base.getId()))

{ result = base; }

if (result Unable to render embedded object: File (= null && () not found.(result instanceof NamingContainer)) && length > 0)

{ throw new IllegalArgumentException(segments[i]); }

if (result == null)

{ break; }

base = result;
}

if( result == null && initialBase != null && initialBase.getParent() != null )

{ initialBase.getParent().findComponent(expr); }

[/code]



 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.

Comment by Ed Burns [ 13/Aug/14 ]

I'm concerned about the performance implications of your suggestion.





[JAVASERVERFACES_SPEC_PUBLIC-1198] Specify behavior when multiple phase-listener decls with same FQCN are encountered Created: 11/Jun/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: None

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


 Description   

The XSD for <phase-listener> states:

The "phase-listener" element contains the fully qualified class
name of the concrete PhaseListener implementation class that will
be registered on the Lifecycle.

What is the correct behavior if multiple decls with the exact same FQCN are encountered? I think it should be "last one wins, log a message if more than one".



 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-1197] Support multiple attribute on h:inputFile Created: 10/Jun/13  Updated: 01/Aug/14

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-802 Ajax fileupload capabilities Closed

 Description   

HTML 5 has a new attribute on input file: multiple.

When present, the user agent must allow the file chooser to select multiple files.

While the pass through attributes feature allows this to render correctly:

<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>
...

The renderer for javax.faces.Input javax.faces.File doesn't handle this case correctly.

Instead, as it iterates through the parts, it just overwrites the preceding part with each file in the uploaded collection.

I think a better strategy is to always have the value of the component be a List<Part> instead of just Part.



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1196] CC-like conveniences for Facelet tags Created: 02/Jun/13  Updated: 29/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use, ease_of_development, facelets, tag, taglib

 Description   

In JSF 2.x there are composite components and Facelets tags. A prime difference between these two is that composite components become a component themselves in the component tree, while Facelets tags cause their "child" components to be inserted but they themselves do not become part of the tree.

Both these two artifacts have their own unique use cases, and thus the newer composite component cannot totally replace the older Facelet tags.

However, composite components being the more modern variant have several ease of use features such as the ability for being auto-registering when put into the /resources folder and the definition of its attributes directly into the defining .xhtml file.

Since Facelets tags are still very useful in modern JSF programming, I'd like to request them being upgraded to support auto-registering and attribute definition in the .xhtml file as well.

E.g.

/resources/mytag.xhtml
<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
    
    <ui:attribute name="foo" />
    
    ...
</ui:composition>

The above would register a Facelets tag just like the following in a -taglib.xml would do:

<tag>
    <tag-name>mytag</tag-name>
    <source>tags/mytag.xhtml</source>
    <attribute>
        <name>foo</name>	
    </attribute>
</tag>


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

This is a nice idea.

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.

Comment by djmj [ 29/Aug/15 ]

What about conditionally allowing composite component's behave like a tag or not to be a naming container?

I don't know much about the implementation background but was a developer these concepts seem much alike with little difference.
I only use tags when i dont want a naming container or i want to render the tag "as is". (for instance in a <h:panelGrid> to produce multiple cells)





[JAVASERVERFACES_SPEC_PUBLIC-1195] cc.attrs not avaiable when rendering h:outputStyleSheet Created: 24/May/13  Updated: 23/Sep/14

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

Type: Bug Priority: Minor
Reporter: tiagoperes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apache Tomcat 7.0.34 running in Windows 8


Tags: composite-component, outputStyleSheet

 Description   

Situation:
A composite component has its attributes declared with the "composite-attribute" tags, one of these attributes is "theme", used to specify the css file to be used by the component.

<composite:interface>
<composite:attribute name="theme" required="false" default="rose" />
...
</composite:interface>

At the component's implementation I try to import the css file using the "h:outputStyleSheet" tag.

<composite:implementation>
<h:outputStylesheet library="components" name="calendar/#

{theme}

/calendar.css" />
...
</composite:implementation>

Expected behavior:
If no attribute "theme" is specified by the page calling the component, "h:outputStylesheet" should import "calendar/rose/calendar.css". If a theme is specified it should import the specified theme.

Actual behavior:
"h:outputStylesheet" tries to import "calendar//calendar.css", no matter if a theme was specified or not.

My thoughts:
I tried to specify the theme directly inside the EL expression (name="#

{'rose'}

"), it worked, so it's not an expression problem. I think the cc.attrs variables are not available when "h:outputStylesheet" is processed.

There's a similar problem described in Stack Overflow:
http://stackoverflow.com/questions/7386344/evaluating-the-rendered-attribute-of-houtputstylesheet-inside-a-composite



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Comment by jpangamarca [ 23/Sep/14 ]

The same happens for h:panelGroup. I'm using JSF 2.2 (org.jboss.spec.javax.faces.jboss-jsf-api_2.2_spec, Implementation-Version: 2.2.6), Wildfly 8.1.0, WAR deployment.

Consumer:
<my:facelet hasPermission="#

{true}

" />

CC:

Doesn't work (gets rendered):

<h:panelGroup rendered="#

{!cc.attrs.hasPermission}

" layout="block">
<h:outputText value="Unauthorized" />
</h:panelGroup>

But this works:

<h:panelGroup rendered="#

{cc.attrs.hasPermission? false : true}

" layout="block">
<h:outputText value="Unauthorized" />
</h:panelGroup>





[JAVASERVERFACES_SPEC_PUBLIC-1193] Declaring component attributes via annotations Created: 11/May/13  Updated: 17/Aug/15

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

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, annotations, ease-of-use, ease_of_development, no-xml

 Description   

As of JAVASERVERFACES_SPEC_PUBLIC-594, custom components can be declared to be useable in Facelets via the @FacesComponent annotation. Via this it's no longer required to have an entry in a taglib.xml file.

However, if the component author wishes to declare the component's attributes (for documentation, tooling, etc), XML still has to be used.

I therefor would like to propose declaring these attributes via annotations as well.

E.g.

@FacesComponent(value="components.CustomComponent", createTag=true)
public class Foo extends UIComponentBase {

    @Attribute
    String color; // will be injected with getAttributes("color") 

    @Attribute(description="This will determine the ...", required=true)
    String style;

    @Attribute(description="The cost of ... ", default="100")
    Integer cost;

}


 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by c.beikov [ 07/Aug/14 ]

In my opinion the @Attribute annotation should go on an abstract getter and the component class should be declared as abstract. This way you could define reusable behavior in interfaces and inherit these attributes by implementing an interface.
The runtime can just generate an appropriate subclass of a component class that implements those methods. This also gives the implementation flexibility regarding the representation of the data.
If the values of EL expressions are bound to the component instance on creation of the component, how would the component get a changed value if the original EL expression would evaluate to a different value later in the lifecycle?

I implemented an annotation processor that generates these Java classes and XML files based on annotations for me at build time. I think Richfaces did something similar. JSF could just move that process to the runtime.

Comment by Ed Burns [ 17/Aug/15 ]

"Properties" is a hot button topic. It was recently booted out of Java SE 9. This is a decent writeup: http://blog.joda.org/2014/11/no-properties-in-java-language.html





[JAVASERVERFACES_SPEC_PUBLIC-1192] setProperties for validator behaviour is not there for mojarra-2.1.1 , Created: 09/May/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.1 Rev a
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: dorarajappan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

issue reference https://issues.apache.org/jira/browse/MYFACES-1892

As shown in this dtd:
http://java.sun.com/dtd/web-facesconfig_1_1.dtd

the validator element in a faces-config.xml file should support nested attribute and property elements:

<validator>
<validator-id>xyValidtor</validator-name>
<validator-class>com.xy.XyValidator</validator-class>
<property>
<property-name>length</property-name>
<property-class>java.lang.Integer</property>
<default-value>40</default-value>
</property>
</validator>

However this appears to never have been implemented in either 1.1.x or 1.2.x of core; only validator-id and validator-class are supported. Note that the equivalent feature exists for converters, and does appear to have been implemented.

What is the reason reference implementation is not having this behaviour?



 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-1191] SelectMany with generic collection results in ClassCastException Created: 07/May/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.1
Fix Version/s: None

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

Glassfish 3.12


Tags: collection, generic, selectmanycheckbox, selectmanylistbox

 Description   

Using a generic wrapper class similar to java.util.Map.Entry with a collection as generic value argument within a selectmany-component will result in following ClassCastException on submit:

Bean.java
private List<String> values;

private Entry<TestType, List<String>> entry;
site.xhtml
<h:selectManyMenu value="#{bean.entry.value}">
	<f:selectItems value="#{bean.values}"
		var="var" itemLabel="#{var}" itemValue="#{var}"/>
</h:selectManyMenu>

"java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to java.util.Collection"

(the Entry class does not works since it does not follows bean conventions, but its just for understanding of the generic problem)



 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1190] Extend facelet-taglib schema Created: 30/Apr/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Schema
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: facelets, taglib

 Description   

The Facelet taglib XML file has a number of limitations and it might be a good idea to improve the format.

Currently when a component inherits from another component, each and every attribute of the parent component has to be copied into the tag declaration in the taglib file. This makes taglib files very verbose and makes it hard to see which attribute the new tag introduces. A solution to this would be adding a way to declare that a tag inherits from another tag.

For instance:

<tag extends-namespace="http://java.sun.com/jsf/html" extends-tag="form">
    <tag-name>form</tag-name>
    <component>
        <component-type>org.example.Form</component-type>
    </component>

    <attribute>
        <description>
            Whether to include all URL (GET) request parameters in the action URI.
        </description>
        <name>includeRequestParams</name>
        <required>false</required>
        <type>boolean</type>
    </attribute>

    <!-- 20+ attributes of h:form such as "render", "accept", etc inherited -->
</tag>

Components in JSF can introduce an (EL) variable for their children to consume, e.g. like the var attribute of a datatable. This can however not be declared in a taglib, so tools have to have hardcoded knowledge of which tag does what with which attribute. This means tools lack behind new tags from a certain component library and only well known component libraries are supported. It would be great if it could be declared that an attribute represents the name of an introduced (EL) variable.

For instance:

<attribute>
    <description>
        Name of a request-scope attribute under which the model data for the
        row selected by the current value of the "rowIndex" property
        (i.e. also the current value of the "rowData" property) will be exposed.
    </description>
    <name>var</name>
    <required>false</required>
    <type>java.lang.String</type>
    <output>
        <scope>request</scope>
        <type-ref-attribute>value</type-ref-attribute>
        <type-ref-collection-element>true</type-ref-collection-element>
    </output>
</attribute>

In the above example var is declared to be an "output variable", that has as its type the type of the "collection element" that's bound to the value attribute. E.g. if value is bound to a List<Foo>, then the type of var is Foo. Other options would be setting a fixed type or referring directly to the type of another attribute.

Another issue is that attributes often have a default and an allowed range of values. This now has to be communicated in the description of an attribute and that description has to be kept in sync with the actual code. Tools sometimes have hardcoded knowledge of the allowed values (for auto-completion and warning flagging) for some attribute, but this too can be out of sync with newer releases of a component lib and doesn't support lesser known or internal components.

It would help a lot of this could be declared in a taglib file as well. E.g.:

<at