[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-1416] Introduce annotation/class based configuration Created: 15/Apr/16  Updated: 13/Jan/17

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: Ed Burns
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-1417] Deprecate types in javax.faces.bean package Created: 18/May/16  Updated: 26/May/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Managed Beans
Affects Version/s: 2.3
Fix Version/s: 2.3

Type: Task Priority: Major
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-4145 Implement deprecate types in javax.fa... Closed

 Description   

JSF has for some time been emphasising to use CDI instead of its own native bean facility. Specifically, newer features such as @FlowScoped that were introduced in JSF 2.2 require CDI and won't work with the native bean facility.

Having the old native managed bean facility available is not rarely confusing to users. E.g. it's common to accidentally import javax.faces.bean.RequestScoped instead of javax.enterprise.context.RequestScoped.

Because of this I'd like to propose deprecating all the types in the javax.faces.bean package as well as the package itself via the @Deprecated annotation and/or javadoc, and mention what the alternatives are.






[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-1435] getViewResources method(s) to get list of physical view resources and logical views Created: 03/Jan/17  Updated: 03/Jan/17

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

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


 Description   

The ServletContext has a method to acquire all paths to resources within a web application; getResourcePaths().

In JSF resources are handled by the ResourceHandler This has a method createViewResource that takes a path and effectively returns a URL, just like ServletContext has a getResource method taking a path and returning a URL.

In both cases, the usage is to abstract the actual location of resources, which could therefor transparently be on a local or remote filesystem, in a database, custom jar location, or whatever.

The JSF specific ResourceHandler however does not have a getResourcePaths() equivalent.

I'd like to propose to rectify this by introducing such method for JSF view resources.

Care should be taken that it can both physical and logical views, and both views that can be requested for a top level request only, and all views (including those for includes).






[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-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.






Generated at Wed Jan 18 14:41:09 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.