[JAVASERVERFACES_SPEC_PUBLIC-1141] Specify that all parts of a resource identifier must not have "/". Created: 01/Nov/12  Updated: 05/Mar/15  Resolved: 14/Nov/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.2 Sprint 14

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 10 minutes
Time Spent: 40 minutes
Original Estimate: 50 minutes

Issue Links:
blocks JAVASERVERFACES-2401 Regression: Resolving resources via E... Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1366 Within Resource Identifier, allow res... Open


A test for JAVASERVERFACES-2401 asserts that the following is valid:


This is not valid and should never have been valid.

JSF 2.2 does add a new method resourceHandler.createViewResource() but that is intended to resolve facelet files, and those may have slashes in the path name.

Comment by Ed Burns [ 05/Nov/12 ]

Re-opening per Leonardo Uribe's 20121103-1254 email.

Comment by Ed Burns [ 12/Nov/12 ]

Consider this EG email text from < http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/10 >.

Leonardo, do you think it is sufficient to modify the javadoc for just
ResourceHandler.createResource(String) to say that if the argument
contains more than one slash, the text between the beginning of the
string and that first slash must be taken as the libraryName, and the
remainder must be used to find the resourceName?

[JAVASERVERFACES_SPEC_PUBLIC-1129] API for "reset button" Created: 03/Aug/12  Updated: 01/Aug/14  Resolved: 06/Dec/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.0 Rev a, 2.1 Rev a
Fix Version/s: 2.2 Sprint 14

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 23 hours, 17 minutes
Time Spent: 6 hours, 43 minutes
Original Estimate: 1 day, 6 hours

Issue Links:
blocks JAVASERVERFACES-2576 Implement ResetInput Closed
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1060 Reset EditableValueHolders which are ... Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1060 Reset EditableValueHolders which are ... Closed


I'd like to discuss something I've been thinking about lately. How to clear forms easily when validation fails?

Consider this simple case;


<h:messages />

<h:inputText value="#

{pprBean.firstname}" required="true"/>
<h:inputText value="#{pprBean.surname}" required="true"/>

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

<h:commandButton value="Reset" actionListener="#{pprBean.reset}">
<f:ajax render="@form" execute="@this"/>

<h:outputText value="#{pprBean.firstname}

" id="display" />



private String firstname, surname;

public void reset()

{ firstname = null; surname = null; }

So when you run this, if one of the field is empty and the other is not, validations fails and message is displayed. Problem happens when reset button is clicked to reset the form values. At processValidations phase UIInput saves the converted value at state
and since validation failed, update model is not executed so local value is never cleared. Clicking reset, clears the bean's values but inputText will not use the bound value and use the one kept in state as well ending up a confusing behavior. I've seen this in many forums.

I know wiki's like this;


But I mean shouldn't this work as expected? Proposed solutions seem way too hard just to clear form values. (component binding and calling resetValue(), new view, javascript etc.)

If at processValidations phase, local value is not stored in state, I think that will make the code above work, but I'm not sure if there will be any side effects. Does anyone know why converted local value is kept at state by calling setValue(). Both mojarra and myfaces keeps the value at state and I cannot find anything regarding this in spec, please point me if I'm wrong.


Çağatay Çivici

Comment by Ed Burns [ 05/Dec/12 ]

When sitting down to implement this, I discovered at least one additional aspect that must be specified. AjaxBehavior must have a boolean "resetInput" property.

Comment by Ed Burns [ 06/Dec/12 ]

Need verification from Cagatay.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

[JAVASERVERFACES_SPEC_PUBLIC-533] Externalization of application metadata Created: 27/Feb/09  Updated: 15/Mar/13  Resolved: 15/Mar/13

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

Type: Improvement Priority: Minor
Reporter: daschneider Assignee: Ed Burns
Resolution: Fixed Votes: 12
Labels: None
Σ Remaining Estimate: 1 week, 2 days, 18 hours, 39 minutes Remaining Estimate: 1 week, 2 days, 18 hours, 39 minutes
Σ Time Spent: 5 hours, 21 minutes Time Spent: 5 hours, 21 minutes
Σ Original Estimate: 1 week, 3 days Original Estimate: 1 week, 3 days

Operating System: All
Platform: All

Issue Links:
blocks JAVASERVERFACES-2509 Implement FacesConfigDocumentPopulato... Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-730 Make flows reusable Closed
JAVASERVERFACES_SPEC_PUBLIC-421 Configuration at runtime needed Sub-task Open  
Issuezilla Id: 533
Status Whiteboard:

cat2 frame size_large importance_medium

Tags: adf, adf_high


The JSF specification defines the format and syntax for files containing the
framework's metadata (e.g. faces-config.xml). The drawback to this is it limits
the ability to reuse the base JSF implementation in a framework that extends it.
A plugable API that allowed metadata to be feed into the base implementation
this would open up a number of doors for extending the base JSF functionality.

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


Comment by Ed Burns [ 17/Mar/10 ]


Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]


Comment by rogerk [ 27/Oct/10 ]


Comment by Ed Burns [ 01/Feb/12 ]

After thinking about this some more, wouldn't this better be solved at the platform level?

Comment by Ed Burns [ 02/Feb/12 ]

After consulting with a key stakeholder from ADF, I've decided to de-prioritize this, noting that JAVASERVERFACES_SPEC_PUBLIC-730 will likely address most of what's important at this issue.

I'll leave the FixVersion as Unknown, excluding it from consideration for 2.2.

Comment by Ed Burns [ 13/Feb/12 ]

I spoke with David Schneider from ADFc on 20120207. He advised me that a simple specification for this issue would satisfy. Here it is.

Modify the spec so that there's an API that is called exactly once, at startup, that will give an instance of org.w3c.dom.Document when called. This Document will be included in the list of Documents that form the runtime representation of the Application Configuration Resources.

As usual, items specified in WEB-INF/faces-config.xml will take precedence over other items.

Comment by tedgoddard [ 21/Feb/12 ]

If the scope of this feature is reduced to the previous comment: expose a parsed DOM (immutable or cloned for each caller) for each configuration file, it is not controversial and implementation would be straightforward.

Comment by Ed Burns [ 12/Sep/12 ]

Manfred suggested using META-INF/services instead of an annotation. I asked David Schneider about this and he was OK with that approach.

I'll rework this issue to use that approach.

Comment by Ed Burns [ 12/Sep/12 ]

New approach. Simpler to implement.

Comment by Ed Burns [ 15/Mar/13 ]

Andy Schwartz made some suggestions.

Generated at Tue Feb 21 09:10:32 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.