[JAVASERVERFACES-4149] Implement CDI replacement for @ManagedProperty Created: 01/Jun/16  Updated: 13/Jun/16

Status: In Progress
Project: javaserverfaces
Component/s: expression language
Affects Version/s: None
Fix Version/s: 2.3.0-m07

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

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1418 CDI replacement for @ManagedProperty In Progress

 Description   

Implement JAVASERVERFACES_SPEC_PUBLIC-1418






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

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

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

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

 Description   

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

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






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

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

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


 Description   

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

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

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

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

E.g.

@FacesConfig
public class JustAClass {

}

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

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

E.g.

@FacesConfig(
    stateSavingMethod = "server"
)

Or a new option, to indicate the JSF version:

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

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

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

E.g.

@FacesConfig 
public class MyConfig {

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

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

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






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

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

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

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1078 Have DataModel implementations regist... Reopened

 Description   

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

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

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

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






[JAVASERVERFACES_SPEC_PUBLIC-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-1342] Support @Inject of current flow like "@Inject Flow currentFlow" Created: 12/Dec/14  Updated: 10/Aug/15

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

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


 Description   

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

@Inject
Conversation currentConversation

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






[JAVASERVERFACES_SPEC_PUBLIC-1316] Support @Inject on JSF artifacts Created: 09/Oct/14  Updated: 07/Oct/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: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified

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

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

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

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

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

Comment by Manfred Riem [ 14/Jan/15 ]

In Progress

Comment by Manfred Riem [ 15/Jan/15 ]

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

Comment by arjan tijms [ 30/Jul/15 ]

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

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





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

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

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

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

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

Make sure the appropriate spec text is added for:

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

Comment by arjan tijms [ 30/Jul/15 ]

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

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

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

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

Comment by Manfred Riem [ 20/Aug/15 ]

r=mriem

Comment by arjan tijms [ 20/Aug/15 ]

Applied to 2.3 trunk:

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





[JAVASERVERFACES_SPEC_PUBLIC-1193] Declaring component attributes via annotations Created: 11/May/13  Updated: 17/Aug/15

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

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

Tags: annotation, annotations, ease-of-use, ease_of_development, no-xml

 Description   

As of JAVASERVERFACES_SPEC_PUBLIC-594, custom components can be declared to be useable in Facelets via the @FacesComponent annotation. Via this it's no longer required to have an entry in a taglib.xml file.

However, if the component author wishes to declare the component's attributes (for documentation, tooling, etc), XML still has to be used.

I therefor would like to propose declaring these attributes via annotations as well.

E.g.

@FacesComponent(value="components.CustomComponent", createTag=true)
public class Foo extends UIComponentBase {

    @Attribute
    String color; // will be injected with getAttributes("color") 

    @Attribute(description="This will determine the ...", required=true)
    String style;

    @Attribute(description="The cost of ... ", default="100")
    Integer cost;

}


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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by c.beikov [ 07/Aug/14 ]

In my opinion the @Attribute annotation should go on an abstract getter and the component class should be declared as abstract. This way you could define reusable behavior in interfaces and inherit these attributes by implementing an interface.
The runtime can just generate an appropriate subclass of a component class that implements those methods. This also gives the implementation flexibility regarding the representation of the data.
If the values of EL expressions are bound to the component instance on creation of the component, how would the component get a changed value if the original EL expression would evaluate to a different value later in the lifecycle?

I implemented an annotation processor that generates these Java classes and XML files based on annotations for me at build time. I think Richfaces did something similar. JSF could just move that process to the runtime.

Comment by Ed Burns [ 17/Aug/15 ]

"Properties" is a hot button topic. It was recently booted out of Java SE 9. This is a decent writeup: http://blog.joda.org/2014/11/no-properties-in-java-language.html





[JAVASERVERFACES_SPEC_PUBLIC-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-1029] viewParam value lost after validation errors Created: 02/Aug/11  Updated: 04/Sep/15

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

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

Tags: state, validation

 Description   

As every UIInput component, UIViewParameter normally retains its value after a postback. If there's any kind of validation error on the page (unrelated to the UIViewParameter) the model to which the UIViewParameter is bound will correctly not be updated. However, when the component is subsequently encoded this model will be queried for its value.

In effect, the retained value is typically lost when the model is in request scope.

The following reproduces this:

viewparam.xhtml
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
>

    <f:metadata>
        <f:viewParam id="id" name="id" value="#{viewParamBean.id}"/>
    </f:metadata>

    <h:body>

        <h:messages />

        #{viewParamBean.id} <br/>

        <h:form>
            <h:inputText value="#{viewParamBean.text}" >
                <f:validateLength minimum="2"/>
            </h:inputText>

            <h:commandButton value="test" action="#{viewParamBean.actionMethod}"/>
        </h:form>

    </h:body>
</html>
ViewParamBean.java
@ManagedBean
@RequestScoped
public class ViewParamBean {

    private long id;    
    private String text;

    public void actionMethod() {

    }

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getText() {
        return text;
    }

    public void setText(String text) {
        this.text = text;
    }    
}

If you call the Facelet with viewparam.xhtml?id=12 it will display the 12 onscreen. If you then input something valid, e.g. aaaaa, the id will disappear from the URL, but keeps being displayed on screen (owning to the stateful nature of ui components). As soon as any validator error occurs (e.g. entering a), the id will be permanently lost. Entering valid input afterwards will not bring it back.

The implementation of encodeAll of UIViewParameter in Mojarra highlights what's happening:

UIViewParameter.java
public void encodeAll(FacesContext context) throws IOException {
    if (context == null) {
        throw new NullPointerException();
    }

    // if there is a value expression, update view parameter w/ latest value after render
    // QUESTION is it okay that a null string value may be suppressing the view parameter value?
    // ANSWER: I'm not sure.
    setSubmittedValue(getStringValue(context));
}

public String getStringValue(FacesContext context) {
    String result = null;
    if (hasValueExpression()) {
        result = getStringValueFromModel(context);
    } else {
        result = (null != rawValue) ? rawValue : (String) getValue();
    }
    return result;
}

Because hasValueExpression() in getStringValue() is true, this will try to get the value from the model. But in case the model is request scoped it will not have any value for this request, since validation has just failed and thus no value has ever been set. In effect, the stateful value of UIViewParameter is overwritten by whatever the model returns as a default (typically null, but this depends on the model of course).

Expected behavior: After validation errors occur, the model should not be consulted (e.g. as implemented by Mojarra's HtmlBasicRenderer#getCurrentValue)



 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-1429] Add constructor taking wrapped to all FacesWrapper classes Created: 26/Jul/16  Updated: 26/Jul/16

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

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


 Description   

https://java.net/projects/javaserverfaces-spec-public/lists/jsr372-experts/archive/2016-07/message/37






[JAVASERVERFACES_SPEC_PUBLIC-1423] Dynamic resource loading in ajax requests Created: 16/Jun/16  Updated: 26/Jul/16

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Resources
Affects Version/s: 2.2
Fix Version/s: None

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


 Description   

Currently if you dynamically add components via java code on a ajax postback, and the component type was not available in the initial request, the component probably missing it's required scripts/styles.
The same applies for dynamic ui:includes with a EL as src attribute.

The problem actually occurs with any JSF library.

The initial solution in PF was custom JS which checks if the script is included, otherwise we loaded the required styles/scripts.

The new solution is the following:

  • remember all resources with a RESTORE_VIEW phaselistener
  • in our PrimePartialResponseWriter (before RENDER_RESPONSE), we loop the current resources and create a diff
  • for the diff (new resources), we ask the resourceHandler#createResource for the URL and pass them to the client via ajax eval tag

AFAIK MyFaces Core already implemented something similiar.

Probably it's enough the describe the feature in the specs, there is no need to adding new API classes.
A param to deactive the feature woudl be great.



 Comments   
Comment by balusc [ 20/Jun/16 ]

Related:

Comment by stiemannkj1 [ 01/Jul/16 ]

In order to understand this issue better, I created a reproducer here: https://github.com/stiemannkj1/dynamic-resource-loading-ajax-reproducer

As tandraschko said, the problem occurs when you try to do something like the following:

Application application = FacesContext.getCurrentInstance().getApplication();
// exampleComponent has an @ResourceDependency on example.js
UIComponent exampleComponent = application.createComponent(ExampleComponent.COMPONENT_TYPE);
UIComponent parent = actionEvent.getComponent().getParent();
parent.getChildren().add(exampleComponent);

When that code is run, the @ResourceDependency s of exampleComponent are not loaded.

The problem also occurs when the src attribute of a ui:include is changed during Ajax, and the included ui:composition contains a component with an @ResourceDependency (the resource dependency is never loaded):

<h:form>
    <ui:include id="include" src="#{bean.include}" /><br />
    <h:commandButton value="Toggle Include" actionListener="#{bean.toggleInclude}">
        <f:ajax render="@form" />
    </h:commandButton>
</h:form>
public void toggleInclude() {

    if ("includeText.xhtml".equals(getInclude())) {
        // Contains example:component which has an @ResourceDependency on example.js
        setInclude("includeExample.xhtml");
    }
    else {
        setInclude("includeText.xhtml");
    }
}

I'll try to add some comments about how to implement this feature in a way that will work for JSF portlets soon.

- Kyle

Comment by stiemannkj1 [ 05/Jul/16 ]

The solution proposed by BalusC's would work for portlets, but it would need to be modified. The server-side solution of keeping a list of rendered resources somehow (likely using the JAVASERVERFACES_SPEC_PUBLIC-1404 solution) and doing a diff of what's rendered or not rendered would work fine with portlets. However the client-side aspect of "...passing resource path to JS and have it check if it's already in DOM and if not, then dynamically create script element." would need to be modified slightly. The problem with relying on the resource path is that portlet containers have full control of URLs and there is no guarantee that a resource URL will appear in the DOM in a parseable form. On top of that, resource URLs in Liferay and Pluto (the Portlet Container reference implementation) provide the resource library and name as parameters: portal/url?ln=library-name&javax.faces.resource=resource-name.js. Finally, in a portlet environment those parameter names are supposed to be prefixed with the portlet's namespace. Therefore, relying on the resource path on the client-side would be too hard (too many possible corner cases). Instead I propose that resources loaded during Ajax be loaded via and API like this:

resourceLoader.load('resource-library:resource-name', 'some/url/to/resource-name.js');

// resourceLoader.load() does something like this:
// if (!loadedResourceSet.contains('resource-library:resource-name')) {
//     // dynamically load the resource
// }

This would also require that resources loaded during a non-Ajax request be added to the loadedResourceSet:

<script type="text/javascript" src="some/url/to/resource-name.js" />
<script>
    resourceLoader.addLoadedResource('resourceLibrary:resourceName');
</script>

Finally, since the portlet container might need to be made aware that a resource has been loaded via Ajax, jsf.js would need to fire an event like resourceLoaded which would contain the resource URL and resource id.

Comment by balusc [ 22/Jul/16 ]

JAVASERVERFACES_SPEC_PUBLIC-1404 has been implemented. There's now a ResourceHandler#markResourceRendered() and isResourceRendered(). It should be trivial to re-mark the resources as rendered during restore view phase, provided that any dynamic resources are properly been added as component resources. I'm currently looking for the best place for that in API/impl.

Comment by balusc [ 22/Jul/16 ]

I created a bunch of test cases in order to reproduce and inspect the problem in below cases performed in the same view, invoked in arbitrary amount and order:

  • component resource added via view.addComponentResource(context, script, "head").
  • component resource added via view.addComponentResource(context, script, "body").
  • component resource added via parent.getChildren().add(componentWithResourceDependency).
  • component resource added via dynamic include referring component with resource dependency.

In all cases (at least in Mojarra) the view is properly restored with information about which resources have already been added during previous postbacks (via restore dynamic actions). In other words, view.getComponentResources() returns the correct information already. Indeed a diff on this during pre render view would have been sufficient in order to detect new resources. It looks like UIViewRoot#addComponentResource() is the best place to collect this information and PartialViewContext#processPartial() is the best place to render missing script resources (only if getRenderAll() is false). I was thinking about reusing update id="javax.faces.ViewHead" which is currently unimplemented in Mojarra's jsf.js. It merely throws a JS error saying that browsers doesn't support replacing head itself: https://github.com/javaserverfaces/mojarra/blob/a3f6431b9bde82b689540fc44ae0925baea2a9b7/jsf-api/src/main/resources/jsf.js#L1401 This is true, but browsers actually support manipulating head's contents (i.e. create script element and add it to head), so we could go on this route.

Issues yet to investigate:

  • does that also work for stylesheet resources
  • how exactly to implement processPartial() + javax.faces.ViewHead update
  • how would that work in Portlets as it doesn't seem to have a notion of "HTML head"
  • should we provide fallback when stateless view is used
Comment by balusc [ 22/Jul/16 ]

Those are the test cases: https://java.net/projects/mojarra/sources/git/revision/dcf22c7d30ec251fc34942b7bb5cfdb72a80931f

Comment by balusc [ 25/Jul/16 ]

I implemented the changes locally and got it running as intented. It also works for stylesheets and the fallback is mentioned in jsf.ajax.response() by explicitly stating "new elements" (i.e. when it does not exist in head, append it). Here are the API changes:

UIViewRoot#addComponentResource() (this should actually have been done as per issue 1404)

* <div class="changed_added_2_3"><p>The resource <code>Renderer</code> must ensure of the following:
* <ul><li>Do not render when {@link ResourceHandler#isResourceRendered(FacesContext, String, String)}
* returns <code>true</code>.</li>
* <li>After rendering, call {@link ResourceHandler#markResourceRendered(FacesContext, String, String)}.</li></ul></div>

UIViewRoot#processEvent()

* <p class="changed_added_2_3">
* If the argument <code>event</code> is an instance of {@link PostRestoreStateEvent} and 
* {@link PartialViewContext#isAjaxRequest()} returns <code>true</code>, then loop over all component resources
* and call {@link ResourceHandler#markResourceRendered(FacesContext, String, String)} for each of them.
* </p>

PartialViewContext#processPartial()

* <div class="changed_added_2_3"><p>When the indicated <code>phaseId</code>
* equals {@link PhaseId#RENDER_RESPONSE} and all components have been
* rendered, then perform the following tasks:
* <ol><li>
* If {@link PartialViewContext#isRenderAll()} returns <code>false</code>, 
* then render any component resource of {@link UIViewRoot} whose
* {@link ResourceHandler#isResourceRendered(FacesContext, String, String)}
* returns <code>false</code> in an update element with an identifier of
* <code>javax.faces.ViewHead</code>.</li>

jsf.ajax.response()

* <li>If an <code>update</code> element is found in the response with the identifier
* <code>javax.faces.ViewHead</code>:
* <pre><code>&lt;update id="javax.faces.ViewHead"&gt;
*    &lt;![CDATA[...]]&gt;
* &lt;/update&gt;</code></pre>
* <span class="changed_modified_2_3">append new elements from the <code>CDATA</code> contents from the
* response to the document's <code>head</code> section</span>.</li>

If there are no objections I will push the changes.

Comment by stiemannkj1 [ 25/Jul/16 ]

balusc,

1. How do you determine that a resource does not exist in the head already? From your previous comments, it seems like the list of resources is checked on the server-side before adding the resources. Is that the case, or is there client-side code which checks for duplicate resources?

2. Are the head (<update id="javax.faces.ViewHead">) scripts loaded before any markup (<update id="some:element:Id">) scripts? The head scripts should be loaded before the markup scripts to ensure that the markup scripts can utilize the head scripts. For example, consider a primefaces component which relies on jQuery. The component is added to a page which does not have jQuery loaded, and the component markup includes a script which relies on jQuery. If jQuery isn't loaded before this script, the component will fail with a JavaScript error. In Mojarra 2.2.13, jsf.js worked around a similar issue* by loading external scripts synchronously.

* The issue was that scripts in the partial response should still be executed in order of appearance whether they were external or inline, so that scripts in the partial response could depend on other scripts in the partial response.

Comment by balusc [ 25/Jul/16 ]

1. Perhaps "new elements" statement in jsf.ajax.response() is not clear enough? Maybe "non-existing elements" is clearer?
2. Good point, I will take this into account.

I have by the way changed loadScript for 2.3 and 2.2.14 as per https://java.net/jira/browse/JAVASERVERFACES-4024

Comment by balusc [ 26/Jul/16 ]

Updated API proposal:

UIViewRoot#processEvent()

 * <p class="changed_added_2_3">
 * If the argument <code>event</code> is an instance of {@link PostRestoreStateEvent} and 
 * {@link PartialViewContext#isPartialRequest()} returns <code>true</code>, then loop over all component resources
 * and call {@link ResourceHandler#markResourceRendered(FacesContext, String, String)} for each of them.
 * Finally, delegate to super.
 * </p>

PartialViewContext#processPartial() (this is indeed more than necessary for the issue, but I noticed this information is nowhere detailed so it had to be added anyway)

 * <div class="changed_added_2_3">
 * <p>When the indicated <code>phaseId</code> equals {@link PhaseId#RENDER_RESPONSE}, then perform the following
 * tasks in sequence:
 * <ol><li>If {@link #isResetValues()} returns <code>true</code>, then call 
 * {@link UIViewRoot#resetValues(FacesContext, Collection)}, passing {@link #getRenderIds()}.</li>
 * <li>If {@link #isRenderAll()} returns <code>false</code>, then render any component resource of
 * {@link UIViewRoot} whose {@link ResourceHandler#getRendererTypeForResourceName(String)} does not return 
 * <code>null</code>, and whose {@link UIComponent#getChildCount()} is zero, and whose
 * {@link ResourceHandler#isResourceRendered(FacesContext, String, String)} returns <code>false</code>, in an
 * <code>update</code> element with an identifier of <code>javax.faces.Resource</code>.</li>
 * <li>Process the components.</li>
 * <li>Obtain the state by calling {@link StateManager#getViewState} and write out it as an <code>update</code>
 * element with an identifier of <code>&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;&lt;SEP&gt;javax.faces.ViewState</code>
 * where <code>&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;</code> is the return from
 * {@link UIViewRoot#getContainerClientId(FacesContext)} on the view from whence this state originated, and
 * <code>&lt;SEP&gt;</code> is the currently configured {@link UINamingContainer#getSeparatorChar(FacesContext)}.
 * </li>
 * <li>If {@link #isRenderAll()} returns <code>false</code>, then write out each script of {@link #getEvalScripts()}
 * as an <code>eval</code> element.</li>
 * </ol></div>

jsf.ajax.response()

 * <li class="changed_added_2_3">If an <code>update</code> element is found in the response with the
 * identifier <code>javax.faces.Resource</code>:
 * <pre><code>&lt;update id="javax.faces.Resource"&gt;
 *    &lt;![CDATA[...]]&gt;
 * &lt;/update&gt;</code></pre>
 * append any element found in the <code>CDATA</code> contents which is absent in the document to the document's <code>head</code> section.
 * </li>

If there are no objections I will push the changes.

Comment by balusc [ 26/Jul/16 ]

For convenience I will also add UIViewRoot#getComponentResources(FacesContext) which returns all component resources without the need to know or specify all targets.

Comment by stiemannkj1 [ 26/Jul/16 ]

Thanks balusc, the JSDoc is very clear now.

However, as I mentioned above, checking whether a resource is loaded on the client-side will not work the same way for portlets. But, I've realized that the solution in my comment is probably overkill for JSF in webapps. Instead, the JSF portlet bridge would need an extension point in jsf.js where the bridge could determine whether a resource element should be appended to the head. The bridge would also need the opportunity to modify aspects of the element (for example adding or removing attributes) before adding it to the head section. These aren't really pressing concerns, so we can talk about them more when the implementation is closer to being completed. But I want to make sure that this feature will be compatible with portlets before the issue is closed.

Comment by balusc [ 26/Jul/16 ]

Indeed, you should be able to continue using UIViewRoot#addComponentResource() without much worrying.





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

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

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


 Description   

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

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

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

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

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

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



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

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

Comment by balusc [ 26/Aug/15 ]

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





[JAVASERVERFACES-4081] [PORT 2.2] Accept encoding string of slash ('/') causes ArrayIndexOutOfBoundsException Created: 25/Nov/15  Updated: 25/Nov/15

Status: Open
Project: javaserverfaces
Component/s: renderkit
Affects Version/s: 2.2.12, 2.3.0-m04
Fix Version/s: None

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

Any


Issue Links:
Cloners
clones JAVASERVERFACES-4077 Accept encoding string of slash ('/')... Resolved

 Description   

Apparently, some user agents send just a slash ('/') as Accept-Encoding header.
This causes Mojarra to error out the request with ArrayIndexOutOfBoundsException

The issue is clear in this code, RenderKitUtils.java, line 920
If the user agent's type is just a slash, the array would be empty
and the exception is bound to occur.
The correct action is to check if the array size is zero, to return empty
Accept-Encoding array then

            // now split type and subtype
            if (typeSubType.indexOf(CONTENT_TYPE_SUBTYPE_DELIMITER) >= 0) {
                String[] typeSubTypeParts = Util.split(appMap, typeSubType.toString(), CONTENT_TYPE_SUBTYPE_DELIMITER);
                // Apparently there are user-agents that send invalid
                // Accept headers containing no subtype (i.e. text/).
                // For those cases, assume "*" for the subtype.
                if (typeSubTypeParts.length == 1) {
                    type = typeSubTypeParts[0].trim();
                    subtype = "*";
                } else {
                    type = typeSubTypeParts[0].trim(); !!! *** Error Here ***
                    subtype = typeSubTypeParts[1].trim();
                }

I don't have a reproducer as this is happening on a live system,
but it's pretty clear what's happening here.

Here is the full exception:

java.lang.ArrayIndexOutOfBoundsException: 0
	at com.sun.faces.renderkit.RenderKitUtils.buildTypeArrayFromString(RenderKitUtils.java:920)
	at com.sun.faces.renderkit.RenderKitUtils.determineContentType(RenderKitUtils.java:570)
	at com.sun.faces.renderkit.RenderKitImpl.createResponseWriter(RenderKitImpl.java:268)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1195)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:406)
	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:136)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:126)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:223)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:669)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:177)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:63)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.omnifaces.facesviews.FacesViewsForwardingFilter.filterExtensionLess(FacesViewsForwardingFilter.java:128)
	at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:89)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:122)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)
]]





[JAVASERVERFACES-4080] [PORT 2.2.8] Accept encoding string of slash ('/') causes ArrayIndexOutOfBoundsException Created: 25/Nov/15  Updated: 25/Nov/15

Status: Open
Project: javaserverfaces
Component/s: renderkit
Affects Version/s: 2.2.12, 2.3.0-m04
Fix Version/s: None

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

Any


Issue Links:
Cloners
clones JAVASERVERFACES-4077 Accept encoding string of slash ('/')... Resolved

 Description   

Apparently, some user agents send just a slash ('/') as Accept-Encoding header.
This causes Mojarra to error out the request with ArrayIndexOutOfBoundsException

The issue is clear in this code, RenderKitUtils.java, line 920
If the user agent's type is just a slash, the array would be empty
and the exception is bound to occur.
The correct action is to check if the array size is zero, to return empty
Accept-Encoding array then

            // now split type and subtype
            if (typeSubType.indexOf(CONTENT_TYPE_SUBTYPE_DELIMITER) >= 0) {
                String[] typeSubTypeParts = Util.split(appMap, typeSubType.toString(), CONTENT_TYPE_SUBTYPE_DELIMITER);
                // Apparently there are user-agents that send invalid
                // Accept headers containing no subtype (i.e. text/).
                // For those cases, assume "*" for the subtype.
                if (typeSubTypeParts.length == 1) {
                    type = typeSubTypeParts[0].trim();
                    subtype = "*";
                } else {
                    type = typeSubTypeParts[0].trim(); !!! *** Error Here ***
                    subtype = typeSubTypeParts[1].trim();
                }

I don't have a reproducer as this is happening on a live system,
but it's pretty clear what's happening here.

Here is the full exception:

java.lang.ArrayIndexOutOfBoundsException: 0
	at com.sun.faces.renderkit.RenderKitUtils.buildTypeArrayFromString(RenderKitUtils.java:920)
	at com.sun.faces.renderkit.RenderKitUtils.determineContentType(RenderKitUtils.java:570)
	at com.sun.faces.renderkit.RenderKitImpl.createResponseWriter(RenderKitImpl.java:268)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1195)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:406)
	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:136)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:126)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:223)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:669)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:177)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:63)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.omnifaces.facesviews.FacesViewsForwardingFilter.filterExtensionLess(FacesViewsForwardingFilter.java:128)
	at org.omnifaces.facesviews.FacesViewsForwardingFilter.doFilter(FacesViewsForwardingFilter.java:89)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at com.baw.website.filters.CmsFilter.doFilter(CmsFilter.java:32)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.omnifaces.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:122)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
	at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
	at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
	at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
	at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
	at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
	at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
	at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
	at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
	at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)
]]





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

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

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


 Description   

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

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






[JAVASERVERFACES-4067] <f:validateBean disabled="true" > seems to not be implemented Created: 19/Sep/15  Updated: 19/Sep/15

Status: Open
Project: javaserverfaces
Component/s: validation
Affects Version/s: None
Fix Version/s: None

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


 Description   

While working on the implementation of JAVASERVERFACES_SPEC_PUBLIC-1, I observed that the "disabled" attribute on <f:validateBean> seems to not be implemented.






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

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

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

Tags: state, state_saving, state_saving_method

 Description   

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

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

The options can be as follows:

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





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

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

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

Tags: state, state_saving, state_saving_method, stateless

 Description   

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

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

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

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






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

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

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

Tags: state, state_saving, state_saving_method

 Description   

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

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

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






[JAVASERVERFACES-4020] HtmlResponseWriter passThroughAttributes ivar is ConcurrentHashMap. Why? Created: 18/Aug/15  Updated: 19/Aug/15

Status: Open
Project: javaserverfaces
Component/s: renderkit
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to JAVASERVERFACES-4019 UIComponent passThroughAttributes imp... Open

 Description   

From Kevin Jackson:

KJ> 3) When you make a copy of the pass thru attributes, you create another
KJ> ConcurrentHashMap. Are ResponseWriters ever accessed concurrently? I
KJ> don't think so.






[JAVASERVERFACES-4019] UIComponent passThroughAttributes implemented as ConcurrentHashMap. Why? Created: 18/Aug/15  Updated: 18/Aug/15

Status: Open
Project: javaserverfaces
Component/s: lifecycle
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to JAVASERVERFACES-4020 HtmlResponseWriter passThroughAttribu... Open

 Description   

From Kevin Jackson:

KJ> 1) In UIComponentBase, PassThroughAttributesMap is a ConcurrentHashMap.
KJ> I see several other maps in this class and they are all ordinary
KJ> HashMaps. Since ConcurrentHashMaps are so much heavier than HashMaps,
KJ> there must be something that I am missing here. Why did you use a
KJ> ConcurrentHashMap for pass thru attributes? From what I understand, the
KJ> component tree can only be accessed from one thread at a time.






[JAVASERVERFACES-3791] Implement JAVASERVERFACES_SPEC_PUBLIC-1359 views Created: 25/Feb/15  Updated: 19/Jun/15

Status: Open
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.3.0-m02
Fix Version/s: None

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

Attachments: Text File 20150305-1945Z-i_moj_3791.patch    
Issue Links:
Related
is related to JAVASERVERFACES-3793 Implement 1365-quickVersionCheck Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1359 Resolve views from dedicated folder In Progress

 Description   

Impl issue for JAVASERVERFACES_SPEC_PUBLIC-1359.



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

Snapshot of work.





[JAVASERVERFACES-3763] Plain HTML is lost when a composite component is added dynamically and is re-rendered Created: 09/Feb/15  Updated: 03/Mar/15

Status: Open
Project: javaserverfaces
Component/s: dynamic components
Affects Version/s: 2.2.10
Fix Version/s: None

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

Tomcat 7.0.47


Attachments: File reproducer-3763.war    
Issue Links:
Cloners
clones JAVASERVERFACES-3224 Plain HTML is lost when a composite c... Closed

 Description   

A problem similar to the one described in issue 3158.

A composite component which contains a mixture of plain HTML and JSF tags is added dynamically with FaceletContext.
If the partial response is rendered first, everything is fine.
But if another AJAX request is submitted and the part of the HTML document which contains the composite is updated,
the plain HTML is missing.

I will provide an example where the initial view already contains an instance of the Composite (dcc:foo).
There is a button for adding another instance of the foo component.
Afterwards, if one Triggers the other button 'Partial update', the updated page obviously does not look alright.

I am well aware that issue 3158 has been closed 'working as designed' and that you couldn't reproduce that error.

Note that I am using Tomcat (instead of Glassfish), as well, just as the reporter of 3158.
But I guess, there shoudn't be any difference just because of different Container implementations.



 Comments   
Comment by lutzulrich [ 09/Feb/15 ]

Sorry, I used to 'clone' operation thinking I would be able to change the affected versions etc.

These days we switched from Mojarray 2.1.x to 2.2.10.
Thus, I wanted to use the JSF 2.2 way of adding composites as suggested by M. Riem in his comments on issue 3224.
But the problem I reported in 3224 is still present in 2.2.10.

I will provide a reproduced, soon.

Comment by lutzulrich [ 11/Feb/15 ]

I just noticed that the JSF 2.2 specification defines new tag library URIs.
In my reproducer, I used the old ones (http://java.sun.com/jsf/...).
In my IDE, I switched to the new ones (http://xmlns.jcp.org/jsf/...). But that didn't solve the problem.

Also note that in JSF 2.2 it is easy to turn plain HTML into components by using the jsf:element attribute.
Applying it to all HTML elements can be used as a workaround.
But the <script> element is still a problem.





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

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

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


 Description   

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

case_Ajax

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

case_MultiSubmit

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






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

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

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

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1099 Resolve views by convention from dedi... Closed
is related to JAVASERVERFACES-3791 Implement JAVASERVERFACES_SPEC_PUBLIC... Open

 Description   

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

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

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

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

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



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

Sort of sub-issue of 1099





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

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

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

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

 Description   

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

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



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

Not enough information in the bug report to take action.

Comment by Ed Burns [ 27/Aug/15 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1321] Leverage HTTP2 Server Push from JSF Created: 13/Oct/14  Updated: 01/Sep/15

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

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


 Description   

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






[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-1298] Resolve backward incompatible change regarding PartialResponseWriter.writePreamble() Created: 11/Aug/14  Updated: 10/Sep/15

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

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

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

 Description   

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



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

These were done at the request of the portlet community:

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

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

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

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

And Neil Griffin replied with a justification:

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

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

Comment by Ed Burns [ 11/Aug/14 ]

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

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

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

Comment by btsulliv [ 14/Aug/14 ]

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

writePreamble

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Simple:

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

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

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

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

Comment by Ed Burns [ 05/Sep/14 ]

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

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





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

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

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

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

 Description   

Consider this spec text, from section 7.4.2:

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

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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1244] Reword requirements for EL expressions inlined in Facelets pages, but outside of components. Created: 19/Dec/13  Updated: 10/Sep/15

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

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


 Description   

Text copied from JAVASERVERFACES-3094

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

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

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



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1202] cc:attributes type attribute: fallback case: use what the ELResolver returns. Created: 03/Jul/13  Updated: 10/Sep/15

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

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


 Description   

JAVASERVERFACES_SPEC_PUBLIC-745 amended the language for the Composite Component Attributes ELResolver's getType() method.

An additional change is needed for correctness to the cc:attribute tag's type attribute. The existing language states:

Declares that this attribute must be a ValueExpression whose expected type is given by the value of this attribute. If not specified, and no "method-signature" attribute is present, java.lang.Object is assumed. This attribute is mutually exclusive with the "method-signature" attribute. If both attributes are present, the "method-signature" attribute is ignored.

This needs to be changed. Instead of assuming java.lang.Object, the system must use the return from the CC attribute ELResolver's getType() method.



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1185] Pass Through attribute should have priority when rendering Created: 25/Apr/13  Updated: 19/Aug/15

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

Type: Bug Priority: Critical
Reporter: Bruno Borges Assignee: Ed Burns
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-1270 JavaDoc for TagDecorator regarding pa... Resolved

 Description   

Tried the following code:

index.xhtml
<a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a>

The href attribute rendered contains the value anotherPage_fake.xhtml. In this case (and similar others), the pass through attribute should have priority in the rendering process, if it will compete with a static attribute.



 Comments   
Comment by Bruno Borges [ 13/Aug/13 ]

Digging more into Pass Through Attributes, I find this feature one of the best things I've ever seen in JSF in years, because it could bring development/designer preview without the need to run an app server. A feature that several frameworks permit, such as Apache Wicket and Tapestry. But if Pass Through Attributes doesn't override regular attributes, then it becomes not interesting.

The spec is not clear about this, and I think it should be provided an Errata, with a change in the current implementation.

Sample A

 
<script type="text/javascript"
             src="../../js/jQuery.js"
             p:src="${facesContext.externalContext.requestContextPath}/js/jQuery.js"></script>

Sample B

<script type="text/javascript" src="../../js/jQuery.js">
    <f:passThroughAttribute
       name="src"
       value="${facesContext.externalContext.requestContextPath}/js/jQuery.js" />
</script>

Either samples should end up with this:

<script type="text/javascript" src="/myapp-1.0-SNAPSHOT/js/jQuery.js"></script>
Comment by Frank Caputo [ 13/Aug/13 ]

Pass through attributes have priority as specified in the “Rendering Pass Through Attributes” section of the overview of the standard HTML_BASIC render kit: https://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_behavior_encoding

In <a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a> the href attribute becomes a pass through attribute and thus has priority.

Comment by Bruno Borges [ 13/Aug/13 ]

Hi Frank, thanks for pointing that out, but I disagree that "static" attributes should have priority when faced against calculated/dynamic attributes such as jsf:outcome.

If an element has both attributes (a static like 'href', and a dynamic as 'jsf:outcome'), the general idea is that the static attribute is for static preview/prototyping only, and should be replaced by the calculated value.

This is how other web frameworks have been doing for years.

Comment by jyeary [ 13/Aug/13 ]

The link you specified has some very specific text about priority.

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence. Pass through attributes are rendered as if they were passed to ResponseWriter.writeURIAttribute().

Unless I am reading this incorrectly, the jsf:outcome should take precedence over the static href attribute. I am on the fence on this though. I think that the pass through attributes are a great addition to the framework. However, if the renderer has the attribute defined, it can be set dynamically using EL. In this case, pass through attributes are simply duplicating the renderer specific attributes. This is for the case of the JSF components.

What advantages do we gain from the pass through taking precedence over the renderer specific attributes if they duplicate each other? I would say that the renderer specific attributes should take precedence.

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

Comment by Bruno Borges [ 13/Aug/13 ]

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

This is what I'm looking for. I don't want to loose the "previability" of the page.

Comment by Ed Burns [ 28/Aug/13 ]

From the spec section cited by John and Frank:

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence.

Consider Bruno's original markup:

<a href="anotherPage_fake.xhtml" 
   jsf:outcome="/anotherPage.xhtml">Another Page</a>

Because this is an <a> element with a jsf:outcome attribute, it is treated as an h:link, specified in the following.

http://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html

Perhaps the root problem here is that there is another set of attributes that must be considered, separate from the set of renderer specific attributes. This is the set of attributes that the renderer itself must use when rendering the component. Let's call these renderer required attributes. I suggest that the spec be modified to define the term renderer required attributes, and to say that renderer required attributes take precedence over pass through attributes on the markup.

Unfortunately, there is no runtime representation of the set of renderer required attributes, so it's not possible for the spec to say that, though. We would need to have a way for each renderer to declare its set of renderer required attributes, then we could require the ResponseWriter to act accordingly based on the priority.

There is no conflict because "href" is not a renderer specific attribute.

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-1150] Add @ClientWindowScoped Created: 04/Dec/12  Updated: 05/Oct/15

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

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


 Description   

JSF 2.2 added ClientWindow capabality. There should be a corresponding CDI scope.



 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 frederickkaempfer [ 05/Oct/15 ]

Please note the importance of specifying client window timeouts and/or a maximum number of client windows per http session to provide an upper limit of the memory requirements of this feature. Faces Flows currently do not have such a limit either (https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1398), but could get it as well by storing them in the client window scope.





[JAVASERVERFACES_SPEC_PUBLIC-1203] Empty String as Null is not effective in 2.2.0 Created: 04/Jul/13  Updated: 20/Aug/15

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

Type: Improvement Priority: Critical
Reporter: jasonzhang2002gmailcom Assignee: Frank Caputo
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0, EL 3.0


Issue Links:
Related
is related to JAVASERVERFACES-3071 javax.faces.INTERPRET_EMPTY_STRING_SU... Closed
Tags: null, string

 Description   

GlassFish 4.0 uses EL 3.0.
Section 1.23.2 in EL 3.0 states that null String will be converted to empty String.
So we need a ELResolver to handle the conversion somethig like this

public class NullStringHanlder  extends ELResolver
{

	@Override
	public Class<?> getCommonPropertyType(ELContext context, Object base)
	{
		
		return String.class;
	}

	@Override
	public Iterator<FeatureDescriptor> getFeatureDescriptors(ELContext context,
			Object base)
	{
		return null;
	}

	@Override
	public Class<?> getType(ELContext context, Object base, Object property)
	{
		
		return null;
	}

	@Override
	public Object getValue(ELContext context, Object base, Object property)
	{
		
		return null;
	}

	@Override
	public boolean isReadOnly(ELContext context, Object base, Object property)
	{
		
		return true;
	}

	@Override
	public void setValue(ELContext context, Object base, Object property,
			Object value)
	{
		
		
	}

	@Override
	public Object convertToType(ELContext context, Object obj,
			Class<?> targetType)
	{
		if (obj==null && String.class.equals(targetType))
		{
			context.setPropertyResolved(true);;
			return null;
		}
		return null;
			
		
	}
	

}




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

Thanks for taking the time to report this. How do you suggest we reconcile this issue with the meaning of the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context-param? This param is described in section 11.1.3 Application Configuration Parameters of the spec.

javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL – If this param is set, and calling toLowerCase().equals("true") on a String representation of its value returns true, any implementation of UIInput.validate() must take the following additional action.
If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and UIInput.getSubmittedValue() returns a zero-length String call UIInput.setSubmittedValue(null) and continue processing using null as the current submitted value

Comment by jasonzhang2002gmailcom [ 05/Jul/13 ]

This is integration issue. Mojarra definitely follows the specification. However, the problem is deeply down into EL implementation/Spec. I am currently using a custom ELResolver(see above) only for this string conversion. By this way, no mojarra or EL is effected. Mojarra can come with such a resolver to explicitly to control the string conversion by default.

Comment by Ed Burns [ 08/Jul/13 ]

We need to move this to the spec issue tracker because what you are asking is a spec change. We understand that EL 3.0 allows this, but we would need to bring this issue up to the expert group.

Comment by rekiem87 [ 10/Apr/14 ]

Glassfish 4.0.1 with the latest mojarra still have the issue

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-1314] Change @FacesConverter to handle both value and forClass attributes Created: 03/Oct/14  Updated: 31/Aug/15

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

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

Attachments: Text File changebundle.txt    

 Description   

The Javadoc of @FacesConverter contains this text:

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

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



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

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

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

Comment by Ed Burns [ 26/Aug/15 ]

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

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

1. Use a converter by class

<h:inputText value="#

{bean.fooProperty}

" />

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

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

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

Will this satisfy?

Comment by Hanspeter Duennenberger [ 31/Aug/15 ]

Hi Ed.

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

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

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

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

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

Best regards
Hanspeter





[JAVASERVERFACES-4110] f:convertDateTime with java.time styles fails on platform with non-English locale Created: 13/Mar/16  Updated: 21/Jun/16

Status: Open
Project: javaserverfaces
Component/s: conversion
Affects Version/s: 2.3.0-m04
Fix Version/s: None

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


 Description   

In DateTimeConverter#getDateFormat(), the DateTimeFormatter#ofLocalizedTime() calls doesn't take into account the specified locale and therefore fails on a non-English locale (as noticed by failing integration test for issue 4087 when executed on a machine with a non-English locale, as happened to me on a Dutch-localized machine).

Solution is to set the locale afterwards via DateTimeFormatter#withLocale(). Integration tests can use Locale#setDefault() to unit-test the behavior (don't forget to set back to original default afterwards).



 Comments   
Comment by ZhangXinyuan [ 28/Apr/16 ]

Hi,
I can't reproduce this bug.
Could you give me more information about how to set up the non-English locale environment.
Thanks!





[JAVASERVERFACES-4093] The required="true" attribute is ignored when used with passthrough:required="required". Created: 14/Jan/16  Updated: 04/Mar/16

Status: In Progress
Project: javaserverfaces
Component/s: validation
Affects Version/s: 2.2.12
Fix Version/s: None

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

JBoss EAP 7


Attachments: File index.xhtml    

 Description   

The required="true" attribute is ignored when used with passthrough:required="required". This problem does not occur when using f:validateRequired instead of required="true".

To reproduce the issue (see attached index.xhtml):
Press one of the "Without passthrough" buttons: The validation message will be displayed as expected.
Click on "Remove required-attribute" (to be able to submit the form) and then on the "With passthrough" button for required="true": The validation message won't be displayed which is wrong.



 Comments   
Comment by juneau001 [ 10/Feb/16 ]

This seems like a non-issue, depending upon which browser you are using. I believe that the HTML "required" attribute is working, as expected.

By applying the passthrough, JSF is not handling the required attribute as it is being handed off, so the message will not be updated in the same manner as it is with the use of the JSF component. If using the Chrome browser 48.0.2564.103 and FireFox 46.0 the HTML5 passthrough:required="true" attribute indicates that the field needs to be populated. However, if using Safari 9.0.1, it does not indicate anything...browsers have inconsistent reactions to the HTML5 "required" attribute.

Comment by Mi4uric3 [ 11/Feb/16 ]

Maybe I misunderstand your answer, but it is not about the HTML5-attribute, it's about the JSF-attribute which is not working correctly.

Comment by juneau001 [ 04/Mar/16 ]

The example that is attached to this issue works as expected with the Chrome browser mentioned in the previous comment. I believe the JSF attribute is working correctly, because the h:inputText that contains the 'passthrough:required="required"' attribute is not being processed via JSF since it is marked to passthrough. As mentioned, the HTML5 validation for that particular component works fine when used on a compatible browser. Fair enough?





[JAVASERVERFACES-4136] passthrough is not handled correctly Created: 14/May/16  Updated: 12/Jun/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.13, 2.2.8-14
Fix Version/s: None

Type: Bug Priority: Major
Reporter: zentrum Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:pt="http://java.sun.com/jsf/passthrough"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:body>
<h:form pt:role="form">
<ui:include src="test.xhtml"/>
<h:inputText id="second" pt:placeholder="Test"/>
</h:form>
</h:body>
</html>

and the file test.xhtml:

<ui:composition
xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:pt="http://xmlns.jcp.org/jsf/passthrough"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:inputText id="first" pt:placeholder="Test"/>
</ui:composition>

calling the first facelet, its rendered like:

<input id="j_idt4:first" type="text" name="j_idt4:first" placeholder="Test" />
<input id="j_idt4:second" type="text" name="j_idt4:second" />

To me, it looks like a bug?






[JAVASERVERFACES-4119] Tracking bug for 23039607 Created: 01/Apr/16  Updated: 01/Apr/16

Status: Open
Project: javaserverfaces
Component/s: lifecycle
Affects Version/s: None
Fix Version/s: None

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





[JAVASERVERFACES-4116] EL-Conditional operator ?: in composite component Created: 23/Mar/16  Updated: 28/Mar/16

Status: Open
Project: javaserverfaces
Component/s: composite components, lifecycle
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tony3031 Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If conditional operator ? : in composite component is used with a list in a c:foreach loop, its behavior is not correct.

Please see for more Details: http://stackoverflow.com/q/36156345/2023524






[JAVASERVERFACES-4112] Buffer size doesn't support -1 Created: 16/Mar/16  Updated: 28/Mar/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.8-01
Fix Version/s: None

Type: Bug Priority: Major
Reporter: VsevolodGolovanov Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Wildfly 8.2.0



 Description   

JSF spec says:

javax.faces.FACELETS_BUFFER_SIZE – The buffer size to set on the response when the ResponseWriter is generated. By default the value is 1024. A value of -1 will not assign a buffer size on the response.

Setting the option value to -1 results in exceptions when rendering:

16:01:00,355 ERROR [application] (default task-11) Error Rendering View[/views/SomeView.xhtml]: java.lang.NegativeArraySizeException
	at com.sun.faces.application.view.WriteBehindStateWriter.<init>(WriteBehindStateWriter.java:92)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:421)
	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)

Looking further:

protected ResponseWriter createResponseWriter(FacesContext context)
throws IOException {

	...

	if (responseBufferSizeSet) {
		// set the buffer for content
		extContext.setResponseBufferSize(responseBufferSize);
	}

This doesn't take -1 into account too, servlets wouldn't understand it.
Plus it seemingly wouldn't apply the default Mojarra's buffer size, when it's not set explicitly, which appears to be another problem.

com.sun.faces.resourceBufferSize could use a fix in the same vein.

-1 is useful because it means using servlets'/server's default. With Wildfly 8.2.0 and Undertow 1.1.8 the default would be to use a direct memory buffer pool. Mojarra doesn't support -1, resulting in a new direct memory buffer allocation for each response, which is a performance problem.



 Comments   
Comment by VsevolodGolovanov [ 16/Mar/16 ]

could use a fix in the same vein

Could have put it another way :\

Comment by VsevolodGolovanov [ 21/Mar/16 ]

I feel like the description is a bit unclear. I'll summarize.

  1. FaceletViewHandlingStrategy shouldn't set extContext's response buffer size when FACELETS_BUFFER_SIZE == -1, because JSF spec says so.
  2. FaceletViewHandlingStrategy should set extContext's response buffer size when FACELETS_BUFFER_SIZE is not set, because JSF spec promises a default buffer of 1024.
  3. ResourceHandlerImpl shouldn't set extContext's response buffer size when com.sun.faces.resourceBufferSize == -1 for consistency with FACELETS_BUFFER_SIZE and an option to configure buffering externally to JSF.




[JAVASERVERFACES-4102] [PORT 2.3]JAVASERVERFACES-3531 didn't correct all uses of getExternalContext().isSecure() Created: 04/Feb/16  Updated: 04/Feb/16

Status: Open
Project: javaserverfaces
Component/s: flash
Affects Version/s: 2.1.29
Fix Version/s: 2.1.29

Type: Bug Priority: Major
Reporter: ivassile Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones JAVASERVERFACES-4074 JAVASERVERFACES-3531 didn't correct ... Closed

 Description   

It seems that the fix applied in JAVASERVERFACES-3531 didn't correct all uses of getExternalContext().isSecure(). In particular, it's still called from elsewhere in ELFlash#setCookie [1].

Please fix the bug, because a Red Hat customer needs this issue to be resolved.

[1] https://github.com/jboss/mojarra/blob/8111d0950fa9a1bb2e48934bae76a466f474b552/jsf-ri/src/main/java/com/sun/faces/context/flash/ELFlash.java#L1002






[JAVASERVERFACES-4101] [PORT 2.2]JAVASERVERFACES-3531 didn't correct all uses of getExternalContext().isSecure() Created: 04/Feb/16  Updated: 04/Feb/16

Status: Open
Project: javaserverfaces
Component/s: flash
Affects Version/s: 2.1.29
Fix Version/s: 2.1.29

Type: Bug Priority: Major
Reporter: ivassile Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones JAVASERVERFACES-4074 JAVASERVERFACES-3531 didn't correct ... Closed

 Description   

It seems that the fix applied in JAVASERVERFACES-3531 didn't correct all uses of getExternalContext().isSecure(). In particular, it's still called from elsewhere in ELFlash#setCookie [1].

Please fix the bug, because a Red Hat customer needs this issue to be resolved.

[1] https://github.com/jboss/mojarra/blob/8111d0950fa9a1bb2e48934bae76a466f474b552/jsf-ri/src/main/java/com/sun/faces/context/flash/ELFlash.java#L1002






[JAVASERVERFACES-4100] [PORT 2.2.8]JAVASERVERFACES-3531 didn't correct all uses of getExternalContext().isSecure() Created: 04/Feb/16  Updated: 04/Feb/16

Status: Open
Project: javaserverfaces
Component/s: flash
Affects Version/s: 2.1.29
Fix Version/s: 2.1.29

Type: Bug Priority: Major
Reporter: ivassile Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones JAVASERVERFACES-4074 JAVASERVERFACES-3531 didn't correct ... Closed

 Description   

It seems that the fix applied in JAVASERVERFACES-3531 didn't correct all uses of getExternalContext().isSecure(). In particular, it's still called from elsewhere in ELFlash#setCookie [1].

Please fix the bug, because a Red Hat customer needs this issue to be resolved.

[1] https://github.com/jboss/mojarra/blob/8111d0950fa9a1bb2e48934bae76a466f474b552/jsf-ri/src/main/java/com/sun/faces/context/flash/ELFlash.java#L1002






[JAVASERVERFACES-4099] [PORT 2.2]The parameter is not passed to h:commandButton defined as composite component Created: 03/Feb/16  Updated: 03/Feb/16

Status: Open
Project: javaserverfaces
Component/s: composite components
Affects Version/s: 2.1.28, 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: EiichiN Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones JAVASERVERFACES-4073 The parameter is not passed to h:comm... Resolved

 Description   

The parameter is not passed to h:commandButton defined as composite component.
Please take a look at the example.

1. Deploy the testapp.war
2. Access to http://localhost:8080/testapp/test.xhtml
3. Push the "Hello World" button.
4. You can confirm following output on stdout.

# called initialize()
# called button2() value=
# called initialize()

But, TomEE/MyFaces is able to output "Hello World" as follows.

# called initialize()
# called button2() value=Hello World
# called initialize()





[JAVASERVERFACES-4098] [PORT 2.2.8]The parameter is not passed to h:commandButton defined as composite component Created: 03/Feb/16  Updated: 03/Feb/16

Status: Open
Project: javaserverfaces
Component/s: composite components
Affects Version/s: 2.1.28, 2.2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: EiichiN Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File javaserverfaces-4073.war     File testapp.war    
Issue Links:
Cloners
clones JAVASERVERFACES-4073 The parameter is not passed to h:comm... Resolved

 Description   

The parameter is not passed to h:commandButton defined as composite component.
Please take a look at the example.

1. Deploy the testapp.war
2. Access to http://localhost:8080/testapp/test.xhtml
3. Push the "Hello World" button.
4. You can confirm following output on stdout.

# called initialize()
# called button2() value=
# called initialize()

But, TomEE/MyFaces is able to output "Hello World" as follows.

# called initialize()
# called button2() value=Hello World
# called initialize()





[JAVASERVERFACES-4094] ui:repeat varStatus last properties error when there is an offset Created: 15/Jan/16  Updated: 21/Jan/16

Status: Open
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.2.12
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: eproffit Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 5 minutes
Time Spent: Not Specified
Original Estimate: 5 minutes
Environment:

windows, linux,...



 Description   

In UIRepeat.process(), when iterating on a list on n elements with an offset of n-1, the IterationStatus is not initialize correctly.
The last property is set to false, but it should be set to true as it is the first and last element.

The initialization should be :
this.updateIterationStatus(faces, new IterationStatus(true, (i + s >= e), i, begin, end, step));



 Comments   
Comment by ren.zhijun.oracle [ 21/Jan/16 ]

Can you provide a reproducer?





[JAVASERVERFACES-4091] Media attribute not declared for outputStyleSheet tag Created: 10/Jan/16  Updated: 13/Jan/16

Status: Open
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.2.7
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: steban90 Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 1.8, NetBeans 8.0.2



 Description   

The media attribute is not declared in the tag

<h:outputStylesheet  />


 Comments   
Comment by ren.zhijun.oracle [ 13/Jan/16 ]

Hi, can you make it more clear? in doc: http://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/vdldocs/facelets/ , the media attribute can be declared.

Comment by steban90 [ 13/Jan/16 ]

Hello, well, the metia attribute can be declared but it generates an error in the IDEs because the attribute is not declared in the taglib file html_basic.taglib.xml, here: https://github.com/javaserverfaces/mojarra/blob/master/jsf-ri/conf/share/html_basic.taglib.xml#L6575

So an error is displayed in the IDE's, but the attribute does work, and no errors are generated at runtime. Its a taglib.xml problem.

Comment by ren.zhijun.oracle [ 13/Jan/16 ]

Well, I will investigation further, thanks

Comment by steban90 [ 13/Jan/16 ]

You're welcome.





[JAVASERVERFACES-4082] Handling of localized resources not working as intended Created: 27/Nov/15  Updated: 24/Dec/15

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tstieler Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Since a few month I tried the newest versions of mojarra for a feature, that is basic IMHO, but doesn't work as intended: The delivery of localized resources (like images).

I use german and english as the localePrefixes for the locales de and en, and accordingly I have two images in JSF resource folder:

resources/german/img/locale.png
resources/english/img/locale.png

I include the following tags in my facelet page:

<h:graphicImage library="img" name="locale.png"/>

The corresponding HTML img src attributes are:

http://localhost:<port>/jsf/javax.faces.resource/locale.png?ln=img&loc=german
and
http://localhost:<port>/jsf/javax.faces.resource/locale.png?ln=img&loc=english

But the response is not (always) like expected. If you call these two URL directly in the browser, the result is either the german or the english version of the image, but the "loc"-parameter isn't used to determine the image file!

I stepped into the code, and I see the problem in RequestHandlerImpl#handleResourceRequest(FacesContext).

In this method, the loc-Parameter from the request is ignored, instead the method

ResourceHandler#createResource(String resourceName, String libraryName)

ist called, which (in the end) calls

ResourceManager#findResource(String libraryName,
                                     String resourceName,
                                     String contentType,
                                     boolean isViewResource,
                                     FacesContext ctx)

In this method, the current FacesContext is used to get the localePrefix, and it isn't guaranteed that this matches the loc parameter from the request!






[JAVASERVERFACES-4078] Performance issue with ELUtils#isCompositeComponentMethodExprLookup Created: 12/Nov/15  Updated: 24/Dec/15

Status: Open
Project: javaserverfaces
Component/s: facelets, performance
Affects Version/s: 2.1.6
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Daniel Lichtenberger Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2



 Description   

On a complex page I hit a performance issue apparently caused by the regular expression-based methods in ELUtils that are used for classifying tag attributes:

isCompositeComponentLookupWithArgs
isCompositeComponentMethodExprLookup
isCompositeComponentExpr

These methods get called many hundreds of times on my page, and I suspect that the performance drop can be attributed mostly to a few way too long EL expressions.

With the attached naive caching of expressions I can cut the server-side rendering time of this page in half.

Since these methods are only called from TagAttributeImpl, I think that a cleaner solution would be to cache the results of these methods in three boolean fields in the TagAttributeImpl class itself - as is already being done for the result of ELUtils.isLiteral().

However this would require a small refactoring of the private (public?) method getValueExpression(FaceletContext ctx, String expr, Class type), since it can be called with any expression (not just the expression of the TagAttributeImpl). Thoughts?



 Comments   
Comment by Daniel Lichtenberger [ 12/Nov/15 ]

Apparently I cannot add attachments, so here's the patch (against 2.1.6, but the source in the current Git master seems to be unchanged):

--- jsf-ri/src/main/java/com/sun/faces/el/ELUtils.java	(revision 13974)
+++ jsf-ri/src/main/java/com/sun/faces/el/ELUtils.java	(revision )
@@ -66,6 +66,8 @@
 import java.util.Collections;
 import java.util.List;
 import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.ConcurrentMap;
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
 
@@ -106,6 +108,10 @@
     private static final Pattern METHOD_EXPRESSION_LOOKUP =
           Pattern.compile(".[{]cc[.]attrs[.]\\w+[}]");
 
+    private static final ConcurrentMap<String, Boolean> CACHE_COMPOSITE_WITH_ARGS = new ConcurrentHashMap<String, Boolean>();
+    private static final ConcurrentMap<String, Boolean> CACHE_COMPOSITE_EXPR = new ConcurrentHashMap<String, Boolean>();
+    private static final ConcurrentMap<String, Boolean> CACHE_METHOD_EXPR = new ConcurrentHashMap<String, Boolean>();
+
     private static final String APPLICATION_SCOPE = "applicationScope";
     private static final String SESSION_SCOPE = "sessionScope";
     private static final String REQUEST_SCOPE = "requestScope";
@@ -188,30 +194,31 @@
 
 
     public static boolean isCompositeComponentExpr(String expression) {
+        return cachedMatcher(CACHE_COMPOSITE_EXPR, COMPOSITE_COMPONENT_EXPRESSION, expression);
 
-        // TODO we should be trying to re-use the Matcher by calling
-        // m.reset(expression);
-        Matcher m = COMPOSITE_COMPONENT_EXPRESSION.matcher(expression);
-        return m.find();
-
     }
 
 
     public static boolean isCompositeComponentMethodExprLookup(String expression) {
+        return cachedMatcher(CACHE_METHOD_EXPR, METHOD_EXPRESSION_LOOKUP, expression);
 
-        Matcher m = METHOD_EXPRESSION_LOOKUP.matcher(expression);
-        return m.matches();
-
     }
 
 
     public static boolean isCompositeComponentLookupWithArgs(String expression) {
+        return cachedMatcher(CACHE_COMPOSITE_WITH_ARGS, COMPOSITE_COMPONENT_LOOKUP_WITH_ARGS, expression);
-
+        
-        // TODO we should be trying to re-use the Matcher by calling
-        // m.reset(expression);
-        Matcher m = COMPOSITE_COMPONENT_LOOKUP_WITH_ARGS.matcher(expression);
-        return m.find();
+    }
-        
+
+    private static boolean cachedMatcher(ConcurrentMap<String, Boolean> cache, Pattern regexp, String expression) {
+        Boolean result = cache.get(expression);
+        if (result != null) {
+            return result;
+        }
+        Matcher m = regexp.matcher(expression);
+        result = m.find();
+        cache.put(expression, result);
+        return result;
     }




[JAVASERVERFACES-4048] Make system events utilize the new constructors Created: 03/Sep/15  Updated: 18/Mar/16

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

Type: Improvement Priority: Major
Reporter: Manfred Riem Assignee: ren.zhijun.oracle
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by ren.zhijun.oracle [ 06/Sep/15 ]

Hi Manfred, What's the background of this issue? can you clarify the requirement of this issue?

Comment by Manfred Riem [ 08/Sep/15 ]

Zhijun, open up any of the SystemEvents and you will see an additional constructor was added that takes the FacesContext.

The current runtime does not take advantage of that constructor but it should.

Please change the runtime to use it in every case possible.

Thanks!

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

Manfred, are you mean the class javax.faces.event.SystemEvent and all its subclasses? But I can't find constructor which take FacesContext as you said, can you help to clarify and better give an example?

Comment by Manfred Riem [ 09/Sep/15 ]

Update your sources and you will see it





[JAVASERVERFACES-3883] faces flow "containing directory" convention correctness Created: 11/May/15  Updated: 06/Sep/15

Status: Open
Project: javaserverfaces
Component/s: flow
Affects Version/s: 2.2.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: ren.zhijun.oracle
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-1371 11.4.3.3 (Packaging Flows in Director... Open

 Description   

Implement JAVASERVERFACES_SPEC_PUBLIC-1371.



 Comments   
Comment by ren.zhijun.oracle [ 06/Sep/15 ]

Hi Ed, can you help to clarify this issue more detailed?





[JAVASERVERFACES-4135] [PORT 2.2.8]Inconsistency in URL encoding with respect to CSRF Created: 12/May/16  Updated: 12/May/16

Status: Open
Project: javaserverfaces
Component/s: lifecycle
Affects Version/s: 2.2.8-15
Fix Version/s: None

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

Issue Links:
Cloners
clones JAVASERVERFACES-4134 Inconsistency in URL encoding with re... Closed

 Description   

Excellent writeup from @aschwart.

The incompatibility has to do with how Mojarra deals with encoding of 
the cryptographically strong token.

Roughly, here is how things are going wrong:

- Mojarras implementation of 
ResponseStateManager.getCryptographicallyStrongTokenFromSession calls 
URLEncoder.encode() on the token before returning it.
- Mojarras implementation of ViewHandler.getActionURL() appends the 
token as a query parameter with the name javax.faces.Token without 
performing any further URL encoding of the (already encoded) token value.
- This results in a properly url-encoded action url.  So, for example, 
if the non-encoded value for the token is foo?bar, 
getCryptographicallyStrongTokenFromSession() returns the url encoded 
value of foo%3Fbar and getActionURL returns an url with the properly 
encoded query string ?javax.faces.Token=foo%3Fbar.
- So far, so good.
- When the GET request arrives, the query parameters are decoded and 
stashed away in the request parameter map.
- During restore view processing, Mojarra checks to see whether the 
incoming token matches the value returned by 
getCryptographicallyStrongTokenFromSession().
- Since the incoming token has been decoded by the servlet engine, the 
token value retrieved from the request map is foo?bar.  This does not 
match the token returned by 
getCryptographicallyStrongTokenFromSession(), which returns the 
url-encoded value foo%3Fbar.

So, even though the GET request correctly includes the url-encoded value 
of the token, the request fails to pass the CSRF test due to the 
encoding  mismatch.  As a result, the request is (unexpectedly) not able 
to access the protected view.

Now, clearly, CSRF protection is working more generally, so we also took 
a closer look at why this is working for other cases, but not for our 
case.  In particular, we looked at this trivial use case:

             <h:button value="JSF button" outcome="/csrf_protected_page"/>

Which works just fine.

The key difference between the working <h:button> case and the failing 
ADF Faces case is that the h:button case calls 
ViewHandler.getBookmarkableURL(), whereas the ADF Faces case calls 
ViewHandler.getActionURL() directly.

For the <h:button> case, we have the following sequence:

- Mojarras implementation of getBookmarkableURL() calls 
ViewHandler.getActionURL() to get the base url.  Assuming the 
non-encoded token value is again foo?bar, getActionURL returns an url 
with the query string ?javax.faces.Token=foo%3Fbar.
- getBookmarkableURL then passes this base url through 
ExternalContext.encodeBookmarkableURL().
- Although the base url that is passed into encodeBookmarkableURL() is 
already properly url-encoded, Mojarras implementation of 
encodeBookmarkableURL() pulls apart the query string and encodes the 
query parameter values a second time.
- As a result, the query string is further transformed from the 
url-encoded value of ?javax.faces.Token=foo%3Fbar to doubly 
url-encoded value of ?javax.faces.Token=foo%253Fbar.  (This seems wrong.)
- When the corresponding GET request arrives on the server, the token 
value is decoded back to foo%3Fbar by the servlet engine and this 
value is stored in the request parameter map.
- When Mojarra compares this incoming value to the secret value on the 
server, both are now singly url-encoded, and thus the test passes.

While it is handy that this works, the approach seems flawed.

The crux of the issue is whether Mojarras implementation of 
encodeBookmarkableURL() should be (re-)encoding query parameters that 
are provided via the base url.  My inclination is that it is a mistake 
for encodeBookmarkableURL() to (re-)encode these query parameters.
The reason that I feel that this is a mistake is because the typical 
input to encodeBookmarkableURL() is the url produced by getActionURL().  
If the action url includes any query parameters, getActionURL() must 
take care of encoding on behalf of the caller.

So we know that getActionURL() must return a properly url-encoded url.  
We also know that this url is going to be passed into 
encodeBookmarkableURL().  Thus it seems strange that 
encodeBookmarkableURL() would assume that query parameter values that 
have been appended to the base url by the caller would not have already 
been properly url-encoded by the caller.  In the very common case where 
the base url is the action url, we know that this encoding has already 
been performed.

If it were up to me, the way that this would all work is:

- getCryptographicallyStrongTokenFromSession would return a plain old 
token (no URL encoding).
- getActionURL() would url encode the token value before appending it to 
the query string.
- encodeBookmarkableURL() would avoid re-encoding query parameters that 
are already present on the base url.

With this approach, the token is url encoded once, is decoded by the 
servlet engine before being put in the request map and matches the 
(non-encoded) token that is stored int the session.

Thoughts?





[JAVASERVERFACES-4140] Issue with escaping for selectOneMenu when using selectItems and selectItem Created: 23/May/16  Updated: 27/Jun/16

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

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

Attachments: Text File escapeIssue_bean.txt     HTML File escapeIssue_xmlCodeSnipped.txt.html    

 Description   

NOTE: Java.net is having some issues with new members (to be resolved June 16) I am reporting on behalf of Radoslaw - he can be contacted at radoslaw dot dittman at gmail - Sonya

Hello,
I've found out that there is some issue with escaping for selectOneMenu when using selectItems and selectItem. It seems that escaping is not working for that container while it works fine i.e. for selectOneRadio.
By default there is no escape which I think should be as a standard option set to true.
For instance 2nd (f:selectItem) case from h:selectOneRadio uses already escaped characters with different flags showing correct result. The same example presented for h:selectOneMenu as a 2nd case doesn't escaped & and presents it in initial form.
3rd example in h:selectOneMenu when using (f:selectItems) has been broken on 4th record due to lack of escaping. Same sample (4th) for h:selectOneRadio works fine.
I wasn't also able to turn on/off escaping either for h:selectOneRadio (while using f:selectItems - 3,4,5 have the same result) or h:selectOneMenu (while using f:selectItems - 2 has the same result for each setting default/true/false, which shows the initial state of character).

JSF used: 2.1.29-01

Best regards,
Radoslaw






[JAVASERVERFACES-4139] Issue with escaping for selectOneMenu Created: 23/May/16  Updated: 06/Jul/16

Status: In Progress
Project: javaserverfaces
Component/s: composite components
Affects Version/s: 2.1.29-01
Fix Version/s: None

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

JSF 2.1.29-01



 Description   

I've found out that there is some issue with escaping for selectOneMenu when using selectItems and selectItem. It seems that escaping is not working for that container while it works fine i.e. for selectOneRadio.
By default there is no escape which I think should be as a standard option set to true.
For instance 2nd (f:selectItem) case from h:selectOneRadio uses already escaped characters with different flags showing correct result. The same example presented for h:selectOneMenu as a 2nd case doesn't escaped & and presents it in initial form.
3rd example in h:selectOneMenu when using (f:selectItems) has been broken on 4th record due to lack of escaping. Same sample (4th) for h:selectOneRadio works fine.
I wasn't also able to turn on/off escaping either for h:selectOneRadio (while using f:selectItems - 3,4,5 have the same result) or h:selectOneMenu (while using f:selectItems - 2 has the same result for each setting default/true/false, which shows the initial state of character).

JSF used: 2.1.29-01
Attached files:

  • escapeIssue_selectOneMenu.PNG (screen-shot from example)
  • escapeIssue_bean.txt (backing bean for example)
  • escapeIssue_xmlCodeSnipped.txt (page code for example)


 Comments   
Comment by ZhangXinyuan [ 01/Jul/16 ]

hi sebastian,

when view page source on Chrome, I found itemEscaped works.

For examole, the following codes
<h:selectOneMenu value="#

{userData.data}

" style="line-break: normal" >
<f:selectItem itemLabel="&lt ;b&gt ;5&lt ;/b&gt ;" itemValue="itemEscaped=true" itemEscaped="true" />
<f:selectItem itemLabel="&lt ;b&gt ;6&lt ;/b&gt ;" itemValue="itemEscaped=false" itemEscaped="false"/>
</h:selectOneMenu>

corresponding to following page source

<select name="j_idt6:j_idt8" size="1" style="line-break: normal">
<option value="itemEscaped=true">&lt ;b&gt ;5&lt ;/b&gt ;</option>
<option value="itemEscaped=false"><b>6</b></option>
</select>

when itemEscaped="false", itemLabel="&lt ;b&gt ;6&lt ;/b&gt ;" escaped successfully.
But <b>6</b> didn't render. This is probably the result of tag <option> doesn't support it.

Feel free to let me know any question in time.

Comment by _sebastian_ [ 01/Jul/16 ]

Hi Zhang Xinyuan,
I've checked that and it is not working in my opinion. Please find attached code for tests. My findings:
For given string "&lt ; b&gt ; 5&lt ; /b&gt ;" result should be as follows:

  • "&lt ; b&gt ; 5&lt ; /b&gt ;" -> when default behavior for escaping (escaped twice)
  • "&lt ; b&gt ; 5&lt ; /b&gt ;" -> when TRUE set for escaping (escaped twice)
  • "< b> 5< /b>" -> when FALSE set for escaping (escaped once)

When working with h:selectOneRadio:

  • f:selectItem with itemEscaped - works fine based on it's value -> OK
  • f:selectItems with itemLabelEscaped/itemEscaped (actually 1st one should be set) - doesn't work as expected (it is ALWAYS escaped) -> NOK
    When working with h:selectOneMenu:
  • f:selectItem with itemEscaped - works incorrectly while it is NEVER escaped -> NOK
  • f:selectItems with itemLabelEscaped/itemEscaped (actually 1st one should be set) - doesn't work as expected (it is NEVER escaped) -> NOK

PAGE CODE:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">

<h:head>
<title>JSF 2.1.29-01 encode test</title>
</h:head>
<h:body bgcolor="white">
<h1>JSF 2.1.29-01 encode test</h1>
<h:form>
<!-- h:selectOneRadio -->
<h2>### h:selectOneRadio for ZhangXinyuan ###</h2>
<h4>1. INITIAL: #

{encodeTest.zhangXinyuanSample} - f:selectItem itemEscaped="default/true/false" – OK</h4>
<h:selectOneRadio value="#{encodeTest.result}" style="line-break: normal">
<f:selectItem itemLabel="#{encodeTest.zhangXinyuanSample}

" itemValue="itemEscaped=default" />
<f:selectItem itemLabel="#

{encodeTest.zhangXinyuanSample}" itemValue="itemEscaped=true" itemEscaped="true" />
<f:selectItem itemLabel="#{encodeTest.zhangXinyuanSample}

" itemValue="itemEscaped=false" itemEscaped="false" />
</h:selectOneRadio>
<h4>2. f:selectItems itemLabelEscaped="default – NOK!!!"</h4>
<h:selectOneRadio value="#

{encodeTest.result}" style="line-break: normal">
<f:selectItems value="#{encodeTest.selectItemsForZX}" />
</h:selectOneRadio>
<h4>3. f:selectItems itemLabelEscaped="true – NOK!!!"</h4>
<h:selectOneRadio value="#{encodeTest.result}

" style="line-break: normal">
<f:selectItems itemLabelEscaped="true" value="#

{encodeTest.selectItemsForZX}" />
</h:selectOneRadio>
<h4>4. f:selectItems itemLabelEscaped="false – NOK!!!"</h4>
<h:selectOneRadio value="#{encodeTest.result}" style="line-break: normal">
<f:selectItems itemLabelEscaped="false" value="#{encodeTest.selectItemsForZX}

" />
</h:selectOneRadio>
<h4>5. f:selectItems itemEscaped="false – NOK!!!"</h4>
<h:selectOneRadio value="#

{encodeTest.result}" style="line-break: normal">
<f:selectItems itemEscaped="false" value="#{encodeTest.selectItemsForZX}" />
</h:selectOneRadio>
<!-- h:selectOneMenu -->
<h2>### h:selectOneMenu for ZhangXinyuan ###</h2>
<h4>1. INITIAL: #{encodeTest.zhangXinyuanSample} - f:selectItem itemEscaped="default/true/false – NOK!!!"</h4>
<h:selectOneMenu value="#{encodeTest.result}

" style="line-break: normal">
<f:selectItem itemLabel="#

{encodeTest.zhangXinyuanSample}" itemValue="itemEscaped=default" />
<f:selectItem itemLabel="#{encodeTest.zhangXinyuanSample}

" itemValue="itemEscaped=true" itemEscaped="true" />
<f:selectItem itemLabel="#

{encodeTest.zhangXinyuanSample}

" itemValue="itemEscaped=false" itemEscaped="false" />
</h:selectOneMenu>
<h4>2. f:selectItems itemLabelEscaped="default" – NOK!!!</h4>
<h:selectOneMenu value="#

{encodeTest.result}" style="line-break: normal">
<f:selectItems value="#{encodeTest.selectItemsForZX}" /> <!-- 2nd item would fail while it has incorrect content for HTML / page would be broken here-->
</h:selectOneMenu>
<h4>3. f:selectItems itemLabelEscaped="true" – NOK!!!</h4>
<h:selectOneMenu value="#{encodeTest.result}

" style="line-break: normal">
<f:selectItems itemLabelEscaped="true" value="#

{encodeTest.selectItemsForZX}" /> <!-- 2nd item would fail while it has incorrect content for HTML -->
</h:selectOneMenu>
<h4>4. f:selectItems itemLabelEscaped="false" – NOK!!!</h4>
<h:selectOneMenu value="#{encodeTest.result}" style="line-break: normal">
<f:selectItems itemLabelEscaped="false" value="#{encodeTest.selectItemsForZX}

" /> <!-- 2nd item would fail while it has incorrect content for HTML -->
</h:selectOneMenu>
<h4>5. f:selectItems itemEscaped="true" – NOK!!!</h4>
<h:selectOneMenu value="#

{encodeTest.result}

" style="line-break: normal">
<f:selectItems itemEscaped="true" value="#

{encodeTest.selectItemsForZX}

" /> <!-- 2nd item would fail while it has incorrect content for HTML -->
</h:selectOneMenu>
</h:form>
</h:body>
</html>

BACKING BEAN CODE:
package com.encode.jsf.issue;

import java.util.ArrayList;
import java.util.List;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
import javax.faces.model.SelectItem;

import org.apache.commons.lang.StringEscapeUtils;

@ManagedBean(name = "encodeTest")
@ViewScoped
public class EncodeTest {
public String zhangXinyuanSample = "&lt$; b&gt$; 5&lt$; /b&gt$;"; // -> please remove '$' and leave ''
public String result;

public List<SelectItem> selectItemsForZX = new ArrayList<SelectItem>();

public EncodeTest()

{ SelectItem siZX0 = new SelectItem(0, zhangXinyuanSample + " - was escaped before"); SelectItem siZX1 = new SelectItem(1, StringEscapeUtils.unescapeHtml(zhangXinyuanSample) + " - wasn't escaped before"); selectItemsForZX.add(siZX0); selectItemsForZX.add(siZX1); }

public String getResult()

{ return result; }

public void setResult(String result)

{ this.result = result; }

public String getZhangXinyuanSample()

{ return zhangXinyuanSample; }

public List<SelectItem> getSelectItemsForZX()

{ return selectItemsForZX; }

}

Comment by ZhangXinyuan [ 05/Jul/16 ]

hi sebastian,

If the item of selecitems tag is a SelectItem Object, you need to set its attribute by construction or set method. And if the item is any other Java Object, you can set its attribute by attributes of selectitems.

in you case, you can set the escape attribute like below

public EncodeTest()

{ SelectItem siZX0 = new SelectItem(0, zhangXinyuanSample,null,false,false); SelectItem siZX1 = new SelectItem(1, StringEscapeUtils.unescapeHtml(zhangXinyuanSample),null,false,false); selectItemsForZX.add(siZX0); selectItemsForZX.add(siZX1); }

Feel free to let me know any question in time.

Comment by _sebastian_ [ 05/Jul/16 ]

Hi Zhang Xinyuan,
I do not think so that this is an issue with incorrect constructor used.

In my case constructor with 2 arguments is used:

  • SelectItem(Object value, String label)

While this is a telescoping constructor it should and it will call more complex one which initialize fields:

  • SelectItem(Object value, String label, String description, boolean disabled, boolean escape, boolean noSelectionOption)

By default in this case 'escape' attribute is set to 'true' which is desired behavior by me. Unfortunately it is not reflected in the results. Please note that while using the same List<SelectItem> under different containers it behaves inconsistently which in my opinion is a bug. There are two cases for two containers which should work similar:

  • f:selectItem (with its attribute 'itemEscaped') when used in:
  • h:selectOneRadio
    • when 'itemEscaped' in 'f:selectItem' not given (DEFAULT) it would escape characters - OK
    • when 'itemEscaped' in 'f:selectItem' set to (TRUE) it would escape characters - OK
    • when 'itemEscaped' in 'f:selectItem' set to (FALSE) it would NOT escape characters - OK
  • h:selectOneMenu (should work as for 'h:selectOneRadio' but it doesn't)
    • when 'itemEscaped' in 'f:selectItem' not given (DEFAULT) it would NOT escape characters - NOK
    • when 'itemEscaped' in 'f:selectItem' set to (TRUE) it would NOT escape characters - NOK
    • when 'itemEscaped' in 'f:selectItem' set to (FALSE) it would NOT escape characters - NOK
      Based on above mentioned it seems that when using 'f:selectItem' under 'h:selectOneMenu' it doesn't work as expected.
  • f:selectItems (with its attribute 'itemLabelEscaped') when used in:
  • h:selectOneRadio (insensitive for 'itemLabelEscaped' value; behaves based on 'escape' attribute of SelectItem JavaObject)
    • when 'itemLabelEscaped' in 'f:selectItems' not given (DEFAULT) it would escape characters - ?
    • when 'itemLabelEscaped' in 'f:selectItems' set to (TRUE) it would escape characters - ?
    • when 'itemLabelEscaped' in 'f:selectItems' set to (FALSE) it would NOT escape characters - ?
  • h:selectOneMenu (should work at least as for 'h:selectOneRadio' but it doesn't)
    • when 'itemLabelEscaped' in 'f:selectItems' not given (DEFAULT) it would NOT escape characters - NOK
    • when 'itemLabelEscaped' in 'f:selectItems' set to (TRUE) it would NOT escape characters - NOK
    • when 'itemLabelEscaped' in 'f:selectItems' set to (FALSE) it would NOT escape characters - NOK
      Based on above mentioned it seems that when using 'f:selectItems' under 'h:selectOneMenu' it doesn't work as expected. In my opinion it should behave at least like in case of 'h:selectOneRadio'. Additionally please explain me what is the purpose and how properly 'itemLabelEscaped' should be used while it seems that it is insensitive for value change.

To simplify test case you can set:
public String zhangXinyuanSample = "&"; -> while escaped we should get '&'; while NOT escaped there should be rendering error
or
public String zhangXinyuanSample = "&amp$;"; -> while escaped we should get '&amp ;' - means double escaped; while NOT we should get '&' while it was already escaped. ($ should be removed)

Please note also that in jsf_core.tld 'itemLabelEscaped' attribute is defined twice with the same name. Snippet below:

<attribute>
<description>

<![CDATA[ <p class="changed_added_2_0">evaluates to a boolean that will
determine if the rendered markup for the item receives normal JSF HTML escaping or not.</p> ]]>

</description>
<name>itemLabelEscaped</name>
<deferred-value>
<type>java.lang.Boolean</type>
</deferred-value>
</attribute>

<attribute>
<description>

<![CDATA[ <p class="changed_added_2_0">Is either an EL expression
pointing to the element in the value collection whose value should be
marked as a “no selection” item, or a literal string that
exactly matches the value of the item in the collection that must be
marked as the “no selection” item. If the user selects such
an item <strong>and</strong> the field is marked as required, then it
will not pass validation.</p> ]]>

</description>
<name>itemLabelEscaped</name>
<deferred-value>
<type>java.lang.Boolean</type>
</deferred-value>
</attribute>





[JAVASERVERFACES-4120] Ajax file upload fails when com.sun.faces.namespaceParameters is set to true Created: 05/Apr/16  Updated: 30/Jun/16

Status: Open
Project: javaserverfaces
Component/s: ajax
Affects Version/s: 2.2.13
Fix Version/s: None

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


 Description   

Steps to reproduce:

1. Clone the project:

git clone https://github.com/stiemannkj1/ajax-fileupload-reproducer.git

2. Build the project with maven:

cd ajax-fileupload-reproducer && mvn clean install

3. Deploy the project to tomcat:

cp target/ajax-fileupload-reproducer*.war $TOMCAT_HOME/webapps/

4. Verify that Ajax file upload works when com.sun.faces.namespaceParameters is not set:

i. Navigate to the webapp in the browser: http://localhost:8080/ajax-fileupload-reproducer-1.0-SNAPSHOT/faces/index.xhtml

ii. Click the Browse... button.

iii. Select the Readme.md file. The text of Readme.md should appear in the browser.

5. Uncomment the following line in the web.xml to set com.sun.faces.namespaceParameters to true:

<!--    <context-param>
            <param-name>com.sun.faces.namespaceParameters</param-name>
            <param-value>true</param-value>
        </context-param>-->

6. Rebuild the project:

mvn clean install

7. Redeploy the webapp:

rm -r $TOMCAT_HOME/webapps/ajax-fileupload-reproducer*; cp target/ajax-fileupload-reproducer*.war $TOMCAT_HOME/webapps/

8. Navigate to the webapp in the browser: http://localhost:8080/ajax-fileupload-reproducer-1.0-SNAPSHOT/faces/index.xhtml

9. Click the Browse... button.

10. Select the Readme.md file.

If the bug still exists, an Ajax POST will occur, but the file text will not appear in the browser.



 Comments   
Comment by stiemannkj1 [ 05/Apr/16 ]

Pull Request sent to @vsingleton on github: https://github.com/vsingleton/mojarra/pull/8





[JAVASERVERFACES-4117] Not all validators for input field are executed Created: 23/Mar/16  Updated: 06/May/16

Status: Open
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.2.12
Fix Version/s: None

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

Windows
Wildfly 9.0.2



 Description   

Example:
<h:inputText value="#

{bean.value}

" >
<f:validateRegex pattern=".

{3,10}

"></f:validateRegex>
<f:validateRegex pattern="^[A-Za-z]+$"></f:validateRegex>
</h:inputText>

In the example above only the first validator is executed, while the second one is skipped. The problem occurs when you apply the same validator tag more than once.
Debugging into the code I found the method 'applyAttachedObject' in the class 'ValidatorTagHandlerDelegateImpl', which might be the source of the problem.
It checks the validator classes applied to an object. In case a validator class appears more than once it will be skipped.

Please search for the following lines on the code:

Validator[] validators = evh.getValidators();
boolean found = false;

for (Validator validator : validators) {
if (validator.getClass().equals(v.getClass()))

{ found = true; break; }

}

As far as I could see this check was introduced with version 2.2.5.

I'm not sure if this is a bug or according to the jsf2.2 specification.



 Comments   
Comment by ZhangXinyuan [ 06/May/16 ]

JSF supports a mechanism for registering zero or more validators on each EditableValueHolder component in the component tree.
And Mojara design it to support the different validators for one EditableValueHolder component.
Because the validators likes f:validateLength , f:validateDoubleRange, ... , needn't to verify twice.





[JAVASERVERFACES-4113] Message order of FacesContext#getMessages is not added order Created: 17/Mar/16  Updated: 30/Jun/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.28, 2.2.12
Fix Version/s: None

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

WildFly 10.0.0.Final
GlassFish 4.1.1



 Description   

javadoc explains that:

The elements of the Iterator must be returned in the order in which they were added with calls to addMessage(java.lang.String, javax.faces.application.FacesMessage).

How ever, messages ordere by client Id, then added order. For example, when I added messages like 1 and display it via 23, the message order is 4.

Implemented parts in 2.1.29 are there:
https://github.com/javaserverfaces/mojarra/blob/2.1.28/jsf-ri/src/main/java/com/sun/faces/context/FacesContextImpl.java#L111-L116
https://github.com/javaserverfaces/mojarra/blob/2.1.28/jsf-ri/src/main/java/com/sun/faces/context/FacesContextImpl.java#L359-L360

[1]

String message = "A new user with id " + newUser.getId() + " has been created successfully";
facesContext.addMessage("reg:username", new FacesMessage("1"));
facesContext.addMessage("reg:firstName", new FacesMessage("2"));
facesContext.addMessage("reg:lastName", new FacesMessage(message));
facesContext.addMessage(null, new FacesMessage("3"));
facesContext.addMessage("reg:username", new FacesMessage("4"));
facesContext.addMessage("reg:firstName", new FacesMessage("5"));
facesContext.addMessage("reg:lastName", new FacesMessage("6"));
facesContext.addMessage(null, new FacesMessage("7"));
facesContext.addMessage("reg:username", new FacesMessage("8"));
facesContext.addMessage("reg:firstName", new FacesMessage("9"));
facesContext.addMessage("reg:lastName", new FacesMessage("10"));

[2]

public class JsfHelper {
  public List<FacesMessage> getMessages() {
    ArrayList<FacesMessage> ret = new ArrayList<FacesMessage>();
    Iterator<FacesMessage> it = FacesContext.getCurrentInstance().getMessages();
    while (it.hasNext()) {
      ret.add(it.next());
    }
    return ret;
  }
}

[3]

<ui:repeat var="item" value="#{jsfHelper.messages}">
 <p>
  <h:outputText value="#{item.detail}" />
 </p>
</ui:repeat>

[4]

    1
    4
    8
    2
    5
    9
    A new user with id 1 has been created successfully
    6
    10
    3
    7





[JAVASERVERFACES-4089] NPE while tearing down Mojarra runtime Created: 26/Dec/15  Updated: 05/Jul/16

Status: Open
Project: javaserverfaces
Component/s: integration
Affects Version/s: 2.2.9, 2.3.0-m04
Fix Version/s: None

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


 Description   

When stopping a web application where Faces is enabled, a NPE is thrown:
2015-12-26 21:40:37,333 ERROR [Gogo shell] jsf.config - Unexpected exception when attempting to tear down the Mojarra runtime
java.lang.NullPointerException
at com.sun.faces.context.ApplicationMap.get(ApplicationMap.java:97)
at com.sun.faces.application.ApplicationAssociate.getInstance(ApplicationAssociate.java:350)
at com.sun.faces.el.ELUtils.getDefaultExpressionFactory(ELUtils.java:912)
at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:348)
at osgi.extender.web.servlet.OurServletContext.lambda$6(OurServletContext.java:151)
at osgi.extender.web.servlet.OurServletContext.lambda$25(OurServletContext.java:714)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)



 Comments   
Comment by vanwijngaarden [ 26/Dec/15 ]

Analysis
The contextDestroyed method in com.sun.faces.config.ConfigureListener is called during destruction of a servlet context for which Mojarra was enabled. During this action, ELUtils.getDefaultExpressionFactory is called, a change made in 2.2.9. This method calls ApplicationAssociate.getInstance with the ExternalContext of the InitialFacesContext object. ApplicationAssociate.getInstance uses the ApplicationMap from the ExternalContext to retrieve the ApplicationAssociate object.

Unfortunately, as soon as one call is made to FacesServlet.service(), InitialFacesContext.release() is called, meaning that the servlet context and thus the ApplicationMap is unavailable from the InitialFacesContext object.

Solution
Don't know the exact reason for the change in 2.2.9, but at least a null check on the ApplicationMap should be performed in ApplicationAssociate.getInstance(ExternalContext) to prevent the NPE. But given the code, in normal situations, ELContext.getDefaultExpressionFactory will always return null at the location where the code was added and therefore has no use at all.

Comment by ren.zhijun.oracle [ 13/Jun/16 ]

Hi, can you provide the application war and the reproducing steps?

Comment by vanwijngaarden [ 13/Jun/16 ]

Preparation
I prepared a .zip file with the application. You can download it from:
http://www.avineas.org/uploads/Runtime.zip because somehow I don't have a means to upload a file here.

After you upack the zip you get an OSGi environment with Mojarra 2.3m04 as JSF environment. Run the "run.sh" script to start the application. You will get an equinox osgi> prompt as a result (after some startup logs). Bundle "JSF_1.0.0" is the WAB, which contains just one faces file index.xhtml showing a page with just "Hallo". This bundle has id 24.

Reproduction steps
(after the script is run, the WAB is started automatically).
Normal situation

  • Stop the WAB:
    osgi> stop 24
    
  • Start the WAB
    osgi> start 24
    

    As you see, the WAB is undeployed and deployed without problems.

Problematic situation
(WAB must be started)





[JAVASERVERFACES-4088] NullPointerException in StateHolderSaver contructor Created: 26/Dec/15  Updated: 21/Jun/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.12
Fix Version/s: None

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

Mojarra 2.2.12, Primefaces 5.3



 Description   

Seems like the contructor for StateHolderSaver is not null safe?
I got a NullPointerException in a table when the state should be saved.

  1. Location in code where the constructors i called - UIComponentBase, method saveAttachedState, row 1175
    ...
                        resultList.add(new StateHolderSaver(context, value));
    ...
    
  2. In my case the 'value' above is null so that StateHolderSaver constructor will then throw a NullPointerException since the code invokes toSave.getClass().getName(). Se below:
    ....
        public StateHolderSaver(FacesContext context, Object toSave) {
            this.className = toSave.getClass().getName();
    ....
         }
    
  • This must be a very common use case (that a 'value' is null to be persisted/restored). Is it my code that´s using the StateHolderSaver in a special way or is this a new bug in 2.1.12?


 Comments   
Comment by acerhigh2015 [ 26/Dec/15 ]

After further investigation I notice that this exception will be thrown for ANY component that will store a state i.e attachedObject that is a Map if that Map has any key that is mapped to a value that is null.

            } else if(newWillSucceed && attachedObject instanceof Map) {
                Map attachedMap1 = (Map)attachedObject;
                resultList = null;
                Iterator i$ = attachedMap1.entrySet().iterator();

                while(true) {
                    Object key;
                    do {
                        Entry entry;
                        do {
                            if(!i$.hasNext()) {
                                result = resultList;
                                return result;
                            }

                            entry = (Entry)i$.next();
                            key = entry.getKey();
                        } while(key instanceof StateHolder && ((StateHolder)key).isTransient());

                        value = entry.getValue();
                    } while(value instanceof StateHolder && ((StateHolder)value).isTransient());

                    if(resultList == null) {
                        resultList = new ArrayList(attachedMap1.size() * 2 + 1);
                        resultList.add(new StateHolderSaver(context, mapOrCollectionClass));
                    }

                    resultList.add(new StateHolderSaver(context, key));
                    resultList.add(new StateHolderSaver(context, value));             <<<--- this will throw NullPointerException
                }

Other types of attachedObject, Collections etc, seems to have sufficient null check and therefor will not showcase this bug.

Comment by acerhigh2015 [ 11/Jan/16 ]

Have someone looked into this, would be good to have some sort of notification of the status of the story/issue?

Comment by ren.zhijun.oracle [ 12/Jan/16 ]

Hi I am taking care of these JIRA issues including this one, will update you once done.

Comment by acerhigh2015 [ 12/Jan/16 ]

Ok, thanks for the update in the story. Just contact me if there are some questions or something I can help with.

Comment by acerhigh2015 [ 13/Feb/16 ]

Hi again,
can someone please fix this bug. This is obviously a bug that has to be fixed ASAP.

Comment by acerhigh2015 [ 06/May/16 ]

Hi, can you comment back the plan about when this issue can be fixed?
(It has been 4 month now, on this severe bug, and no feedback yet)

Comment by ren.zhijun.oracle [ 06/May/16 ]

Hi, Emma is working on this now, will get fixed soon, please stay tuned.

Comment by acerhigh2015 [ 08/May/16 ]

Ok, thanks for the quick reply, I wait for Emmas fix then.

Comment by ZhangXinyuan [ 12/May/16 ]

hi,
I want to reproduce this bug, could you offer me the test case?

Comment by ren.zhijun.oracle [ 20/May/16 ]

Hi, Can you provide a test war application for this bug?

Comment by acerhigh2015 [ 21/Jun/16 ]

Hi, sorry for taking some time before responding!

Sorry, have no time to do that at the moment. If that it needed I will try o fix that next month. Else, it is an "obvious bug" and should be able to covered it with a "simple" junit test.
See my comment I made "26/Dec/15 10:19 PM", there you can see that in case for storing Map with a "value" that is null the code will throw a NullpointerException.

Is it still needed with a test-war?





[JAVASERVERFACES-4083] f:validateWholeBean requires f:validateBean in each input Created: 16/Dec/15  Updated: 13/Jun/16

Status: Open
Project: javaserverfaces
Component/s: validation
Affects Version/s: 2.3.0-m04
Fix Version/s: None

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

Payara 4.1



 Description   

f:validateWholeBean requires f:validateBean in each input -
f:validateBean should be indicated for each input even if there is no validation contrains, otherwise I get an "HV000028: Unexpected exception during isValid call." exception. I don't think this is pretty intuitive.



 Comments   
Comment by ren.zhijun.oracle [ 07/Jan/16 ]

Can you give me an example or sample application?

Comment by anghelleonard [ 07/Jan/16 ]

Yes, of course. Please check here: https://github.com/AnghelLeonard/JSF-2.3/tree/master/JSF23ValidateWholeBeanExample
This example works fine because I have avoided the reported issues. But, you can simply remove the f:validateBean for an input and observe the issue. Thanks!





[JAVASERVERFACES-4164] NullPointerException at WebappLifecycleListener#getActiveSessions when hot deploying a portlet Created: 18/Jul/16  Updated: 18/Jul/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.28
Fix Version/s: None

Type: Bug Priority: Major
Reporter: SebastianBetker Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
  • JBoss EAP 6.4.7.GA
  • JSF Version: Mojarra 2.1.28.SP9 (jsf-impl-2.1.28.SP9-redhat-1)
  • Liferay 6.2.5
  • Java 8


 Description   

When I try to deploy a portlet while the server is running I can observe the following exception. The deployment is nevertheless successfully. This exception doesn't always occur, maybe one in five attempts.
I've seen JAVASERVERFACES-2001 which includes a proposed solution but the ticket was closed because of inactivity.

2016.07.15 13:09:38,164 INFO  [com.liferay.portal.deploy.auto.PortletAutoDeployListener] (user=, pid=, institution=, rolle=, com.liferay.portal.kernel.deploy.auto.AutoDeployScanner) Portlets for {JBOSS-HOME}\liferay\deploy\example-portlet.war copied successfully. Deployment will start in a few seconds.
2016.07.15 13:09:39,914 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) jndi:/default-host/example-portlet/WEB-INF/faces-config.xml changed!
2016.07.15 13:09:39,918 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) Reloading JSF configuration for context /example-portlet
2016.07.15 13:09:39,919 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) java.lang.NullPointerException
2016.07.15 13:09:39,922 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.ArrayList.<init>(ArrayList.java:177)
2016.07.15 13:09:39,923 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.application.WebappLifecycleListener.getActiveSessions(WebappLifecycleListener.java:349)
2016.07.15 13:09:39,925 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.config.ConfigureListener.reload(ConfigureListener.java:510)
2016.07.15 13:09:39,926 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.config.ConfigureListener.access$600(ConfigureListener.java:122)
2016.07.15 13:09:39,928 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor.run(ConfigureListener.java:1039)
2016.07.15 13:09:39,929 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
2016.07.15 13:09:39,931 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
2016.07.15 13:09:39,932 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
2016.07.15 13:09:39,933 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
2016.07.15 13:09:39,935 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2016.07.15 13:09:39,936 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2016.07.15 13:09:39,937 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.lang.Thread.run(Thread.java:745)
2016.07.15 13:09:40,109 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! JBAS018047: Thread local injection container not set
2016.07.15 13:09:40,110 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:376)
2016.07.15 13:09:40,111 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.config.ConfigureListener.reload(ConfigureListener.java:569)
2016.07.15 13:09:40,111 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.config.ConfigureListener.access$600(ConfigureListener.java:122)
2016.07.15 13:09:40,111 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor.run(ConfigureListener.java:1039)
2016.07.15 13:09:40,112 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
2016.07.15 13:09:40,112 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
2016.07.15 13:09:40,112 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
2016.07.15 13:09:40,113 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
2016.07.15 13:09:40,113 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2016.07.15 13:09:40,114 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2016.07.15 13:09:40,114 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.lang.Thread.run(Thread.java:745)
2016.07.15 13:09:40,115 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) Caused by: java.lang.IllegalStateException: JBAS018047: Thread local injection container not set
2016.07.15 13:09:40,116 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at org.jboss.as.jsf.injection.JSFInjectionProvider.<init>(JSFInjectionProvider.java:42)
2016.07.15 13:09:40,116 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at sun.reflect.GeneratedConstructorAccessor257.newInstance(Unknown Source)
2016.07.15 13:09:40,117 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
2016.07.15 13:09:40,117 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
2016.07.15 13:09:40,117 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at java.lang.Class.newInstance(Class.java:442)
2016.07.15 13:09:40,118 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.spi.InjectionProviderFactory.getProviderInstance(InjectionProviderFactory.java:156)
2016.07.15 13:09:40,118 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.spi.InjectionProviderFactory.createInstance(InjectionProviderFactory.java:117)
2016.07.15 13:09:40,119 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:335)
2016.07.15 13:09:40,119 ERROR [stderr] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) 	... 10 more

2016.07.15 13:09:40,119 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (user=, pid=, institution=, rolle=, Mojarra-WebResourceMonitor-55-thread-1) Reload complete.
2016.07.15 13:09:42,333 INFO  [org.jboss.web] (user=, pid=, institution=, rolle=, ServerService Thread Pool -- 1895) JBAS018224: Deregistrierung von Webkontext: /example-portlet
2016.07.15 13:09:42,338 SEVERE [javax.faces] (user=, pid=, institution=, rolle=, ServerService Thread Pool -- 1895) Die Anwendung wurde bei Systemstart nicht einwandfrei initialisiert, Factory konnte nicht gefunden werden: javax.faces.application.ApplicationFactory. Rügriff versucht.
2016.07.15 13:09:42,339 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (user=, pid=, institution=, rolle=, ServerService Thread Pool -- 1895) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.IllegalStateException: Kein Rügriff für javax.faces.application.ApplicationFactory gefunden.
	at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1010) [jboss-jsf-api_2.1_spec-2.1.28.SP1-redhat-1.jar:2.1.28.SP1-redhat-1]
	at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:342) [jboss-jsf-api_2.1_spec-2.1.28.SP1-redhat-1.jar:2.1.28.SP1-redhat-1]
	at com.sun.faces.config.InitFacesContext.getApplication(InitFacesContext.java:141) [jsf-impl-2.1.28.SP9-redhat-1.jar:2.1.28.SP9-redhat-1]
	at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.1.28.SP9-redhat-1.jar:2.1.28.SP9-redhat-1]
	at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3427) [jbossweb-7.5.15.Final-redhat-1.jar:7.5.15.Final-redhat-1]
	at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3939) [jbossweb-7.5.15.Final-redhat-1.jar:7.5.15.Final-redhat-1]
	at org.jboss.as.web.deployment.WebDeploymentService.doStop(WebDeploymentService.java:178) [jboss-as-web-7.5.7.Final-redhat-3.jar:7.5.7.Final-redhat-3]
	at org.jboss.as.web.deployment.WebDeploymentService.access$100(WebDeploymentService.java:61) [jboss-as-web-7.5.7.Final-redhat-3.jar:7.5.7.Final-redhat-3]
	at org.jboss.as.web.deployment.WebDeploymentService$2.run(WebDeploymentService.java:116) [jboss-as-web-7.5.7.Final-redhat-3.jar:7.5.7.Final-redhat-3]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_92]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_92]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_92]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_92]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122)

Please fix in Version 2.1 otherwise the chances to be included in JBoss EAP 6 will be slim.






[JAVASERVERFACES-4162] cc not pushed in ui:repeat when full state saving Created: 12/Jul/16  Updated: 12/Jul/16

Status: Open
Project: javaserverfaces
Component/s: facelets
Affects Version/s: 2.3.0-m06
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   

http://stackoverflow.com/q/38102383/157882

When full state saving is enabled, the ui:repeat does not properly push composite component parent in EL context, causing e.g.

<ui:repeat value="#{cc.attrs.model}">

to evaluate null during postback and a.o. broadcasting of descendant actions to fail.






[JAVASERVERFACES-4160] The fix for JAVASERVERFACES-3080 causes a regression. Created: 01/Jul/16  Updated: 18/Jul/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.29-06
Fix Version/s: None

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

EAP 6.4



 Description   

The fix for JAVASERVERFACES-3080 causes a regression for our customer.
<h:commandButton value="#

{msg['global.save']}

" action="#

{merchantView.savePosEdition}

">
<f:ajax execute="@form" render=":merchantPoses" />
</h:commandButton>
<h:commandButton value="#

{msg['global.cancel']}

" action="#

{merchantView.cancelPosEdition}

" immediate="true">
<f:ajax execute="@form" render=":merchantPoses" />
</h:commandButton>

JSF 2.1.26: Save button and cancel button work as expected and rerender the surrounding rich:panel.

JSF 2.1.27: Save button doesn't work at all and merchantView.savePosEdition isn't called. However, the merchantView.cancelPosEdition method for the Cancel button (with immediate=true) is called and the behaviour is correct.

Commit: https://github.com/javaserverfaces/mojarra/commit/ee7e4e7d83b2422828205f06e69fafbf416db153
Issue: https://java.net/jira/browse/JAVASERVERFACES-3080



 Comments   
Comment by ivassile [ 01/Jul/16 ]

From our customer:
"In attachment, you will find a sample application in order to reproduce the issue (small-jsf-project.zip).
I ran it into a vanilla jboss-eap-6.2.0 and it worked as expected, on the other hand, when deployed on a vanilla jboss-eap-6.4.0 the application is broken.

In attachment you can find videos that illustrate the expected behaviour (JBoss_6_2_0.mp4) and broken behaviour (JBoss_6_4_0.mp4).

Steps to reproduce :

JBoss_6_2_0 :

  • click on edit -> the merchantView.editMerchant() method is called
  • click on save -> the merchantView.saveMerchant() method is called and returns to edit view
  • click on edit -> the merchantView.editMerchant() method is called

JBoss_6_4_0 :

  • click on edit -> the merchantView.editMerchant() method is called
  • click on save -> (BROKEN) the merchantView.saveMerchant() method is not called and it doesn't return to edit view
  • click on cancel -> the merchantView.cancelMerchant() method is called and returns to edit view
  • click on edit -> (BROKEN) the merchantView.editMerchant() method is not called
Comment by ivassile [ 05/Jul/16 ]

Sent email to issues@javaserverfaces.java.net on 07/01/16 with the reproducer.

Comment by Farah Juma [ 18/Jul/16 ]

Any thoughts on why the action method for the h:commandButton no longer gets invoked in this case? This is important for one of our customers - it's a regression from Mojarra 2.1.26. The customer is currently running into this issue with Mojarra 2.1.27 or higher on EAP 6.4.4.

As mentioned in the description, without the fix for JAVASERVERFACES-3080, the action method for the h:commandButton in the provided example does get invoked successfully.





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

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

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


 Description   

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

Forward:
return "index.xhtml"

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

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

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

{ return "index.xhtml"; }




[JAVASERVERFACES-4152] comment can't be set using ExternalContext.addResponseCookie Created: 14/Jun/16  Updated: 14/Jun/16

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

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


 Description   

As stated in the javaDoc of ExternalContext.addResponseCookie, there are various 'properties' that can be set using the Map parameter.

But the list of supported property keys (see com.sun.faces.context.ExternalContextImpl$ALLOWABLE_COOKIE_PROPERTIES) doesn't allow for the value comment.






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

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

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

Portlets



 Description   

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

Portlet Incompatibility #1

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

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

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

Portlet Incompatibility #2

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

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

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

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

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

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

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

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

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

For example, given the following JSF view:

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

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

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

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



 Comments   
Comment by balusc [ 11/Jun/16 ]

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

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

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

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

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

Comment by Neil Griffin [ 14/Jun/16 ]

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

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

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

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

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

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





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

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

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


 Description   

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

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

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

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

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

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

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

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






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

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

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


 Description   

e.g. HtmlInputText#EVENT_NAMES should contain oninput

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

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






[JAVASERVERFACES-4141] XML update parsing error because of the 0x0C (Form Feed) control character Created: 23/May/16  Updated: 23/May/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.12
Fix Version/s: None

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

Wildfly 10



 Description   

com.sun.faces.util.HtmlUtils escapes the rendered text, but its isPrintableControlChar specifically allows the 0x0C character. This character causes AJAX updates to fail, because it's an invalid character in XML 1.0:

Char	   ::=   	#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]	/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */


 Comments   
Comment by VsevolodGolovanov [ 23/May/16 ]

I've put 2.2.12 as the affected version, because that's where we encountered it, but the problem seems to exist since JAVASERVERFACES-1126 (2009).
Sent a reproducer to issues@javaserverfaces.java.net (I didn't implement the auto IT).





[JAVASERVERFACES-4122] Bean Validator is called multiple times Created: 07/Apr/16  Updated: 07/Apr/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.12
Fix Version/s: None

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


 Description   

When using Bean validation, component binding and ajax together, the validation is added at every ajax call to the validator list of the component. This results in multiple calls and displaying the validation message multiple times.

Example:

<h:inputText id="input" validator="#{bean.validate}" binding="#{bean.component}">
  <f:ajax />
</h:inputText>


 Comments   
Comment by mwalliczek [ 07/Apr/16 ]

Environment: Apache Deltaspike 1.5.4, Primefaces 5.3.5, Omnifaces 2.2





[JAVASERVERFACES-4121] Updating jsf separator char requires users to clear their browser cache Created: 06/Apr/16  Updated: 06/Apr/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.12
Fix Version/s: None

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


 Description   

The jsf.js file contains a line:
jsf.separatorchar = '-';

This appears to be generated from the separator value in the web.xml file of an application. However, because of the way the file is cached it seems that changing the separator value requires clients to clear their cache to pick up the new version of the jsf.js file.

While it is unlikely that we will change the separator char often, it seems that it should be something an application could do without requiring users to clear their cache (no application should ever force a user to clear their cache).

How to reproduce:

If I access the application I can see in the browser network logs an initial request with a 200 response for jsf.js and subsequent 304 (not modified) responses as I navigate around. This is expected.

If I modify the jsf separator char in the application's web.xml and redeploy the browser receives only 304s for the jsf.js resource, even though the jsf.js file has changed because it contains the separator char as a variable.

Forcing the browser to do a refresh will fetch the latest jsf.js file from the server and the application will work correctly.






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

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

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


 Description   

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

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

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

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

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

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

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

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






[JAVASERVERFACES-4105] Missing subversion Tag for 2.1.29-05 and ... Created: 14/Feb/16  Updated: 14/Feb/16

Status: Open
Project: javaserverfaces
Component/s: build
Affects Version/s: 2.1.29, 2.1.29-05
Fix Version/s: None

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


 Description   

Hi, (sorry for my small d-english)

I have build a glassfish 3.1.2.2 against mojarra 2.1.29-05 (and more artifacts from maven central). In the server.log of glassfish I see this info message:

[#|2016-02-14T06:10:09.592+0100|INFO|glassfish3.1.2|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=50;_ThreadName=Thread-2;|Initializing Mojarra 2.1.29-05 ( 20160119-2247 unable to get svn info) for context ''|#]

Mojarra realy trying a svn info?

Thanks,
Torsten






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

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

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

Payara 4.1






[JAVASERVERFACES-4103] preRenderView of the multi hop forwarded page not getting executed in JSF - Mojarra 2.2.12 Created: 10/Feb/16  Updated: 10/Feb/16

Status: Open
Project: javaserverfaces
Component/s: ajax, facelets
Affects Version/s: 2.2.12
Fix Version/s: None

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

Wildfly 9.0.2.Final, JDK 1.8.0_65, Windows 8



 Description   

Here is the scenario which is

Page A.xhtml
i. Click an ajax submit button
ii. above click navigates to Page B (not a redirect)

Page B.xhtml
i. There is a "preRenderView" event defined in under f:metadata.
ii. "preRenderView" listener under certain scenario's does a forward to next page i.e. Page C.xhtml
iii. This is used to do navigation - facesContext.getApplication().getNavigationHandler().handleNavigation(facesContext, null, outcome); (not a redirect)

So far so good

Page C.xhtml
i. There is a "preRenderView" event defined in this page under f:metadata - which never gets executed

Problem: Page C is rendered but its "preRenderView" never gets executed.

Note: I tested this scenario with WAS Liberty Server 8.5.5.8 - JEE7 compliant server with Apache MyFaces and it works perfectly fine there.

Thanks for looking into it.






[JAVASERVERFACES-4097] InterfaceHandler wrongly reports required "id" attribute is missing Created: 28/Jan/16  Updated: 28/Jan/16

Status: Open
Project: javaserverfaces
Component/s: composite components
Affects Version/s: 2.2.12
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: c.beikov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Wildfly 10.0.0.CR5



 Description   

I have a composite component that declares an attribute "id" like

<cc:attribute name="id" type="java.lang.String" required="true" />

When using the composite component and setting the "id" attribute, the rendering fails with the following exception:

javax.faces.view.facelets.TagException: /DS/DeliveryScheduleView/delivery_schedule.xhtml @184,73 <clever:confirmDialog> Folgendes Eigenschaften sind erforderlich, aber leider Sie haben keinen Werte übergegeben: id. 
	at com.sun.faces.facelets.tag.composite.InterfaceHandler.validateComponent(InterfaceHandler.java:232)
	at com.sun.faces.facelets.tag.composite.InterfaceHandler.apply(InterfaceHandler.java:125)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:326)
	at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.applyCompositeComponent(CompositeComponentTagHandler.java:387)
	at com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.applyNextHandler(CompositeComponentTagHandler.java:188)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:106)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:206)
	at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
	at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:111)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:106)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:206)
	at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
	at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:111)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:106)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:206)
	at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
	at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:111)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:225)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:174)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:174)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:174)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:161)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:1006)
	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:99)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
	at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:111)
	at javax.faces.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:92)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
	at com.clevercure.web.core.application.filter.UserFilter.doFilter(UserFilter.java:103)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
	at com.clevercure.filter.GWTFilter.doFilter(GWTFilter.java:31)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
	at com.clevercure.web.core.application.filter.FileUploadFilter.doFilter(FileUploadFilter.java:78)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
	at com.clevercure.web.core.application.filter.WebElementsProducerFilter.doFilter(WebElementsProducerFilter.java:35)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
	at com.clevercure.web.core.application.filter.UserContextFilter.doFilter(UserContextFilter.java:58)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)


 Comments   
Comment by c.beikov [ 28/Jan/16 ]

I tracked down the error to the following code block

                if (null != cur.getValue("method-signature") && null == cur.getValue("type")) {
                    // Yes, look for it as an EL expression.
                    found = (null != cc.getValueExpression(key));
                } else {
                    // No, look for it as an actual attribute
                    found = attrs.containsKey(key);
                    // Special case: nested composite components
                    if (!found) {
                        // Check if an EL expression was given.
                        found = (null!=cc.getValueExpression(key));
                    }
                }

`attrs.containsKey(key)` returns false for "id" although `attrs.get(key)` would return the actual value.





[JAVASERVERFACES-4096] javax.faces.validator.ValueExpressionAnalyzer does not delegate method invokation if bean has a parameter like bean1.getAttribut(someParameter).someOther Created: 28/Jan/16  Updated: 30/Jun/16

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Meinolf 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-4159 Implement TagValueExpression#getValue... Closed

 Description   

javax.faces.validator.ValueExpressionAnalyzer does not delegate method invokation if bean has a parameter like bean1.getAttribut(someParameter).someOther

Patch ist to add an invocation delegate to ValueExpressionAnalyzer

public Object invoke(ELContext context, Object base, Object method, Class<?>[] paramTypes, Object[] params)
{
	return delegate.invoke(context, base, method, paramTypes, params);
}


 Comments   
Comment by Meinolf [ 28/Jan/16 ]

In older and newer 2.3.x Versions this seems not to work either.

It is used on bean validation. No error or warning occurs, it silently just doesn't validate.

Comment by arjan tijms [ 04/Feb/16 ]

Actually, shouldn't the private javax.faces.validator.ValueExpressionAnalyzer be replaced by using ValueExpression#getValueReference?

Although this is currently blocked because ValueReference can't be obtained from a TagValueExpression in JSF 2.x (since it doesn't implement getValueReference and its super class just returns null).

In fact, javax.faces.validator.BeanValidator already mentions this in comments:

// PENDING(rlubke, driscoll): When EL 1.3 is present, we won't need
// this.

ValueExpressionAnalyzer expressionAnalyzer =
new ValueExpressionAnalyzer(valueExpression);





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

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

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


 Description   

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

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

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






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

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

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

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



 Description   

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






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

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

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


 Description   

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

For example:

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

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

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

</facelet-taglib>

See this Stack Overflow question for the full example.

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

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

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






[JAVASERVERFACES-4076] DelegatingAnnotationProvider does not handle ArrrayStoreException when retrieving annotations Created: 28/Oct/15  Updated: 28/Oct/15

Status: Open
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.2.12
Fix Version/s: None

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


 Description   

When retrieving a class's annotations via getAnnotations, an ArrayStoreException can be thrown if the class is annotated with an annotation that references a class that isn't on the classpath. One such example is Spring Boot's ConditionalOnBean annotation whose value is a Class[]. A specific example of this problem is described in this Spring Boot issue.

DelegatingAnnotationProvider currently catches any NoClassDefFoundError thrown while retrieving a class's annotation but doesn't deal with the above-described possibility of an ArrayStoreException being thrown.






[JAVASERVERFACES-4072] Error Component already found when using c:if in composite components Created: 01/Oct/15  Updated: 27/Apr/16

Status: Open
Project: javaserverfaces
Component/s: composite components
Affects Version/s: 2.2.12
Fix Version/s: None

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

Glassfish 4.1 + Mojarra 2.2.12



 Description   

Hi

I'm using Composite Components with c:if like this:

    <cc:interface>
        <cc:attribute name="id" required="false"/>
        <cc:attribute name="showPanel" required="false" default="true"/>
    </cc:interface>

    <cc:implementation>
			<c:if test="#{cc.attrs.showPanel}">
                <h:outputText value="#{cc.attrs.id}" id="test"/>
			</c:if>
    </cc:implementation>

In my JSF page I have 2 of these tags, like this:

    <h:form id="form">
		<comp:compositePanel id="test1" showPanel="#{testBean.display}"/>
        <comp:compositePanel id="test2" showPanel="true"/> 
						
        <h:commandLink value="Submit" action="#{testBean.toggle}" />
    </h:form>

In my Bean I do have a toggle Method that toggles a boolean state.

When I click the commandLink, I get an error:

javax.servlet.ServletException: Component ID form:test2:test has already been found in the view.

This exact same example works in Apache Myfaces



 Comments   
Comment by AlexP [ 05/Nov/15 ]

Any news on this?

Comment by klavikka [ 13/Nov/15 ]

This issue seems to be highly similar to those reported by AlexP (JAVASERVERFACES-3978) and me (JAVASERVERFACES-3940).

The pattern is identical:

  1. We have a dynamic build-time tag, either a ui:include or c:if.
  2. Inside it we have a composite component.
  3. There is also another instance of that particular composite component class, that may, or may not be inside a dynamic tag.
  4. During postback, the contents of the composite component that appears later in the component tree gets duplicated and an exception is thrown.
Comment by Steveee [ 13/Nov/15 ]

This is a big issue to me and my application. I've looked at the other two bugs and they look indeed similar. It worked before, but I can't upgrade to glassfish4 because of this. I'm disappointed this didn't even get assigned to anybody after over a month.

Comment by klavikka [ 30/Mar/16 ]

I spent some time today investigating this problem a bit further. Mojarra releases 2.1.21 and 2.2.0 are unaffected. The problem has appeared in 2.1.22 and 2.2.1. I believe that it is related to the fix of issue JAVASERVERFACES-2494. Here's a new reproducer that demonstrates the problem in more sophisticated way: https://github.com/tuner/mojarra-dynamic-include-reproducer

Comment by michpetrov [ 27/Apr/16 ]

I've encountered the same problem, this is my reproducer:

index.xhtml
<h:form>
    <h:commandButton value="Click">
        <f:ajax render="includePanel" listener="#{controller.setPath('include1.xhtml')}"/>
    </h:commandButton>
    <h:panelGrid id="includePanel">
        <ui:include src="#{controller.path}" />
    </h:panelGrid>
    <my:example />
</h:form>

include1.xhtml contains just the composite

example.xhtml
<composite:interface />

<composite:implementation>
    <h:outputText id="txt" value="Text" />
</composite:implementation>

For some reason the error does not occur if the composite component is placed before the ui:include.





[JAVASERVERFACES-4071] Backport JAVASERVERFACES-3673 Created: 30/Sep/15  Updated: 30/Sep/15

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

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


 Description   

Is it possible if this bug could also be backported into 2.2.x at all?

https://java.net/jira/browse/JAVASERVERFACES-3673






[JAVASERVERFACES-4069] @ViewScoped @ManagedBean destroyed when using <h:link includeViewParams=“true”> Created: 25/Sep/15  Updated: 25/Sep/15

Status: Open
Project: javaserverfaces
Component/s: managed bean
Affects Version/s: 2.2.12
Fix Version/s: None

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

java8, tomcat7, jsf 2.2 mojarra 2.2.12



 Description   

I'm using Mojarra 2.2.12. I have a case where a @ViewScoped @ManagedBean is immediately destroyed on page load, although the view is not ended. The problem is reproducible with solely the below in <h:body>:
<h:outputText value="#

{testBean.value}

" />
<h:link outcome="other" includeViewParams="true">link</h:link>
The other must refer to a different view and not the same view. There's no <f:viewParam> necessary to reproduce the problem.

And the below bean:

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;

@ManagedBean
@ViewScoped
public class TestBean implements Serializable {

@PostConstruct
public void init()

{ System.out.println("@PostConstruct on " + this); }

@PreDestroy
public void clear()

{ System.out.println("@PreDestroy on " + this); }

public String getValue()

{ return "test"; }

}
If we remove includeViewParams="true" attribute, then the bean is not immediately destroyed.Why does includeViewParams="true" cause this behavior?






[JAVASERVERFACES-4065] wrong to render html select element. Created: 17/Sep/15  Updated: 21/Sep/15

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

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


 Description   

I debug the component tree

<HtmlForm enctype="application/x-www-form-urlencoded" id="registerForm" inView="true" prependId="true" rendered="true" styleClass="register-form" submitted="false" transient="false">
<h3>Sign Up</h3> <p> Enter your personal details below: </p> <div class="form-group"> <label class="control-label visible-ie8 visible-ie9">Full Name</label> <div class="input-icon"> <i class="fa fa-font"/> <input class="form-control placeholder-no-fix" type="text" placeholder="Full Name" name="fullname"/> </div> </div> <div class="form-group"> <!-ie8, ie9 does not support html5 placeholder, so we just show field title for that-> <label class="control-label visible-ie8 visible-ie9">Email</label> <div class="input-icon"> <i class="fa fa-envelope"/> <input class="form-control placeholder-no-fix" type="text" placeholder="Email" name="email"/> </div> </div> <div class="form-group"> <label class="control-label visible-ie8 visible-ie9">Address</label> <div class="input-icon"> <i class="fa fa-check"/> <input class="form-control placeholder-no-fix" type="text" placeholder="Address" name="address"/> </div> </div> <div class="form-group"> <label class="control-label visible-ie8 visible-ie9">City/Town</label> <div class="input-icon"> <i class="fa fa-location-arrow"/> <input class="form-control placeholder-no-fix" type="text" placeholder="City/Town" name="city"/> </div> </div> <div class="form-group"> <label class="control-label visible-ie8 visible-ie9">Country</label> <select name="country" id="select2_sample4" class="select2 form-control"> <option value=""/> <option value="AF">Afghanistan</option> <option value="AL">Albania</option> <option value="DZ">Algeria</option> <option value="AS">American Samoa</option> <option value="AD">Andorra</option> <option value="AO">Angola</option> <option value="AI">Anguilla</option> <option value="AR">Argentina</option> <option value="AM">Armenia</option> <option value="AW">Aruba</option> <option value="AU">Australia</option> <option value="AT">Austria</option> <option value="AZ">Azerbaijan</option> <option value="BS">Bahamas</option> <option value="BH">Bahrain</option> <option value="BD">Bangladesh</option> <option value="BB">Barbados</option> <option value="BY">Belarus</option> <option value="BE">Belgium</option> <option value="BZ">Belize</option> <option value="BJ">Benin</option> <option value="BM">Bermuda</option> <option value="BT">Bhutan</option> <option value="BO">Bolivia</option> <option value="BA">Bosnia and Herzegowina</option> <option value="BW">Botswana</option> <option value="BV">Bouvet Island</option> <option value="BR">Brazil</option> <option value="IO">British Indian Ocean Territory</option> <option value="BN">Brunei Darussalam</option> <option value="BG">Bulgaria</option> <option value="BF">Burkina Faso</option> <option value="BI">Burundi</option> <option value="KH">Cambodia</option> <option value="CM">Cameroon</option> <option value="CA">Canada</option> <option value="CV">Cape Verde</option> <option value="KY">Cayman Islands</option> <option value="CF">Central African Republic</option> <option value="TD">Chad</option> <option value="CL">Chile</option> <option value="CN">China</option> <option value="CX">Christmas Island</option> <option value="CC">Cocos (Keeling) Islands</option> <option value="CO">Colombia</option> <option value="KM">Comoros</option> <option value="CG">Congo</option> <option value="CD">Congo, the Democratic Republic of the</option> <option value="CK">Cook Islands</option> <option value="CR">Costa Rica</option> <option value="CI">Cote d'Ivoire</option> <option value="HR">Croatia (Hrvatska)</option> <option value="CU">Cuba</option> <option value="CY">Cyprus</option> <option value="CZ">Czech Republic</option> <option value="DK">Denmark</option> <option value="DJ">Djibouti</option> <option value="DM">Dominica</option> <option value="DO">Dominican Republic</option> <option value="EC">Ecuador</option> <option value="EG">Egypt</option> <option value="SV">El Salvador</option> <option value="GQ">Equatorial Guinea</option> <option value="ER">Eritrea</option> <option value="EE">Estonia</option> <option value="ET">Ethiopia</option> <option value="FK">Falkland Islands (Malvinas)</option> <option value="FO">Faroe Islands</option> <option value="FJ">Fiji</option> <option value="FI">Finland</option> <option value="FR">France</option> <option value="GF">French Guiana</option> <option value="PF">French Polynesia</option> <option value="TF">French Southern Territories</option> <option value="GA">Gabon</option> <option value="GM">Gambia</option> <option value="GE">Georgia</option> <option value="DE">Germany</option> <option value="GH">Ghana</option> <option value="GI">Gibraltar</option> <option value="GR">Greece</option> <option value="GL">Greenland</option> <option value="GD">Grenada</option> <option value="GP">Guadeloupe</option> <option value="GU">Guam</option> <option value="GT">Guatemala</option> <option value="GN">Guinea</option> <option value="GW">Guinea-Bissau</option> <option value="GY">Guyana</option> <option value="HT">Haiti</option> <option value="HM">Heard and Mc Donald Islands</option> <option value="VA">Holy See (Vatican City State)</option> <option value="HN">Honduras</option> <option value="HK">Hong Kong</option> <option value="HU">Hungary</option> <option value="IS">Iceland</option> <option value="IN">India</option> <option value="ID">Indonesia</option> <option value="IR">Iran (Islamic Republic of)</option> <option value="IQ">Iraq</option> <option value="IE">Ireland</option> <option value="IL">Israel</option> <option value="IT">Italy</option> <option value="JM">Jamaica</option> <option value="JP">Japan</option> <option value="JO">Jordan</option> <option value="KZ">Kazakhstan</option> <option value="KE">Kenya</option> <option value="KI">Kiribati</option> <option value="KP">Korea, Democratic People's Republic of</option> <option value="KR">Korea, Republic of</option> <option value="KW">Kuwait</option> <option value="KG">Kyrgyzstan</option> <option value="LA">Lao People's Democratic Republic</option> <option value="LV">Latvia</option> <option value="LB">Lebanon</option> <option value="LS">Lesotho</option> <option value="LR">Liberia</option> <option value="LY">Libyan Arab Jamahiriya</option> <option value="LI">Liechtenstein</option> <option value="LT">Lithuania</option> <option value="LU">Luxembourg</option> <option value="MO">Macau</option> <option value="MK">Macedonia, The Former Yugoslav Republic of</option> <option value="MG">Madagascar</option> <option value="MW">Malawi</option> <option value="MY">Malaysia</option> <option value="MV">Maldives</option> <option value="ML">Mali</option> <option value="MT">Malta</option> <option value="MH">Marshall Islands</option> <option value="MQ">Martinique</option> <option value="MR">Mauritania</option> <option value="MU">Mauritius</option> <option value="YT">Mayotte</option> <option value="MX">Mexico</option> <option value="FM">Micronesia, Federated States of</option> <option value="MD">Moldova, Republic of</option> <option value="MC">Monaco</option> <option value="MN">Mongolia</option> <option value="MS">Montserrat</option> <option value="MA">Morocco</option> <option value="MZ">Mozambique</option> <option value="MM">Myanmar</option> <option value="NA">Namibia</option> <option value="NR">Nauru</option> <option value="NP">Nepal</option> <option value="NL">Netherlands</option> <option value="AN">Netherlands Antilles</option> <option value="NC">New Caledonia</option> <option value="NZ">New Zealand</option> <option value="NI">Nicaragua</option> <option value="NE">Niger</option> <option value="NG">Nigeria</option> <option value="NU">Niue</option> <option value="NF">Norfolk Island</option> <option value="MP">Northern Mariana Islands</option> <option value="NO">Norway</option> <option value="OM">Oman</option> <option value="PK">Pakistan</option> <option value="PW">Palau</option> <option value="PA">Panama</option> <option value="PG">Papua New Guinea</option> <option value="PY">Paraguay</option> <option value="PE">Peru</option> <option value="PH">Philippines</option> <option value="PN">Pitcairn</option> <option value="PL">Poland</option> <option value="PT">Portugal</option> <option value="PR">Puerto Rico</option> <option value="QA">Qatar</option> <option value="RE">Reunion</option> <option value="RO">Romania</option> <option value="RU">Russian Federation</option> <option value="RW">Rwanda</option> <option value="KN">Saint Kitts and Nevis</option> <option value="LC">Saint LUCIA</option> <option value="VC">Saint Vincent and the Grenadines</option> <option value="WS">Samoa</option> <option value="SM">San Marino</option> <option value="ST">Sao Tome and Principe</option> <option value="SA">Saudi Arabia</option> <option value="SN">Senegal</option> <option value="SC">Seychelles</option> <option value="SL">Sierra Leone</option> <option value="SG">Singapore</option> <option value="SK">Slovakia (Slovak Republic)</option> <option value="SI">Slovenia</option> <option value="SB">Solomon Islands</option> <option value="SO">Somalia</option> <option value="ZA">South Africa</option> <option value="GS">South Georgia and the South Sandwich Islands</option> <option value="ES">Spain</option> <option value="LK">Sri Lanka</option> <option value="SH">St. Helena</option> <option value="PM">St. Pierre and Miquelon</option> <option value="SD">Sudan</option> <option value="SR">Suriname</option> <option value="SJ">Svalbard and Jan Mayen Islands</option> <option value="SZ">Swaziland</option> <option value="SE">Sweden</option> <option value="CH">Switzerland</option> <option value="SY">Syrian Arab Republic</option> <option value="TW">Taiwan, Province of China</option> <option value="TJ">Tajikistan</option> <option value="TZ">Tanzania, United Republic of</option> <option value="TH">Thailand</option> <option value="TG">Togo</option> <option value="TK">Tokelau</option> <option value="TO">Tonga</option> <option value="TT">Trinidad and Tobago</option> <option value="TN">Tunisia</option> <option value="TR">Turkey</option> <option value="TM">Turkmenistan</option> <option value="TC">Turks and Caicos Islands</option> <option value="TV">Tuvalu</option> <option value="UG">Uganda</option> <option value="UA">Ukraine</option> <option value="AE">United Arab Emirates</option> <option value="GB">United Kingdom</option> <option value="US">United States</option> <option value="UM">United States Minor Outlying Islands</option> <option value="UY">Uruguay</option> <option value="UZ">Uzbekistan</option> <option value="VU">Vanuatu</option> <option value="VE">Venezuela</option> <option value="VN">Viet Nam</option> <option value="VG">Virgin Islands (British)</option> <option value="VI">Virgin Islands (U.S.)</option> <option value="WF">Wallis and Futuna Islands</option> <option value="EH">Western Sahara</option> <option value="YE">Yemen</option> <option value="ZM">Zambia</option> <option value="ZW">Zimbabwe</option> </select> </div> <p> Enter your account details below: </p> <div class="form-group"> <label class="control-label visible-ie8 visible-ie9">Username</label> <div class="input-icon"> <i class="fa fa-user"/> <input class="form-control placeholder-no-fix" type="text" autocomplete="off" placeholder="Username" name="username"/> </div> </div> <div class="form-group"> <label class="control-label visible-ie8 visible-ie9">Password</label> <div class="input-icon"> <i class="fa fa-lock"/> <input class="form-control placeholder-no-fix" type="password" autocomplete="off" id="register_password" placeholder="Password" name="password"/> </div> </div> <div class="form-group"> <label class="control-label visible-ie8 visible-ie9">Re-type Your Password</label> <div class="controls"> <div class="input-icon"> <i class="fa fa-check"/> <input class="form-control placeholder-no-fix" type="password" autocomplete="off" placeholder="Re-type Your Password" name="rpassword"/> </div> </div> </div> <div class="form-group"> <label> <input type="checkbox" name="tnc"/> I agree to the <a href="javascript:;"> Terms of Service </a> and <a href="javascript:;"> Privacy Policy </a> </label> <div id="register_tnc_error"> </div> </div> <div class="form-actions"> <button id="register-back-btn" type="button" class="btn"> <i class="m-icon-swapleft"/> Back </button> <button type="submit" id="register-submit-btn" class="btn blue pull-right"> Sign Up <i class="m-icon-swapright m-icon-white"/> </button> </div>
</HtmlForm>

but the http response html is below.

<div class="form-group">
<label class="control-label visible-ie8 visible-ie9">Country</label>
<select name="country" id="select2_sample4" class="select2 form-control">
<option value=""></select>
<option value="AF">Afghanistan</div>
<option value="AL">Albania</form>
<option value="DZ">Algeria</option>
<option value="AS">American Samoa</option>



 Comments   
Comment by gyp [ 21/Sep/15 ]

remove the issue





[JAVASERVERFACES-4064] BIDUBrowser produces NPE Created: 14/Sep/15  Updated: 14/Sep/15

Status: Open
Project: javaserverfaces
Component/s: renderkit
Affects Version/s: 2.2.10
Fix Version/s: None

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


 Description   

BIDUBrowser sends an illegal Accept header: "/;" which produces an NPE. It should simply choose "text/html". The following headers are sent:

headers
connection: close
cache-control: max-age=0
accept: */*;
accept-language: zh-CN,zh;q=0.8,en;q=0.6
user-agent: Mozilla/5.0 (Windows; U; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; BIDUBrowser 7.6)
stacktrace
 java.lang.NullPointerException
	at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1017)
	at java.lang.Double.parseDouble(Double.java:540)
	at com.sun.faces.renderkit.RenderKitUtils.findMatch(RenderKitUtils.java:991)
	at com.sun.faces.renderkit.RenderKitUtils.determineContentType(RenderKitUtils.java:566)
	at com.sun.faces.renderkit.RenderKitImpl.createResponseWriter(RenderKitImpl.java:260)
	at javax.faces.render.RenderKitWrapper.createResponseWriter(RenderKitWrapper.java:108)





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

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

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


 Description   

Reported in:

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

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

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

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

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

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

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

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

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

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

It says this:

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

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

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

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

This issue needs to be discussed at spec level.

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






[JAVASERVERFACES-4029] Implicit EL resolver for #{component} erroneously makes resolved outcome conditionally Created: 25/Aug/15  Updated: 30/Sep/15

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

Type: Bug Priority: Major
Reporter: arjan tijms 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   

ImplicitObjectELResolver sets the outcome of whether #{component} is resolved based on the value of the result.

This happens via the following code:

 UIComponent c = UIComponent.getCurrentComponent(facesContext);
context.setPropertyResolved(c != null);

This doesn't seem to be correct. Property resolved should be set solely based on whether the resolver handles the property or not (it always does here, so should always be set to true).



 Comments   
Comment by Manfred Riem [ 04/Sep/15 ]

Looks good r=mriem

Comment by arjan tijms [ 04/Sep/15 ]

Applied to 2.3 trunk:

svn commit -m "https://java.net/jira/browse/JAVASERVERFACES-4029, resolved no longer depends on value outcome, r=mriem"
Sending jsf-ri/src/main/java/com/sun/faces/el/ImplicitObjectELResolver.java
Sending test/unit/src/test/java/com/sun/faces/el/ImplicitObjectELResolverTest.java
Transmitting file data ..
Committed revision 15126.

Comment by Ed Burns [ 30/Sep/15 ]

Total 0 (delta 0), reused 0 (delta 0)
To ssh://edburns@git.java.net/mojarra~git
e44a592..eb672ce master -> master

Commit eb672ce2bbfbce2879a0480cbaf20978b2bac2d8 reverts 4029 and restores AdminGUIIT to running.





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

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

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

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



 Description   

Given a class containing a map

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

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

The values of this map might be accessed by this getter

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

This should be used from facelets like in following code

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

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

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

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

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

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





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

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

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


 Description   

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

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

To solve this problem either

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


 Comments   
Comment by lu4242 [ 01/Sep/15 ]

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





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

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

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


 Description   

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

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

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



 Comments   
Comment by fischermatte [ 13/Aug/15 ]

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





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

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

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


 Description   

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

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

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

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

Where can I submit the tests?

Patch:

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





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

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

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

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

 Description   

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

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



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

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

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





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

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

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


 Description   

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

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

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






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

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

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


 Description   

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

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

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






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

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

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


 Description   

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

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

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



 Comments   
Comment by wtlucy [ 02/Jul/15 ]

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

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

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





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

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

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


 Description   

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

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





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

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

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


 Description   

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






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

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

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

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

 Description   

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

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



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

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

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

This is indeed strange that there is both a

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

and a

testing: bounded-task-flow/ OK

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

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

Hi Ed,

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

BR,
Zhijun





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

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

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


 Description   

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

<h:outputText value="#

{Boolean.TRUE}

" />

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

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






[JAVASERVERFACES_SPEC_PUBLIC-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-1366] Within Resource Identifier, allow resourceName to have path separator Created: 05/Mar/15  Updated: 03/Feb/16

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

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

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

 Description   

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

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

  • Added this text to createResource(string)

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

The following additional spec actions must be taken.

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

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

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

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



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

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

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

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

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

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

Other possible problems:

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

Not addressed by JSF 2.3 Early Draft Review.





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

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

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


 Description   

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

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

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

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



 Comments   
Comment by muellermi [ 12/Feb/15 ]

example:

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

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

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





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

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

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


 Description   

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

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

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

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

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