[JAVASERVERFACES_SPEC_PUBLIC-1287] Make @javax.faces.bean.ManagedBean mean the same thing as @javax.inject.Named Created: 26/Jun/14  Updated: 15/Jan/15  Resolved: 15/Jan/15

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Managed Beans
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Blocker
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1311 Let CDI handle #{facesContext} EL res... Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open

 Description   

The JSF 2.2 spec for the package javax.faces.bean states:

The annotations in this package may be deprecated in a future version of this specification because they duplicate functionality provided by other specifications included in JavaEE. When possible, the corresponding annotations from the appropriate Java EE specification should be used in preference to these annotations.

Rather than deprecate, this issue suggests we re-purpose this package to just be equivalent to the equivalent items in CDI and JSR-330.



 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 Blocker

Comment by Manfred Riem [ 15/Jan/15 ]

Instead of doing this we have decided it is better to make tighter CDI support an opt-in for JSF 2.3. So we are not going to retrofit to make it work in CDI.





[JAVASERVERFACES_SPEC_PUBLIC-913] Unlabeled Navigation in HTML_BASIC RenderKit Docs Created: 30/Nov/10  Updated: 18/Sep/14  Resolved: 18/Sep/14

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

Type: Bug Priority: Critical
Reporter: rogerk Assignee: Manfred Riem
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_small


 Description   

The navigation left-hand frame does not label the values as "family" and "renderer type". Some kind of label is needed so that the reader understands that the documentation is organized as a breakdown of Renderers which are denotes not only by a string value called a Renderer Type but another string value called a Component Family. It is difficult enough to figure out what the purpose of component family is and conceptualize a use case. Also, for one new to JSF it is not intuitive what this documentation should be used for. The newbie JSF developer is going to be focused on JSF tags and that is not what is covered by these docs per se. Per the Faces config schema a renderer is denoted by a renderer type, component family and an implementation class. I do not see a a correlation to this in the docs. If one clicks on a particular rendered link, there is nothing on the page which even mentioned the name of the renderer. This documentation set, which is really cool that its auto-generated, and probably accurate and detailed, is not providing the value that is needed for the developer. If the automated tempaltes/tools can be changed to fix some of the labeling problems and if a human can write an overview page which comes up first I think it would remedy the issue.
matthew.stevens@sun.com 2004-02-16



 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 Ed Burns [ 18/Sep/14 ]

Manfred suggested marking this as WONTFIX on IRC.

I agree.





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

 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-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-1049] UIColumn and PreValidate / PostValidate events Created: 07/Nov/11  Updated: 18/Sep/14  Resolved: 18/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: 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-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-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-1241] web-facesconfig_2_2.xsd is missing definition for client-window-factory element Created: 09/Dec/13  Updated: 08/Sep/14  Resolved: 08/Sep/14

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

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-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-1213] f:viewParam doesn't work when using xmlns:f="http://xmlns.jcp.org/jsf/core" Created: 06/Aug/13  Updated: 03/Sep/14  Resolved: 03/Sep/14

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

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

JavaEE 7 maven web application with JSF 2.2
GlassFish Server Open Source Edition 4.0 (build 89)


Issue Links:
Duplicate
duplicates JAVASERVERFACES-2868 f:viewParam and f:viewAction not work... Closed
is duplicated by JAVAEETUTORIAL-238 NullPoint error in chapter 8.5 Compo... Closed

 Description   

Given

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

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

myBean.id will never be populated. However, changing the xmlns to the following fixes it:

      xmlns:f="http://java.sun.com/jsf/core"

Glassfish 4 should support the new xmlns for an EE7 project (JSF version 2.2).



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





[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-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... Resolved
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-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-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-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-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-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... Resolved
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-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-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-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-941] reduce number of times rendered attribute value expression is evaluated Created: 31/Jan/11  Updated: 26/Jan/15  Resolved: 26/Jan/15

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

Type: Bug Priority: Critical
Reporter: rogerk Assignee: Manfred Riem
Resolution: Won't Fix Votes: 15
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Status Whiteboard:

size_medium importance_medium


 Description   

The rendered attribute is an Achilles heal of JSF performance. JSF abuses the
value expression used in rendered attributes. It's expected that the value
expression is going to be resolved more than once on a request because by nature
it is a pass-through construct and because the value it is representing is
likely contextual (meaning it can change as the application changes). However,
in the case of the render attribute, it's a little bit out of control. Any
getter method bound to a rendered attribute is being called way too many times.
This could easily be solved by being more frugal about when it is consulted.

For example, the rendered value expression is resolved in encodeChildren,
encodeBegin (or encodeParentAndChildren) and again at encodeEnd of most
components. We should state that when a component is first addressed during
encoding (perhaps in encodeBegin) that is when the rendered attribute should be
evaluated. Then the resolved value simply cannot change again in that phase.
(The exception would be a row in UIData, which the rendered attribute would need
to be resolved once per component per row).

We should also consider having encodeAll check the rendered attribute and not
encodeBegin. Or, we could keep the current contract the same but deprecate
encodeBegin, encodeChildren, encodeEnd and getRendersChildren so that most
people start using encodeAll instead so that isRendered gets called only once
per component per render phase execution.



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

Set fixVersion to 2.3. I think this may be better handled by having a way to advise the EL to start caching expression evaluations for the current thread and have a way to turn off that caching at the end of the JSF lifecycle.

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

As per EG discussion I am closing this as "Won't fix".





[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-523] Make the name of 'javax.faces.ViewState' configurable Created: 09/Feb/09  Updated: 25/Feb/15  Resolved: 12/Jan/15

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

Type: Improvement Priority: Critical
Reporter: kennardconsulting Assignee: Manfred Riem
Resolution: Won't Fix Votes: 0
Labels: 2_3_wont_fix
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 523
Status Whiteboard:

cat2 frame size_large importance_large


 Description   

A recommended security practice is to reveal as little information about a
system's architecture as possible. We do this by, say, suppressing HTTP headers
that give away server information and mapping *.jsf to something less obvious
(such as *.web). This is quite effective in stopping hackers even knowing we
are a Java-based application.

The one giveaway is the id of the ViewState field. This
is 'javax.faces.ViewState'. The ViewState itself is encrypted (so could easily
be a, for example, ASP.NET ViewState) but the name is obvious.

It appears the name 'javax.faces.ViewState' is mandated by the spec? If it were
configurable, it would be much harder for an attacker to know which platform
the app was running on.



 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 rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

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 rogerk [ 29/Jun/10 ]

This is actually a fairly large change - considering all the place where we may
reference javax.faces.ViewState

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 12/Jan/15 ]

Closing this as "Won't Fix" as it is not worth the effort as illustrated by the discussion on the EG mailing list, see https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2015-01/message/14





[JAVASERVERFACES_SPEC_PUBLIC-1243] Use bean-like name as converter-id when @FacesConverter "value" attribute is omitted Created: 19/Dec/13  Updated: 25/Feb/15  Resolved: 23/Jan/15

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

Type: New Feature Priority: Critical
Reporter: kithouna Assignee: Manfred Riem
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 2_3_wontfix

 Description   

The JavaDoc of @FacesValidator's "value" attribute states:

If no value is specified, or the value is null, the value is taken to be the return of calling getSimpleName on the class to which this annotation is attached and lowercasing the first character.

It would be nice to have this feature for @FacesConverter as well.

See also JAVASERVERFACES_SPEC_PUBLIC-703



 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 ]

While on the surface it looks possible to do this change, in reality it is not. The specification currently specifies that if the value attribute is omitted the forClass attribute is taken for registration. This allows you to register a Converter for the Object.class type.

Or in other words, the requested change is not possible because the FacesConverter forClass attribute defaults to Object.class which means if you currently annotate a converter with just @FacesConverter it already has a meaning as illustrated below.

@FacesConverter => @FacesConverter(forClass = Object.class)

So I am closing this as "Won't fix"





[JAVASERVERFACES_SPEC_PUBLIC-1305] Since FacesContext is @Injectable, it should also be Serializable. Created: 05/Sep/14  Updated: 25/Feb/15  Resolved: 12/Jan/15

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

Type: Improvement Priority: Critical
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Works as designed Votes: 1
Labels: 2_3_works_as_designed
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-527 Support @Inject for FacesContext Resolved

 Description   

JAVASERVERFACES_SPEC_PUBLIC-527 makes FacesContext @Injectable into @RequestScoped beans only. This feature is best implemented by making FacesContext itself Serializable. This issue requires us to closely examine the consequences of such a change.



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

The FacesContext itself does not need to be Serializable as the FacesContextProducer is what produces the reference to the FacesContext and as such it should be Serializable, but FacesContext does not have to be.

Closing this as "Works as designed"





[JAVASERVERFACES_SPEC_PUBLIC-1037] UIComponent.getFamily() not clearly specified Created: 30/Sep/11  Updated: 25/Feb/15  Resolved: 08/Sep/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.1 Rev a
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: c.beikov Assignee: Manfred Riem
Resolution: Works as designed Votes: 2
Labels: 2_3_works_as_designed
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The method getFamily() is not clearly specified on wether it is possible to return null as value or not.



 Comments   
Comment by balusc [ 30/Sep/11 ]

Background: http://stackoverflow.com/questions/7610067/may-uicomponentgetfamily-return-null-or-not

Comment by arjan tijms [ 02/Oct/11 ]

Slightly related, what about making specifying the family optional?

If the spec would allow null, and null would mean no or a default family, then the currently abstract UIComponent#getFamily(); could be given a default implementation, could it?

Comment by c.beikov [ 02/Oct/11 ]

This would probably do the job!

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

On the question is it allowed to return null from getFamily:

The Javadoc states "Return the identifier of the component family to which this component belongs." While it does not specifically say null is not supported it is clear from the semantic meaning of the word identifier.

On the question of the getFamily() default:

If you want to use the default component family to be selected make the getFamily method return "HTML_BASIC"

Closing this as works as designed.





[JAVASERVERFACES_SPEC_PUBLIC-1057] VDL Docs Need Correction/Clarification Created: 01/Dec/11  Updated: 25/Feb/15  Resolved: 23/Jan/15

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

Type: Bug Priority: Critical
Reporter: rogerk Assignee: Manfred Riem
Resolution: Incomplete Votes: 0
Labels: 2_3_incomplete
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 23/Jan/15 ]

No actual statement of work here. Closing it as "Incomplete"





[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-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... Resolved
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-1319] Expose Faces Flows for use from MVC Created: 13/Oct/14  Updated: 25/Feb/15  Resolved: 25/Feb/15

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

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


 Description   

This issue covers whatever changes to the spec are necessary to use the Faces Flows feature in JSF 2.2 from MVC.



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

MVC 1.0 is not going to support Flow scope





[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-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-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... Resolved
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-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-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-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-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-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-1344] Move 2.3 CDI producers out of API packages Created: 05/Jan/15  Updated: 05/Jan/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: 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:
Dependency
depends on JAVASERVERFACES-3668 Move 2.3 CDI producers out of API pac... Closed




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

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

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

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

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

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

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

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

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

 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-441] Subforms Created: 21/Aug/08  Updated: 25/Feb/15  Resolved: 25/Feb/15

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

Type: Bug Priority: Major
Reporter: mwessendorf Assignee: Unassigned
Resolution: Won't Fix Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 441
Status Whiteboard:

EGTop5 cat2 size_medium importance_medium draft

Tags: 2_3_wontfix

 Description   

For some reason several JSF libs provide a subform component:
-Trinidad
-Tomahawk
-Tobago
-ADF Faces
...

Why not making this component standard ?
Also, don't forget the required interface (see issue # 322)



 Comments   
Comment by Ed Burns [ 09/Sep/08 ]

EGTop5

Comment by Ed Burns [ 15/Oct/08 ]

Change target milestone to 2.0

Comment by Ed Burns [ 04/Aug/09 ]

Pushing out to 2.1

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 kito75 [ 24/Feb/10 ]

Changed subcomponent to Components/Renderers.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1212] javax.faces.context.ExternalContext#getInitParameter : NullPointerException Restriction Needs To Be Removed. Created: 02/Aug/13  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.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rogerk Assignee: rogerk
Resolution: Invalid Votes: 0
Labels: 2_3_invalid
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Background: https://java.net/jira/browse/JAVASERVERFACES-2979
Since the ServletContext returns null of the parameter is not found, I believe the javadocs need to be changed to remove the NullPointerException restriction.



 Comments   
Comment by Ed Burns [ 02/Oct/13 ]

We're going to keep the spec unchanged and fix the impl.





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

 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-1099] Resolve views by convention from dedicated faces-views directory Created: 12/May/12  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: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1359 Resolve views from dedicated folder In Progress

 Description   

In JSF 2.1 the FacesServlet is by default mapped to the following URL patterns:

  • /faces/*
  • *.jsf
  • *.faces

The Facelets VDL will by default try to resolve a corresponding view in the root of the web application; a file with the same path and name as the wildcard in the URL pattern, but with the .xhtml suffix.

In addition to this mechanism, I would like to propose introducing a dedicated directory where (Facelets) views are resolved. By convention, the existence of this directory in a web application will cause the FacesServlet to be mapped, and will cause it to be mapped to those views that are present in that directory (with subdirectories mapped to paths).

Just like implicit navigation supports letting the user specify destination views with or without suffix, so could this automatic mapping support URL patterns with or without a suffix, thereby introducing a simple and lightweight pretty URL facility to the platform. Simultaneously, users putting their view files in this directory are automatically protected from the source-code expose vulnerability that exists now when using Facelets (see JAVASERVERFACES_SPEC_PUBLIC-1015).

Example:

WebContent
    WEB-INF
        faces-views
            foo.xhtml
            promotion
                 register.xhtml

Assuming the web app containing this is deployed with / as its context root:

Valid request URLs:

  • localhost:8080/foo
  • localhost:8080/foo.xhtml
  • localhost:8080/promotion/register
  • etc

Note that there is no web.xml used in this example, and that one should not be necessary.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by Ed Burns [ 25/Feb/15 ]

Agreed on IRC ##jsf that this is covered better under JAVASERVERFACES_SPEC_PUBLIC-1359.





[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... Resolved
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-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... Resolved
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-1312] FacesContext retrieve ValidatorFactory Created: 17/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

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

Tags: ValidatorFactory, jsr-303, validator

 Description   

JSF validation phase does not includes class-level constraints and so they must be validated within action method.

Create method in FacesContext to retrieve ValidatorFactory or ValidatorFactory.getValidator() based on BeanValidator.validate(...) logic.

/**

  • Retrieves the ValidatorFactory from the given context
  • @param context FacesContext
  • @return {@link ValidatorFactory}

    */
    public static ValidatorFactory getValidatorFactory(final FacesContext context)
    {
    final Object cachedObject = context.getExternalContext().getApplicationMap()
    .get(BeanValidator.VALIDATOR_FACTORY_KEY);

ValidatorFactory validatorFactory;

if (cachedObject instanceof ValidatorFactory)
validatorFactory = (ValidatorFactory) cachedObject;
else
try

{ validatorFactory = Validation.buildDefaultValidatorFactory(); context.getExternalContext().getApplicationMap() .put(BeanValidator.VALIDATOR_FACTORY_KEY, validatorFactory); }

catch (final ValidationException e)

{ throw new FacesException("Could not build a default Bean Validator factory", e); }

return validatorFactory;
}



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

What you are asking for is already part of of the specification, please see the JSF 2.2 spec PDF, section 3.5.6.2 Obtaining a ValidatorFactory.

Closing this issue as "Invalid". If you think that is not correct please let me know.





[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-1343] EL enable flow start-node element Created: 17/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

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

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES-3603 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed

 Description   

Currently when defining a flow the start node must be hard coded as a literal string. It would be nice to allow this come from EL.



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

The builder API must be enabled for this feature as well. Consider adding to FlowBuilder the following.

public FlowBuilder startNodeId(String nodeIdOrELExpression);
public FlowBuilder startNodeId(ValueExpression nodeIdELExpression);
Comment by Ed Burns [ 18/Dec/14 ]

We should also allow EL in

<flow-call>
<flow-reference>
  <flow-document-id>#{foo.bar}</flow-document-id>
  <flow-id>#{foo.bar}</flow-id>
</flow-reference>
</flow-call>

and the corresponding builder API

class abstract FlowCallBuilder implements NodeBuilder {
  public abstract FlowCallBuilder flowReference(String flowDocumentId, String flowId);  // allow these to be EL expressions.
  // new method
  public abstract FlowCallBuilder flowReference(ValueExpression flowDocumentId, ValueExpression flowId);
Comment by Ed Burns [ 24/Dec/14 ]

The immutability of the flow start node id and flow reference properties is too valuable to abandon.





[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 ... Resolved
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-920] Enhance ProjectStage to contain DesignTime value Created: 20/Jan/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_medium

Tags: 3_1-exclude

 Description   

http://markmail.org/message/v742dgxrnovm7fpl

Hi,

opening a ADF/Trinidad application in JDeveloper's I am seeing a
"warning" like this:

WARNING: Your environment is configured as production and Apache
Trinidad is running with debug javascript. See the
"org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT" parameter in
/WEB-INF/web.xml

The WARNING itself is fine, since the web.xml doesn't have any
ProjectStage setting, but it contains a flag to not obfuscate our
JavaScript (to make it readable)...

However, in DT (DesignTime) mode this can be pretty annoying..
Therefore I was wondering if the standard ProjectStage ([1]) should
contain a "DesingTime" value?
In a similar fashion like the java.beans.Beans class does have a
isDesignTime() method ([2]).

Not sure if that has been already discussed when specifying the new
ProjectStage contract.

Greetings,
Matthias

[1]
http://myfaces.apache.org/core20/myfaces-api/xref/javax/faces/application/ProjectStage.html
[2]
http://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/beans/src/main/java/java/beans/Beans.java



 Comments   
Comment by mwessendorf [ 20/Jan/11 ]

The ApplicationImpl's getProjectStage() would immediately return "ProjectStage.DesignTime", if Beans.isDesignTime() is true.

Comment by Jakob Korherr [ 15/Apr/11 ]

We could even allow custom ProjectStages like MyFaces CODI enables you to!

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.





[JAVASERVERFACES_SPEC_PUBLIC-1000] Support for Generic Type Managed Beans Created: 10/May/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: josefreire Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is a copy of issue http://java.net/jira/browse/UEL-7. This issue already has a proposed patch.

Text as in UEL-7:
--------------------------------[ begin ]--------------------------------
When we have a class like:

public class GenericsTestController<E extends Object> {

private E value;

public E getValue()

{ return value; }

public void setValue(E value)

{ this.value = value; }

}

And we have this class to use as a managed bean (integerTest):
public class IntegerTestController extends GenericsTestController<Integer> {

public String add()

{ setValue(getValue()+1); return null; }

public String subtract()

{ setValue(getValue()-1); return null; }

}

This JSF code will not work:
<h:form>
Value:
<h:inputText value="#

{integerTest.value}

" />
<h:commandButton action="#

{integerTest.add}

" value="+" />
<h:commandButton action="#

{integerTest.subtract}

" value="-" />
</h:form>

With this error:
java.lang.ClassCastException: java.lang.String cannot be cast to Java.lang.Integer at genericstest.IntegerTestController.add(IntegerTestController.java:18)

The problem is with section 2.2.7 of the specification (1.1):

"The provided property will first be coerced to a String. If there is a BeanInfoProperty for this property and there were no errors retrieving it, the propertyType of the propertyDescriptor is returned. Otherwise, a PropertyNotFoundException is thrown."

The propertyType of a generic property is Object.class, that gets coerced to String.class, and we get the ClassCastException.
--------------------------------[ end ]--------------------------------



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

Use CDI instead.





[JAVASERVERFACES_SPEC_PUBLIC-978] support for app version Created: 18/Apr/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: kellerapps Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_small


 Description   

When a new version of an app is released but users submit old pages, restoring an old tree doesn't seem meaningful. Better to throw a version mismatch exception?



 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.





Support view actions that execute before tree is built w/ navigation support (JAVASERVERFACES_SPEC_PUBLIC-758)

[JAVASERVERFACES_SPEC_PUBLIC-968] Improve Event Handling Created: 14/Apr/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Sub-task Priority: Trivial
Reporter: kenpaulsen Assignee: Unassigned
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: el, event, jsf

 Description   

I would like to propose we improve support for <f:event> to accept body content which describes how the event should be handled. I have an implementation of this that uses EL (plus some flow control constructs: if/foreach/etc) that I could demonstrate and contribute. My implementation allows for a page author to do something like this:

<f:event type="preRenderComponent">
<![CDATA[
if (requestScope.a < mybean.b)

{ mybean.doSomething(requestScope.a); logbean.log("did something"); }

]]>
</f:event>

Source code is available at: http://java.net/projects/jsftemplating/sources/svn/show/trunk/src/java/com/sun/jsft?rev=1507

-Ken

-Ken



 Comments   
Comment by alexsmirnov [ 14/Apr/11 ]

It's bad idea to mix markup and Java on the same file. No IDE support, hard to test and maintain.

Comment by lamine_ba [ 14/Apr/11 ]

I have voted for this issue even if Ken Paulsen and I, don't have the same goal. I'm totally agree with alexsmirnov's comment. It's a bad idea to mix markup and Java on the same file especially in the perspective of a web designer. But I see good things in this idea and I'm sure there is another way to achieve it.

Comment by kenpaulsen [ 14/Apr/11 ]

I agree as well. However, minimal simple tasks in the context of an event fill an important gap. Complex logic absolutely does NOT belong in a markup (xhtml) file.

Comment by lamine_ba [ 15/Apr/11 ]

Totally agree with you Ken, sometimes the bad thing can be the good thing. It depends only on the context of your problem and there is nothing stopping us to make the two opposite approaches to coexist but only at the condition to find the right balance. As far as I'm concern, I had a hard time to know that the Event Handling is managed by the Application class. And in my opinion, the Event Handling deserves its own class to be manageable, understandable and extensible. Could we create an EventHandler class to enforce loose coupling and high cohesion? For me, things should be intuitive, you think and you get...

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

Closed on the basis of not allowing procedural code in views.





Portlets + ajax API (JAVASERVERFACES_SPEC_PUBLIC-861)

[JAVASERVERFACES_SPEC_PUBLIC-966] Make finding components involved by <f:ajax> more flexible Created: 07/Apr/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Sub-task Priority: Trivial
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Won't Fix Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_large


 Description   

Specifying the components for execution and re-rendering is very limited. Identifying components outside of a naming container is restricted to absolute component id paths. This is not very flexible. In combination with composite components this leads to requiring knowledge about the tree structure outside of the composite component. This breaks encapsulation.

This simple example is not possible at the moment:
<h:panelGroup id="outside">
Something
</h:panelGroup>
<h:form id="form">
<h:commandLink id="inner" value="Ajax">
<f:ajax render="outside" />
</h:commandLink>
</h:form>

There should be a much more flexible solution.

Furthermore the concept of solely defining the components that take part in a partial (AJAX) request (execute and render) by parameters submitted by the client is very limited.
There should be an option to dynamically decide on the server which components take part in the partial request. At the moment the client is responsible to send these ids.

AJAX requests for example could have a logical name. Components could receive an event or register a listener at the view root that can in turn decide whether the component has to participate in the request or not. This could ease the initially described limitation and allows loosely coupled ajaxified parts of the view.
Maybe this is a usecase for server-side behaviors?



 Comments   
Comment by Hanspeter Duennenberger [ 18/Apr/11 ]

There are components that should be rendered on all AJAX requests - like e.g. the h:messages area showing all the messages. There must be a way to add id's of components to render during PartialViewContext processing (see also my related blog for this https://insights2jsf.wordpress.com/2010/10/17/wrapping-partialviewcontext-or-howto-automatically-add-clientids-to-render-on-ajax-requests/).

Having said that - there might even be components to execute always. I actually created a tag <my:always render="..." execute="..." /> that can be placed on pages to specify areas on the page to render/execute always.

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-942] Allow JSF application artifacts to be delivered as OSGi bundles Created: 31/Jan/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Bug Priority: Trivial
Reporter: rogerk Assignee: Unassigned
Resolution: Won't Fix Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File message.txt    
Status Whiteboard:

size_large importance_large


 Description   

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=edburns):

Created an attachment (id=878)
Unix Mail file of discussion on this topic

The term "JSF artifacts" has multiple meanings,
and I'm sorry about that. I've changed the status to "JSF application
artifacts" to reflect its intended meaning, which is: converters, validators,
components, etc. In short, any code a developer would write as part of a JSF
application that conforms to some sort of JSF contract.



 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-934] JSF 2 Compatibility and JSR-303 Created: 31/Jan/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Bug Priority: Trivial
Reporter: rogerk Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive beanvalidatortest.zip    
Status Whiteboard:

size_medium importance_medium


 Description   

I am currently using JSF 2, Facelets 1.1.15 and RichFaces 3.3.3-BETA1. JSR-303
bean validation does not work by default. Apparently JSF does not add
BeanValidator in as a default validator by itself, and it does not recognize:
<application>
<default-validators>
<validator-id>javax.faces.Bean</validator-id>
</default-validators>
<application/>

I created a phase listener that iterates through the component tree and adds
the bean validator to any UIInputs before the process validation phase, which
seems to help partially. However, even with VALIDATE_EMPTY_FIELDS set to true,
empty fields are not validated by the bean validator. I also have
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL set to true if it matters.

This may seem like something that should be low on the list to fix, but with RF
4 slated for summer at the earliest I think this limitation with worth some
attention.

ADDITIONAL COMMENTS (edburns):

I'm marking this INVALID to get your attention. You mention you are using
Facelets 1.1.15, yet most of the new features in JSF2 depend upon using the
Facelets that is built into JSF2. Am I to understand that you are manually
disabling the facelets built into JSF2 in favor of using your bundled Facelets
1.1.15?

Also, if you could come up with a testcase to attach, I'd really appreciate it.

Your assertion that JSR-303 validation doesn't work is questionable, since we
have automated tests that are currently passing demonstrating that it does
work. Are you running on Glassfish v3? If not, on what container are you
running?

ADDITIONAL COMMENTS (jpleed3)

You have my attention.

Yes, I am using Glassfish v3. Yes, I have the Facelets 2 view handler disabled.
RichFaces 3.3.3 is compatible with JSF 2, but not with Facelets 2. See details
here: http://community.jboss.org/wiki/RichFaces333andJSF20

Personally I would love to switch to Facelets 2, but like I said RF 4 - which
will be compatible with Facelets 2 - is months away.

That said, give me a little while and I'll see if I can come up with something
simple.
[ Show » ]
jpleed3 added a comment - 08/Feb/10 01:56 PM You have my attention. Yes, I am using Glassfish v3. Yes, I have the Facelets 2 view handler disabled. RichFaces 3.3.3 is compatible with JSF 2, but not with Facelets 2. See details here: http://community.jboss.org/wiki/RichFaces333andJSF20 Personally I would love to switch to Facelets 2, but like I said RF 4 - which will be compatible with Facelets 2 - is months away. That said, give me a little while and I'll see if I can come up with something simple.

ADDITIONAL COMMENTS (edburns):

For the record, the software stack you are using is not qualified to work with
Bean Validation, so I am going to change the target milestone to 2.0.next.

I will leave the issue open, however and work on it as time permits.

NOTE: Attachment is from jpleed3 illustrating issue.



 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-932] PreValidate/PostValidate events are not published properly Created: 31/Jan/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Bug Priority: Trivial
Reporter: rogerk Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

In UIComponentBase implementation, PreValidate/PostValidate events are
published as below:

Application app = context.getApplication();
app.publishEvent(context, PreValidateEvent.class, this);
// Process all the facets and children of this component
Iterator kids = getFacetsAndChildren();
while (kids.hasNext())

{ UIComponent kid = (UIComponent) kids.next(); kid.processValidators(context); }

app.publishEvent(context, PostValidateEvent.class, this);

This makes overrided methods of subclasses cannot publish these events
properly. For example in UIInput as below:

super.processValidators(context);
if (!isImmediate())

{ executeValidate(context); }

You can see, the PostValidate event for UIInput will always be published BEFORE
its own actual validating



 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-926] UIInput change Created: 31/Jan/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Bug Priority: Trivial
Reporter: rogerk Assignee: Unassigned
Resolution: Won't Fix Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

We had an issue with UIInput type components regarding validation. If the user
entered a lot of spaces in the Input field, the UIInput validator accepted the
value as "filled out".

We suggest to change the isEmpty function in the javax.faces.component.UIInput
class to:

private static boolean isEmpty(Object value) {

if (value == null)

{ return (true); } else if ((value instanceof String) &&
(((String) value).trim().length() < 1)) { return (true); }

else if (value.getClass().isArray()) {
if (0 == java.lang.reflect.Array.getLength(value))

{ return (true); }
} else if (value instanceof List) {
if (((List) value).isEmpty()) { return (true); }

}
return (false);
}

Where we trim the value before examining the length of it: (((String)
value).trim().length(), so a lot of space will not be a valid value.

Thanks.
Description
We had an issue with UIInput type components regarding validation. If the user entered a lot of spaces in the Input field, the UIInput validator accepted the value as "filled out". We suggest to change the isEmpty function in the javax.faces.component.UIInput class to:
private static boolean isEmpty(Object value) {
if (value == null)

{ return (true); } else if ((value instanceof String) &&
(((String) value).trim().length() < 1)) { return (true); }

else if (value.getClass().isArray()) {
if (0 == java.lang.reflect.Array.getLength(value))

{ return (true); }
} else if (value instanceof List) {
if (((List) value).isEmpty()) { return (true); }


}
return (false);
}
Where we trim the value before examining the length of it: (((String) value).trim().length(), so a lot of space will not be a valid value. Thanks.
Show »



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

Too fundamental to change this at this point in the technology lifecycle.





[JAVASERVERFACES_SPEC_PUBLIC-982] Allow a default for <cc:editableValueHolder> and <cc:valueHolder> <cc:actionSource> Created: 21/Apr/11  Updated: 14/Aug/14  Resolved: 12/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_large


 Description   

When a composite component declares <cc:editableValueHolder>, <cc:valueHolder> or <cc:actionSource> it could also define one default like it is possible for <cc:clientBehavior>.

A user of the composite component then may ommit the "for" attribute for validators, converters and action listeners.
Furthermore if the composite component only declares one the exposed inner component types a user of that composite component doesn't even need to know it is a composite component. Its interface does behave like a normal component. This simplifies for example using wrapped/enhanced base input components.



 Comments   
Comment by ioss [ 21/Apr/11 ]

This should be added to http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-901

Comment by Ed Burns [ 22/Apr/11 ]

I like this idea.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Mathias Werlitz [ 14/Aug/14 ]

Is this idea part of JAVASERVERFACES_SPEC_PUBLIC-755?
What's the reason to close the issue if you actually like the idea?

Comment by Ed Burns [ 14/Aug/14 ]

Well, I liked the idea in 2011, but now three years later I have to prioritize more conservatively.





[JAVASERVERFACES_SPEC_PUBLIC-950] Pluggable Annotation Scanner Created: 21/Mar/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_small


 Description   

Looking at JSR-314-EG discussion from September 2008, I see that the 287-PluggableScanning thread appears to have been dropped.

http://archives.java.sun.com/cgi-bin/wa?A2=ind0809&L=JSR-314-EG&P=R6009&D=0&H=0&O=D&T=0&X=67011806635D16CFFF&Y=ed.burns%40sun.com

The code was attached at <http://java.net/jira/secure/attachment/13638/287-FacesAnnotationHandler.zip> on JAVASERVERFACES_SPEC_PUBLIC-287, but it seems never to have been committed.



 Comments   
Comment by Ed Burns [ 30/Mar/11 ]

Set to lifecycle

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.





[JAVASERVERFACES_SPEC_PUBLIC-948] JSF Security Created: 15/Mar/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: luisalves00 Assignee: Unassigned
Resolution: Won't Fix Votes: 19
Labels: None
Σ Remaining Estimate: 1 week Remaining Estimate: 1 week
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 1 week Original Estimate: 1 week

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-971 Multi-templating System Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-446 How to Provide JAAS Authorization in ... Sub-task Open  
Status Whiteboard:

size_large importance_medium


 Description   

Add native authentication and access-control to JSF.

Related projects:
http://jsf-security.sourceforge.net/



 Comments   
Comment by arjan tijms [ 17/May/11 ]

>Add native authentication and access-control to JSF.

I'm not sure if JSF itself should implement any authentication, but it IMO should definitely integrate better with the existing security infrastructure offered by Java EE and the Servlet spec in particular.

Currently, JSF can work with Java EE's form-based authentication, but posting to j_security_check and using input elements with j_username and j_password names feels a little awkward. I'm sure a more native JSF solution would be possible here, possibly taking advantage of Servlet 3.0's programmatic login.

The securityScope proposed by the linked project is interesting, although with the latest EL revision it's now possible to call several of the existing methods in HttpServletRequest from EL.

Some like Tomhawk's enabledOnUserRole and visibleOnUserRole attributes may also be worth considering.

Comment by john_waterwood [ 06/Oct/12 ]

Is this still planned for 2.2? Some level of support is really important for a web framework imho.

Comment by arjan tijms [ 19/Jul/14 ]

Having thought about this on and off for the better of 3 years now, I don't think there's much JSF should define itself.

At most a few utility methods could be defined (like isUserInAnyRole), but those invariably would be useful for the entire platform and not just for JSF.

More elaborate things like a general SecurityContext that can be injected in CDI beans as well as CDI/Interceptor based versions of things like @RolesAllowed for use in backing beans are all certainly better defined by a security JSR.

What JSF could perhaps do though is providing several integration points with such security JSR (if this indeed was started for Java EE 8). E.g. the mentioned SecurityContext could be defined as a new implicit EL variable in JSF. Actions that are bound to methods for which the user is not authorized at the time of rendering could optionally be omitted or rendered differently. The same thing could be done for links that resolve to URLs for which the user is not authorized.

E.g.

public class MyBean {

    @RolesAllowed("foo")
    public String doAction() {
        // ...
        return "bar"
    }
}

On some view:

<h:commandButton action="#{myBean.doAction}" value="do it"/>
<h:link outcome="/something" value="some link" />

faces-config.xml

<security>
    <components>
         <unauthorized-binding>RENDER_IS_FALSE</unauthorized-binding>
         <unauthorized-navigation-outcome><class>COLOR_RED</class></unauthorized-navigation-outcome>
    </components>
</security>         

If, using the to-be-defined security API and annotations, JSF determined that the doAction binding is protected and the user does not have the role "foo", and that /something resolves to a URL that is protected and for which the user does not have access, then JSF will not render the command button and will apply the COLOR_RED CSS class to the link component.

(the syntax is faces-config is just an example)

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by arjan tijms [ 03/Aug/14 ]

(the syntax is faces-config is just an example)

Actually, explicit syntax in faces-config wouldn't even be necessary. The styles and rendered attributes could be set with something like o:massAttribute (see http://showcase.omnifaces.org/taghandlers/massAttribute) in a template, purely based on EL expressions and the above mentioned securityContext.

Comment by Ed Burns [ 12/Aug/14 ]

Too broad.





[JAVASERVERFACES_SPEC_PUBLIC-1228] Consider UIInputFile as a means to deal with the problem of the "value" attribute with respect to state saving. Created: 08/Oct/13  Updated: 13/Aug/14  Resolved: 13/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days

Issue Links:
Related
is related to JAVASERVERFACES-3037 h:inputFile Ajax File Upload: Works e... Closed

 Description   

JSF 2.2 added file upload but did so by leveraging the javax.faces.Input component-family with the newly-defined javax.faces.File renderer-type. There is one aspect in which this may be problematic: the storing of the "value" property in component state. Please see JAVASERVERFACES-3037.



 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 ]

Impl issue marked as Cannot Reproduce.





[JAVASERVERFACES_SPEC_PUBLIC-1204] h:commandLink behaves different from h:commandButton Created: 08/Jul/13  Updated: 13/Aug/14  Resolved: 13/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0,


Tags: html5

 Description   

If a submit button is generated, browser will perform some extra tasks in HTML5 when the button is clicked. For example, browser may need to validate the form, and include input fields for this form (but out of form in DOM structure). When a link is generated, script is used to perform submission. The extra tasks performed by the form will not be performed.

Given the new html5 validation support, validation could be moved to client side. The tasks performed by browser could be important. I suggest to generate a hidden button if link is requested. When link is clicked, the event is routed to the hidden button. By this way, the browser action is always invoked.

-jason



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

This is a spec issue and must be brought to the expert group.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 13/Aug/14 ]

I'm not sure if you are asking for client side validation support or for a smaller change in how buttons work. If you are still interested in this, please file another issue that is more narrowly defined.





[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-1266] Extract Facelets as Templating for Java EE Created: 11/Feb/14  Updated: 13/Aug/14  Resolved: 13/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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

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





[JAVASERVERFACES_SPEC_PUBLIC-1176] Separate implicit bean navigation from action method via additional outcome attribute Created: 18/Mar/13  Updated: 16/Aug/14  Resolved: 13/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: djmj Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: action, logic, outcome, separate, view

 Description   

The submit/command components: 'commandButton' and 'commandLink' use implicit navigation via their 'action' attribute and the returned String in the bean method that is invoked and referenced from the 'action' attribute.

Why is the navigation outcome handled in the called method of the bean and not within the the view?
Should the view not be as much separated from the logic as possible, especially if reusing code.

Adding the 'outcome' attribute of the 'button' and 'link' components to the related command components 'commandButton' and 'commandLink' would resolve this issue.

If the command component is invoked by the user the method of its 'action' attribute is called and navigates to the target defined in its 'outcome' attribute.

<h:commandButon action="#

{bean.method()}

" outcome="/index.xhtml"/>

Currently I used a workaround by adding my own outcome via an 'f:param' to my command, since for the few cases where I used bean-navigation the logic had to be reusable and not be bound to a specific view or application.



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

Thank you for suggesting a new feature.

Note that feature requests that change existing behavior or add to it
need to be filed at the JAVASERVERFACES_SPEC_PUBLIC issue tracker.

Can you file the issue there? Thank you!

Comment by djmj [ 21/Mar/13 ]

I got an email that it was moved automatically to public issue tracker.

Is the closed status because of the wrong issue tracker?

So should it not be reopened, or is the issue itself invalid?

Comment by Ed Burns [ 22/Mar/13 ]

Re-open.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 13/Aug/14 ]

I hate to have to close this as WontFix after sitting on it for so long. However, the change you suggest is fundamentally incompatible with the design of JSF. If you feel strongly about it, please wait for the JSF 2.3 expert group to start discussions and bring it up on the users@javaserverfaces-spec-public mailing list. You can follow @jsf_spec on twitter for a notification for when the discussions start.

Comment by djmj [ 16/Aug/14 ]

Thanks for working on it. If i do not forget it i will bring it up.





HTML5 Support (JAVASERVERFACES_SPEC_PUBLIC-1090)

[JAVASERVERFACES_SPEC_PUBLIC-1076] HTML5 Sectioning and Heading Created: 22/Feb/12  Updated: 13/Aug/14  Resolved: 13/Aug/14

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

Type: Sub-task Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See: http://dev.w3.org/html5/spec/Overview.html#sectioning-content-0

HTML5 includes support for declaring page sections. JSF 2.0 includes support for declaring page sections. The challenge for JSF 2.2 is to expand the way that JSF 2.0 declares page sections so that HTML5 support is obtained for the smallest amount of developer effort. The impacted elements are:

article
aside
nav
section

h1
h2
h3
h4
h5
h6
hgroup



 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 ]

Passthru elements are sufficient here.





[JAVASERVERFACES_SPEC_PUBLIC-1148] Ability to use JSF Engine to render emails - "one way to do things" Created: 28/Nov/12  Updated: 13/Aug/14  Resolved: 13/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: tony.herstell Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2615 Ability to use JSF Engine to render e... Closed

 Description   

Require to use JSF to render emails from an "email" page template ; possibly fired from a EJB timer (so no client).

Basically to get JSF email rendering working consistently, we need to be able to boot an embedded version of JSF that has full programmatic control. This requires a number things such as splitting out the core engine so it has no servlet dependencies, ensuring that there is no thread dependence in the core etc.

Note; gmail (and others) only work with embedded styles I believe.

Seam2 had this capability (to some respect)

Originally raised: JAVASERVERFACES-2615 (http://java.net/jira/browse/JAVASERVERFACES-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350860#action_350860)
Ed asked for it to be raised here.



 Comments   
Comment by kithouna [ 05/Mar/13 ]

Isn't this a duplicate of JAVASERVERFACES_SPEC_PUBLIC-749?

Comment by tony.herstell [ 30/Apr/14 ]

Craig (see this site) is working on a JSF Mail plugin...
http://reallifejava.com/blog/

As well as Seamy stuff like
simpleBPM
simpleSecuirty

Think:
s/simeple/seam4/g

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





[JAVASERVERFACES_SPEC_PUBLIC-910] Can't render a multiline <selectone_radio/> or <selectmany_c.b.l/> Created: 15/Nov/10  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 910
Status Whiteboard:

size_medium importance_small


 Description   

Name: gm110360 Date: 03/17/2004

A DESCRIPTION OF THE REQUEST :
It would be nice to "wrap" a radio list or checkbox list when using a
<selectone_radio/> tag or <selectmany_checkboxlist/> tag.

I mean: when the collection binded to <selectitems/> is too large, we could ask
to the renderer to render it on more than one line.

JUSTIFICATION :
Better presentation of large collection of radio or checkbox lists

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
(o) Item 1 (o) Item 2 (o) Item 3
(o) Item 4 (o) Item 5 (o) Item 6
...
(o) Item n-1 (o) Item n

with, for example, another attribute: <selectone_radio rows="4">...</>
ACTUAL -
(o) Item 1 (o) Item 2 (o) Item 3 ... (o) Item n-1 (o) Item n

---------- BEGIN SOURCE ----------
<h:selectmany_checkboxlist id="complications" layout="LINE_DIRECTION">
<f:selectitem itemLabel="Aucune" itemValue="0"/>
<f:selectitem itemLabel="D�c�s" itemValue="1"/>
<f:selectitem itemLabel="Infarctus Q" itemValue="2"/>
<f:selectitem itemLabel="Infarctus non-Q" itemValue="3"/>
<f:selectitem itemLabel="PAC urgent" itemValue="4"/>
<f:selectitem itemLabel="R�occlusion" itemValue="5"/>
<f:selectitem itemLabel="H�matome inguinal" itemValue="6"/>
<f:selectitem itemLabel="Dissection iliof�morale" itemValue="7"/>
<f:selectitem itemLabel="Pseudoan�vrysme" itemValue="8"/>
<f:selectitem itemLabel="Fistule AV f�morale" itemValue="9"/>
<f:selectitem itemLabel="Atteinte crurale" itemValue="10"/>
<f:selectitem itemLabel="R�paration vasculaire" itemValue="11"/>
<f:selectitem itemLabel="H�morragie" itemValue="12"/>
<f:selectitem itemLabel="AVC" itemValue="13"/>
<f:selectitem itemLabel="Transfusion" itemValue="14"/>
<f:selectitem itemLabel="R�action anaphylactique" itemValue="15"/>
<f:selectitem itemLabel="FV" itemValue="16"/>
<f:selectitem itemLabel="Infection" itemValue="17"/>
<f:selectitem itemLabel="OAP" itemValue="18"/>
<f:selectitem itemLabel="D�collement p�ricarde" itemValue="19"/>
</h:selectmany_checkboxlist>

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
May use <selectone_menu/> or a <selectmany_menu/> tag instead (but is slower to
do in some cases)

May also use 'layout="PAGE_DIRECTION"', but not always beautiful

I may write another component too (but is time-consuming & use of a non-standard
component)
(Incident Review ID: 240440)
======================================================================



 Comments   
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-876] ViewChangedEvent Created: 13/Aug/10  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 876
Status Whiteboard:

size_small importance_small


 Description   

>>>>> On Fri, 30 Jul 2010 10:11:33 +0200, Dünnenberger Hanspeter said:

HD> as an outcome of this discussion, would you welcome a new
HD> SystemEvent (e.g. named ViewRootChangeEvent) to be fired whenever
HD> the current ViewRoot instance changes?



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Hanspeter Duennenberger [ 06/Jun/11 ]

Actually, it would be nice if the event object would provide references to the old and new ViewRoot - that would allow for some usage to copy viewScope entries from one ViewRoot to the next if a user wants to, e.g. in case both view's have the same viewId.

Comment by Ed Burns [ 06/Jun/11 ]

##jsf freenode IRC discussion

<hpdueni> Hi all. I discovered a problem using component binding and teh detection of annotated ResourceDependencies e.g. in renderers
<hpdueni> when navigating to the same page, I end up with a new ViewRoot instance but I don't get the resource dependencies from annotations.
<hpdueni> that is because the component binding prevents the tag handlers from beeing invoked in the render phase after the viewRoot was exchanged.
<edburns> hpdueni: Wow, that's subtle.
<edburns> hpdueni: I think it's really because Application.createComponent() is not being called based on the scope of the binding.
<hpdueni> Now I suspect if we need a binding-scope or if we should just rely on the ViewRootChangeEvent (which i requested in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876) to reset all component bindings

  • rogerk1 (~Adium@pool-96-237-170-36.bstnma.fios.verizon.net) has joined ##jsf
    <edburns> hpdueni: When you say "reset all component bindings" do you mean that funny little traversal we do of the tree before really getting started with the lifecycle?
    <hpdueni> or what we already have in CS JSF is a Bindings bean that should be used for all component bindings - and that one is cleared whenever ViewRoot changes
    <ioss> hpdueni: if your binding would always return null, wouldn't that solve the problem? not sure I got your issue right?
    <hpdueni> with reset component binding when viewroot changes I mean, the backing bean which holds the bound component must release that component which is from the previous view
    <ioss> or why would you want to hold the component for longer then a request?
    <hpdueni> for simplicity we used e.g. h:panelGroup bindgin="# {facesContext.attributes['someid']}

    " and then ass that el into another CC to pass on teh dynamic clientId
    <hpdueni> ioss: that problem already happens within one request - as required, we never hold bindings longer than a request.
    <hpdueni> ioss: but as it tunred out, request scope is already too long in case when viewroot changes -
    <edburns> hpdueni: Yes, I know requestscope is too long when the viewroot changes, but I'm still trying to understand your quandry.
    <hpdueni> edburns: exactly, since the component that was created in restore phase is bound to something in request scope, the component is still there after viewRoot changed and therfore Application.createComponent() will not be invoked and none of teh resource dependencies are detected
    <ioss> Hanspeter: how about always returning null?
    <ioss> then your component binding should get reset on the render-phase
    <ioss> you should possibly get a call on restore-view and another one after the view changes
    <edburns> ak: I see. Actually, there were no changes in the XSD for facelet taglibs in 2.1, so you can just use the 2.0 one.
    <hpdueni> ioss: if teh binding always returns null I can't use it anymore to pass component references to some other component ...
    <ioss> hpdueni: sure, name the binding in another way
    <ioss>
    <edburns> In fact, I just had to make the first change in the facelet taglib xsd since 2.0 a few weeks ago.
    <ioss> getTemplateComponent => null, setTemplateComponent => normal setter + getComponent => returns the one that was set by setTemplateComponent
    <hpdueni> ioss: would mean to have one attribute name with only a set method to pass teh component and another read-only name to retrieve it ...
    <ioss> right
    <hpdueni> ioss: that could work, would that be your general recommendation for component binding ?
    <ioss> hpdueni: not the nicest approach I agree, but still not horrible I would say
    <ioss> hpdueni: for components that you will never provide yourself (you can not return null there) I guess it is a possible approach
    <ioss> hpdueni: I nearly never use componentbinding
    <ioss> hpdueni: I am more a "lookup"-guy
    <hpdueni> ioss: yea, it has its pitfalls

  • mbenson_ (~mbenson@apache/committer/mbenson) has joined ##jsf
    <ioss> also there is a myfaces codi extension to bind components to longer scopes, that works that way (I think it is still in development)
    <edburns> ak: Can you please file an issue in the docmentation sub-component on this JIRA: http://java.net/jira/browse/JAVASERVERFACES
    <hpdueni> ioss: now we are close to what we do - we actually need to pass the id of one component to some CC - but as the component's clientId is unknown at development time we pass the component using this binding .
    <ioss> hpdueni: so the template author does not know the id?
    <hpdueni> ioss: not the full clientId - that may change depending on if you are running as a web app or as a Portlet - both is possible from the same web app instance
    <ioss> hpdueni: If it is different templates (inclusion/etc) it is probably cleaner to bind the component in question
    <ioss> ok
    <ioss> so this is really some sort of fire-and-(partially)-forget
    <ioss> i guess a readonly property describes exactly your "contract", as that component is never meant to be set directly
    <ioss> directly=by java code
    <ioss> by java code=non jsf implementation java code
    <hpdueni> ioss: kind of, but still I need a writable property to get hold on the component which I want to read-only from somewhere else
    <hpdueni> I just think some of the new features interfere with component binding and we need a general approach for that
    <ioss> hpdueni: if you like to go creazy you could add an ELResolver, that will set even a private property
    <ioss> or one that will return null always when el is used
    <ioss> that's actually not to bad
    <ioss> if you can come up with a naming convention, or annotations
    <ioss> or a "fake" scope
    <ioss> # {componentwriteonlybinding.mybean.property}

    <ioss> so setter and getter would work normally, but el will always return null
    <ioss> hpdueni: but i think the viewchangedevent is not a bad one, you'll just have to find a good place to "bind" them too
    <hpdueni> ioss: sounds somehow weird - actually, thinking on that kind of use my binding should work as readonly only while component tree is built - (buildView) - to prevent passing the component to the new view and allow Application.createComponent() doing it's work
    <hpdueni> ioss: I wouldn't like another ELResolver for that as there are already so many ELResolvers involved - and writing to private method would involve reflection and is somehow dirty
    <hpdueni> ioss: talking about face scope - a custom scope could hanlde that
    <ioss> hpdueni: right
    <hpdueni> ioss: on the other hand, I'd like a solution for all JSF users, not only the ones that are aware of that potential problem
    <ioss> hpdueni: couldn't you use a prerender event?
    <ioss> hpdueni: it guess it does not matter for you, if the view changed or not, you just have to get rid of that component before rendering
    <hpdueni> ioss: sure - to always get a fresh or updated component in buildView all such bindings could be thrown away in before render phase
    <ioss> hpdueni: I think a scope is the easiest way to cope with that for now. either clean the scope, or let the scope have a "special" getter, while the normal getter will return null always
    <hpdueni> ioss: but now, where does that lead us - would that mean standard bindings usage should behave always like this? Then we could really use a BindingsScope to support that
    <ioss> hpdueni: well i wouldn't call it bindingscope, but there might be use for a scope that has a "half-request" lifetime
    <hpdueni> ioss: such a bindings scope would survive during the execute phases and be a separate instance for the render phase
    <ioss> right
    <hpdueni> ioss: whatever it's called - it would have separate lifetime for execute phases and render phase
    <hpdueni> ioss: that is pretty close to the two Portlet phases
    <ioss> you could probably even use it for some fancy persistence stuff, like make the "execute" phase transactional and write enabled, while the request-phase would have an long-running em to cope with lazy-load, but also would not allow to persist anything
    <ioss> Reminds me, that I have to read about portlets!
    <hpdueni> ioss: guess we close the discussion for now - was anybody else listening on that? Any other positions on that?
    <edburns> hpdueni: Ok, so ioss proposed a workaround involving an extra javabeans property, and then the discussion went to having a scope for this use-case.
    <hpdueni> edburns: yes, some special ELResolver was also in discussion
    <edburns> hpdueni: But really, this is closelely related to <http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876>.
    <edburns> Let me capture this discussion to the comment thread on the issue.
    <hpdueni> edburns: what would be a solution for everybody - or should binding be considered as advanced usage where one has to know the bindings might need to be cleared in certain cases even in the middle of the request?

Comment by Darious3 [ 07/Oct/12 ]

The bindings issue mentioned in the chat is somewhat related to the problem that if the view navigated to contains meta-data, that meta-data isn't processed. See JAVASERVERFACES-2279

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

Feel free to re-open if you want to contribute the fix yourself.





[JAVASERVERFACES_SPEC_PUBLIC-860] com.sun.faces literal string value in public FaceletContext public API Created: 29/Jun/10  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 860
Status Whiteboard:

size_small importance_small


 Description   

public abstract class FaceletContext extends ELContext {

// The key in the FacesContext attribute map
// for the FaceletContext instance.
public static final String FACELET_CONTEXT_KEY =
"com.sun.faces.facelets.FACELET_CONTEXT";



 Comments   
Comment by Ed Burns [ 29/Jun/10 ]

triage

Andy suggested a typesafe utility method.

I think that's too big for now, so I'll settle for just changing the value of the string and specifying that the
old value must be supported as well.

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.





[JAVASERVERFACES_SPEC_PUBLIC-822] Editorial Review of Spec Correctness Created: 21/Jun/10  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 822
Status Whiteboard:

size_large importance_large


 Description   

Avoid another issue 714 debacle.



 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 [ 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 Ed Burns [ 12/Aug/14 ]

Too broad.





[JAVASERVERFACES_SPEC_PUBLIC-764] Layout manager components Created: 09/Mar/10  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 764
Status Whiteboard:

size_medium importance_small


 Description   

We need some layout manager components. Lincoln suggested looking at these:

http://livedocs.adobe.com/flex/3/langref/mx/containers/HBox.html
http://livedocs.adobe.com/flex/3/langref/mx/containers/VBox.html



 Comments   
Comment by Ed Burns [ 18/May/10 ]

Move to unscheduled.

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-728] per-component INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL Created: 19/Jan/10  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh
URL: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1511


Issuezilla Id: 728
Status Whiteboard:

size_small importance_medium


 Description   

Allow control over whether an empty string is treated as null per UIInput,
potentially overriding the application-wide setting.

It would be helpful if a inputText field which is empty could be set as a null in
the backing bean instead of a empty String. This happens frequently with entity
bean validation on a nullable field where you either want the field to be null or
be a length of 10.

A config option globally was well as a knob on the inputText component would be
useful.



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

Not for 2.0 Rev a.

Comment by Ed Burns [ 08/Jun/10 ]

Ian Evans, from the doc team, recently came across a scenario where this would have been useful.

Comment by Ed Burns [ 22/Jun/10 ]

sheetalv

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.





[JAVASERVERFACES_SPEC_PUBLIC-692] JSF-2 AJAX response needs default namespace declaration Created: 11/Dec/09  Updated: 12/Aug/14  Resolved: 12/Aug/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: