[JAVASERVERFACES_SPEC_PUBLIC-1056] More flexible state saving Created: 30/Nov/11  Updated: 22/Jan/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: Unassigned
Resolution: Unresolved Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: state, 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. Because this is a global setting that applies to all views in the application, it's not really flexible.

I would like to propose making this more flexible. Ideally the user would have three options for state: none (see JAVASERVERFACES_SPEC_PUBLIC-1055), client and server and would be able to set this globally, per URL pattern, or per view.

Setting the state saving method on a view would override any setting done per URL pattern, and setting state saving for a URL pattern overrides the global setting.

One step further would be to even allow setting the state saving method per individual component.



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

Although this would be very useful, we have to leave this as Fix Version unknown because I haven't figured out yet how to fit it into JSF 2.2.

Comment by Ed Burns [ 01/Aug/14 ]

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





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

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

Type: Improvement 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

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




[JAVASERVERFACES_SPEC_PUBLIC-1179] Clarify UIComponent.encodeAll requirements Created: 04/Apr/13  Updated: 17/Aug/15

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

Type: Improvement Priority: Critical
Reporter: aschwart Assignee: aschwart
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As requested by Manfred here:

http://java.net/jira/browse/JAVASERVERFACES-2743

I am logging this issue to request that the spec be more explicitly in stating that JSF implementations must call UIComponent.encodeAll() instead of directly calling each of encodeBegin/encodeChildren/encodeEnd() when rendering any component.

The reason for this is that UIComponent.encodeAll() is a non-final public method that components are free to override. JSF implementations should never bypass these overrides since this can result in bugs/loss of functionality.



 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-1399] Allow for UTF-8 in links Created: 19/Aug/15  Updated: 19/Aug/15

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

Type: Improvement Priority: Critical
Reporter: Manfred Riem Assignee: balusc
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-4005 Cutting symbols while URL-Encoding by... Open




[JAVASERVERFACES_SPEC_PUBLIC-1396] Standardize WebSocket and SSE integration with f:socket Created: 12/Aug/15  Updated: 20/Aug/15

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: None
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: 0 minutes
Time Spent: 1 hour, 8 minutes
Original Estimate: Not Specified





[JAVASERVERFACES_SPEC_PUBLIC-1393] Let CDI handle #{requestScope} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1388] Let CDI handle #{headerValues} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1391] Let CDI handle #{paramValues} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1394] Let CDI handle #{resource} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1389] Let CDI handle #{initParam} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1392] Let CDI handle #{request} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1387] Let CDI handle #{header} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1390] Let CDI handle #{param} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1078] Have DataModel implementations registrable Created: 28/Feb/12  Updated: 21/Aug/15

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

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

Attachments: Text File changebundle.txt     Text File changebundle.txt     Text File changebundle3.txt     Text File changebundle4.txt     Zip Archive newfiles.zip     Zip Archive newfiles.zip     Zip Archive newfiles3.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1380 Utilize @FacesDataModel for existing ... Open
is related to JAVASERVERFACES_SPEC_PUBLIC-1103 UIRepeat and UIData supports Iterable Resolved

 Description   

There have been issues and discussions about having a DataModel implementation in the spec for java.util.Set. This is certainly a good thing. Better though, would be to have a way (via annotation and/or faces-config.xml) to register an implementation and the type of Object it supports. This would clean up code in UIData and also allow for expansions of DataModel types without having to update the spec.



 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 arjan tijms [ 11/Jul/15 ]

Expanded @FacesDataModel support to UIRepeat

Comment by arjan tijms [ 13/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "Initial commit for https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Have DataModel implementations registerable, r=mriem"
Sending jsf-api/src/main/java/javax/faces/component/UIData.java
Adding jsf-api/src/main/java/javax/faces/model/FacesDataModel.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiExtension.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiUtils.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesMapProducer.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/FacesDataModelAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java
Adding test/javaee8/facelets
Adding test/javaee8/facelets/pom.xml
Adding test/javaee8/facelets/src
Adding test/javaee8/facelets/src/main
Adding test/javaee8/facelets/src/main/java
Adding test/javaee8/facelets/src/main/java/com
Adding test/javaee8/facelets/src/main/java/com/sun
Adding test/javaee8/facelets/src/main/java/com/sun/faces
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child1.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child11.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child111.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child11Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child1Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child21.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child21Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/DataBacking.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Parent.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/ParentModel.java
Adding test/javaee8/facelets/src/main/webapp
Adding test/javaee8/facelets/src/main/webapp/WEB-INF
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/beans.xml
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/glassfish-web.xml
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/web.xml
Adding test/javaee8/facelets/src/main/webapp/datatableCustomDataModel11.xhtml
Adding test/javaee8/facelets/src/main/webapp/datatableCustomDataModel111.xhtml
Adding test/javaee8/facelets/src/main/webapp/uirepeatCustomDataModel11.xhtml
Adding test/javaee8/facelets/src/main/webapp/uirepeatCustomDataModel111.xhtml
Adding test/javaee8/facelets/src/test
Adding test/javaee8/facelets/src/test/java
Adding test/javaee8/facelets/src/test/java/com
Adding test/javaee8/facelets/src/test/java/com/sun
Adding test/javaee8/facelets/src/test/java/com/sun/faces
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Sending test/javaee8/pom.xml
Transmitting file data ..............................
Committed revision 14837.

Comment by Manfred Riem [ 13/Jul/15 ]

Can you please address the following PMD issues

UIRepeat.java:61, UnusedImports, Priority: Normal
Avoid unused imports such as 'com.sun.faces.cdi.CdiUtils'.

DataModelClassesMapProducer.java:40, TooManyStaticImports, Priority: Normal
Too many static imports may lead to messy code.

Note it might be better to move the @interface into its own file instead of doing it as an inner class.

Comment by arjan tijms [ 14/Jul/15 ]

Avoid unused imports such as 'com.sun.faces.cdi.CdiUtils'.

I'll look at this one right away. I have the same checks running locally but this one slipped through (likely because of some noise regarding a couple of existing warnings)

DataModelClassesMapProducer.java:40, TooManyStaticImports, Priority: Normal
Too many static imports may lead to messy code.

I'll take a look at this one too. What's the limit currently set too?

Note that for JDK8 code we may want to increase the limit or remove the rule (if possible). JDK8 code puts a lot more emphasis on static imports and this is considered good practice. The PMD rule is likely still based on JDK5 style code. JDK8 provides a lot of goodies in utility classes such as Collectors (e.g; Collectors::toList that typical code does not write out fully (see basically all Oracle examples for Stream based code).

Note it might be better to move the @interface into its own file instead of doing it as an inner class.

Do you mean DataModelClassesMapProducer.DataModelClasses here? The initial idea was to keep it private to the parent class, since it was just a way to prevent an ambiguous situation when injecting Map. Code in the API project obtains the map by name only, so no new types were needed to be introduced there.

However, UIRepeat is in the impl project and could make use of utility code, so it may make sense indeed now to move it to a top level class. Additionally, if/when the API project can make use of utility code this would also allow it to obtain the map in a more strongly typed way.

Comment by arjan tijms [ 14/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Several cleanups, r=mriem"
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClasses.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesMapProducer.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java
Sending test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2Model.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Transmitting file data .......
Committed revision 14843.

Comment by arjan tijms [ 15/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Excluded tests for WLS 12.2.1, r=mriem"
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Transmitting file data ..
Committed revision 14861.





[JAVASERVERFACES_SPEC_PUBLIC-1355] Parameterize Object argument in Converter and Validator interfaces Created: 30/Jan/15  Updated: 21/Aug/15

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

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

Attachments: Text File changebundle-part-revert.txt     Text File changebundle-revert-all.txt     Text File changebundle.txt     Java Source File DateTimeConverter.java     Zip Archive newfiles.zip    

 Description   

All Converter and Validator implementations need to cast Object to T of interest. This is unnecessarily clumsy. Change Object to T in Converter and Validator interfaces.

public interface Converter<T> {
  public T getAsObject(FacesContext contect, UIComponent component, String submittedValue);
  public String getAsString(FacesContext contect, UIComponent component, T modelValue);
}
public interface Validator<T> {
  public void validate(FacesContext contect, UIComponent component, T value);
}


 Comments   
Comment by arjan tijms [ 30/Jul/15 ]

Applied to 2.3 trunk:
svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, generics in converter and validator, r=mriem"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/Converter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/EnumConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/BeanValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/MethodExpressionValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RequiredValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/Validator.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Sending test/servlet30-isolated/cactus/src/main/java/com/sun/faces/application/TestApplicationImpl.java
Adding test/unit/src/test/java/javax/faces/validator/CastingValidatorTestCase.java
Transmitting file data .........................
Committed revision 14952.

Comment by arjan tijms [ 30/Jul/15 ]

Reverting commit, tests don't pass.

svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, reverse, servlet30/systest failing"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/Converter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/EnumConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/BeanValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/MethodExpressionValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RequiredValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/Validator.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Sending test/servlet30-isolated/cactus/src/main/java/com/sun/faces/application/TestApplicationImpl.java
Deleting test/unit/src/test/java/javax/faces/validator/CastingValidatorTestCase.java
Transmitting file data ........................
Committed revision 14953.

Comment by Manfred Riem [ 10/Aug/15 ]

Look good r=mriem

Comment by arjan tijms [ 10/Aug/15 ]

Applied to 2.3 trunk:
svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, generics in converter and validator with fixed test, r=mriem"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/Converter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/EnumConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/BeanValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/MethodExpressionValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RequiredValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/Validator.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Sending test/servlet30/systest/src/main/java/com/sun/faces/systest/model/EnumBean.java
Sending test/servlet30/systest/src/main/webapp/enum-converter-1.jsp
Sending test/servlet30-isolated/cactus/src/main/java/com/sun/faces/application/TestApplicationImpl.java
Adding test/unit/src/test/java/javax/faces/validator/CastingValidatorTestCase.java
Transmitting file data ...........................
Committed revision 14983.

Comment by arjan tijms [ 12/Aug/15 ]

A concern was raised that Mojarra's own provided Converters and a single Validator weren't totally backwards compatible anymore for the perhaps rare but possible case where someone would assign say a BigDecimal to a variable of type Object and feed that into the getAsString method of a BigDecimalConverter.

With the new tyfe-safe change such usage would not compile anymore. Therefor largely reverted the changes to the provided Converters/Validator, but kept the changes to the Interfaces, since legacy code would have a raw version of these, which are compatible by design.

Applied to 2.3 trunk:
svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, partially reverted Mojarra’s converters/validators for backwards compatibility. Only interfaces themselves typesafe. r=mriem"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Sending test/servlet30-isolated/cactus/src/main/java/com/sun/faces/application/TestApplicationImpl.java
Transmitting file data ..................
Committed revision 14994.

Comment by Ed Burns [ 17/Aug/15 ]

Hello Arjan,

I'm still having problems running our ADF automated tests against
mojarra 2.3 trunk since your generics changes to
javax.faces.convert.Converter. Here is the compilation failure message:

8<------------------

[otranslate] wptgFile = /ade/aime_slc08ydi/oracle/built/trinidad-api/src-wptg.txt
[echo] Response file /ade/aime_slc08ydi/oracle/built/trinidad-api/src-javac.rsp
[echo] Compiling with out-of-process JAVAC
[java] Compiling 477 sources
[java] Error: /ade/aime_slc08ydi/jdevadf/modules/trinidad-api/etc/src/main/java/org/apache/myfaces/trinidad/convert/DateTimeConverter.java(178,8): javax.faces.convert.Converter cannot be inherited with different arguments: <> and <java.lang.Object>
[java] Some input files use or override a deprecated API.
[java] Recompile with -Xlint:deprecation for details.
[java] Some input files use unchecked or unsafe operations.
[java] Recompile with -Xlint:unchecked for details.
[java] Compilation time: 4978 msec, cdi generation time: 4759 msec.
[java] 1 error, 0 warnings
Scanned 22326 files and directories in 341ms: 0 files added, 0 files
removed, 0 directories added, 0 directories removed

8<------------------

I've attached the failing file so you can see what's going on. This is
from the Apache trinidad JSF Component library.

Can you please make the necessary changes so the attached compiles with
JSF 2.3?

Thanks,

Ed

Comment by arjan tijms [ 18/Aug/15 ]

Now reverted all provided Converters and Validators completely.

Problem was that a somewhat questionable but possible construct appeared in the wild, where a class would both extend a Converter implementation (e.g. DateTimeConverter and then also implement Converter separately (which is not needed, since the class from which is inherited already implements this interface). With the <Object> added to the super class, the two Converter implementations would be different; effectively parameterized with <Object> vs raw. Unfortunately this does not compile.

svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, completely reverted Mojarra’s converters/validators for backwards compatibility. Only interfaces themselves typesafe. r=mriem"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/EnumConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/BeanValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/MethodExpressionValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RequiredValidator.java
Transmitting file data ....................
Committed revision 15020.





[JAVASERVERFACES_SPEC_PUBLIC-1356] Explicitly specify and document UIInput#processValidators() behavior as to component's children Created: 30/Jan/15  Updated: 21/Aug/15

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

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


 Description   

In Mojarra, the processValidators() is first executed on the UIInput component itself and then on its facets/children. But in MyFaces, the processValidators() is first executed on the UIInput component's facets/children and then on itself. Exactly the other way round.

The desired behavior is as of now nowhere explicitly specified in the spec. It should be specified and aligned out.






[JAVASERVERFACES_SPEC_PUBLIC-1380] Utilize @FacesDataModel for existing DataModel wrappers Created: 19/Jul/15  Updated: 21/Aug/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: 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-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-1386] Let CDI handle #{flowScope} Created: 30/Jul/15  Updated: 21/Aug/15

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

Type: Improvement 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

Attachments: Text File changebundle-tmp-workaround.txt     Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open

 Comments   
Comment by Manfred Riem [ 21/Aug/15 ]

If you can fix Javadoc copy-paste error ("SessionMap") then r=mriem

Comment by arjan tijms [ 21/Aug/15 ]

copy/paste error fixed and committed to 2.3 trunk:

svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1386, CDI producer for #

{flowScope}

, r=mriem"
Adding jsf-api/src/main/java/javax/faces/annotation/FlowMap.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiExtension.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/FlowMapAnnotationLiteral.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/FlowMapProducer.java
Sending jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java
Adding test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectFlowMapBean.java
Adding test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectFlowMapBeanX.java
Sending test/javaee8/cdi/src/main/webapp/WEB-INF/web.xml
Adding test/javaee8/cdi/src/main/webapp/flow
Adding test/javaee8/cdi/src/main/webapp/flow/flow-flow.xml
Adding test/javaee8/cdi/src/main/webapp/flow/flow.xhtml
Adding test/javaee8/cdi/src/main/webapp/flow/next.xhtml
Adding test/javaee8/cdi/src/main/webapp/flowx
Adding test/javaee8/cdi/src/main/webapp/flowx/flowx-flow.xml
Adding test/javaee8/cdi/src/main/webapp/flowx/flowx.xhtml
Adding test/javaee8/cdi/src/main/webapp/flowx/next.xhtml
Adding test/javaee8/cdi/src/main/webapp/injectFlowMap.xhtml
Adding test/javaee8/cdi/src/test/java/com/sun/faces/test/javaee8/cdi/Spec1386IT.java
Sending test/javaee8/el/src/main/webapp/WEB-INF/web.xml
Adding test/javaee8/el/src/main/webapp/flow
Adding test/javaee8/el/src/main/webapp/flow/flow-flow.xml
Adding test/javaee8/el/src/main/webapp/flow/flow.xhtml
Adding test/javaee8/el/src/main/webapp/flow/next.xhtml
Adding test/javaee8/el/src/main/webapp/flowMap.xhtml
Adding test/javaee8/el/src/main/webapp/flowx
Adding test/javaee8/el/src/main/webapp/flowx/flowx-flow.xml
Adding test/javaee8/el/src/main/webapp/flowx/flowx.xhtml
Adding test/javaee8/el/src/main/webapp/flowx/next.xhtml
Adding test/javaee8/el/src/test/java/com/sun/faces/test/javaee8/el/Spec1386IT.java
Transmitting file data .........................
Committed revision 15033.

Comment by arjan tijms [ 21/Aug/15 ]

Tmp change of EL name to avoid since clash, since even producers are not totally deactivated and still present now.

Applied to 2.3 trunk:

svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1386, Temp EL name change to fix tests, r=mriem"
Sending jsf-ri/src/main/java/com/sun/faces/cdi/FlowMapProducer.java
Sending test/javaee8/el/src/main/webapp/flow/flow.xhtml
Sending test/javaee8/el/src/main/webapp/flow/next.xhtml
Sending test/javaee8/el/src/main/webapp/flowx/flowx.xhtml
Sending test/javaee8/el/src/main/webapp/flowx/next.xhtml
Transmitting file data .....
Committed revision 15036.





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

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: Not Specified
Time Spent: Not Specified
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.





[JAVASERVERFACES_SPEC_PUBLIC-1370] Provide Converters for Java 8 Date and Time API (JSR 310) Created: 01/May/15  Updated: 25/Aug/15

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

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

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1272 Take advantage of Java SE 8 JSR-310 T... Closed

 Description   

Apologies if I have missed an existing issue but I'm trying to determine how the convertDateTime converters will be aligned to support Java 8 Date and Time API in JSF 2.3



 Comments   
Comment by codylerum [ 01/May/15 ]

I meant to do this as a SPEC issue. Can it be moved?

Comment by Manfred Riem [ 01/May/15 ]

Done

Comment by Ed Burns [ 18/Aug/15 ]

Yes, this is a must for JSF 2.3.

EG member Josh Juneau wrote a blog post about it, but to actually get it in the spec we need a lot more work: < http://www.javacodegeeks.com/2015/06/utilizing-the-java-8-date-time-api-with-jsf-and-java-ee-7.html >.

Comment by Ed Burns [ 18/Aug/15 ]

Some questions about putting this in the spec.

1. What do we need to say in section 3.3.3 Standard Converter Implementations?

2. Which of java.time.

{LocalDate,LocaleTime,LocalDateTime}

do we want to support? All of them I'd think, but how does this square with the JSF conversion model which seems to favor the combined "DateTime" concept.

3. Perhaps we should create a new converter along side DateTimeConverter, say JavaTimeDateTimeConverter and trick it out with lots of attributes as the current DateTimeConverter does?





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






UIData needs review on a couple of fronts (JAVASERVERFACES_SPEC_PUBLIC-935)

[JAVASERVERFACES_SPEC_PUBLIC-963] Alignment/extending of iterating ui components Created: 01/Apr/11  Updated: 01/Aug/14

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

Type: Sub-task Priority: Major
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_small


 Description   

UIRepeat and UIData do pretty much the same: iterate over a collection of items. There should be a common base class for this, encapsulating the complicated logic for saving/restoring and iterating the state of the "rows". Something like "UIIterate".

Writing iterating components is very complicated at the moment. This base class should be easy to extend and also support any kind of data structures, not only "lists". Using an integer for the "row" iterating index is insufficient for creating "tree" components. A string or kind of indexing object would be much more flexible.

UIRepeat and UIData could extend this class and provide the existing interface on top of it.



 Comments   
Comment by Mathias Werlitz [ 21/Apr/11 ]

Well the essential difference between UIData(<h:dataTable>) and UIRepeat is how the iteration is done during render response.
UIRepeat iterates in the component and HtmlDataTable iterates in the renderer. This flexibility should be possible. Iterating in the renderer can be easier for "tree" components.

I could imagine a structure like this:

UINamingContainer
|
UIIterate
|
|- UISequentialIterate
| |
| |- UIData
| |- UIRepeat
|
|- UITree?

At least there should be an marking interface for such components because state saving seems to be different when nesting of iterating components is possible. For example UIRepeat already checks for UIData or UIRepeat parents. UIData does only look for itself as a parent.

Comment by Ed Burns [ 22/Apr/11 ]

I thought we had an issue for this, but yes, it's a good idea.

Comment by arjan tijms [ 27/Mar/14 ]

I think is a very important issue. In general UIData seems to be more robust than UIRepeat, but they indeed do pretty much the same thing and when inspecting the code it also looks like they had similar implementations at one time and/or borrowed from each other.

If there was a common implementation bugs such as JAVASERVERFACES-3215 would probably not have been there.

It would also prevent issues like JAVASERVERFACES_SPEC_PUBLIC-1103. In that case UIData got a new feature that UIRepeat would have needed just as well, but because of the time between JSF releases now has to wait for this for a rather long time.

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-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-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-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-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-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: 0
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-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 ... Open

 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-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-1183] selectMany components swallow/forgets preselected disabled SeletItems Created: 18/Apr/13  Updated: 01/Aug/14

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

Type: Improvement 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

Issue Links:
Related
is related to JAVASERVERFACES-2555 selectMany components swallow/forgets... Closed

 Description   

Consider this situation: you have a number of options and some options are already selected but must not be unselected. SelectItem allows to pass a disable item state and the item will be correctly rendered as checked but disabled. If some other options/checkboxes are enabled during decode only the submitted options will survive - the preselected disabled option will be lost since the disabled items checked state is not submitted.

I have a fix ready for that and also a test application - what's currently missing is the unit test for it, but I hope Manfred could help me out with that.

The change works like this: during rendering selected & disabled itemValues will be added to a Set that is maintained on the component attributes map with name "selectedDisabledItems". This Set, if existing, will be merged to the newValues[] array with the submitted values.

See attached changebundle.txt and the sources of the test bean and page.



 Comments   
Comment by Manfred Riem [ 18/Apr/13 ]

Please see associated issue for attachments

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-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-1160] Clarify intended workings of includeViewParams Created: 29/Jan/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: 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-2260 includeViewParams does not work Closed

 Description   

The workings of includeViewParams need to be clarified. See also http://java.net/jira/browse/JAVASERVERFACES-2260



 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-1177] Make it so com.sun.faces.faceletCache works with caching with respect to Resource Library Contracts Created: 20/Dec/12  Updated: 25/Feb/15

Status: Reopened
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: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2655 DefaultFaceletFactory.needsToBeRefres... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1346 Parties that decorate FaceletCacheFac... Resolved

 Description   

We've had a context-param called com.sun.faces.faceletCache for a long time. When Frank Caputo implemented some of Resource Library Contracts, he didn't carry forward the honoring of that contract to the parts of the impl that intersect with caching. Frank wonders if we can do it in FaceletCacheFactoryImpl.



 Comments   
Comment by Ed Burns [ 30/Jan/13 ]

Ed will read through Leonardo's comments on this matter on the thread he started on 14 January 2013 on the EG list.

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-1182] Implement new requirements for ViewState multi-form case in Ajax Created: 08/Nov/12  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: 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   

Please contact Werner Punz if you need more explanations on how to test this.

>>>>> On Wed, 31 Oct 2012 09:35:34 -0700, Edward Burns <edward.burns@oracle.com> said:

EB> I added this sentence:

EB> * In
EB> * addition to the submitting form, all forms created by JSF
EB> * under the view root identified by
EB> * <code>VIEW_ROOT_CONTAINER_CLIENT_ID</code> must be
EB> * updated similarly.

This is in jsf.js.



 Comments   
Comment by Ed Burns [ 30/Jan/13 ]

Move to m10.

Comment by rogerk [ 13/Mar/13 ]

After talking with Werner Punz (EG member) we agreed that there were some unanswered issues that could not be addressed in time for 2.2.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1372] f:ajax doesn't validate client ID anymore - confusing to starters Created: 20/Mar/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: Major
Reporter: balusc Assignee: Unassigned
Resolution: Unresolved Votes: 0
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-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-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-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-1329] @NotNull for f:viewParam is not triggered when the parameter is missing in the query string Created: 21/Oct/14  Updated: 27/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: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 15 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-1074] Add ViewDeclarationLanguageWrapper to JSF API Created: 21/Feb/12  Updated: 12/Aug/14

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

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

Attachments: Java Source File ViewDeclarationLanguageWrapper.java    

 Description   

While developing a portlet bridge, I found it necessary to have a ViewDeclarationLanguageWrapper. I've attached it do this issue with the hopes that it will be included JSF 2.2. Thanks!



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

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

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-1070] Add ExternalContext#setFlash(Flash) method Created: 13/Feb/12  Updated: 12/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Neil Griffin 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_SPEC_PUBLIC-1071 Portlet bridge unable to wrap Flash i... Closed

 Description   

Due to an incongruity between the JSF and Portlet lifecycles, I would like to propose adding the ExternalContext#setFlash(Flash) method to ExternalContext.

There is precedent for a method like this, for example ExternalContext#setRequest(Object) and ExternalContext#setResponse(Object):
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#setRequest(java.lang.Object)
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#setResponse(java.lang.Object)

For more information and justification, please refer to these issues:
https://issues.apache.org/jira/browse/PORTLETBRIDGE-201
https://issues.apache.org/jira/browse/PORTLETBRIDGE-207



 Comments   
Comment by Ed Burns [ 20/Mar/13 ]

Set fixVersion to 2.3.

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-1115] How does JSF handle children when they are not JSF components? Created: 13/Jun/12  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: paul_dijou Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mojarra 2.1


Tags: child, jsf2

 Description   

I've tryed to find in the spec how a JSF component should handle its children if those are HTML tags or plain text instead of JSF components but I couldn't really find anything. So please, if I've miss it, just indicate me the chapter number.

So I've make some tests and it appears that Mojarra is always wrapping those kind of child inside a UIInstructions (which is implementation specific). Shouldn't a standard way should be specify to let people know how to handle with non JSF content inside a JSF component? So every JSF implementation use the same mechanism.

In the same topic, I'm fine when plain text is nested inside a UIInstructions, but a bit sad when several HTML tags are nested inside only one UIInstructions. Why? Because I can no longer easily use both JSF components and HTML tags at the same time. For example, let's say I have a dropdown menu that will wrap each of its child inside a <li> tag when rendered.

<x:dropdownMenu>
	<h:link outcome="/index" value="Home"/>
	<h:link outcome="/admin" value="Admin"/>
</x:dropdownMenu>

Should generated, by iterating over the children, something like:

<ul class="dropdown">
	<li><a href="you.context.path/index.jsf">Home</a></li>
	<li><a href="you.context.path/admin.jsf">Home</a></li>
</ul>

But what if I use HTML tags directly now?

<x:dropdownMenu>
	<h:link outcome="/index" value="Home"/>
	<h:link outcome="/admin" value="Admin"/>
	<a href="help.externatsite.com">Help</a>
	<a href="partner.com">Our partner</a>
</x:dropdownMenu>

The generated code will be:

<ul class="dropdown">
	<li><a href="you.context.path/index.jsf">Home</a></li>
	<li><a href="you.context.path/admin.jsf">Home</a></li>
	<li><a href="help.externatsite.com">Help</a><a href="partner.com">Our partner</a></li>
</ul>

Why is that? Because the two HTML tags are wrapped inside only one UIInstructions, so for the parent JSF component, both of them are only one child, and so they are both nested inside only one <li> tag.

You could say that I could have used <h:outputLink> but that's not the point here. There is lots of HTML tags that just don't have a JSF equivalent, even more since HTML5, and those tags are not greatly handle when it comes to tree hierarchy IMO. Since the goal of JSF is to generate HTML, it should be able to plug with HTML natively.

What about creating a JSF component like "UIHtmlTag" that would wrap any HTML tag found? So, in the previous example, instead of having only one UIInstructions, you would have two UIHtmlTag, far better for child rendering purpose. UIInstructions would be use for plain text only. What do you think?



 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-1106] Content of ui.taglib.xml Created: 30/May/12  Updated: 24/May/15

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

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

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-1107 Use VDLDoc tool for spec Facelets VDL... In Progress

 Description   

In one project I tried to display content of facelet-taglib descriptions from the file ui.taglib.xml as HTML.
In a browser (Mozilla) the content of

<div class="syntax"><div class="html4strict"
        style="font-family: monospace;"><ol><li class="li1"><div
        class="de1"><span class="sc0">&amp;lt;!DOCTYPE html PUBLIC
        &amp;quot;-//W3C//DTD XHTML 1.0 Transitional//EN&amp;quot;</div></li>

is not displayed correctly.

I do not know why

&amp

is used before every HTML entity. I think that this can be replaced by

&

to display it correctly.



 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-1123] Add an ability to specify charset of the properties file while using ResourceBundle Created: 17/Jul/12  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-2462 Add an ability to specify charset of ... Closed

 Comments   
Comment by Eccenux [ 17/Jul/12 ]

As mentioned in #JAVASERVERFACES-2462 I think you can do the following:

  1. Add an extra Control constructor with the charset parameter.
  2. This constructor would set the charset property of Control class/object.
  3. The default constructor of Control would set charset to "ISO-8859-1".
  4. The charset would be used in ResourceBundle.Control#newBundle (as mentioned in #JAVASERVERFACES-2462).

This I belive would make it as backward compatible as possible.

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-1137] ExternalContext.encodeNamespace does not(should?) throw NPE when arg is null. Created: 12/Oct/12  Updated: 01/Aug/14

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

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

N/A



 Description   

ccording to the javadoc for ExternalContext.encodeNamespace(String name)

java.Lang.NullPointerException - if name is null

also the API says the following.

Servlet: The input value must be returned unchanged.

Now to me I would think that the throws clause would take precedence over the Servlet noted section. Meaning that we would check the arg for null regardless, then precede.

The Impl does return 'null' if the argument passed in is null when running in a Servlet container.



 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-1104] Can't use expression for validator attributes Created: 24/May/12  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: dmsinotte Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive validator.zip    
Issue Links:
Related
is related to JAVASERVERFACES-2417 Can't use expression for validator at... Closed
Tags: ajax, el, validator

 Description   

Attaching a test case that shows a problem when using an expression for an attribute in a validator. We have markup that looks like this:

<h:inputText id="ajaxMy"
value="#

{testBean.myNumber}

">
<f:validateLongRange minimum="1"
maximum="#

{testBean.maxValue}

"/>
<f:ajax execute="@this"
render="@form"/>
</h:inputText>

When the value of the maximum attribute is modified via Ajax from another input field, the value of the bean is properly set but the validator doesn't resolve appear to resolve the expression at the right time and the result is that validation occurs against the "old" values.



 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-1105] f:convertDateTime within h:dataTable/h:colum is not resolving EL expression referencing dataTable var Created: 29/May/12  Updated: 01/Aug/14

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

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

JBoss AS 7
Tomcat 7


Issue Links:
Related
is related to JAVASERVERFACES-2430 f:convertDateTime within h:dataTable/... Closed
Tags: colum, convertDateTime, dataTable, expression

 Description   

I have a scenario where every row in a data table has a date and also a different timeZone spec.
I wanted to use f:convertDateTime and set the timeZone parameter from the var element to format it. But this is not working as expected. Instead of the per-row timezone it is allways using the default timeZone to format the output since the EL expression for timeZone resolvs to null for all rows.

Attached is a minimal sample class and jsf file to demonstrate the issue. The expected output would be the time for 3 different timezones. But instead all 3 rows are rendered in the default TZ.

There are several workarounds for this but handling it like this would be the preffered one.

Thanks



 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-1003] Specify that fast iteration (with indices) is possible Created: 19/May/11  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: Martin Kočí Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Performance related problem:

Both Mojarra and MyFaces use iterator() for iteration over children. That is very slow if view is big and contains thousands of components.

Specify:
1) Specify : UIComponent.getChildren() is type of java.util.RandomAccess
2) Specify new UIComponent.getFacets(): List (java.util.RandomAccess) for fast iteration over facets

1) is very easy because mojarra and myfaces use ArrayList for children (so does trinidad)

I think this is not implementation detail, because custom renderkits must know that fast iteration is possible

See:
https://issues.apache.org/jira/browse/MYFACES-3130
http://www.mail-archive.com/dev@myfaces.apache.org/msg52979.html



 Comments   
Comment by Jakob Korherr [ 19/May/11 ]

As I followed the discussion on MYFACES-3130, I have to say that this is a valueable "change" (actually it is not really a change, just a hint).

So +1 on including this info in the spec from my side!

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-1011] ResourceELResolver does not encode the URL with ExternalContext.encodeResourceURL() Created: 26/May/11  Updated: 01/Aug/14

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

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

Attachments: Text File SPEC-1011-ResourceELResolver.patch    

 Description   

The getValue() method says:

  • If one of the above steps resulted in the creation of a {@link Resource}
  • instance, call <code>ELContext.setPropertyResolved(true)</code> and return
  • the result of {@link javax.faces.application.Resource#getRequestPath()}

Taken from: http://java.net/jira/browse/JAVASERVERFACES-1878



 Comments   
Comment by Hanspeter Duennenberger [ 15/Jun/11 ]

Hi Ed.

Here an updated patch for this ResourceELResolver issue.

Actually I opened this issue as a mojarra impl bug, but Roger has closed JAVASERVERFACES-1878 and created this one instead.

I'm not sure if that is right - I mean, if ResourceELResolver is affecting the spec, why is it then not in package javax.faces.el? Or is resource handling subject to bigger change for JSF 2.2?

Anyway, the attached patch contains the changes to fix this issue and a little correction in javadoc.

regards
Hanspeter

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-933] Support for zero-arg action/valueChangeListener does not work with EL VariableMapper Created: 31/Jan/11  Updated: 01/Aug/14

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

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

Status Whiteboard:

size_medium importance_medium


 Description   

Template client:
<h:body >
<ui:decorate template="template.xhtml">
<ui:param name="bean" value="#

{beanA}" />
</ui:decorate>
</h:body>

Template:
<f:subview xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:form >
<h:inputText value="value" valueChangeListener="#{bean.processValueChange}" />
<h:commandButton value="Click" actionListener="#{bean.processAction}" />
</h:form>
</f:subview>

if processValueChange/processAction are methods without event param, a exception
"javax.el.PropertyNotFoundException: Target Unreachable, identifier 'bean'
resolved to null" is thrown.
Description
Template client:
<h:body >
<ui:decorate template="template.xhtml">
<ui:param name="bean" value="#{beanA}

" />
</ui:decorate>
</h:body>
Template:

<f:subview xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html">
<h:form >
<h:inputText value="value" valueChangeListener="#

{bean.processValueChange}

" />
<h:commandButton value="Click" actionListener="#

{bean.processAction}

" />
</h:form>
</f:subview>

if processValueChange/processAction are methods without event param, a exception "javax.el.PropertyNotFoundException: Target Unreachable, identifier 'bean' resolved to null" is thrown.
Show »

ADDITIONAL COMMENTS:

Problem can be solved in
com.sun.faces.facelets.tag.jsf.ActionSourceRule.ActionListenerMapper2.applyMetadata:
MethodExpression methodExpressionOneArg = this.attr.getMethodExpression(ctx,
null,ActionSourceRule.ACTION_LISTENER_SIG);
MethodExpression methodExpressionZeroArg = this.attr.getMethodExpression(ctx,
null,ActionSourceRule.ACTION_SIG);

.. new MethodExpressionActionListener(methodExpressionOneArg,
methodExpressionZeroArg)

and probably similarly in Rule for ValueChangeListener.



 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-979] Extending the FacesContext to get to the maximum severity of the FacesMessages for all children of a NamingContainer Created: 18/Apr/11  Updated: 01/Aug/14

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

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

Status Whiteboard:

size_small importance_medium


 Description   

Sometimes a component needs to know that it contains components with a FacesMessage.



 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-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-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-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-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-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-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-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-1187] SelectItem ignores null value if used with converter that returns null Created: 27/Apr/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: Minor
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.1.2


Tags: converter, selectItem, selectItems

 Description   

Using a 'selectItem' with a 'null' value and a converter that will return 'null' for this value will ignore the value in the html output.

If the value is ignored not renderd in html 'select' tag the submitted value will be the label since no value was provided.

site.xhtml
<f:selectItem itemLabel="None" itemValue="#{null}"/>
TestConverter.java

@Override
public String getAsString(final FacesContext context, final UIComponent component, final Object value)
{
	if (value == null)
		return null;
	else
		return String.valueOf(value);
}

@Override
public Object getAsObject(final FacesContext context, final UIComponent component, final String value)
{
	if (value == null || value.trim() == "")
		return null;

	// convert string to object here just example

	return null;
}
Html output
<option>None</option>

Submitting the form will lead to a conversion error: "None" cannot be converted...
since html takes the label as the value if no value is provided.

Should the desired html not be in which case the conversion would succeed.

Html output desired
<option value="">None</option>

Returning empty String would lead to desired behavior. But I would prefer returning null instead, and also because of issue: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1180



 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-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-1163] Keep State Encoded in the Request URL For Postbacks Created: 14/Feb/13  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: rogerkeays Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

Kito suggested I submit this as a feature request. The idea is simply to retain the Request URL for postbacks in order to keep state encoded in the Request URL.

All forms are posted back to the original View ID. But this doesn't tell the whole story because the View ID is not the Request URL and we lose state that is encoded in request parameters or RESTful URL schemes like /app/widgets/300/edit.

We can fix this fairly easily.

All we need to do is post back to the original Request URL instead of the View ID and we're done. The forms come out looking like:

<form action="/app/widgets/WidgetEditor.xhtml?id=300&type=blue">..</form>

or

<form action="/app/widgets/300/edit">..</form>

instead of

<form action="/app/widgets/WidgetEditor.xhtml"/>..</form>

I posted an implementation of this scheme at http://www.ninthavenue.com.au/preserving-jsf-request-parameters-and-rest-urls and am using it in production.



 Comments   
Comment by arjan tijms [ 20/Mar/13 ]

JAVASERVERFACES_SPEC_PUBLIC-1175 seems to ask for the same thing.

Note that we implemented something similar for the o:form component in OmniFaces. The current implementation only includes the view parameters though, not all request parameters (I'll add an option for doing the last thing as well which can optionally be used while this issue is still open).

Comment by arjan tijms [ 20/Mar/13 ]

p.s. JAVASERVERFACES_SPEC_PUBLIC-776 and JAVASERVERFACES_SPEC_PUBLIC-1029 are slightly related to this.

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





Generated at Fri Aug 28 06:17:57 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.