[JAVASERVERFACES_SPEC_PUBLIC-1403] Using f:viewAction to navigate into a flow via redirect misses required query parameters Created: 26/Aug/15  Updated: 31/Aug/15  Resolved: 31/Aug/15

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

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

Attachments: Text File changebundle.txt    

 Description   

UIViewAction says:

Spec> If a navigation case is matched that causes the new viewId to be
Spec> different from the current viewId, the runtime must force a
Spec> redirect to that matched navigation case with different viewId,
Spec> regardless of whether or not the matched navigation case with
Spec> different viewId called for a redirect.

When using <f:viewAction> to enter a flow, this is functionally
equivalent to using GET based navigation to enter the flow, however,
this code path misses out on attaching the necessary parameters required
by FlowHandler.clientWindowTransition() to successfully enter the flow
in the GET based navigation case. Specifically, the
FlowHandler.TO_FLOW_DOCUMENT_ID_REQUEST_PARAM_NAME and the
FlowHandler.FLOW_ID_REQUEST_PARAM_NAME must be added to the query string
when entering the flow in this way.

The trick here will be to find the right place to specify that these
must be tacked on.



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

In progress.





[JAVASERVERFACES_SPEC_PUBLIC-1402] @FlowScoped beans were not intended to be acting as "eager" Created: 20/Aug/15  Updated: 20/Aug/15  Resolved: 20/Aug/15

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

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

Attachments: Text File changebundle.txt    

 Description   

The javadoc for @FlowScoped <https://javaserverfaces.java.net/docs/2.2/javadocs/javax/faces/flow/FlowScoped.html> states:

FlowScoped is a CDI scope that causes the runtime to consider classes with this annotation to be in the scope of the specified Flow. The implementation must provide an implementation of javax.enterprise.inject.spi.Extension that implements the semantics such that beans with this annotation are created when the user enters into the specified Flow, and de-allocated when the user exits the specified Flow.

It is reasonable to conclude from the above text that these beans should be created immediately upon entry into the flow, without regard for their being accessed and created lazily upon the first reference to the bean.

This should be clarified to state that such beans are created lazily, in a similar fashion to every other JSF managed bean, CDI or otherwise.






[JAVASERVERFACES_SPEC_PUBLIC-1401] Note that using the ExceptionHandler during RENDER RESPONSE does not allow for invoking the NavigatinHandler. Created: 19/Aug/15  Updated: 19/Aug/15  Resolved: 19/Aug/15

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3870 If exception occurs and handled by Cu... Closed

 Description   

Some bugs have been reported where the user tried to invoke the NavigationHandler from within their ExceptionHandler. This is fine, but it must not be done if the current phase is RENDER_RESPONSE. Add some advisory text to the spec warning about this.






[JAVASERVERFACES_SPEC_PUBLIC-1399] Allow for UTF-8 in links Created: 19/Aug/15  Updated: 19/Aug/15

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

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

Issue Links:
Related
is related to JAVASERVERFACES-4005 Cutting symbols while URL-Encoding by... Open




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

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




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

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




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

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




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

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




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

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




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

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




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

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




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

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1386] Let CDI handle #{flowScope} Created: 30/Jul/15  Updated: 21/Aug/15

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

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

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

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

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

Comment by arjan tijms [ 21/Aug/15 ]

copy/paste error fixed and committed to 2.3 trunk:

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

{flowScope}

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

Comment by arjan tijms [ 21/Aug/15 ]

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

Applied to 2.3 trunk:

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





[JAVASERVERFACES_SPEC_PUBLIC-1385] Let CDI handle #{flash} Created: 30/Jul/15  Updated: 19/Aug/15  Resolved: 19/Aug/15

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

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Fixed 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
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open

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

Looks excellent, r=mriem

Comment by arjan tijms [ 07/Aug/15 ]

Applied to 2.3 trunk:
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1385, CDI producer for #

{flash}

, r=mriem"
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiExtension.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/FlashProducer.java
Adding test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectFlashBean.java
Adding test/javaee8/cdi/src/main/webapp/injectFlash.xhtml
Adding test/javaee8/cdi/src/test/java/com/sun/faces/test/javaee8/cdi/Spec1385IT.java
Adding test/javaee8/el/src/main/webapp/flash.xhtml
Adding test/javaee8/el/src/test/java/com/sun/faces/test/javaee8/el/Spec1385IT.java
Transmitting file data .......
Committed revision 14970.





[JAVASERVERFACES_SPEC_PUBLIC-1384] Let CDI handle #{component} Created: 30/Jul/15  Updated: 05/Aug/15  Resolved: 05/Aug/15

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

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Fixed 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
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open

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

Only thing I would change is to move the test description into a Javadoc comment on the test itself instead of in the body of the test. Other than that r=mriem.

Comment by arjan tijms [ 04/Aug/15 ]

Applied to 2.3 trunk:
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1384, CDI producer for #

{component}

, r=mriem"
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiExtension.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/ComponentProducer.java
Adding test/javaee8/el/src/main/webapp/component.xhtml
Adding test/javaee8/el/src/test/java/com/sun/faces/test/javaee8/el/Spec1384IT.java
Transmitting file data ....
Committed revision 14961.





[JAVASERVERFACES_SPEC_PUBLIC-1383] Let CDI handle #{cc} Created: 30/Jul/15  Updated: 24/Aug/15  Resolved: 03/Aug/15

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

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Fixed 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
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open

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

In the future please avoid "matches" in regular expression tests if possible. Other than that r=mriem

Comment by arjan tijms [ 03/Aug/15 ]

Applied to 2.3 trunk:
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1383, CDI producer for #

{cc}

, r=mriem"
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiExtension.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiProducer.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/CompositeComponentProducer.java
Adding test/javaee8/el/src/main/webapp/WEB-INF/resources
Adding test/javaee8/el/src/main/webapp/WEB-INF/resources/test
Adding test/javaee8/el/src/main/webapp/WEB-INF/resources/test/composite1.xhtml
Adding test/javaee8/el/src/main/webapp/WEB-INF/resources/test/composite2.xhtml
Sending test/javaee8/el/src/main/webapp/WEB-INF/web.xml
Adding test/javaee8/el/src/main/webapp/compositeComponent.xhtml
Adding test/javaee8/el/src/test/java/com/sun/faces/test/javaee8/el/Spec1383IT.java
Transmitting file data ........
Committed revision 14958.





[JAVASERVERFACES_SPEC_PUBLIC-1382] ExternalContext#getInitParamterMap missing generics Created: 29/Jul/15  Updated: 26/Aug/15  Resolved: 26/Aug/15

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

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

Tags: type-safe

 Description   

While every other type returned by methods in ExternalContext has have had generic parameters added, getInitParameterMap returns a raw Map.

Since raw maps should be avoided for type-safety reasons and for overall consistency, the correct generics (String, String) should be added.



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

Let's see if this one causes problems with ADF.





[JAVASERVERFACES_SPEC_PUBLIC-1379] ExternalContex.getResponseCharacterEncoding() and portlet lifecycle Created: 24/Jun/15  Updated: 17/Jul/15  Resolved: 17/Jul/15

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

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


 Description   

ExternalContext.getResponseCharacterEncoding() currently says:

Returns the name of the character encoding (MIME charset) used for the body sent in this response.

Servlet: This must return the value returned by the javax.servlet.ServletResponse method getCharacterEncoding().

The default implementation throws UnsupportedOperationException and is provided for the sole purpose of not breaking existing applications that extend this class.

In a portlet environment it is challenging to correctly implement this method for all possible invocation scenarios. Ross Clewley wrote:

In a portlet environment the portlet API (JSR286), it's not possible to get the response encoding for every type of request. Only when it's a markup producing request - a RenderRequest or a ResourceRequest do the corresponding response objects have a getCharacterEncoding method. Action and Event requests don't produce markup and there's no response encoding available. The Bridge ensures the JSF lifecycle only executes the render phase for Render and Resource requests and getting the response character encoding during render is fine but any time before that there's potentially a problem.

Can we have some text in the JSF spec to make this easier?

https://docs.oracle.com/javaee/7/api/javax/faces/context/ExternalContext.html#getResponseCharacterEncoding%28%29



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

I propose we add some text to the effect:

Portlet: If this method is called during a lifecycle phase other than RENDER_RESPONSE, this method will return null. If called during RENDER_RESPONSE, return the response encoding of the portlet response.

Comment by rossclewley [ 16/Jul/15 ]

This seems to be a sensible update. However, the Portlet Bridge JSR 329 specification contradicts this:

getResponseCharacterEncoding():

Returns the name of the character encoding (MIME charset) used for the body sent in this response. If called during the RENDER_PHASE or RESOURCE_PHASE, returns the value from the corresponding render response.getCharacterEncoding(). If called during the ACTION_PHASE or EVENT_PHASE it throws an IllegalStateException.

Therefore the above update would need to be coordinated with a corresponding change in the Portlet Bridge specification, which could happen in JSR378 if agreed by the Portlet Bridge EG.

Comment by Ed Burns [ 17/Jul/15 ]

Yes, I think we should modify the Portlet Bridge spec for this method to match ours. Non-portlet use cases never need to throw ISE from this method, so the principle of least astonishment argues supports this approach.

Comment by Ed Burns [ 17/Jul/15 ]

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/context/ExternalContext.java

  • Modify getResponseCharacterEncoding() to add spec text for portlet
    case.
    Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java
    Transmitting file data .
    Committed revision 14867.




[JAVASERVERFACES_SPEC_PUBLIC-1377] Clarify ui:repeat var and varStatus to be of type String (the name of the request scoped variable) Created: 03/Jun/15  Updated: 10/Aug/15  Resolved: 10/Aug/15

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

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

Attachments: Text File changebundle.txt    

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

The ui.tld documentation is misleading as it on the one hand says name of the exported variable (which to me implies String) and then later on it states "Its type depends on the object of the underlying collection".

As its type refers to the actual object that the name is pointing to and not the name itself this should be changed to reflect that

Thoughts?

Comment by Ed Burns [ 10/Aug/15 ]

I agree. That "depends on the type" text may be copy paste error.

Comment by Manfred Riem [ 10/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1377, Clarify ui:repeat var and varStatus to be of type String (the name of the request scoped variable)"
Sending jsf-ri/conf/share/ui.taglib.xml
Sending jsf-ri/conf/share/ui.tld
Transmitting file data ..
Committed revision 14981.





[JAVASERVERFACES_SPEC_PUBLIC-1364] UIRepeat and UIData supports Map Created: 19/Feb/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Manfred Riem
Resolution: Fixed 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:
Cloners
is cloned by JAVASERVERFACES-3836 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1103 UIRepeat and UIData supports Iterable Resolved

 Description   

In reference to JAVASERVERFACES_SPEC_PUBLIC-1103 Bauke Scholtz commented the following:

Would be even more cool if it transparently recognizes Map like c:forEach so we don't need value="#{bean.map.entrySet()}" everytime.

Splitting this off from 1103; it's strongly related but a different (additional) type.



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

When discussing support for Iterable, the wish for Map also came up.

Comment by arjan tijms [ 07/Mar/15 ]

For this change the spec document needs to be updated, specifically section 4.1.3.2.

This section currently (in the 2.3 branch) contains the following text:

The current value identified by the value property is normally of type DataModel. [P1-start-uidataModel]However, a DataModel wrapper instance must automatically be provided by the JSF implementation if the current value is of one of the following types:
java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet) 
javax.servlet.jsp.jstl.sql.Result
java.util.Collection
java.lang.Iterable
Any other Java object is wrapped by a DataModel instance with a single row.[P1-end]

The updated text in section 4.1.3.2 after this update would be the following:

The current value identified by the value property is normally of type DataModel. [P1-start-uidataModel]However, a DataModel wrapper instance must automatically be provided by the JSF implementation if the current value is of one of the following types:
java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet) 
javax.servlet.jsp.jstl.sql.Result
java.util.Collection
java.lang.Iterable
java.util.Map (uses the wrapper for java.lang.Iterable by providing access to java.util.Map#entrySet())
Any other Java object is wrapped by a DataModel instance with a single row.[P1-end]
Comment by Manfred Riem [ 24/Mar/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1364, UIRepeat and UIData supports Map"
Sending spec/frame/standardUserInterfaceComponents.fm
Transmitting file data .
Committed revision 1166.





[JAVASERVERFACES_SPEC_PUBLIC-1362] Revisit "Facelet Taglibrary <tag><component> must contain exactly one of <component-type>, <resource-id>, or <handler-class> Created: 11/Feb/15  Updated: 16/Feb/15  Resolved: 16/Feb/15

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3762 web-facelettaglibary_2_2 erroneously ... Closed

 Description   

Part of the work for JAVASERVERFACES_SPEC_PUBLIC-599 includes this change:

The commit log message that made this change includes this text:

M jsf-api/doc/web-facelettaglibrary_2_2.xsd

Make it so a <tag> must have exactly one of <component-type>,
<resource-id>, or <handler-class>

Here is the rationale behind the above change: if you are going to specify a handler-class, it does not matter what the component-type is because the handler-class effectively can do whatever it wants to create the component. The component-type is only necessary if you want JSF to create the component for you.



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

The reporter for JAVASERVERFACES-3762 wants this decision to be revisited in light of this comment:

Yes, I understand that you can do that, but here's why I feel this should be reverted:

  1. Requiring the component's handler-class to create the component-type couples them tightly together, removing the ability to re-use a handler-class for other components. I feel this fights against the original design, which encouraged the re-use of the 3 component parts: handler-class, component-type, and renderer-type.
  2. The most typical use case of specifying a handler-class for a custom component is to add MetaRuleset rules by overriding createMetaRuleset(). In this case, delegating the creation of the component to JSF is the desired functionality. Requiring every custom handler-class to also create the component requires developers to add unnecessary code.
  3. The current implementation in com.sun.faces.config.processor.FaceletTaglibConfigProcessor.java simply doesn't match the xsd. Currently, any of the following combinations can be defined in the taglib for a component:
    • handler-class (with optional component-type and/or renderer-type)
    • component-type (with optional renderer-type)
    • resource-id




[JAVASERVERFACES_SPEC_PUBLIC-1361] Flow design incorrectly allows re-entrancy for @FlowScoped beans Created: 10/Feb/15  Updated: 12/Feb/15  Resolved: 12/Feb/15

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 14 minutes
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES-3680 Entering same flow again as nested flow Closed

 Description   

Taken from JAVASERVERFACES-3680

Consider having some flows in application, for example PersonListFlow,
PersonDetailFlow, AddressDetailFlow

Example:
1) enter person list - flow PersonListFlow

2) enter person detail - flow PersonDetailFlow

3) enter address detail - flow AddressDetailFlow

4) go to another person living on the same address -> flow
PersonDetailFlow. Flow stack would be:

PersonListFlow
PersonDetailFlow
AddressDetailFlow
PersonDetailFlow

Problem there is that FlowScoped ManagedBean is created for flow ID
"PersonDetailFlow" and is shared with two instances of PersonDetailFlow
in flow stack. In other words, data would be shared and after returning
to first flow PersonDetailFlow instance they will be corrupted for the
first person.



 Comments   
Comment by Martin_Svihlik [ 11/Feb/15 ]

Hi Ed,
What an elegant sollution using stack depth.

When I was reading your code I noticed new method getCurrentFlowDepth was created. I tried to do something simmilar about two months ago when I wanted to determine that I am back in the first flow of application (that I returned from all the nested flows back to the "root" flow). I noticed that when going back from nested flow's return node to method call node in calling flow, the method call node was executed with the nested flow still on the stack. The flow was removed from stack after entering VIEW node.

That means that when having stack F1->F2->F3 and going F3->F2->F1->F2 the stack in method call node invoked in F1 when returned from F2 would be still F1, F2, F3.

I know that many improvements were made on FacesFlows lately, I just wanted to point out that observation. Maybe it is not an issue after many fixes that were made on Faces Flows.

With regards,
Martin

Comment by Ed Burns [ 12/Feb/15 ]

The spec should be modified to state that transitions of the sort mentioned in this issue are valid and that the @FlowScoped CDI context/extension instance needs to take that into account. Also add to the spec that when replacing (rather than decorating) the FlowHandler, one must also replace the @FlowScoped CDI context/extension. The technique of doing this replacement is still an open question.

Comment by Ed Burns [ 12/Feb/15 ]

Mark Struberg suggests this open question is handled by https://issues.jboss.org/browse/CDI-157.

Comment by Ed Burns [ 12/Feb/15 ]

What an elegant sollution using stack depth.

That was Zhijun's idea, and it is what I recommend for JAVASERVERFACES-3680, but without the API change.

Ed





[JAVASERVERFACES_SPEC_PUBLIC-1353] Support @Inject for RequestCookieMap Created: 21/Jan/15  Updated: 21/Jan/15  Resolved: 21/Jan/15

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3709 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added requestCookieMap to the list of things to be described to our parent spec issue.





[JAVASERVERFACES_SPEC_PUBLIC-1351] Support @Inject for FacesBehavior Created: 15/Jan/15  Updated: 15/Jan/15  Resolved: 15/Jan/15

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3691 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Comments   
Comment by Manfred Riem [ 15/Jan/15 ]

Added entry to parent issue so it will end up in the specification PDF





[JAVASERVERFACES_SPEC_PUBLIC-1350] Support @Inject for FacesValidator Created: 14/Jan/15  Updated: 14/Jan/15  Resolved: 14/Jan/15

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3689 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added entry to parent issue so it will end up in the specification PDF





[JAVASERVERFACES_SPEC_PUBLIC-1349] Support @Inject for FacesConverter Created: 14/Jan/15  Updated: 15/Jan/15  Resolved: 14/Jan/15

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3688 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added entry to parent issue so it will end up in the specification PDF





[JAVASERVERFACES_SPEC_PUBLIC-1347] Typo in usingFacesInWebapps.fm 11.4.5 Application Configuration Resource Format Created: 12/Jan/15  Updated: 12/Jan/15  Resolved: 12/Jan/15

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

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

Attachments: PNG File 20150112-1721Z-i_spec_1347.png    

 Description   

Section 11.4.5 Application Configuration Resource Format of the spec PDF has a typo:

<faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.ord/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_2.xsd"
    version="2.0">

It should be

<faces-config 
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
    version="2.2">


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

Proposed spec text:

Application configuration resources that are written to run on JSF 2.2 must include the following schema declaration and must conform to the schema shown in Chapter A “Appendix A - JSF Metadata:
<faces-config
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
version="2.2">

Note that the “hostname” of the xmlns and xsi:schemaLocation attributes has changed from “java.sun.com” to “xmlns.jcp.org”. The “xmlns.jcp.org” hostname must be used when using version="2.2" and web-facesconfig_2_2.xsd. It is not valid to use this hostname with versions prior to 2.2. Likewise, it is not valid to use the “java.sun.com” hostname when using version="2.2" and web-facesconfig_2_2.xsd.
Application configuration resources that are written to run on JSF 2.1 must include the following schema declaration:
<faces-config
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_1.xsd"
version="2.1">

Application configuration resources that are written to run on JSF 2.0 must include the following schema declaration:
<faces-config
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">





[JAVASERVERFACES_SPEC_PUBLIC-1346] Parties that decorate FaceletCacheFactory must use reflection: not good Created: 09/Jan/15  Updated: 10/Feb/15  Resolved: 04/Feb/15

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

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

Attachments: Zip Archive i_spec_1346-test-app.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1177 Make it so com.sun.faces.faceletCache... Reopened
is related to JAVASERVERFACES-1592 Hook for facelet cache management Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-777 Define API to allow pluggable Facelet... Closed
is related to JAVASERVERFACES-3755 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Description   

Consider this simple case.

public class MDSFaceletCacheFactory extends FaceletCacheFactory
{
  public MDSFaceletCacheFactory(FaceletCacheFactory wrapped)
  {
    _wrapped = wrapped;
  }

  @Override
  public FaceletCache getFaceletCache()
  {
    FaceletCache defaultCache = _wrapped.getFaceletCache();
    return new MDSFaceletCache(defaultCache);
  }
  
  private final FaceletCacheFactory _wrapped;
}

and this one

public final class MDSFaceletCache
  extends FaceletCache
{
  public MDSFaceletCache(FaceletCache defaultFaceletCache)
  {
    _defaultFaceletCache = defaultFaceletCache;
  }
...

This is the natural way to use this API, but yet it wall cause a NullPointerException

java.lang.NullPointerException
	at com.sun.faces.facelets.impl.DefaultFaceletCache$2.newInstance(DefaultFaceletCache.java:107)
	at com.sun.faces.facelets.impl.DefaultFaceletCache$2.newInstance(DefaultFaceletCache.java:102)
	at com.sun.faces.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at com.sun.faces.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache.java:114)
	at com.sun.faces.facelets.impl.DefaultFaceletCache.getViewMetadataFacelet(DefaultFaceletCache.java:156)
	at com.sun.faces.facelets.impl.DefaultFaceletCache.getViewMetadataFacelet(DefaultFaceletCache.java:64)
	at com.sun.faces.test.servlet30.facelets.faceletCacheFactory.MDSFaceletCache.getViewMetadataFacelet(MDSFaceletCache.java:119)
	at com.sun.faces.facelets.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:323)
	at com.sun.faces.facelets.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:253)
	at com.sun.faces.application.view.ViewMetadataImpl.createMetadataView(ViewMetadataImpl.java:138)
	at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:241)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)


 Comments   
Comment by Ed Burns [ 09/Jan/15 ]

The reason for the NPE is that while the MDSFaceletCache does have its setMemberFactories() method called, there is no way for the container to ensure that initialization step is passed on to the decorated instance such as in

    FaceletCache defaultCache = _wrapped.getFaceletCache();
Comment by Ed Burns [ 09/Jan/15 ]

The original design of this API was covered in JAVASERVERFACES_SPEC_PUBLIC-777, which was introduced in JSF 2.1.

Comment by Ed Burns [ 09/Jan/15 ]

It would seem we should pass the MemberFactory instances into FaceletCacheFactory.getFaceletCache() rather than out of band using the protected FaceletCache.setMemberFactories() method.

Comment by Ed Burns [ 09/Jan/15 ]

One reason this hasn't cropped up before is that ADF has been using the context param "com.sun.faces.faceletCache" introduced in JAVASERVERFACES-1592 and only now has to use the FaceletCacheFactory API.

Comment by prakashudupa [ 10/Jan/15 ]

ADF does have FaceletCacheFactory implementation for quite some time now. This issue did not surface earlier because because our FacletCache implementation always served the facelet well for all cases where our ResourceResolver implementation provided the URL. Composite component usecase is pretty new for us, and we now find it failing. The underlying issue is that JSF RI does not call our ResourceResolver for composite component case (which makes it a JSF bug). We tried to do a workaround based on observation by Mojarra team that the DefaultFaceletChange works fine for composite component case. Workaround is to delegate to DefaultFaceletChange for composite component case, upon doing so we hit this NPE.

Comment by Ed Burns [ 12/Jan/15 ]

While it is true that this issue didn't surface until MDS started using composite components, that is not the problem being tracked by this issue. This issue is tracking the fact that the initialization contract for the FaceletCacheFactory must include the runtime supplying the factory with the means to produce Facelet and metadata Facelet instances. Currently this is done with an additional step aside from calling FaceletCacheFactory.getFaceletCache().

Comment by Ed Burns [ 04/Feb/15 ]

1346-FaceletCacheFactoryInitializationContract PROPOSAL

The existing contract for creating the FaceletCache is the following:

FaceletCacheFactory cacheFactory = (FaceletCacheFactory)
FactoryFinder.getFactory(FactoryFinder.FACELET_CACHE_FACTORY);
FaceletCache cache = cacheFactory.getFaceletCache();

followed by a reflective invocation of the setMemberFactories() on the cache.

This is wrong in two ways.

1. It requires reflection

2. It is impossible to decorate the cache so that the setMemberFactories
call happens.

I propose modify the contract to remove the need for the reflective call.

The following steps must be taken.

  • Deprecate FaceletCache method

protected void setMemberFactories()

  • Add FaceletCache method

public void FaceletCache.setMemberFactoriesPublic().

With a default implementation that calls setMemberFactories(). This
is necessary because we can't make an existing protected method public
without breaking existing classes that extend FaceletCacheFactory.





[JAVASERVERFACES_SPEC_PUBLIC-1345] Support @Inject for the sessionMap Created: 07/Jan/15  Updated: 07/Jan/15  Resolved: 07/Jan/15

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3676 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Comments   
Comment by Manfred Riem [ 07/Jan/15 ]

Added sessionMap to the list of things to be described to our parent spec issue.





[JAVASERVERFACES_SPEC_PUBLIC-1344] Move 2.3 CDI producers out of API packages Created: 05/Jan/15  Updated: 21/Aug/15  Resolved: 05/Jan/15

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

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

Issue Links:
Dependency
depends on JAVASERVERFACES-3668 Move 2.3 CDI producers out of API pac... Closed




[JAVASERVERFACES_SPEC_PUBLIC-1338] Clarify pseudo code in 2.6.1.4 Libraries of Localized and Versioned Resources Created: 22/Nov/14  Updated: 23/Jan/15  Resolved: 22/Jan/15

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: Frank Caputo Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 17 minutes
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1339 Clarify search requirements for resou... Open

 Description   

There are 2 problems with the pseudo code in 2.6.1.4 of the PDF.

  1. in line 7 of deriveResourceIdConsideringLocalePrefixAndContracts the contracts parameter is missing.
     result = deriveResourceIdConsideringLocalePrefixAndContracts(prefix, resourceName, libraryName, null); 

    is obviously wrong. It must be

     result = deriveResourceIdConsideringLocalePrefixAndContracts(contract, prefix, resourceName, libraryName, null) 


  2. The pseudo code won't find resources in contracts in jars, because the web app resource loader tries to find the resource without a contract before the classpath resource loader tries. The web app resource loader usually finds the resource without a contract. So the way it iterates should change to iterate per contract over both resource loaders. The following pseudo code change until function deriveResourceId should work as expected.
    function createResource(resourceName, libraryName) {
        var resource = null;
        var resourceId = null;
        for (var contract : getLibraryContracts()) {
            resourceId = deriveResourceIdConsideringResourceLoaders(contract, resourceName, libraryName)
            if (null != resourceId) {
                resource = create the resource using the resourceId;
                return resource;
            }
        }
    
        // try without a contract
        resourceId = deriveResourceIdConsideringResourceLoaders(null, resourceName, libraryName)
        if (null != resourceId) {
            resource = create the resource using the resourceId;
        }
        return resource;
    }
    
    function deriveResourceIdConsideringResourceLoaders(contract, resourceName, libraryName) {
        var prefix = web app root resource prefix;
        var resourceLoader = web app resource loader;
        // these are shorthand for the prefix and resource loading
        // facility specified in Section 2.6.1.1. They are
        // not actual API per se.
        var resourceId = deriveResourceIdConsideringLocalePrefix(contract, prefix, resourceLoader, resourceName, libraryName);
    
        if (null == resourceId) {
            prefix = classpath resource prefix;
            resourceLoader = classpath resource loader;
            // these are shorthand for the prefix and resource
            // loading facility specified in Section 2.6.1.2. They are
            // not actual API per se.
            resourceId = deriveResourceIdConsideringLocalePrefix(contract, prefix, resourceLoader, resourceName, libraryName);
        }
        return resourceId;
    }
    
    function deriveResourceIdConsideringLocalePrefix(contract, prefix, resourceLoader, resourceName, libraryName) {
        var localePrefix = getLocalePrefix();
        var result = deriveResourceId(contract, prefix, resourceLoader, resourceName, libraryName, localePrefix);
        // If the application has been configured to have a localePrefix, and the resource
        // is not found, try to find it again, without the localePrefix.
        if (null == result && null != localePrefix) {
            result = deriveResourceId(contract, prefix, resourceLoader, resourceName, libraryName, null);
        }
        return result;
    }
    
    function deriveResourceId(contract, prefix, resourceLoader, resourceName, libraryName, localePrefix) {
        // stays as is
    }
    
    function getLocalePrefix() {
        // stays as is
    } 
    





[JAVASERVERFACES_SPEC_PUBLIC-1337] ResourceELResolver does not require a call to ExternalContext.encodeResourceURL() Created: 11/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

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


 Description   

Every other occasion where we send a resource request we require a call to ExternalContext.encodeResourceURL(). I discovered one place where we do not: ResourceELResolver.getValue().






[JAVASERVERFACES_SPEC_PUBLIC-1335] Support @Inject for the viewMap Created: 31/Oct/14  Updated: 15/Jan/15  Resolved: 31/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3525 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added viewMap to the list of things to be described to our parent spec issue.





[JAVASERVERFACES_SPEC_PUBLIC-1334] Let CDI handle #{viewScope} Created: 31/Oct/14  Updated: 31/Oct/14  Resolved: 31/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is blocked by JAVASERVERFACES-3524 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added statement of work to the parent issue as it will be done as one spec CDI EL spec text change





[JAVASERVERFACES_SPEC_PUBLIC-1333] Support @Inject for UIViewRoot Created: 28/Oct/14  Updated: 15/Jan/15  Resolved: 28/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3518 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Related
is related to JAVASERVERFACES-3675 Add test for JAVASERVERFACES_SPEC_PUB... Closed

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

Added view to the list of things to be described to our parent spec issue.





[JAVASERVERFACES_SPEC_PUBLIC-1332] Let CDI handle #{view} Created: 28/Oct/14  Updated: 28/Oct/14  Resolved: 28/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is blocked by JAVASERVERFACES-3517 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added statement of work to the parent issue as it will be done as one spec CDI EL spec text change





[JAVASERVERFACES_SPEC_PUBLIC-1331] Let CDI handle #{application} Created: 27/Oct/14  Updated: 27/Oct/14  Resolved: 27/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is blocked by JAVASERVERFACES-3514 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added statement of work to the parent issue as it will be done as one spec EL spec text change





[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: 0
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-1328] Let CDI handle #{session} EL resolving Created: 17/Oct/14  Updated: 27/Oct/14  Resolved: 17/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is blocked by JAVASERVERFACES-3497 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added appropriate summary to parent issue that needs to be incorporated in the entire CDI EL spec section





[JAVASERVERFACES_SPEC_PUBLIC-1327] Verify @Inject HttpSession support Created: 17/Oct/14  Updated: 17/Oct/14  Resolved: 17/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3496 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added entry to parent issue so it will end up in the specification PDF





[JAVASERVERFACES_SPEC_PUBLIC-1325] Let CDI handle #{applicationScope} Created: 15/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is blocked by JAVASERVERFACES-3489 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added statement of work to the parent issue as it will be done as one spec CDI EL spec text change





[JAVASERVERFACES_SPEC_PUBLIC-1323] Support @Inject for the applicationMap Created: 15/Oct/14  Updated: 15/Jan/15  Resolved: 15/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3488 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Added applicationMap to the list of things to be described to our parent spec issue.





[JAVASERVERFACES_SPEC_PUBLIC-1322] Simplify #{externalContext} to use ExternalContextProducer Created: 15/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is blocked by JAVASERVERFACES-3487 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed




[JAVASERVERFACES_SPEC_PUBLIC-1318] Expose Facelets for use from MVC Created: 13/Oct/14  Updated: 25/Feb/15  Resolved: 25/Feb/15

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

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


 Description   

This issue covers whatever spec changes we will need to support the use of Facelets from the MVC framework.



 Comments   
Comment by Manfred Riem [ 25/Feb/15 ]

No additional work was needed.





[JAVASERVERFACES_SPEC_PUBLIC-1311] Let CDI handle #{facesContext} EL resolving Created: 16/Sep/14  Updated: 17/Oct/14  Resolved: 14/Oct/14

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

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

Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
blocks JAVASERVERFACES_SPEC_PUBLIC-1287 Make @javax.faces.bean.ManagedBean me... Closed
is blocked by JAVASERVERFACES-3440 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

The following changes were added to the spec:

ADDED - As part of a continued effort of aligning the JSF specification with the CDI specification the EL resolver added by the CDI runtime will play a more important role in doing EL resolving. As such the following table states which JSF artifacts will be resolved by means of CDI producers:

JSF Artifact Backing JSF methods
FacesContext FacesContext.getCurrentInstance()

REMOVED - the references to the FacesContext EL resolving in the implicit EL resolver area

Comment by Manfred Riem [ 08/Oct/14 ]

The changes have been reverted because we are going to open an issue that better describes it from a high level. It will show what the expected changes for this issue are going to be and related issues.





[JAVASERVERFACES_SPEC_PUBLIC-1309] Support @Inject for ExternalContext Created: 08/Sep/14  Updated: 13/Oct/14  Resolved: 13/Oct/14

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

Type: New Feature Priority: Critical
Reporter: Manfred Riem Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3423 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

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

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1309, Support @Inject for ExternalContext"
Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java
Transmitting file data .
Committed revision 13747.





[JAVASERVERFACES_SPEC_PUBLIC-1307] validator attributes TLD doc misleading Created: 05/Sep/14  Updated: 16/Sep/14  Resolved: 16/Sep/14

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

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

Operating System: All
Platform: All


Attachments: Text File changebundle.txt    
Issue Links:
Cloners
clones JAVASERVERFACES_SPEC_PUBLIC-891 converter and validator attributes TL... Resolved
Issuezilla Id: 891
Status Whiteboard:

size_small importance_medium


 Description   

UIOutput converter attribute allows assigning a literal to specify the
converterId of the converter to be used or a ValueExpression evaluating to an
instance of Converter.
TLD doc only mentions the ValueExpression as allowed type and also the
Description does not mention the possibility to pass the converterId.

The same is missing for validator attributes on input components - TLD doc only
mentions teh MethodExpression but says nothing about the literal validatorId
that can be used too.



 Comments   
Comment by Manfred Riem [ 05/Sep/14 ]

This issue will take care of the validator attributes

Comment by Manfred Riem [ 16/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1307, clarify validator tag attribute"
Sending jsf-api/doc/editable-props.xml
Sending jsf-api/doc/standard-html-renderkit.xml
Transmitting file data ..
Committed revision 13685.





[JAVASERVERFACES_SPEC_PUBLIC-1306] @FlowScoped should be @NormalScope(passivating=true) Created: 05/Sep/14  Updated: 24/Aug/15  Resolved: 24/Aug/15

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

Type: Improvement Priority: Critical
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    

 Description   

In order to run flows in a cluster, @FlowScoped should be passivating=true.



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

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1306, @FlowScoped should be @NormalScope(passivating=true)"
Sending jsf-api/src/main/java/javax/faces/flow/FlowScoped.java
Transmitting file data .
Committed revision 15039.





[JAVASERVERFACES_SPEC_PUBLIC-1304] FacesContext.setResourceLibraryContracts() missing @since 2.2 designator. Created: 04/Sep/14  Updated: 04/Sep/14  Resolved: 04/Sep/14

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

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


 Comments   
Comment by Ed Burns [ 04/Sep/14 ]

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/context/FacesContext.java

  • @throws IllegalStateException if this method is called after
  • this instance has been released
    *
    + * @since 2.2
    + *
    */

public void setResourceLibraryContracts(List<String> contracts) {

There you have it.
Sending jsf-api/src/main/java/javax/faces/context/FacesContext.java
Transmitting file data .
Committed revision 13628.





[JAVASERVERFACES_SPEC_PUBLIC-1301] XML validation gives error on vdl-document in faces-config Created: 25/Aug/14  Updated: 12/Aug/15  Resolved: 12/Aug/15

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

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

Attachments: Text File changebundle.txt    

 Description   

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

The following XML document gives the following error when validating the contents within Eclipse or Netbeans.

Errors:

cvc-pattern-valid: Value '/sec/flows/flow1/step1.xhtml' is not facet-valid with respect to pattern '($|_|\p

{L})(\p{L}
\p {Nd}
_ $)*' for type
'null'.
cvc-complex-type.2.2: Element 'vdl-document' must have no element [children], and the value must be valid.

faces-config:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
version="2.2">
<flow-definition id="createInvoice">
<start-node>index</start-node>
<view id="index">
<vdl-document>/sec/flows/flow1/step1.xhtml</vdl-document>
</view>
</flow-definition>
</faces-config>



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

I like to change the vdl-document element to be of type javaee:pathType as it is a path and not an identifier.

<xsd:sequence>
<xsd:element name="vdl-document"
type="javaee:pathType">
<xsd:annotation>
<xsd:documentation>
<![CDATA[
<p class="changed_added_2_2 changed_modified_2_3">
Define the path to the vdl-document for the enclosing view.
<p>
]]>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>

Comment by Ed Burns [ 11/Aug/15 ]

I endorse this change, but it begs the question if we should use this type for other path like structures? However, we can address that as a separate issue if desired.

r=edburns

Comment by Manfred Riem [ 12/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1301, XML validation gives error on vdl-document in faces-config"
Sending jsf-api/doc
Sending jsf-api/doc/web-facesconfig_2_3.xsd
Transmitting file data .
Committed revision 14986.





[JAVASERVERFACES_SPEC_PUBLIC-1300] UIViewRoot.getViewMap() require different publishEvent() variant. Created: 21/Aug/14  Updated: 16/Sep/14  Resolved: 21/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3375 ViewScopeEventListener not safe for u... Closed

 Description   

See JAVASERVERFACES-3375.

The javadoc for UIViewRoot.getViewMap() is very explicit about the arguments to publishEvent(). Because we are so specific, we should require calling the variant that takes the base class.






[JAVASERVERFACES_SPEC_PUBLIC-1294] Modify TaglibraryDoc for <ui:debug> so that it states it only works when ProjectStage is development. Created: 16/Jul/14  Updated: 09/Sep/14  Resolved: 09/Sep/14

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

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

Issue Links:
Blocks
is blocked by JAVASERVERFACES-3424 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Description   

<ui:debug> should state that it only works if ProjectStage is development.



 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-1292] Clarify how attributes on passthru elements get rendered Created: 14/Jul/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

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


 Description   

See < https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-03/message/17 >. Specifically, Leonardo wants us to clarify how the attributes get rendered on the pass through element.



 Comments   
Comment by Ed Burns [ 14/Jul/14 ]

Section "10.1.4.1 Non-normative Feature Overview" states:

As in the preceding example, the TagDecorator mechanism is activated but it is determined that this component should act as a <jsf:element> component for the purposes of postback processing. The behavior of the <jsf:element> is normatively specified in the VDLdoc for that tag. The behavior of the javax.faces.passthrough.Element renderer is normatively specified in the RenderKitDoc for that renderer.

I propose we add the following sentence at the end.

The ResponseWriter also plays a role in rendering passthrough attributes, as specified in the "general notes on encoding" in the RenderKitDoc for the HTML_BASIC RenderKit.

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-1283] Allow for injection on UIComponent, Converter and Validator Created: 12/Jun/14  Updated: 23/Jan/15  Resolved: 23/Jan/15

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

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

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open

 Description   

Investigate what is necessary to make it so UIComponent, Converter and Validator are injectable (and do it



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 23/Jan/15 ]

Converters and Validators are injectable. UIComponents are not.





[JAVASERVERFACES_SPEC_PUBLIC-1279] UIInput.isEmpty() lacks specification Created: 15/May/14  Updated: 12/Aug/15  Resolved: 12/Aug/15

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES-3241 java.lang.IndexOutOfBoundsException: ... Closed

 Description   

This method should have a specification.

It was added in svn revision 6714 as part of issue JAVASERVERFACES_SPEC_PUBLIC-426.

  • make hitherto private static method isEmpty() public. Used from
    RequiredValidator.


 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 Manfred Riem [ 12/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1279, UIInput.isEmpty() lacks specification"
Sending jsf-api/src/main/java/javax/faces/component/UIInput.java
Transmitting file data .
Committed revision 14990.





[JAVASERVERFACES_SPEC_PUBLIC-1277] Missing client-window-factory in web-facesconfig_2_2.xsd Created: 07/May/14  Updated: 05/Sep/14  Resolved: 05/Sep/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Schema
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Critical
Reporter: Neil Griffin Assignee: Manfred Riem
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-1241 web-facesconfig_2_2.xsd is missing de... Resolved

 Description   

The following XML Schema file is missing the client-window-factory feature:
http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd



 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-1274] In ViewMetadata.createMetadataView() clarify state for temporary UIViewRoot Created: 10/Apr/14  Updated: 14/Aug/15  Resolved: 14/Aug/15

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-1273 Clarify what happens to the current F... Closed
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Closed

 Description   

In ViewMetadata.createMetadataView(), specify

  • the new UIViewRoot must be set as the FacesContext's viewRoot before applying the tag handlers, restoring
    the old FacesContext in a finally block.
  • The content's of the current UIViewRoot's ViewMap must be copied to the ViewMap of the new UIViewRoot
    before applying the tag handlers.


 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 [ 14/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1274, In ViewMetadata.createMetadataView() clarify state for temporary UIViewRoot"
Sending jsf-api/src/main/java/javax/faces/view/ViewMetadata.java
Transmitting file data .
Committed revision 15005.





[JAVASERVERFACES_SPEC_PUBLIC-1270] JavaDoc for TagDecorator regarding pass-through attributes not in line with implementation Created: 19/Mar/14  Updated: 19/Aug/15  Resolved: 19/Aug/15

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

Type: Bug Priority: Critical
Reporter: michael_kurz Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 51 minutes
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1185 Pass Through attribute should have pr... Open

 Description   

The documentation for class TagDecorator states the following for processing attributes:

For each of argument tag's attributes obtain a reference to a TagAttribute with the following characteristics. For discussion let such an attribute be convertedTagAttribute.

  • convertedTagAttribute's location: from the argument tag's location.
  • If the current attribute's namespace is http://xmlns.jcp.org/jsf, convertedTagAttribute's qualified name must be the current attribute's local name and convertedTagAttribute's namespace must be the empty string. This will have the effect of setting the current attribute as a proper property on the UIComponent instance represented by this markup.
  • If the current attribute's namespace is empty or different from the argument tag's namespace, let the current attribute be convertedTagAttribute. This will have the effect of setting the current attribute as an attribute on the attributes map of the UIComponent instance represented by this markup.

The third item states, that attributes without a namespace or with a namespace different from the tag's namespace should be attributes of the component (and NOT pass-through attributes).

This is not in line with the implementation in Mojarra (which is correct in my opinion!). Mojarra treats all attributes of a pass-through element without a namespace as pass-through attributes. This perfectly makes sense as I would consider attributes without a prefix in a pass-through element as something belonging to the HTML tag.

With the behavior defined in the spec, this would not work:

<input type="text" jsf:id="name" jsf:value="#{bean.name}"
    placeholder="Enter name"/>

But this feels natural to me! The behavior implemented in Mojarra seems to be consistent too: pass-through attributes must be prefixed on jsf tags and jsf attributes must be prefixed on pass-through elements.

This issue popped up in MyFaces recently as MYFACES-3868 (see [1]).

[1]: https://issues.apache.org/jira/browse/MYFACES-3868



 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-1269] Incorrect literal string value for javax.faces.application.ViewHandler.DISABLE_FACELET_JSF_VIEWHANDLER_PARAM_NAME Created: 11/Mar/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

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

Issue Links:
Dependency
depends on JAVASERVERFACES-3374 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Description   

Spec says the value of this field should be javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER, but the code has DISABLE_FACELET_JSF_VIEWHANDLER.



 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-1268] javax.faces.view.ViewScoped should be @NormalScoped(passivating=true) Created: 06/Mar/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

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

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Issue Links:
Dependency
depends on JAVASERVERFACES-3371 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Related
is related to JAVASERVERFACES-3191 Serialization and CDI Viewscope Closed

 Description   

See JAVASERVERFACES-3191.



 Comments   
Comment by Ed Burns [ 16/Apr/14 ]

I was discussing this on IM with someone from ADF and they made a good point.

if you are managing data structures hanging off of the session on the application's behalf, you are responsible for providing a mechanism for the application to mark the sub pieces as dirty

This is a core requirement for solving this issue.

Comment by Ed Burns [ 16/Apr/14 ]

Another important point about this issue pertains to failover and view state. If you make it so @ViewScoped beans can be failed over, then you will also have to make it so view state can be failed over.

Blake Sullivan from ADF suggests using something like <https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/util/SubKeyMap.java> to store each view state as a separate session attribute.

SubKeyMap is a convenience for flattening out the individual view state entries into separate session attributes so that they can be individually dirtied, and thus are less prone to re-replication. You still have to replicate all the view state entries, but with this solution there is less of an update burden.

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-1267] Clarify meaning of null return from UIComponent.getFamily() Created: 13/Feb/14  Updated: 16/Sep/14  Resolved: 16/Sep/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: 2.3

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

Attachments: Text File changebundle.txt    
Issue Links:
Dependency
blocks JAVASERVERFACES-3180 Possible NPE in FormOmittedChecker Closed

 Description   

Clarify meaning of null return from UIComponent.getFamily().

See JAVASERVERFACES-3180.



 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 Manfred Riem [ 16/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1267, Clarify meaning of null return from UIComponent.getFamily()"
Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Transmitting file data .
Committed revision 13686.





[JAVASERVERFACES_SPEC_PUBLIC-1262] web_partialresponse_2_2.xsd uses incorrect cardinality on partial-response element. Created: 03/Feb/14  Updated: 10/Aug/15  Resolved: 10/Aug/15

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: 2.3

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

Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES-3171 Exception during render on Ajax reque... Closed

 Description   

The XSD file for the partial-response element states that a <partial-response> may have exactly one of <changes>, <redirect>, or <error> as a child element. This is incorrect. We should allow any number and combination of those child elements for maximum flexibility.

This problem manifests itself when the server needs to send an <error> response when some <changes> response data has already been written to the response. This can happen if there is an error during rendering.



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

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

Comment by Ed Burns [ 10/Aug/15 ]

r=edburns

Comment by Manfred Riem [ 10/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1262, web_partialresponse_2_2.xsd uses incorrect cardinality on partial-response element."
Sending jsf-api/doc/web-partialresponse_2_3.xsd
Transmitting file data .
Committed revision 14982.





[JAVASERVERFACES_SPEC_PUBLIC-1258] Declare that text output by <h:outputText> (or equivalent inline EL expressions) within script or style blocks is not escaped by default. Created: 30/Jan/14  Updated: 12/Aug/15  Resolved: 12/Aug/15

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

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

Attachments: Text File changebundle.txt    

 Description   

See JAVASERVERFACES-3150.



 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 [ 12/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1258, Declare that text output by <h:outputText> (or equivalent inline EL expressions) within script or style blocks is not escaped by default."
Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-api/doc/standard-html-renderkit.xml
Transmitting file data ..
Committed revision 14987.





[JAVASERVERFACES_SPEC_PUBLIC-1257] Prevent FaceletContext.FACELET_CONTEXT_KEY constant to be inlined by compiler Created: 27/Jan/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-3372 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Comments   
Comment by lfryc [ 27/Jan/14 ]

I can't see the description of the issue even though I added it.


Re-posting:

In RichFaces 5 when we compile ActionListenerHandler against Mojarra 2.2.5 and then run the code against older 2.1 release (2.1.7), we get NullPointerException.

The issue is well described in RF-13472.

The problem here is that a value of FACELET_CONTEXT_KEY contstant is inlined by compiler, but the value has changed between Mojarra 2.1 ("com.sun.faces.facelets.FACELET_CONTEXT") and 2.2 ("javax.faces.FACELET_CONTEXT"). This means the code compiled against one 2.2 won't work on 2.1 and vice versa.


What we can do is prevent compiler from inlining the FACELET_CONTEXT_KEY constant.

As suggested on stackoverflow, it is possible to use String#intern() or String#toString():

public static final String FACELET_CONTEXT_KEY = 
            "javax.faces.FACELET_CONTEXT".intern();

http://stackoverflow.com/questions/377819/are-all-compile-time-constants-inlined
http://stackoverflow.com/questions/1833581/when-to-use-intern-on-string-literals


I believe the fix should go to 2.1.x branch as well.

Comment by Manfred Riem [ 27/Jan/14 ]

Lukas, I have attached the change bundle and once review has done I will commit it, then when it passes the 2.2 TCK I'll will close this issue. For the 2.1 work please file a back port task pointing back to this issue. Thanks!

Comment by Manfred Riem [ 28/Jan/14 ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3155, r=edburns, intern the FACELET_CONTEXT_KEY so it does not get inlined."
Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletContext.java
Transmitting file data .
Committed revision 12799.

Once the 2.2 TCK passes I will go ahead and close the issue. Thanks!

Comment by Manfred Riem [ 29/Jan/14 ]

Applied to 2.2 branch,

svn commit -m "Reverting change as it breaks the TCK"
Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletContext.java
Transmitting file data .
Committed revision 12804.

Comment by Manfred Riem [ 29/Jan/14 ]

Unfortunately as the proposed change breaks the TCK I have moved it to the spec issue tracker to put it on the table for 2.3.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1254] contracts attribute too restrictive. Created: 22/Jan/14  Updated: 20/Oct/14  Resolved: 20/Oct/14

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Dependency
blocks JAVASERVERFACES-3139 relax restriction of where to place <... Closed

 Description   

The javadoc for the contracts attribute on <f:view> includes this text.

Any use of this attribute on a non-outer-most file must be silently ignored.

A customer stated this is overly restrictive. There are cases when it would be useful to allow a "last one wins" approach. This issue suggests changing the text to read:

Any use of this attribute on a non-outer-most file is undefined.



 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 [ 20/Oct/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1254, contracts attribute too restrictive."
Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
Sending jsf-ri/conf/share/facelets_jsf_core.tld
Transmitting file data ..
Committed revision 13774.





[JAVASERVERFACES_SPEC_PUBLIC-1251] Documentation for javax.faces.application.ResourceHandler.RESOURCE_CONTRACT_XML could use clarification Created: 10/Jan/14  Updated: 01/Aug/14  Resolved: 10/Jan/14

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

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


 Description   

The spec PDF says.

2.7 Resource Library Contracts

[...]

When packaged in a JAR file, there is one additional packaging
requirement: each resource library contract in the JAR must have a
marker file. The name of the file is given by the value of the symbolic
constant javax.faces.application.ResourceHandler.RESOURCE_CONTRACT_XML.
This may be a zero length file, though future versions of the
specification may use the file to declare the usage contract.

The doc for the constant says:

The name of the marker file that the implementation must scan for, within sub-directories META-INF/contracts, to identify the set of available resource library contracts.

I propose the following improvement for the doc for the constant.

This file must be located in META-INF/contracts/<contractName>/ in a jar file that contains a resource library contract, where <contractName> is the name of the contract. If the jar file contains multiple contracts, the marker file must be present in each one. See "constant field values" for the name of the file that must be placed at that location.



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

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/application/ResourceHandler.java

  • The operative change.

RESOURCE_CONTRACT_XML

public static final java.lang.String RESOURCE_CONTRACT_XML

This file must be located in META-INF/contracts/<contractName>/ in a jar file that contains a resource library contract, where <contractName> is the name of the contract. If the jar file contains multiple contracts, the marker file must be present in each one. See "constant field values" for the name of the file that must be placed at that location.

M jsf-api/src/main/resources/jsf-api.css
M jsf-api/src/main/resources/overview.html
M jsf-api/src/main/java/javax/faces/application/package.html
M jsf-api/doc/jsdoc-template/static/default.css
M jsf-ri/conf/share/tlddoc-resources/stylesheet.css
M jsf-tools/src/main/resources/com/sun/faces/generate/facesdoc/stylesheet.css
A jsf-api/doc/changed_deleted_2_3_cursor.cur
A jsf-api/doc/changed_deleted_2_3.png
A jsf-api/doc/changed_added_2_3.png
A jsf-api/doc/changed_modified_2_3_cursor.cur
A jsf-api/doc/changed_modified_2_3.png
A jsf-api/doc/changed_added_2_3_cursor.cur

  • 2.3 preparation startup costs.
    Adding (bin) jsf-api/doc/changed_added_2_3.png
    Adding (bin) jsf-api/doc/changed_added_2_3_cursor.cur
    Adding (bin) jsf-api/doc/changed_deleted_2_3.png
    Adding (bin) jsf-api/doc/changed_deleted_2_3_cursor.cur
    Adding (bin) jsf-api/doc/changed_modified_2_3.png
    Adding (bin) jsf-api/doc/changed_modified_2_3_cursor.cur
    Sending jsf-api/doc/jsdoc-template/static/default.css
    Sending jsf-api/src/main/java/javax/faces/application/ResourceHandler.java
    Sending jsf-api/src/main/java/javax/faces/application/package.html
    Sending jsf-api/src/main/resources/jsf-api.css
    Sending jsf-api/src/main/resources/overview.html
    Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
    Sending jsf-tools/src/main/resources/com/sun/faces/generate/facesdoc/stylesheet.css
    Transmitting file data .............
    Committed revision 12770.
Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1250] Some not existing classes in chapter 5.4.1 Created: 03/Jan/14  Updated: 21/Aug/15  Resolved: 21/Aug/15

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

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


 Description   

In specified chapter in TABLE 5-3 there are mentioned following artifacts (among others):

javax.faces.view.ViewDeclarationFactory
javax.faces.view.facelets.FaceletFactory

I can't see these in 2.2.4 api. There's only javax.faces.view.ViewDeclarationLanguageFactory.



 Comments   
Comment by tremes [ 03/Jan/14 ]

And javax.faces.context.FlashFactory is likely missing.

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 [ 21/Aug/15 ]

Applied to 2.3 spec doc,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1250, Some not existing classes in chapter 5.4.1"
Sending spec/frame/valueReferences.fm
Transmitting file data .
Committed revision 1170.





[JAVASERVERFACES_SPEC_PUBLIC-1242] Remove OpenAjax hub from Specification Created: 17/Dec/13  Updated: 12/Aug/15  Resolved: 12/Aug/15

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

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

Attachments: Text File changebundle.txt    

 Description   

My question here in this group is: should we remove our mention and
usage of OpenAjax in the JSF spec?

EB> 13.2 JavaScript Namespacing

EB> JavaScript objects that are not enclosed within a namespace are global,
EB> which means they run the risk of interfering, overriding and/or
EB> clobbering previously defined JavaScript objects. This section defines
EB> the requirements for implementations intending to use the JavaServer
EB> Faces 2.0 JavaScript API.

EB> The Open Ajax Alliance is an organization of leading vendors, open
EB> source projects, and companies using Ajax. Their prime objective is to
EB> accelerate customer success with Ajax, through the use of open
EB> standards. The Open Ajax Registry is an industry-wide Ajax registration
EB> authority managed by the OpenAjax Alliance. The Registry maintains
EB> industry- wide lists of Ajax runtime libraries to help prevent object
EB> collisions.

EB> There is a top level namespace jsf that is registered with the Open Ajax
EB> Alliance:

EB> Java Ajax:

Unknown macro: {EB> namespaceURI}

EB> [P1-start openajax registration]If the OpenAjax library is available,
EB> libraries must register themselves using OpenAjax.registerLibrary() at
EB> the time when the JavaScript files are fetched and parsed by the
EB> browser\u2019s JavaScript engine. [P1-end]

EB> if (typeof OpenAjax != "undefined" &&
EB> typeof OpenAjax.hub.registerLibrary != "undefined")

Unknown macro: {EB> OpenAjax.hub.registerLibrary("jsf", "www.sun.com", "1.0",EB> null); }

EB> –
EB> 8<---------------

EB> Unfortunately, I now see this text on the website:

EB> "The following organizations were Members of OpenAjax Alliance at the
EB> time OpenAjax Alliance terminated formal operations:" A little research
EB> revealed this email about the termination:

EB> http://openajax.org/pipermail/steeringcommittee/2012q4/001015.html

EB> And this article, now nearly four years old.

EB> https://devcentral.f5.com/articles/5-years-later-openajax-who#.UqdusoG7liw

EB> Basically, it seems OpenAjax is dead. Anyone care to comment on whether
EB> we should bother with it in JSR-362?



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

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

Comment by Ed Burns [ 13/Aug/14 ]

FWIW, I just updated the wikipedia page for Open Ajax Alliance to state that it has terminated operations.

Comment by Manfred Riem [ 12/Aug/15 ]

Implementation changes

Comment by Manfred Riem [ 12/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1242, Remove OpenAjax hub from Specification (implementation side)"
Sending jsf-api/src/main/resources/jsf.js
Transmitting file data .
Committed revision 14997.

Comment by Manfred Riem [ 12/Aug/15 ]

Applied to 2.3 spec,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1242, Remove OpenAjax hub from Specification"
Sending spec/frame/ajaxIntegration.fm
Transmitting file data .
Committed revision 1169.





[JAVASERVERFACES_SPEC_PUBLIC-1241] web-facesconfig_2_2.xsd is missing definition for client-window-factory element Created: 09/Dec/13  Updated: 24/Aug/15  Resolved: 08/Sep/14

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

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

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1277 Missing client-window-factory in web-... Resolved

 Comments   
Comment by Manfred Riem [ 09/Dec/13 ]

As this requires a change to the released schema this would require a spec change. Moved to the spec issue tracker.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1239] HTML_BASIC components converter attribute supports converterId, as well as the already stated ValueExpression that points to a Converter Created: 27/Nov/13  Updated: 05/Sep/14  Resolved: 05/Sep/14

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

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

Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-891 converter and validator attributes TL... Resolved

 Description   

The tags for all of the HTML_BASIC components in Facelets have a "converter" attribute that is specified to do the following.

Type:

javax.el.ValueExpression
(must evaluate to javax.faces.convert.Converter)

Description:

Converter instance registered with this component.

In practice, looking at com.sun.faces.facelets.tag.jsf.ValueHolderRule, this also supports a value that is a converter id.

The spec should be updated to reflect this reality.



 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-1231] Wrong name in spec for javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR Created: 16/Oct/13  Updated: 23/Jan/15  Resolved: 23/Jan/15

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

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


 Description   

Reported by Martin Koci in:

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

In summary JSF 2.2 PDF section 3.5.3 Validation Registration has a reference to a config param javax.faces.validator.DISABLE_BEAN_VALIDATOR but the one used in both Mojarra and MyFaces is javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR.

Probably it was a change done with the objective of improve the meaning of the param. The param that should be used is javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR



 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 Manfred Riem [ 23/Jan/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1231, Wrong name in spec for javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR"
Sending spec/frame/userInterfaceComponentModel.fm
Transmitting file data .
Committed revision 1159.





[JAVASERVERFACES_SPEC_PUBLIC-1229] VDLDoc for <h:dataTable> does not document rowStatePreserved property. See UIData.setRowStatePreserved() Created: 14/Oct/13  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES-2633 UIInput component state incorrect whe... Closed

 Description   

The JavaDocs for UIData have the rowStatePreserved property.

This needs to be exposed on the vdldoc for <h:dataTable>.



 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 Manfred Riem [ 17/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1229, formally add support for rowStatePreserved property."
Sending jsf-api/doc/standard-html-renderkit.xml
Sending jsf-api/doc/uidata-props.xml
Transmitting file data ..
Committed revision 13695.





[JAVASERVERFACES_SPEC_PUBLIC-1218] Validation error message for byte should state -127 to 128 Created: 16/Aug/13  Updated: 01/Aug/14  Resolved: 20/Aug/13

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

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


 Description   

The resource bundle for standard validation messages (see JSR-344 section 2.5.2.4) state
javax.faces.converter.ByteConverter.BYTE=

{2}: ''{0}'' must be a number between 0 and 255.
and
javax.faces.converter.ByteConverter.BYTE_detail={2}

: ''

{0}

'' must be a number between 0 and 255. Example:

{1}

My best understanding is that that is wrong and that they should state
... a number between -127 and 128 ...

(I get the first of these error messages in a facelets page when entering values outside of -127..128 for a byte, so the validation itself works as I expect it but the validation message to the user is misleading)



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

ttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1218

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/Messages_zh_HK.properties
M jsf-api/src/main/java/javax/faces/Messages_es.properties
M jsf-api/src/main/java/javax/faces/Messages_ko.properties
M jsf-api/src/main/java/javax/faces/Messages.properties
M jsf-api/src/main/java/javax/faces/Messages_zh_TW.properties
M jsf-api/src/main/java/javax/faces/Messages_zh_CN.properties
M jsf-api/src/main/java/javax/faces/Messages_en.properties
M jsf-api/src/main/java/javax/faces/Messages_pt_BR.properties
M jsf-api/src/main/java/javax/faces/Messages_fr.properties
M jsf-api/src/main/java/javax/faces/Messages_de.properties
M jsf-api/src/main/java/javax/faces/Messages_ja.properties

  • Correct values for BYTE and BYTE_detail to reflect value of
    Byte.MIN_VALUE and Byte.MAX_VALUE.
    Sending jsf-api/src/main/java/javax/faces/Messages.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_de.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_en.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_es.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_fr.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_ja.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_ko.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_pt_BR.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_zh_CN.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_zh_HK.properties
    Sending jsf-api/src/main/java/javax/faces/Messages_zh_TW.properties
    Transmitting file data ...........
    Committed revision 12423.
Comment by Ed Burns [ 20/Aug/13 ]

https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1218

M spec/frame/requestProcessingLifecycle.fm

  • Section 2.5.2.4

Correct values for BYTE and BYTE_detail to reflect value of
Byte.MIN_VALUE and Byte.MAX_VALUE.

Sending spec/frame/requestProcessingLifecycle.fm
Transmitting file data .
Committed revision 1148.

Comment by Ed Burns [ 20/Aug/13 ]

svn commit -m "Update test after updating property file" jsf-ri/systest/src/com/sun/faces/jsptest/ConverterTestCase.java
Sending jsf-ri/systest/src/com/sun/faces/jsptest/ConverterTestCase.java
Transmitting file data .
Committed revision 12425.

Comment by Ed Burns [ 20/Aug/13 ]

Hudson failures.

Comment by Ed Burns [ 20/Aug/13 ]

Safe to close when < http://slc03qna.us.oracle.com:7070/hudson/view/Mojarra%202.2/job/2_2_x-gf-3_1_2_2-no-cluster/193/ > is clean.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1215] Add warning to javadoc of DelegatingMetaTagHandler.getTagHandlerDelegate Created: 12/Aug/13  Updated: 14/Aug/15  Resolved: 14/Aug/15

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

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

Attachments: Text File changebundle.txt     Text File changebundle.txt    

 Description   

The current spec has no javadoc for DelegatingMetaTagHandler.getTagHandlerDelegate(). [1] This issue proposes adding the following warning to the javadoc for this method.

Code that extends from DelagatingMetaTagHandler (directly or indirectly, as through extending ComponentHandler) must take care to decorate, not replace, the TagHandlerDelegate instance returned by this method. Failure to do so may produce unexpected results.

[1] http://docs.oracle.com/javaee/6/api/javax/faces/view/facelets/DelegatingMetaTagHandler.html#getTagHandlerDelegate%28%29



 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 Manfred Riem [ 14/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1215, Add warning to javadoc of DelegatingMetaTagHandler.getTagHandlerDelegate"
Sending jsf-api/src/main/java/javax/faces/view/facelets/DelegatingMetaTagHandler.java
Transmitting file data .
Committed revision 15006.





[JAVASERVERFACES_SPEC_PUBLIC-1214] Javadoc fails accessibility requirements for color contrast Created: 06/Aug/13  Updated: 01/Aug/14  Resolved: 28/Aug/13

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

Type: Bug Priority: Major
Reporter: Kim Haase Assignee: Kim Haase
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 28 minutes
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     HTML File file01-cc.html     HTML File file02-facelets-ui.html     HTML File file03-javascript.html     HTML File file04-mainpage.html     Java Archive File javax.faces-api-2.2-SNAPSHOT-javadoc.jar    

 Description   

The Facelets and JavaScript documentation for JSF fail accessibility requirements for color contrast. Sorry I missed this before.

I'll attach the output of the color contrast analyzer for four pages that fail: the main page for the Facelets Tag Library doc, the main page for composite components, the main page for Facelets templating, and one of the JavaScript pages (jsf). You only have to worry about the table rows that are red.

In most cases the colored fonts need to be darker. For the JavaScript pages, it might be sufficient to make the typeface bold for the white-on-blue table headings.



 Comments   
Comment by Kim Haase [ 06/Aug/13 ]

Whoops, I can't attach files. I will send them in email.

Comment by Ed Burns [ 26/Aug/13 ]

Updated to avoid A11Y violations.

Comment by Ed Burns [ 26/Aug/13 ]

Also, I attached a javadoc jar (which you can just unzip with the zip
tool) that has the changes applied.

Kim, I'm assigning the issue to you. Please confirm the changes achieve
compliance and let me know. I'll commit when whe achieve compliance.

Thanks,

Ed

Comment by Kim Haase [ 26/Aug/13 ]

Thanks very much, Ed. It's all fixed except for one page:

vdldocs/facelets/f/tld-summary.html

On this page, the equals signs next to the red text are green (it's hard to see between the black and the red) – so the color contrast fails. You might as well make the page black-and-white like the others.

Comment by Ed Burns [ 27/Aug/13 ]

I've just attached another iteration, fixing the problem you mentioned. Please verify.

Comment by Kim Haase [ 27/Aug/13 ]

Thanks, Ed! The fix works.

Comment by Ed Burns [ 28/Aug/13 ]

Kim, please mark this closed when the docs have been published.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1186] Many component from HTML namespace are missing 'role' attributes Created: 26/Apr/13  Updated: 27/Aug/13  Resolved: 27/Aug/13

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

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


 Description   

Components of the "http://xmlns.jcp.org/jsf/html" namespace are missing attributes like 'role':
h:body, h:dataTable, h:form, h:graphicImage, h:inputSecret, h:inputSecret, h:inputTextarea, h:message, h:messages, h:outputFormat, h:outputLabel, h:outputLink, h:outputScript, h:outputStylesheet, h:outputText, h:panelGrid, h:selectBooleanCheckbox, h:selectManyCheckbox, h:selectManyListbox, h:selectManyMenu, h:selectOneListbox, h:selectOneMenu, h:selectOneRadio

I know that you are pretty close to the FCS, probably not necessary for the final build. Fixing it into the next dot release/patch would be really appreciated.

See related NetBeans issue: https://netbeans.org/bugzilla/show_bug.cgi?id=228286



 Comments   
Comment by marfous [ 02/May/13 ]

I think that vdldocs define it correctly, the issue is that it's not defined in the metadata of the JSF library.

Comment by marfous [ 06/May/13 ]

I'm attaching patch for fixing this definition issue of the html_basic.taglib.xml metadata:
https://dl.dropboxusercontent.com/u/1418580/JAVASERVERFACES_SPEC_PUBLIC-1186.patch

Thanks in advance.

Comment by Ed Burns [ 27/Aug/13 ]

Sorry this took so long, especially considering the triviality of doing it.

Comment by Ed Burns [ 27/Aug/13 ]

SECTION: Modified Files
----------------------------
M jsf-ri/conf/share/html_basic.taglib.xml

  • From Martin Fousek. Add role attribute to taglib.xml for HTML_BASIC.
    Sending jsf-ri/conf/share/html_basic.taglib.xml
    Transmitting file data .
    Committed revision 12454.




[JAVASERVERFACES_SPEC_PUBLIC-1170] In facelet vdldoc for HTML_BASIC tag panelpassthrough.Element must be removed. Created: 27/Feb/13  Updated: 24/Aug/15  Resolved: 24/Aug/15

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

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 Description   

In facelet vdldoc for HTML_BASIC tag panelpassthrough.Element must be removed.



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

Roger, this doesn't need to be done by PFD. It can be done by final.

Comment by Ed Burns [ 27/Feb/13 ]

Roger, for the record, I did make this change but the problem persisted.

8<-----------------
Index: jsf-tools/conf/FaceletsHtmlBasicTaglib21.pre-maven-rename.properties
===================================================================
— jsf-tools/conf/FaceletsHtmlBasicTaglib21.pre-maven-rename.properties (revision 11661)
+++ jsf-tools/conf/FaceletsHtmlBasicTaglib21.pre-maven-rename.properties (working copy)
@@ -98,6 +98,7 @@
base.output.dir=build.pre-maven-rename/generate

#OPTIONAL PROPERTIES
+taglib.excludedRendererTypes=javax.faces.passthrough.Element
taglib.include=build/TAG-DEF-21.txt
taglib.description=This tag library contains JavaServer Faces component tags for all\n\
UIComponent + HTML RenderKit Renderer combinations defined in the\n\
Index: jsf-tools/conf/FaceletsHtmlBasicTaglib21.properties
===================================================================
— jsf-tools/conf/FaceletsHtmlBasicTaglib21.properties (revision 11661)
+++ jsf-tools/conf/FaceletsHtmlBasicTaglib21.properties (working copy)
@@ -97,6 +97,7 @@
base.output.dir=build/generate

#OPTIONAL PROPERTIES
+taglib.excludedRendererTypes=javax.faces.passthrough.Element
taglib.include=build/TAG-DEF-21.txt
taglib.description=This tag library contains JavaServer Faces component tags for all\n\
UIComponent + HTML RenderKit Renderer combinations defined in the\n\
8<----------------

I do suspect the taglib.excludedRendererTypes is part of the solution.

Comment by Ed Burns [ 27/Feb/13 ]

Also, note that h:doctype has value and converter and it should not.

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 [ 24/Aug/15 ]

Verified in VDLDoc in new style build it does not contain "panelpassthrough.Element"





[JAVASERVERFACES_SPEC_PUBLIC-1154] cc:clientBehavior tag is not documented in the composite.taglib.xml descriptor Created: 14/Jan/13  Updated: 27/Aug/13  Resolved: 27/Aug/13

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

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


 Description   

This issue was raised against NetBeans IDE which is dependent on the composite.taglib.xml descriptors to be able to detect list of tags and their attributes per project.

<cc:clientBehavior> tag is used to add ajax support to composite components,
for more information:
http://www.ibm.com/developerworks/java/library/j-jsf2fu-0610/index.html?ca=drs-#N10270
Currently the tag is not recognized by the IDE, so it adds a red icon the the
project root indicating that the project contains files with errors. The
project runs without problems but the red icon remains.

Link to the related NetBeans issue: http://netbeans.org/bugzilla/show_bug.cgi?id=224768

Please complete the composite.taglib.xml file, thanks a lot.



 Comments   
Comment by marfous [ 16/Aug/13 ]

I'm attaching patch for fixing this definition issue of the composite.taglib.xml metadata:
https://dl.dropboxusercontent.com/u/1418580/JAVASERVERFACES_SPEC_PUBLIC-1154.patch

Thanks in advance.

Comment by arturo_serrano [ 16/Aug/13 ]

This also affects all the JSF 2.2 releases:

The composite.taglib.xml file in com.sun.faces.metadata.taglib package in Mojarra 2.2.2 jar doesn't have the clientBehavior tag.

The patch provided in the comment avobe should be applied to the next JSF 2.2 release too.





[JAVASERVERFACES_SPEC_PUBLIC-1135] Add PostRenderViewEvent Created: 04/Oct/12  Updated: 25/Feb/15  Resolved: 25/Feb/15

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

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Manfred Riem
Resolution: Fixed Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Text File i_spec_1135-draft.patch     Zip Archive newfiles.zip    
Issue Links:
Blocks
is blocked by JAVASERVERFACES-3747 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Description   

In JSF 2.0 a PreRenderViewEvent was added that is published just before a view is rendered, but there's no corresponding event published just after rendering a view.

There are several alternatives for this, but none of them is really perfect. A per-view PhaseListener can be used, but it fires relatively early and sticks around after a post-back which may be undesirable. A global PhaseListener that picks up a delegating listener in request scope is another option that does work, but is not as intuitively clear (we use this approach in OmniFaces' CallbackPhaseListener).

I therefor propose to add a PostRenderViewEvent that is published right after a view is rendered.

Among the use cases for such an event is doing per request clean-ups; for instance a view scoped backing bean where a value is set such that for one particular request an item is rendered with some emphasis and then after the first post-back rendered normally again.



 Comments   
Comment by arjan tijms [ 04/Oct/12 ]

Draft of PostRenderViewEvent implementation including rudimentary test.

Comment by kithouna [ 07/Mar/13 ]

Would be great if this can still be put in JSF 2.2. Seems to be a very trivial thing.

Comment by kithouna [ 14/Mar/13 ]

On second thoughs, don't add this to JSF 2.2 for the mere reason that the team should focus 100% on polishing and finishing work that has already started and should not do anything new for 2.2.

For 2.3 this would be really great though

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by Manfred Riem [ 02/Feb/15 ]

Implementation changes have been applied. See the associated implementation issue.

Arjan, please review the specification PDF to see if there is additional information to be added from a specification perspective.

Thanks!

Comment by arjan tijms [ 24/Feb/15 ]

Section 2.2.6 now contains the following:

Upon completion of rendering, the completed state of the view must have been saved using the methods of the class StateManager. This state information must be made accessible on a subsequent request, so that the Restore View can access it.[P1-end]

I propose to change this to:

Upon completion of rendering, the completed state of the view must have been saved using the methods of the class StateManager. This state information must be made accessible on a subsequent request, so that the Restore View can access it.

Publish the javax.faces.event.PostRenderViewEvent. (generally this is directly after the call to ViewHandler.renderView())
[P1-end]

Section 3.4.3.1 now contains the following:

PreRenderComponentEvent indicates that the source component is about to be rendered. Please see Section 3.1.7 “Component Tree Manipulation” for a reference to the normative specification.

PreRenderViewEvent indicates that the UIViewRoot source component is about to be rendered. Please see Section 2.2.6 “Render Response” for the normative specification.

PreValidateEvent indicates that an individual component instance is about to be validated. Please see the EditableValueHolder Section 3.2.7.3 “Events” for the normative specification.

I propose to change this to:

PreRenderComponentEvent indicates that the source component is about to be rendered. Please see Section 3.1.7 “Component Tree Manipulation” for a reference to the normative specification.

PreRenderViewEvent indicates that the UIViewRoot source component is about to be rendered. Please see Section 2.2.6 “Render Response” for the normative specification.

PostRenderViewEvent indicates that the UIViewRoot source component has just been rendered. Please see Section 2.2.6 “Render Response” for the normative specification.

PreValidateEvent indicates that an individual component instance is about to be validated. Please see the EditableValueHolder Section 3.2.7.3 “Events” for the normative specification.

Comment by Manfred Riem [ 25/Feb/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1135, Add PostRenderViewEvent"
Sending spec/frame/requestProcessingLifecycle.fm
Sending spec/frame/userInterfaceComponentModel.fm
Transmitting file data ..
Committed revision 1160.





[JAVASERVERFACES_SPEC_PUBLIC-1131] h:outputScript and h:outputStylesheet "name" attribute is not required Created: 15/Aug/12  Updated: 24/Aug/15  Resolved: 17/Aug/15

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

Type: Bug Priority: Critical
Reporter: lu4242 Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    

 Description   

The facelets documentation javadoc for h:outputScript and h:outputStylesheet indicates that "name" attribute is required, but it is valid to use h:outputScript just to render a <script> tag that surrounds the inner content. For example:

<composite:implementation>
<h:outputScript rendered="#

{!empty cc.attrs.script}

"><!--
.myCustomScript = #

{cc.attrs.script}

;
//--></h:outputScript>
</composite:implementation>

or

<composite:implementation>
<h:outputStylesheet rendered="#

{!empty cc.attrs.style}

"><![CDATA[
.myCustomStyle { #

{cc.attrs.style}

}
]]></h:outputStylesheet>
</composite:implementation>

is a valid syntax.



 Comments   
Comment by marfous [ 12/Dec/12 ]

Please would be possible to increase the priority to the Major and fix the issue in the taglib specification.

See related NetBeans IDE issue:
Bug 216926 - h:outputScript and h:outputStylesheet "name" attribute is not required
http://netbeans.org/bugzilla/show_bug.cgi?id=216926

Comment by Lynx6 [ 06/Mar/13 ]

wow... this problem need to be fixed, netbeans is showing each file with error parsing.

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 Manfred Riem [ 17/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1131, h:outputScript and h:outputStylesheet "name" attribute is not required"
Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-ri/conf/share/html_basic.taglib.xml
Transmitting file data ..
Committed revision 15016.

Comment by Manfred Riem [ 17/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1131, h:outputScript and h:outputStylesheet "name" attribute is not required"
Sending jsf-api/doc/standard-html-renderkit.xml
Transmitting file data .
Committed revision 15017.





[JAVASERVERFACES_SPEC_PUBLIC-1103] UIRepeat and UIData supports Iterable Created: 23/May/12  Updated: 08/Mar/15  Resolved: 02/Mar/15

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Duplicate
duplicates FACELETS-240 UIRepeat 'value' attribute and Collec... Resolved
Related
is related to JAVASERVERFACES-3785 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1078 Have DataModel implementations regist... Reopened
is related to JAVASERVERFACES_SPEC_PUBLIC-1364 UIRepeat and UIData supports Map Resolved

 Description   

I encountered a problem attempting to set the ui:repeat "value" attribute to an
instance that was a subclass of java.util.Set (specifically Hibernate's
PersistentSet class): the UIRepeat class treated it like a scalar object.

An iteration tag like ui:repeat should work with all Collection types in my
opinion. In the UIRepeat.getDataModel() method it's possible to detect an
instance of Collection and make use of the ArrayDataModel by invoking the
toArray() method on the instance. In this way a new DataModel implementation
isn't needed. I've made this change in my own copy of Facelets and it works
beautifully.

Hibernate happens to use Sets quite a bit, so this was important to me. I'd be
happy to submit a patch.

This issue occurs in Facelets 1.2 as well.\



 Comments   
Comment by Aditya [ 10/Sep/12 ]

Not only just collections, ui:repeat should also support iterables as well for the value attribute.

Comment by Ertio lew [ 11/Mar/13 ]

ui:repeat should allow iterables to be used with them. Currently we are required to create a new list from iterable just to support ui:repeat. This limitation should be removed.

Comment by kithouna [ 27/Sep/13 ]

The collection / iterable to datamodel conversion should be abstracted and put in a global place. Now DataTable and UIRepeat do pretty much the same thing and differences crop up between them that benefit no one.

Then, we the users should be able to register additional datamodel converters, so we can register something like OmniFaces' IterableDataModel and they would be automatically used by DataTable, UIRepeat and others.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by arjan tijms [ 17/Feb/15 ]

Not only just collections, ui:repeat should also support iterables as well for the value attribute.

I agree, and have adjusted the title of the issue to reflect that. If UIRepeat supports iterables, UIData should support that as well. Thanks for this suggestion!

Comment by Ed Burns [ 23/Feb/15 ]

Section 4.1.3.2 in the spec PDF must be updated as well for this issue to be considered closed. The relevant text in the latest version of the spec is the following:

The current value identified by the value property is normally of type DataModel. [P1-start-uidataModel]However, a
DataModel wrapper instance must automatically be provided by the JSF implementation if the current value is of one
of the following types:
java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet)
javax.servlet.jsp.jstl.sql.Result
Any other Java object is wrapped by a DataModel instance with a single row.[P1-end]
Convenience implementations of DataModel are provided in the javax.faces.model package for each of the
above (see Section 4.2.1.4 “Concrete Implementations”), and must be used by the UIData component to create the
required DataModel wrapper.

Comment by Ed Burns [ 23/Feb/15 ]

I have some comments about the changebundle, but I'll add them on the impl issue JAVASERVERFACES-3785.

Comment by arjan tijms [ 23/Feb/15 ]

The relevant text in the latest version of the spec is the following:

The spec currently lists:

  • java.util.List
  • Array of java.util.Object
  • java.sql.ResultSet
  • javax.servlet.jsp.jstl.sql.Result
  • (Object wrapped as single row)

But java.util.Collection is missing, while this was added via a spec issue (JAVASERVERFACES_SPEC_PUBLIC-479).

The new list would therefor become:

  • java.util.List
  • Array of java.util.Object
  • java.sql.ResultSet
  • javax.servlet.jsp.jstl.sql.Result
  • java.util.Collection
  • java.lang.Iterable
  • (Object wrapped as single row)

Also, a similar list appears in UIRepeat, but I can't find anything about that in the spec.

The updated text in section 4.1.3.2 after this update (and after taking into account the change from 2.2) would be the following:

The current value identified by the value property is normally of type DataModel. [P1-start-uidataModel]However, a DataModel wrapper instance must automatically be provided by the JSF implementation if the current value is of one of the following types:

java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet)
javax.servlet.jsp.jstl.sql.Result
java.util.Collection
java.lang.Iterable
Any other Java object is wrapped by a DataModel instance with a single row.[P1-end]

Comment by arjan tijms [ 25/Feb/15 ]

Patch for ui:repeat's taglib/tld doc

Comment by arjan tijms [ 02/Mar/15 ]

Oops, UIRepeat changes did not make it into previous bundle

Comment by Manfred Riem [ 02/Mar/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1103, UIRepeat and UIData supports Iterable"
Sending jsf-ri/conf/share
Sending jsf-ri/conf/share/ui.taglib.xml
Sending jsf-ri/conf/share/ui.tld
Transmitting file data ..
Committed revision 14464.





[JAVASERVERFACES_SPEC_PUBLIC-1095] Add "rendered" attribute description to "repeat" and "fragment" tag definition in "ui.taglib.xml". Created: 03/May/12  Updated: 24/Aug/15  Resolved: 24/Aug/15

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Duplicate
duplicates JAVASERVERFACES-2406 Add "rendered" attribute description ... Closed

 Description   

Add "rendered" attribute description to "repeat" and "fragment" tag definition in "ui.taglib.xml".

Sample file attached...



 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 Manfred Riem [ 24/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1095, Add "rendered" attribute description to "repeat" and "fragment" tag definition in "ui.taglib.xml"."
Sending jsf-ri/conf/share/ui.taglib.xml
Transmitting file data .
Committed revision 15041.





[JAVASERVERFACES_SPEC_PUBLIC-1081] Missing API docs for javax.faces.validator.DoubleRangeValidator methods Created: 07/Mar/12  Updated: 16/Sep/14  Resolved: 16/Sep/14

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2341 Missing API docs for javax.faces.vali... Closed

 Description   

The following two methods over ride the default functionality but do not explain why.

DoubleRangeValidator.equals()
DoubleRangeValidator.hashcode()



 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 Manfred Riem [ 16/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1081, Missing API docs for javax.faces.validator.DoubleRangeValidator methods"
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/package.html
Transmitting file data ..
Committed revision 13687.





[JAVASERVERFACES_SPEC_PUBLIC-1053] VDL Docs Need Clarification for f:view afterPhase Attribute Created: 23/Nov/11  Updated: 16/Dec/14  Resolved: 05/Sep/14

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

Type: Bug Priority: Critical
Reporter: rogerk Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 30 minutes
Time Spent: 0 minutes
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVASERVERFACES-3419 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Description   

The VDL docs state this for f:view afterPhase :

"MethodBinding pointing to a method that takes a javax.faces.event.PhaseEvent and returns void. This method will be called after every phase except for restore view."

This should be clarified to:

"MethodBinding pointing to a method that takes a javax.faces.event.PhaseEvent and returns void. This method will be called after every phase except for restore view on an initial request."



 Comments   
Comment by rogerk [ 23/Nov/11 ]

Fix Version

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-1049] UIColumn and PreValidate / PostValidate events Created: 07/Nov/11  Updated: 24/Aug/15  Resolved: 18/Sep/14

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

Type: Bug Priority: Critical
Reporter: jperealc_isban Assignee: Manfred Riem
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-1027 Pre/PostValidateEvent publishing cond... Resolved
Tags: PostValidate, PreValidate, UIColumn, UIData, processValidators, spec

 Description   

Javadoc of PreValidateEvent / PostValidateEvent:
Components with children must publish this event before/after processing their child nodes in UIComponent.processValidators(javax.faces.context.FacesContext). This is especially important for iterating components such as UIData, and form components, such as UIForm.

UIColumn is a component with children, so it must publish PreValidate/PostValidate events as the javadoc of those events specifies.

But javadoc for UIData's processValidators() method, explicitly skips the processing of UIColumn components, and only specifies processing of its facets and children.

This is incoherent.



 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 Manfred Riem [ 18/Sep/14 ]

Closing as a duplicate of JAVASERVERFACES_SPEC_PUBLIC-1027





[JAVASERVERFACES_SPEC_PUBLIC-1044] inaccuracy in API doc of javax.faces.application.StateManager Created: 26/Oct/11  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

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

Attachments: Text File changebundle.txt    

 Description   

doc of isSavingStateInClient() reads "if and only if ..."
but should be "if and only if ... and case doesn't matter" or something similar,
because fixing issue 1010 removes case



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

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

Comment by Manfred Riem [ 17/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1044, clarify isSavingStateInClient constant comparison is done case insensitive."
Sending jsf-api/src/main/java/javax/faces/application/StateManager.java
Transmitting file data .
Committed revision 13691.





[JAVASERVERFACES_SPEC_PUBLIC-1027] Pre/PostValidateEvent publishing conditions fixed but not documented Created: 28/Jul/11  Updated: 18/Sep/14  Resolved: 17/Sep/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1, 2.0 Rev a
Fix Version/s: 2.3

Type: Bug Priority: Critical
Reporter: lu4242 Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1049 UIColumn and PreValidate / PostValida... Closed

 Description   

JSF 2.0 spec Section 3.2.7.3 says this:

"... The PreValidateEvent is published immediately before the component gets validated. PostValidate is published after validation has occurred, regardless if the validation was successful or not. If the validation for the component did pass successfully, and the previous value of this component differs from the current value, the ValueChangeEvent is published. ..."

This is ok. A mail was sent long time ago to notify the change:

[jsr-314-open] [537-PrePostValidate] RESOLVED (was: Re: [2.1 Spec Review] Pre/PostValidateEvent publishing conditions)

DG> The only reason I can think of is that UIData is also (potentially,
DG> anyway) a container of inputs. But so are panels, and they,
DG> evidently, are excluded. Why?

EB> No, it does not mean that only those components will deliver those
EB> events. It means that in the case of components who are iterating
EB> components, the event must be published before, or after, the child
EB> component processing. This is true for any components that have
EB> children. I will revise the documentation to be as follows.
EB>
EB> PostValidateEvent
EB>
EB> Components with children must publish this event after processing their
EB> child nodes in processValidators. This is especially important for
EB> iterating components such as UIData and form components, such as UIForm.
EB>
EB> PreValidateEvent
EB>
EB> Components with children must publish this before after processing their
EB> child nodes in processValidators. This is especially important for
EB> iterating components such as UIData and form components, such as UIForm.

The problem is the javadoc of UIComponent.processValidators() and other related methods (UIData, UIForm ...) should describe this change, to match the current behavior.



 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 Manfred Riem [ 17/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1027, added @see for Pre/PostValidateEvent"
Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Sending jsf-api/src/main/java/javax/faces/component/UIData.java
Sending jsf-api/src/main/java/javax/faces/component/UIForm.java
Transmitting file data ...
Committed revision 13693.





[JAVASERVERFACES_SPEC_PUBLIC-1025] Documentation of TagAttribute#getBoolean references Boolean.getBoolean instead of Boolean.parseBoolean Created: 18/Jul/11  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

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

Attachments: Text File changebundle.txt    

 Description   

The documentation at

http://download.oracle.com/javaee/6/api/javax/faces/view/facelets/TagAttribute.html#getBoolean(javax.faces.view.facelets.FaceletContext)

and

http://javaserverfaces.java.net/nonav/docs/2.1/javadocs/javax/faces/view/facelets/TagAttribute.html#getBoolean(javax.faces.view.facelets.FaceletContext)

says:

If literal, return Boolean.getBoolean(java.lang.String) passing our value, otherwise call getObject(FaceletContext, Class).

Since Boolean.getBoolean returns the value of a system property with the given name, the wanted behaviour is probably Boolean.parseBoolean. I did not check whether this is just a documentation issue or if this problem exists also in the code.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 17/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1025, change API doc to reflect usage of Boolean.valueOf"
Sending jsf-api/src/main/java/javax/faces/view/facelets/TagAttribute.java
Sending jsf-api/src/main/java/javax/faces/view/facelets/package.html
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/TagAttributeImpl.java
Transmitting file data ...
Committed revision 13692.





[JAVASERVERFACES_SPEC_PUBLIC-964] ExternalContext.get/setSessionMaxInactiveInterval documentation mention HttpServletRequest, but it should be HttpSession Created: 01/Apr/11  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

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

Attachments: Text File changebundle.txt    
Status Whiteboard:

size_small importance_medium


 Description   

The documentation of ExternalContext.getSessionMaxInactiveInterval says this:

"... Returns the maximum time interval, in seconds, that the servlet container will keep this session open between client accesses. After this interval, the servlet container will invalidate the session. The maximum time interval can be set with the setSessionMaxInactiveInterval(int) method.

A return value of zero or less indicates that the session will never timeout.

Servlet: This must return the result of calling getMaxInactiveInterval on the underlying javax.servlet.http.HttpServletRequest instance.

The default implementation throws UnsupportedOperationException and is provided for the sole purpose of not breaking existing applications that extend this class. ..."

I checked if HttpServletRequest has getMaxInactiveInterval method but the class with that method is HttpSession.

I suppose it is a bug on the javadoc.



 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 [ 17/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-964, make sure it correctly states HttpSession."
Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java
Transmitting file data .
Committed revision 13690.





[JAVASERVERFACES_SPEC_PUBLIC-955] misleading javadoc in Converter.getAsObject() Created: 01/Apr/11  Updated: 19/Aug/14  Resolved: 19/Aug/14

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

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

Issue Links:
Dependency
depends on JAVASERVERFACES-3373 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Status Whiteboard:

size_small importance_small


 Description   

The javadoc in Converter.getAsObject() says that this method is called to convert into a model object to be stored into the UIComponent during the !!! APPLY_REQUEST_VALUES !!! phase.

In apply-request-values phase only the submitted value is set on the UIComponent - Converter.getAsObject() is normally called during process-validation phase.



 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-936] Set FACELETS_REFRESH_PERIOD to -1 if project stage is Production Created: 31/Jan/11  Updated: 24/Feb/15  Resolved: 24/Feb/15

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3787 Set FACELETS_REFRESH_PERIOD to -1 if ... Closed
Status Whiteboard:

size_small importance_small


 Description   

In most common cases there not need to reload Facelet from .xhtml in production
environment. Currently FACELETS_REFRESH_PERIOD has value 2 (if it is not set
explicitly) even in production - for simplification of configuration managenent
it should be set to -1 like:

if (refreshParam == null && stage == production)
refreshPeriod = -1
else
refreshPeriod = refreshParam



 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-923] ui:define name attribute document/behavior inconsistent Created: 27/Jan/11  Updated: 16/Sep/14  Resolved: 16/Sep/14

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

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

Attachments: Text File changebundle.txt    
Status Whiteboard:

size_medium importance_medium


 Description   

The PDL doc for ui:define:

http://javaserverfaces.java.net/nonav/docs/2.0/pdldocs/facelets/ui/define.html

Indicates that the "name" attribute can be specified as a value expression.

However, the implementation says otherwise:

TagAttribute attr = this.getRequiredAttribute("name");
if (!attr.isLiteral())

{ throw new TagAttributeException(this.tag, attr, "Must be Literal"); }

The same isLiteral() check is performed in:

  • Mojarra 2.x
  • MyFaces 2.x
  • Facelets 1.x.

Based on this I believe that the pdl doc is incorrect, so logging as a spec issue rather than implementation issues.



 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 Manfred Riem [ 16/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-923, ui:define name attribute document/behavior inconsistent"
Sending jsf-ri/conf/share/ui.tld
Transmitting file data .
Committed revision 13688.





[JAVASERVERFACES_SPEC_PUBLIC-892] ui:repeat requires document "begin" and "end" properties Created: 12/Oct/10  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Bug Priority: Critical
Reporter: lu4242 Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt    
Issuezilla Id: 892
Status Whiteboard:

size_small importance_medium


 Description   

It was notice that ui:repeat implementation has "begin" and "end" properties,
but there are not mentioned in the javadoc.

After talk with Martin Marinschek, the conclusion was this is an undocumented
feature, but it is provided by Mojarra.



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

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 [ 17/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-892, added documentation about begin and end attributes."
Sending jsf-ri/conf/share/ui.taglib.xml
Sending jsf-ri/conf/share/ui.tld
Transmitting file data ..
Committed revision 13694.





[JAVASERVERFACES_SPEC_PUBLIC-891] converter and validator attributes TLD doc misleading Created: 07/Oct/10  Updated: 16/Sep/14  Resolved: 05/Sep/14

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

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

Operating System: All
Platform: All


Attachments: Text File changebundle.txt    
Issue Links:
Blocks
is blocked by JAVASERVERFACES-3418 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Cloners
is cloned by JAVASERVERFACES_SPEC_PUBLIC-1307 validator attributes TLD doc misleading Resolved
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1239 HTML_BASIC components converter attri... Resolved
Issuezilla Id: 891
Status Whiteboard:

size_small importance_medium


 Description   

UIOutput converter attribute allows assigning a literal to specify the
converterId of the converter to be used or a ValueExpression evaluating to an
instance of Converter.
TLD doc only mentions the ValueExpression as allowed type and also the
Description does not mention the possibility to pass the converterId.

The same is missing for validator attributes on input components - TLD doc only
mentions teh MethodExpression but says nothing about the literal validatorId
that can be used too.



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

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 Manfred Riem [ 05/Sep/14 ]

This issue will take care of the converter attributes. Issue #1307 will take care of the validator attributes.





[JAVASERVERFACES_SPEC_PUBLIC-882] Specification talks about non existing APIs Created: 09/Sep/10  Updated: 23/Jan/15  Resolved: 23/Jan/15

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

Type: Bug Priority: Critical
Reporter: mwessendorf Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 882
Status Whiteboard:

size_small importance_medium


 Description   

I opened this version of the spec:

Version: 2.0 Rev A
Status: Final Release
Release: 9 July 2010

It talks about FacesContext.isPartialRequest() - Note this method does not
exist. A similar is available on PartialViewContext.

Also it talks about FacesContext.isAjaxRequest() AND
PartialViewContext.isAjaxRequest() - Note: the first one does not exist as well



 Comments   
Comment by mwessendorf [ 09/Sep/10 ]

Also from reading the PartialViewContext JAvaDoc it is not clear (to me) what
the main difference is between the two.

Comment by rogerk [ 27/Oct/10 ]

triage - partially fixed

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 [ 23/Jan/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-882, Specification talks about non existing APIs"
Sending spec/frame/ajaxIntegration.fm
Sending spec/frame/requestProcessingLifecycle.fm
Transmitting file data ..
Committed revision 1158.





[JAVASERVERFACES_SPEC_PUBLIC-821] ExternalContext.getRealPath() on startup and shutdown Created: 21/Jun/10  Updated: 25/Feb/15  Resolved: 25/Feb/15

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

Type: Bug Priority: Critical
Reporter: Jakob Korherr Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Blocks
is blocked by JAVASERVERFACES-3794 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1009 Make it so ExternalContext.getRealPat... Closed
Issuezilla Id: 821
Status Whiteboard:

size_small importance_large


 Description   

Looking at the methods which are valid to be called on application startup or
shutdown on ExternalContext, it seems like it was forgotten to include
getRealPath(String path), because all methods which are valid to be called only
rely on the ServletContext and this one also only relies on the ServletContext
(or on the PortletContext in a Portlet environment).

However since the behavior of all methods which are not documented as "valid to
call this method during application startup or shutdown" is undefined, it is
valid to implement this method also for startup and shutdown in JSF 2.0, but it
should be added in the spec javadoc that this one must be available for startup
and shutdown.



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

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

2.1

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-819] add "disabled" attribute for h:button Created: 11/Jun/10  Updated: 29/Jan/15  Resolved: 29/Jan/15

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

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

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issuezilla Id: 819
Status Whiteboard:

size_small importance_small


 Description   

From issue 714:

  • VDLDocs for h:button don't mention a disabled attribute, but the h:link one does have the disabled
    attribute. My guess would be that both should have this attribute?


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

assign to sheetal

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Comment by Manfred Riem [ 29/Jan/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-819, add "disabled" attribute for h:button"
Sending jsf-api/build.xml
Adding jsf-api/doc/outcometargetbutton-props.xml
Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-api/doc/standard-html-renderkit.xml
Sending jsf-ri/build.xml
Sending jsf-ri/conf/share/html_basic.taglib.xml
Transmitting file data ......
Committed revision 14272.





[JAVASERVERFACES_SPEC_PUBLIC-778] Add documentation about the dynamically added h:messages component Created: 26/Mar/10  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Task Priority: Critical
Reporter: Jakob Korherr Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Text File diffs.txt    
Issuezilla Id: 778
Status Whiteboard:

size_small importance_small


 Description   

Apparently it is a JSF 2.0 spec requirement to automatically add a h:messages
component to a view when the ProjectStage is Development (see [1] and [2] and
the related MyFaces issue [3]).

However I couldn't find this in the spec-pdf or the javadocs, so this has to be
added somewhere!

[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=314
[2] http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2
[3] https://issues.apache.org/jira/browse/MYFACES-2624



 Comments   
Comment by Ed Burns [ 17/May/10 ]

Move to 2.1. About to attach patch.

Comment by Ed Burns [ 17/May/10 ]

Created an attachment (id=233)
Fix for this bug, first iteration.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

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 [ 17/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-778, add information about automatically adding h:messages (when missing) when running in ProjectStage.Development"
Sending jsf-ri/conf/share/html_basic.taglib.xml
Transmitting file data .
Committed revision 13689.





[JAVASERVERFACES_SPEC_PUBLIC-686] Missing public constant for INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL Created: 02/Dec/09  Updated: 12/Jan/15  Resolved: 12/Jan/15

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

Type: Bug Priority: Critical
Reporter: Ryan Lubke Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Blocks
is blocked by JAVASERVERFACES-3681 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Issuezilla Id: 686
Status Whiteboard:

cat1 javadoc size_small importance_medium


 Description   

The UIInput has a public constant for this context parameter:
"javax.faces.VALIDATE_EMPTY_FIELDS"

But the one for "javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL"
has been forgotten...



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 ]

Even though this is a trivial change, because it modifies the signature, we must
move it to 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

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-677] Document more clearly the automatic UIPanel behavior for f:facet (was: f:facet can have more than one child) Created: 01/Dec/09  Updated: 24/Aug/15  Resolved: 24/Aug/15

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

Type: Task Priority: Critical
Reporter: Jakob Korherr Assignee: Manfred Riem
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt    
Issuezilla Id: 677
Status Whiteboard:

cat2 vdldoc size_small importance_small


 Description   

Testing mojarra we found out that <f:facet> now can have more than one children,
which will automatically be put in a UIPanel.

However, the spec never mentions that fact.



 Comments   
Comment by mojavelinux [ 18/Dec/09 ]

Update milestone to 2.0 Rev a

This actually became a requirement to support <f:metadata>, so the rule is
loosely implied in that section.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 04/Mar/10 ]
      • Issue 522 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 22/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by Ed Burns [ 30/Jun/10 ]

I did some more research on this, digging into the JSF 1.0 (JSR-127) archive. Here's what I found:

On Wed, 13 Nov 2002, Craig McClanahan wrote:

CM> However, I believe the APIs would be simpler if we actually required
CM> the value pointed at by a "named child" name to be, in fact, a
CM> single component. In the cases where you really would like to use a
CM> collection, it's straightforward to use something like a UIPanel
CM> with arbitrarily nested contents – my "Grid" and "List" renderers
CM> in jsf-pseudo follow this sort of design pattern.

CM> Therefore, I'm proposing that, in the map of "named child" nodes,
CM> the key must be specified (and unique within parent), and the value
CM> must be a single UIComponent. If we decide that the "named list"
CM> notion is also useful, we can relax the latter constraint.

On Fri, 15 Nov 2002 Adam Winer wrote:

AW> The most common use case is that each name/role has either
AW> zero or one corresponding component.

AW> There's an open question of whether it's worth the added complexity
AW> to support a List of components per name/role, but I've not found this
AW> to be especially helpful.

I'm reluctant to change this beyond more clearly documenting the behavior of Mojarra to automatically
fabricate a UIPanel in the case of multiple children within a UIPanel.

Jacob, is this OK? If so, I'd like to change the Summary to:

Document more clearly the automatic UIPanel behavior for f:facet.

Comment by Jakob Korherr [ 02/Jul/10 ]

Yes, of course this is OK for me!

It would just be great to have some documentation about this new feature. For
example one question that would really be necessary to answer is: is this
behavior only supported on facelets or also on JSP?

Thanks!

Comment by Ed Burns [ 02/Aug/10 ]

fix summary as described

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by paul_dijou [ 13/Jun/12 ]

I was going to post a similar issue but I just found this one. I agree that the spec and Mojarra are not synchronized on that point.

Any news about the status of this issue? Will the spec be reviewed to allow several child inside a facet and wrap them automatically inside a javax.faces.component.UIPanel ?

Regards

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 Manfred Riem [ 24/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-677, Document more clearly the automatic UIPanel behavior for f:facet (was: f:facet can have more than one child)"
Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
Transmitting file data .
Committed revision 15040.





[JAVASERVERFACES_SPEC_PUBLIC-633] 'hidden' attribute from composite:attribute missing from VDL docs. Created: 21/Sep/09  Updated: 08/Sep/14  Resolved: 08/Sep/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Bug Priority: Critical
Reporter: Ryan Lubke Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File 633-patch.txt    
Issue Links:
Blocks
is blocked by JAVASERVERFACES-3422 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Issuezilla Id: 633
Status Whiteboard:

cat2 vdldoc size_small importance_large


 Description   

Implementation includes a hidden attribute within the AttributeHandler, but the
VDL docs for composite:attribute makes no mention of it (it's truly hidden).



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 24/Feb/10 ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

vdldoc

Comment by Ed Burns [ 09/May/10 ]

take ownership

Comment by Ed Burns [ 09/May/10 ]

Created an attachment (id=231)
Fix for this bug, first iteration

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 18/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-527] Support @Inject for FacesContext Created: 23/Feb/09  Updated: 17/Oct/14  Resolved: 09/Oct/14

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

Type: New Feature Priority: Critical
Reporter: agoncal Assignee: Manfred Riem
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open
is blocked by JAVASERVERFACES-3416 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1305 Since FacesContext is @Injectable, it... Closed
Issuezilla Id: 527
Status Whiteboard:

cat2 frame size_small importance_large


 Description   

To get the FacesContext in a managed bean you need to do as follow :

FacesContext ctx = FacesContext.getCurrentInstance();

It would be nice to get this context injected such as :

@Resource
private FacesContext ctx;

That's the way EJBs and other components handle their context.



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

Comment by Ed Burns [ 24/Feb/10 ]

By the way, for managed beans you currently can get this injected. Like this:

@ManagedProperty(value="#

{facesContext}

")
private FacesContext facesContext;

@ManagedProperty(value="#

{requestScope}

")
private Map<String, Object> requestMap;

@ManagedProperty(value="#

{sessionScope}

")
private Map<String, Object> sessionMap;

Granted this is only for Managed Beans. I think the real issue is: How to
leverage injection to minimize the occurrence of painful code such as
FacesContext.getCurrentInstance().getExternalContext().getFlash().get("foo")

I have updated the subject.

Comment by rogerk [ 05/Mar/10 ]

cat2 - if we are to incorporate alternate approach as well

Comment by Ed Burns [ 22/Mar/10 ]

from

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-473] FacesEvent should have a convenience getFacesContext() method. Created: 23/Sep/08  Updated: 03/Sep/14  Resolved: 03/Sep/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

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

Operating System: All
Platform: All


Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-807 Need to pass FacesContext instance to... Open
is related to JAVASERVERFACES-3413 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Issuezilla Id: 473
Status Whiteboard:

EGEasy5 effort_easy cat2 javadoc sig size_small importance_small


 Description   

FacesEvent should have a convenience getFacesContext() method. This is very
useful for event listeners.

I'm not sure, but SystemEvent could probably use this method too.



 Comments   
Comment by Ed Burns [ 23/Sep/08 ]

EGEasy5 effort_easy edburns

Comment by Ed Burns [ 15/Oct/08 ]

Change target milestone to 2.0

Comment by Ed Burns [ 10/Aug/09 ]

This didn't make it.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 27/Apr/10 ]

sig change

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage - api

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 Ed Burns [ 03/Sep/14 ]

Comments on the changebundle attached to JAVASERVERFACES-3413

  • Make sure to update the package.html for all impacted packages with changed_modified_2_3.
  • Make sure to use "first modification" attribution in all class javadoc for all modified classes.
  • Use changed_removed_2_3 when you would have used @deprecated.

Otherwise r=edburns.





Generated at Tue Sep 01 19:56:06 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.