<< Back to previous view

[JAVASERVERFACES_SPEC_PUBLIC-1274] In ViewMetadata.createMetadataView() clarify state for temporary UIViewRoot Created: 10/Apr/14  Updated: 10/Apr/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Resolved
Tags:
Participants: Ed Burns

 Description   

In ViewMetadata.createMetadataView(), specify

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





[JAVASERVERFACES_SPEC_PUBLIC-1273] Clarify what happens to the current FacesContext during the execution of ViewMetadata.createMetadataView() Created: 03/Apr/14  Updated: 03/Apr/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Resolved
Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES-3205.

first.xhtml
<f:view>
  <f:metadata>
    <f:viewParam name="id" value="#{outcomeTestFirstBean.firstId}"></f:viewParam>
  </f:metadata>

	<h:head>
	</h:head>
	<h:form>
		
		<h2>Problem description:</h2>
		When visiting this page using the following link: <a href="?id=11111">/first.jsf?id=11111</a> we can show that include-view-params causes a problem.<br/>
		Clicking the TestOutcomeLink poses no problem and will load the second page normally.<br/>
		Any postback will however try to execute the preRenderView event of the OutcomeTestSecondBean (because the metaData is parsed at ViewMetadataImpl.createMetadataView(FacesContext) line: 115)
		<br/><br/><br/>
		<h:link outcome="second" value="TestOutcomeLink" includeViewParams="true">
			<f:param name="extraParam" value="99999" />
		</h:link>
		<br/><br/><br/>
		<h:commandLink value="Postback goes BOOM" action="#{outcomeTestFirstBean.justAnAction}" />&nbsp;
		<h:commandButton value="Postback goes BOOM" action="#{outcomeTestFirstBean.justAnAction}" />
	</h:form>
</f:view>

and

second.xhtml
<f:view>
  <f:metadata>
    <f:viewParam name="id" value="#{outcomeTestSecondBean.secondId}"></f:viewParam>
    <f:event listener="#{outcomeTestSecondBean.load}" type="preRenderView" />
  </f:metadata>
	<h:head>
	</h:head>
	<h:form>
		<h:outputLabel value="#{outcomeTestSecondBean.secondId}" />
	</h:form>
</f:view>

When first.xhtml renders, the <h:link> will cause the <f:metadata>
section of second.xhtml to be executed. This will cause a dummy
UIViewRoot to be created and thrown away, per the spec. Unfortunately,
the <f:listener> in second.xhtml's <f:metadata> section ends up on
first.xhtml's UIViewRoot. The spec for
ViewMetadata.createMetadataView() must require the existing UIViewRoot,
if any, to be restored before returning from the method.






[JAVASERVERFACES_SPEC_PUBLIC-1272] Take advantage of Java SE 8 JSR-310 Time API in the javax.faces.convert package Created: 31/Mar/14  Updated: 31/Mar/14

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

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

Tags:
Participants: Ed Burns

 Description   

JSF has had javax.faces.convert.DateTimeConverter since 1.0. Now that Java SE 8 has a new time API, we need to have another converter that supports this API.






[JAVASERVERFACES_SPEC_PUBLIC-1271] Simplify overriding a component's renderer Created: 27/Mar/14  Updated: 27/Mar/14

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

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

Tags:
Participants: arjan tijms

 Description   

A component in JSF can be customized by overriding its renderer and creating a new tag for it, e.g as demonstrated here: https://weblogs.java.net/blog/mriem/archive/2013/11/07/jsf-tip-34-override-jsf-renderer-and-create-new-tag-it

This however requires a small but tedious amount of XML. As an analogy to the createTag attribute of FacesComponent a similar attribute on @FacesRenderer could simplify this task and provide a greater ease of use. E.g. the XML in the above referenced example could be replaced by the following:

@FacesRenderer(forComponentType="javax.faces.HtmlOutputText" tagName="myOutputText")
public class MyTextRenderer extends Renderer {
    // ...
}

Overriding the render of a component and keeping its existing tag requires roughly the same amount of XML, but less straightforward. It requires the user to find out what the render-kit-id, component-family and renderer-type is of the component for which they want to override. This is demonstrated e.g. here: https://weblogs.java.net/blog/mriem/archive/2013/11/05/jsf-tip-32-override-jsf-renderer

It would be great if this could be simplified to just this:

@FacesRenderer(forComponentType="javax.faces.HtmlOutputText")
public class MyTextRenderer extends Renderer {
    // ...
}

As a user often primarily knows a component by its namespace and tag name, it might be worthwhile to let the user alternatively reference the component via this kind of naming. E.g.

@FacesRenderer(forComponentTag="http://java.sun.com/jsf/html:outputText")
public class MyTextRenderer extends Renderer {
    // ...
}





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

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

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

Tags:
Participants: michael_kurz

 Description   

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

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

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

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

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

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

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

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

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

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






[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/Mar/14

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Tags:
Participants: Ed Burns

 Description   

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






[JAVASERVERFACES_SPEC_PUBLIC-1268] javax.faces.view.ViewScoped should be @NormalScoped(passivating=true) Created: 06/Mar/14  Updated: 16/Apr/14

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Issue Links:
Related
is related to JAVASERVERFACES-3191 Serialization and CDI Viewscope Open
Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES-3191.



 Comments   
Comment by Ed Burns [ 16/Apr/14 08:32 PM ]

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 09:12 PM ]

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.





[JAVASERVERFACES_SPEC_PUBLIC-1267] Clarify meaning of null return from UIComponent.getFamily() Created: 13/Feb/14  Updated: 13/Feb/14

Status: Open
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: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Issue Links:
Dependency
blocks JAVASERVERFACES-3180 Possible NPE in FormOmittedChecker Closed
Tags:
Participants: Ed Burns

 Description   

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

See JAVASERVERFACES-3180.






[JAVASERVERFACES_SPEC_PUBLIC-1266] Extract Facelets as Templating for Java EE Created: 11/Feb/14  Updated: 11/Feb/14

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

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

Tags:
Participants: Ed Burns




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

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3130 NavigationHandlerImpl differs from sp... In Progress
Tags:
Participants: Ed Burns

 Description   

Consider this spec text, from section 7.4.2:

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

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






[JAVASERVERFACES_SPEC_PUBLIC-1264] allow use of Servlet init parameter Created: 10/Jan/14  Updated: 06/Feb/14

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

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

Tags:
Participants: Ed Burns, Hanspeter Duennenberger and Manfred Riem

 Description   

Sometimes it is useful to configure multiple FacesServlet instances with some common and some distinct configuration.
Currently this is not possible - ExternalContext.getInitParameter(name) only provides access to ServletContext init parameters, but not to ServletConfig init parameters.

web.xml allows <context-param>s within <web-app> but also also <init-param>s within <servlet>.
The current ExternalContext interface provides no access to Servlet init-params. It would also be problematic to expose Servlet-init-param explicitly since Portlet API would not match.

A simple solution though would be that ExternalContext.getInitParameter(name) would first consult the Servlet <init-param> and second the web-app <context-param>s.
It would then also make sense to cache the so resolved parameters on FacesContext to optimize multiple access to the same init-parameter.

This proposal most likely affects the SPEC - if accepted create a SPEC issue as well.

regards
Hanspeter



 Comments   
Comment by Manfred Riem [ 06/Feb/14 04:40 PM ]

As this indeed has a major specification impact it has been moved to the spec issue tracker





[JAVASERVERFACES_SPEC_PUBLIC-1263] Add rowStatePreserved property to com.sun.faces.facelets.component.UIRepeat, exactly the same as javax.faces.component.UIData Created: 14/Oct/13  Updated: 06/Feb/14

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Dependency
blocks JAVASERVERFACES-2633 UIInput component state incorrect whe... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1230 VDLDoc for <ui:repeat> does not have ... Open
Tags:
Participants: Ed Burns

 Description   

This is the implementation work for JAVASERVERFACES_SPEC_PUBLIC-1230, but it can be done outside of the spec because properties can be added to Facelet backed components without having to change the TLD.






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

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

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

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

 Description   

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

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






[JAVASERVERFACES_SPEC_PUBLIC-1261] inconsistent behavior with absolute contracts references like /contracts_dir/contract_name/resource.xhtml Created: 03/Feb/14  Updated: 03/Feb/14

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

Type: Improvement Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3146 absolute contract reference (e.g. tem... Closed
Tags:
Participants: Hanspeter Duennenberger

 Description   

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

Absolute references to resources in contracts is not supported by design. However, with contracts deployed in /webapp_root/contracts_dir/contract_name it is possible to reference such resources using the absolute reference /contracts_dir/contract_name/resource.xhtml. Moving the same contract out to a separate jar this reference cannot be resolved anymore.

Since such absolute references are not supported by design such absolute contracts references must be prevented no mather if the contract is deployed into /webapp_root/contracts_dir or in META-INF/contracts within a jar.






[JAVASERVERFACES_SPEC_PUBLIC-1260] Allow for extensionless mapping of views Created: 31/Jan/14  Updated: 31/Jan/14

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

Type: Improvement Priority: Major
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3131 More flexible view mapping Closed
Tags:
Participants: Manfred Riem




[JAVASERVERFACES_SPEC_PUBLIC-1259] Allow mapping on /* Created: 31/Jan/14  Updated: 31/Jan/14

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

Type: Improvement Priority: Major
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3131 More flexible view mapping Closed
Tags:
Participants: Manfred Riem




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

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

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

Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES-3150.






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

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

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

File Attachments: Text File changebundle.txt    
Tags:
Participants: lfryc and Manfred Riem

 Comments   
Comment by lfryc [ 27/Jan/14 12:52 PM ]

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 05:17 PM ]

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 03:36 PM ]

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 01:53 PM ]

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 01:54 PM ]

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.





[JAVASERVERFACES_SPEC_PUBLIC-1256] FacesContextWrapper should call FacesContext.setCurrentinstance(this) in its default constructor Created: 10/Jan/14  Updated: 23/Jan/14

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

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

File Attachments: Text File changebundle.txt    
Tags:
Participants: Ed Burns, Hanspeter Duennenberger and Manfred Riem

 Description   

A common mistake when wrapping FacesContext is to forget to call FacesContext.setCurrentInstance(this) from within the constructor of the new CustomFacesContext extending FacesContextWrapper. Without that call, FacesServlet will use the wrapped FacesContext, but FacesContext.getCurrentInstance() would only return the wrapped RI's FacesContextImpl, but not the wrapper chain.

The call of FacesContext.setCurrentInstace(this) in the default constructor of FacesContextWrapper would prevent this mistake easily.



 Comments   
Comment by Ed Burns [ 22/Jan/14 08:26 PM ]

r=edburns.

Comment by Manfred Riem [ 22/Jan/14 09:28 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3141, r=edburns, make sure the correct FacesContext is set by a wrapped FacesContext."
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Transmitting file data .
Committed revision 12783.

Comment by Manfred Riem [ 23/Jan/14 04:49 PM ]

Applied to 2.2 branch,

svn commit -m "Reverting as this violates the current TCK"
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Transmitting file data .
Committed revision 12786.

Comment by Manfred Riem [ 23/Jan/14 04:50 PM ]

Issue moved to the SPEC tracker as affecting the current fix violates tests in the TCK. Hence this has to wait for the next SPEC cycle.





[JAVASERVERFACES_SPEC_PUBLIC-1255] f:view contracts="#{bean.contracts}" should allow to return null from the bean to let contracts be calculated from configurarion Created: 10/Jan/14  Updated: 22/Jan/14

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

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

Tags:
Participants: Ed Burns and Hanspeter Duennenberger

 Description   

com/sun/faces/facelets/tag/jsf/core/ViewHandler uses TagAttribute.getValue() to retrieve the contracts EL expression value - EL (before 3.0) will coerce null from the bean.contracts to "" and make no contract active.

If ViewHandler would use TagAttribute.getObject() null would be evaluated to null and the contracts calculation from the configuration would be used.

This might as well affect the spec - if this is accepted, a SPEC issue has to be created as well.






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

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

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

Issue Links:
Dependency
blocks JAVASERVERFACES-3139 relax restriction of where to place <... Closed
Tags:
Participants: Ed Burns

 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.






[JAVASERVERFACES_SPEC_PUBLIC-1253] Consider enabling abandoning a flow directly for another flow Created: 17/Jan/14  Updated: 17/Jan/14

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

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive i_spec_1253-reproducer.zip     Text File i_spec_1253.patch    
Tags:
Participants: Ed Burns

 Description   

Consider an app with this arrangement.

src/main/webapp/WEB-INF/faces-config.xml
src/main/webapp/flowA/flowA-flow.xml
src/main/webapp/flowA/flowA.xhtml
src/main/webapp/flowB/flowB-flow.xml
src/main/webapp/flowB/flowB.xhtml
src/main/webapp/flowC/flowC-flow.xml
src/main/webapp/flowC/flowC.xhtml
src/main/webapp/index.xhtml
src/main/webapp/site-template.xhtml

All .xhtml pages in this app are template clients of
site-template.xhtml. The site-template.xhtml has a row of buttons along
the top that allow immediate navigation to all of the flows. The intent
is that whatever flow you're in, you want to abandon it and enter the
new flow when the corresponding button is clicked. This is not a flow
call, but rather should be treated as an atomic "abandon/enter".

The current specification does not support this cleanly.



 Comments   
Comment by Ed Burns [ 17/Jan/14 08:16 PM ]

Diff of reproducer.

Comment by Ed Burns [ 17/Jan/14 08:18 PM ]

zip of reproducer.





[JAVASERVERFACES_SPEC_PUBLIC-1252] It should be possible to specify Resource Dependencies via XML Created: 14/Jan/14  Updated: 16/Jan/14

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

Type: Improvement Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75

 Description   

From the portlet EG mailing list (Neil Griffin and Ed Burns)

NG> @Ed Burns: When you get a chance, could you please shed some light
NG> on why resource dependencies can only be done via JSF annotations,
NG> and not by faces-config.xml? Thx.

EB> I suppose it could be. It turned out to be easier to implement with
EB> annotations. I think you have discovered a wrinkle where our stated
EB> goal of having complete parity of functionality between annotations and
EB> XML is not met.






[JAVASERVERFACES_SPEC_PUBLIC-1251] Documentation for javax.faces.application.ResourceHandler.RESOURCE_CONTRACT_XML could use clarification Created: 10/Jan/14  Updated: 10/Jan/14  Resolved: 10/Jan/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: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags:
Participants: Ed Burns

 Description   

The spec PDF says.

2.7 Resource Library Contracts

[...]

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

The doc for the constant says:

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

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

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



 Comments   
Comment by Ed Burns [ 10/Jan/14 05:54 PM ]

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

  • The operative change.

RESOURCE_CONTRACT_XML

public static final java.lang.String RESOURCE_CONTRACT_XML

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

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

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




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

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

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

Tags:
Participants: Ed Burns and tremes

 Description   

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

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

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



 Comments   
Comment by tremes [ 03/Jan/14 07:54 AM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1249] add "maxRepeats" attribute to ui:repeat. Created: 27/Dec/13  Updated: 27/Dec/13

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

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

Tags:
Participants: Ed Burns

 Description   

It would be very handy if there were a "maxRepeats" attribute on ui:repeat such that the repetition would terminate when either of the following two conditions was true.

1. the collection is empty

2. the maxRepeats value has been reached in terms of number of iterations.






[JAVASERVERFACES_SPEC_PUBLIC-1248] Allow EL in ResourceBundles used by JSF. Created: 27/Dec/13  Updated: 27/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator)
Affects Version/s: None
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

It would be nice if we could allow the use of EL expressions in ResourceBundles used by JSF.






[JAVASERVERFACES_SPEC_PUBLIC-1247] Disable implicit navigation within flows on a per-flow basis. Created: 27/Dec/13  Updated: 27/Dec/13

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

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

Tags:
Participants: Ed Burns

 Description   

The ease of use of implicit navigation can be a boon for quick development, but it can also make it difficult to reason about flows when they get more complex. Consider adding a configuration element that disables implicit navigation in a flow.






[JAVASERVERFACES_SPEC_PUBLIC-1246] Prevent jumping into a flow without going through the front door. Created: 27/Dec/13  Updated: 27/Dec/13

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

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

Tags:
Participants: Ed Burns

 Description   

RS> One observation is with regards to access to flow scoped data. When
RS> using the provided buttons, everything works as it should, i.e. flow
RS> scoped data is created at the point of entering the flow and
RS> destroyed when the flow is exited. However, it is easy to bypass the
RS> entry and exit points. For example I can go directly to a page
RS> associated with a flow without entering the flow, and if the page
RS> tries to access flow data, the result would be
RS> ContextNotActiveException.

One could argue that such an exception is the right response. The
context is indeed not active. However, if you are not using any flow
scoped data, such an exception would not be thrown, and it would give
the impression that the navigation is supported.

I think we can add some language to the spec to detect these "jump in"
cases.



 Comments   
Comment by Ed Burns [ 27/Dec/13 05:59 PM ]

Rossen wrote:

When flows are defined under the web application's root, I can easily access
their source from a browser which is a security concern. I can see there is
an example that puts the flow definition under WEB-INF but the pages are
still under the web application root and hence the flow is in two different
places. It would be useful to be able to keep a flow with all its files in a
folder under WEB-INF.





[JAVASERVERFACES_SPEC_PUBLIC-1245] Section "Determining the active Locale" includes too narrow language Created: 26/Dec/13  Updated: 26/Dec/13

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

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

There is text in section "Determining the active Locale" (section number 2.5.2.1 as of version 2.2 of the JSF spec) that speaks too narrowly of how the system must process the <supported-locale> entries in the <locale-config> of the faces-config.xml file. In particular, this text runs afoul of the changes for script tags specified in IETF BCP47.

This text must be generalized so that existing behavior continues to be spec compliant, while BCP47 style entries can also be supported.

The spec for the <f:view locale> attribute must also be inspected so that it is compatible with BCP47.






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

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

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

Tags:
Participants: Ed Burns

 Description   

Text copied from JAVASERVERFACES-3094

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

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

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






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

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

Type: New Feature Priority: Minor
Reporter: kithouna Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: facesvalidator validator validator-id value annotation
Participants: kithouna

 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






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

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

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

Tags:
Participants: Ed Burns

 Description   

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

EB> 13.2 JavaScript Namespacing

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

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

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

EB> Java Ajax:

Unknown macro: { EB> namespaceURI}

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

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

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

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

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

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

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

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

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

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






[JAVASERVERFACES_SPEC_PUBLIC-1241] web-facesconfig_2_2.xsd is missing definition for client-window-factory element Created: 09/Dec/13  Updated: 09/Dec/13

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

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

Tags:
Participants: Manfred Riem and tremes

 Comments   
Comment by Manfred Riem [ 09/Dec/13 04:15 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1240] Ajax behavior renderer automatically/incorrectly quotes client behavior context parameters when building script. Created: 10/Nov/13  Updated: 06/Dec/13

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

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

Tags:
Participants: cduncan, Ed Burns and Manfred Riem

 Description   

In the AjaxBehaviorRenderer.buildAjaxCommand() method, all ClientBehaviorContext.Parameter parameters are automatically quoted using RenderKitUtils.appendProperty(). This makes dynamicly calculated JavaScript values useless. All other calls to RenderKitUtils.appendProperty specify whether to quote parameters or not. Please do the same for ClientBehaviorContext.Parameter parameters.

The following call in AjaxBehaviorRenderer.java around line 250 should pass false.

for (ClientBehaviorContext.Parameter param : params) { RenderKitUtils.appendProperty(ajaxCommand, param.getName(), param.getValue()); }

I cannot use this very nice way of generating scripts in my custom components until this is fixed. I am currently using jsf.ajax.request, which works fine, but, I would rather use the implementation apis since it is much cleaner.



 Comments   
Comment by cduncan [ 10/Nov/13 02:20 PM ]

The most versatile and unobtrusive solution would be to add a "quoted" member variable to the ClientBehaviorContext.Parameter class. The value could be defaulted to true and referenced in the for loop mentioned above. This would not break existing usage since the for loop defaults to quoted currently. This would allow the developer to choose whether they wanted the quotes or not.

Comment by Manfred Riem [ 11/Nov/13 04:41 PM ]

Can you please tell us which version is affected, what application server you are running? And can you send a reproducing example to issues@javaserverfaces.java.net? That will help us tremendously! Thanks!

Comment by cduncan [ 12/Nov/13 02:33 PM ]

Manfred, I am using the Glassfish 4.0 zip version, which looks to be 2.2.0 according to manifest.mf. My proposed solution in the above comment was looking at the 2.2.4 source.

Thanks!
Chris

Comment by Ed Burns [ 13/Nov/13 08:57 PM ]

Thanks for your response about your version stack. It would help a lot if you could send a reproducer to the list, as suggested by Manfred. Whenever an issue comes in that requests a change in behavior, it is very important that we have the ability to verify that this change does not introduce problems.

Comment by Manfred Riem [ 19/Nov/13 02:16 PM ]

As the code currently in place is working correctly and you are asking for an improvement (by passing it the additional boolean) I am going to re-qualify this as an improvement.

Comment by cduncan [ 24/Nov/13 02:26 AM ]

Manfred, this issue is a show stopper bug for me and not an improvement. I cannot use the client behavior mechanism since it quotes the JavaScript parameters. I will attache the modified files, ClientBehaviorContext.java and AjaxBehaviorRenderer.java. Thanks, Chris.

Comment by cduncan [ 24/Nov/13 02:26 AM ]

/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
  • and Distribution License("CDDL") (collectively, the "License"). You
  • may not use this file except in compliance with the License. You can
  • obtain a copy of the License at
  • https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
  • or packager/legal/LICENSE.txt. See the License for the specific
  • language governing permissions and limitations under the License.
    *
  • When distributing the software, include this License Header Notice in each
  • file and include the License file at packager/legal/LICENSE.txt.
    *
  • GPL Classpath Exception:
  • Oracle designates this particular file as subject to the "Classpath"
  • exception as provided by Oracle in the GPL Version 2 section of the License
  • file that accompanied this code.
    *
  • Modifications:
  • If applicable, add the following below the License Header, with the fields
  • enclosed by brackets [] replaced by your own identifying information:
  • "Portions Copyright [year] [name of copyright owner]"
    *
  • Contributor(s):
  • If you wish your version of this file to be governed by only the CDDL or
  • only the GPL Version 2, indicate your decision by adding "[Contributor]
  • elects to include this software in this distribution under the [CDDL or GPL
  • Version 2] license." If you don't indicate a single choice of license, a
  • recipient has the option to distribute your version of this file under
  • either the CDDL, the GPL Version 2 or to extend the choice of license to
  • its licensees as provided above. However, if you add GPL Version 2 code
  • and therefore, elected the GPL Version 2 license, then the option applies
  • only if the new code is made subject to such option by the copyright
  • holder.
    */

package javax.faces.component.behavior;

import java.util.Collection;
import java.util.Collections;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;

/**

  • <p class="changed_added_2_0"><strong>ClientBehaviorContext</strong>
  • provides context information that may be useful to
  • {@link javax.faces.component.behavior.ClientBehavior#getScript}
  • implementations.
  • </p>
    *
  • @since 2.0
    */
    public abstract class ClientBehaviorContext {

/**

  • <p class="changed_added_2_0">Creates a ClientBehaviorContext instance.</p>
    *
  • @param context the <code>FacesContext</code> for the current request.
  • @param component the component instance to which the
  • <code>ClientBehavior</code> is attached.
  • @param eventName the name of the behavior event to which the
  • <code>ClientBehavior</code> is attached.
  • @param sourceId the id to use as the ClientBehavior's "source".
  • @param parameters the collection of parameters for submitting
  • ClientBehaviors to include in the request.
  • @return a <code>ClientBehaviorContext</code> instance configured with the
  • provided values.
  • @throws NullPointerException if <code>context</code>,
  • <code>component</code> or <code>eventName</code>
  • is <code>null</code>
    *
  • @since 2.0
    */
    public static ClientBehaviorContext createClientBehaviorContext(FacesContext context,
    UIComponent component,
    String eventName,
    String sourceId,
    Collection<ClientBehaviorContext.Parameter> parameters) { return new ClientBehaviorContextImpl(context, component, eventName, sourceId, parameters); }

/**

  • <p class="changed_added_2_0">Returns the {@link FacesContext} for
  • the current request.</p>
    *
  • @since 2.0
    */
    abstract public FacesContext getFacesContext();

/**

  • <p class="changed_added_2_0">Returns the {@link UIComponent} that is
  • requesting the {@link ClientBehavior} script.</p>
    *
    * @since 2.0
    */
    abstract public UIComponent getComponent();

    /**
    * <p class="changed_added_2_0">Returns the name of the behavior event
    * for which the ClientBehavior script is being requested. </p>
    *
    * @since 2.0
    */
    abstract public String getEventName();

    /**
    * <p class="changed_added_2_0">Returns an id for use as the
    * {@link ClientBehavior} source. ClientBehavior implementations that submit back
  • to the Faces lifecycle are required to identify which component
  • triggered the ClientBehavior-initiated request via the
  • <code>javax.faces.source</code> request parameter. In
  • most cases, th source id can be trivially derived from the element
  • to which the behavior's client-side script is attached - ie. the
  • source id is typically the id of this element. However, in components
  • which produce more complex content, the behavior script may not be able to
  • determine the correct id to use for the javax.faces.source
  • value. The {@link ClientBehaviorContext#getSourceId} method allows the component
  • to pass this information into the {@link ClientBehavior#getScript}
  • implementation.</p>
    *
  • @return the id for the behavior's script to use as the "source", or
  • null if the Behavior's script can identify the source from the DOM.
    *
  • @since 2.0
    */
    abstract public String getSourceId();

/**

  • <p class="changed_added_2_0">Returns parameters that "submitting"
  • {@link ClientBehavior} implementations should include when posting back data
  • into the Faces lifecycle. If no parameters are specified, this method
  • returns an empty (non-null) collection.</p>
    *
  • @since 2.0
    */
    abstract public Collection<ClientBehaviorContext.Parameter> getParameters();

// Little static member class that provides a default implementation
private static final class ClientBehaviorContextImpl extends ClientBehaviorContext {
private FacesContext context;
private UIComponent component;
private String eventName;
private String sourceId;
private Collection<ClientBehaviorContext.Parameter> parameters;

private ClientBehaviorContextImpl(FacesContext context,
UIComponent component,
String eventName,
String sourceId,
Collection<ClientBehaviorContext.Parameter> parameters) {

if (null == context) { throw new NullPointerException(); }

if (null == component) { throw new NullPointerException(); } }

if (null == eventName) { throw new NullPointerException(); }

this.context = context;
this.component = component;
this.eventName = eventName;
this.sourceId = sourceId;

this.parameters = (parameters == null) ?
Collections.<ClientBehaviorContext.Parameter>emptyList() :
parameters;
}

@Override
public FacesContext getFacesContext() { return context; }

@Override
public UIComponent getComponent() { return component; }

@Override
public String getEventName() { return eventName; }

@Override
public String getSourceId() { return sourceId; }

@Override
public Collection<ClientBehaviorContext.Parameter> getParameters() { return parameters; }
}

/**
* <p class="changed_added_2_0"><strong>Parameter</strong> instances
* represent name/value pairs that "submitting" ClientBehavior implementations
* should include when posting back into the Faces lifecycle. ClientBehavior
* implementations can determine which Parameters to include by calling
* ClientBehaviorContext.getParameters().
* </p>
*
* @since 2.0
*/
public static class Parameter {

private String name;
private Object value;
private boolean quoteValue;

/**
* <p class="changed_added_2_0">Creates a Parameter instance.</p>
* @param name the name of the parameter
* @param value the value of the parameter
* @throws NullPointerException if <code>name</code>
* is null.
*
* @since 2.0
*/
public Parameter(String name, Object value) { this(name, value, true); }

/**
* <p class="changed_added_2_0">Creates a Parameter instance.</p>
* @param name the name of the parameter
* @param value the value of the parameter
* @param quoteValue indicator for value quotes.
* @throws NullPointerException if <code>name</code>
* is null.
*
* @since 2.2.6
*/
public Parameter(String name, Object value, boolean quoteValue) {

if (null == name) { throw new NullPointerException(); } }

this.name = name;
this.value = value;
this.quoteValue = quoteValue;
}

/**

  • <p class="changed_added_2_0">Returns the Parameter's name.</p>
    *
  • @since 2.0
    */
    public String getName() { return name; }

/**

  • <p class="changed_added_2_0">Returns the Parameter's value.</p>
    *
  • @since 2.0
    */
    public Object getValue() { return value; }

/**

  • <p class="changed_added_2_2_6">Returns the Parameter's quote value indicator.</p>
    *
  • @since 2.2.6
    */
    public boolean getQuoteValue() { return quoteValue; }
    }
    }
Comment by cduncan [ 24/Nov/13 02:27 AM ]

/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • Copyright (c) 1997-2010 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
  • and Distribution License("CDDL") (collectively, the "License"). You
  • may not use this file except in compliance with the License. You can
  • obtain a copy of the License at
  • https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
  • or packager/legal/LICENSE.txt. See the License for the specific
  • language governing permissions and limitations under the License.
    *
  • When distributing the software, include this License Header Notice in each
  • file and include the License file at packager/legal/LICENSE.txt.
    *
  • GPL Classpath Exception:
  • Oracle designates this particular file as subject to the "Classpath"
  • exception as provided by Oracle in the GPL Version 2 section of the License
  • file that accompanied this code.
    *
  • Modifications:
  • If applicable, add the following below the License Header, with the fields
  • enclosed by brackets [] replaced by your own identifying information:
  • "Portions Copyright [year] [name of copyright owner]"
    *
  • Contributor(s):
  • If you wish your version of this file to be governed by only the CDDL or
  • only the GPL Version 2, indicate your decision by adding "[Contributor]
  • elects to include this software in this distribution under the [CDDL or GPL
  • Version 2] license." If you don't indicate a single choice of license, a
  • recipient has the option to distribute your version of this file under
  • either the CDDL, the GPL Version 2 or to extend the choice of license to
  • its licensees as provided above. However, if you add GPL Version 2 code
  • and therefore, elected the GPL Version 2 license, then the option applies
  • only if the new code is made subject to such option by the copyright
  • holder.
    */

package com.sun.faces.renderkit.html_basic;

import com.sun.faces.util.FacesLogger;

import java.util.Collection;
import java.util.LinkedList;
import java.util.logging.Level;
import java.util.logging.Logger;

import javax.faces.FacesException;
import javax.faces.component.ActionSource;
import javax.faces.component.EditableValueHolder;
import javax.faces.component.UIComponent;
import javax.faces.component.behavior.AjaxBehavior;
import javax.faces.component.behavior.ClientBehavior;
import javax.faces.component.behavior.ClientBehaviorContext;
import javax.faces.context.FacesContext;
import javax.faces.event.AjaxBehaviorEvent;
import javax.faces.event.PhaseId;
import javax.faces.render.ClientBehaviorRenderer;

import com.sun.faces.renderkit.RenderKitUtils;

/*
*<b>AjaxBehaviorRenderer</b> renders Ajax behavior for a component.

  • It also
    */

public class AjaxBehaviorRenderer extends ClientBehaviorRenderer {

// Log instance for this class
protected static final Logger logger = FacesLogger.RENDERKIT.getLogger();

// ------------------------------------------------------ Rendering Methods

@Override
public String getScript(ClientBehaviorContext behaviorContext,
ClientBehavior behavior) {
if (!(behavior instanceof AjaxBehavior)) { // TODO: use MessageUtils for this error message? throw new IllegalArgumentException( "Instance of javax.faces.component.behavior.AjaxBehavior required: " + behavior); }

if (((AjaxBehavior)behavior).isDisabled()) { return null; }
return buildAjaxCommand(behaviorContext, (AjaxBehavior)behavior);
}


@Override
public void decode(FacesContext context,
UIComponent component,
ClientBehavior behavior) {
if (null == context || null == component || null == behavior) { throw new NullPointerException(); }

if (!(behavior instanceof AjaxBehavior)) { // TODO: use MessageUtils for this error message? throw new IllegalArgumentException( "Instance of javax.faces.component.behavior.AjaxBehavior required: " + behavior); }

AjaxBehavior ajaxBehavior = (AjaxBehavior)behavior;

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled()) { return; }

component.queueEvent(createEvent(component, ajaxBehavior));

if (logger.isLoggable(Level.FINE)) {
logger.fine("This command resulted in form submission " +
" AjaxBehaviorEvent queued.");
logger.log(Level.FINE,
"End decoding component {0}", component.getId());
}


}

// Creates an AjaxBehaviorEvent for the specified component/behavior
private static AjaxBehaviorEvent createEvent(UIComponent component,
AjaxBehavior ajaxBehavior) { AjaxBehaviorEvent event = new AjaxBehaviorEvent(component, ajaxBehavior); PhaseId phaseId = isImmediate(component, ajaxBehavior) ? PhaseId.APPLY_REQUEST_VALUES : PhaseId.INVOKE_APPLICATION; event.setPhaseId(phaseId); return event; }


// Tests whether we should perform immediate processing. Note
// that we "inherit" immediate from the parent if not specified
// on the behavior.
private static boolean isImmediate(UIComponent component,
AjaxBehavior ajaxBehavior) {

boolean immediate = false;

if (ajaxBehavior.isImmediateSet()) { immediate = ajaxBehavior.isImmediate(); } else if (component instanceof EditableValueHolder) { immediate = ((EditableValueHolder)component).isImmediate(); } else if (component instanceof ActionSource) { immediate = ((ActionSource)component).isImmediate(); }

return immediate;
}

private static String buildAjaxCommand(ClientBehaviorContext behaviorContext,
AjaxBehavior ajaxBehavior) {

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled()) { return null; } }

UIComponent component = behaviorContext.getComponent();
String eventName = behaviorContext.getEventName();

StringBuilder ajaxCommand = new StringBuilder(256);
Collection<String> execute = ajaxBehavior.getExecute();
Collection<String> render = ajaxBehavior.getRender();
String onevent = ajaxBehavior.getOnevent();
String onerror = ajaxBehavior.getOnerror();
String sourceId = behaviorContext.getSourceId();
String delay = ajaxBehavior.getDelay();
Boolean resetValues = null;
if (ajaxBehavior.isResetValuesSet()) { resetValues = ajaxBehavior.isResetValues(); }
Collection<ClientBehaviorContext.Parameter> params = behaviorContext.getParameters();

// Needed workaround for SelectManyCheckbox - if execute doesn't have sourceId,
// we need to add it - otherwise, we use the default, which is sourceId:child, which
// won't work.
ClientBehaviorContext.Parameter foundparam = null;
for (ClientBehaviorContext.Parameter param : params) {
if (param.getName().equals("incExec") && (Boolean)param.getValue()) { foundparam = param; }
}
if (foundparam != null && !execute.contains(sourceId)) { execute = new LinkedList<String>(execute); execute.add(component.getClientId()); }
if (foundparam != null) {
try { // And since this is a hack, we now try to remove the param params.remove(foundparam); } catch (UnsupportedOperationException uoe) {
if (logger.isLoggable(Level.FINEST)) { logger.log(Level.FINEST, "Unsupported operation", uoe); }
}
}

ajaxCommand.append("mojarra.ab(");

if (sourceId == null) { ajaxCommand.append("this"); } else { ajaxCommand.append("'"); ajaxCommand.append(sourceId); ajaxCommand.append("'"); }

ajaxCommand.append(",event,'");
ajaxCommand.append(eventName);
ajaxCommand.append("',");

appendIds(component, ajaxCommand, execute);
ajaxCommand.append(",");
appendIds(component, ajaxCommand, render);

if ((onevent != null) || (onerror != null) || (delay != null) ||
(resetValues != null) || !params.isEmpty()) {

ajaxCommand.append(",{");

if (onevent != null) { RenderKitUtils.appendProperty(ajaxCommand, "onevent", onevent, false); }

if (onerror != null) { RenderKitUtils.appendProperty(ajaxCommand, "onerror", onerror, false); }

if (delay != null) { RenderKitUtils.appendProperty(ajaxCommand, "delay", delay, true); }

if (resetValues != null) { RenderKitUtils.appendProperty(ajaxCommand, "resetValues", resetValues, false); }

if (!params.isEmpty()) {
for (ClientBehaviorContext.Parameter param : params) { RenderKitUtils.appendProperty(ajaxCommand, param.getName(), param.getValue(), param.getQuoteValue()); }
}

ajaxCommand.append("}");
}

ajaxCommand.append(")");

return ajaxCommand.toString();
}

// Appends an ids argument to the ajax command
private static void appendIds(UIComponent component,
StringBuilder builder,
Collection<String> ids) {

if ((null == ids) || ids.isEmpty()) { builder.append('0'); return; }

builder.append("'");

boolean first = true;

for (String id : ids) {
if (id.trim().length() == 0) { continue; }
if (!first) { builder.append(' '); } else { first = false; }

if (id.equals("@all") || id.equals("@none") ||
id.equals("@form") || id.equals("@this")) { builder.append(id); } else { builder.append(getResolvedId(component, id)); }
}

builder.append("'");
}

// Returns the resolved (client id) for a particular id.
private static String getResolvedId(UIComponent component, String id) {

UIComponent resolvedComponent = component.findComponent(id);
if (resolvedComponent == null) { // RELEASE_PENDING i18n throw new FacesException( "<f:ajax> contains an unknown id '" + id + "' - cannot locate it in the context of the component "+component.getId()); }

return resolvedComponent.getClientId();
}
}

Comment by Manfred Riem [ 25/Nov/13 03:02 PM ]

Hi Chris,

I understand your predicament, unfortunately because your change is in javax.faces.component.behavior which is an API package it would violate the TCK (note adding any method to an API package violates the TCK and thus the JSF specification). If you can do it without changing anything in a javax.faces.* package then I certainly would like to get this in, provided it passes all of our tests.

Comment by cduncan [ 25/Nov/13 06:13 PM ]

Manfred:

Thank you for your timely response to this issue and for clarifying changes to the javax.faces.* packages. I was wondering about that before posting the previous solution. I believe there is a simple solution keeping the improvement within the com.sun.faces.renderkit.RenderKitUtils.AjaxBehaviorRenderer class. I will code it up tonight and post a solution that will not interfere with the current usage and allows overrides by component developers.

Thank you,
Chris

Comment by cduncan [ 26/Nov/13 03:30 AM ]

Manfred:

This version of the method com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.buildAjaxCommand() explicitly sets the quoted value in the RenderKitUtils.appendProperty() call to false. Currently, it is not explicitly set and thus invokes the overloaded version of RenderKitUtils.appendProperty() which sets the value to true. All of the calls to RenderKitUtils.appendProperty() explicitly set the quoted value except this one. I am not sure if this was an oversight. This version needs to be thoroughly tested to make sure it does not cause any unwanted side effects.

There is another solution if this one does not pass all tests. We can overload the com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.getScript() method passing in a boolean indicating whether to quote the value. This boolean will be passed to com.sun.faces.renderkit.html_basic.AjaxBehaviorRenderer.buildAjaxCommand() for the last RenderKitUtils.appendProperty() call.

Thank you,
Chris

private static String buildAjaxCommand(ClientBehaviorContext behaviorContext,
AjaxBehavior ajaxBehavior) {

// First things first - if AjaxBehavior is disabled, we are done.
if (ajaxBehavior.isDisabled()) { return null; }

UIComponent component = behaviorContext.getComponent();
String eventName = behaviorContext.getEventName();

StringBuilder ajaxCommand = new StringBuilder(256);
Collection<String> execute = ajaxBehavior.getExecute();
Collection<String> render = ajaxBehavior.getRender();
String onevent = ajaxBehavior.getOnevent();
String onerror = ajaxBehavior.getOnerror();
String sourceId = behaviorContext.getSourceId();
String delay = ajaxBehavior.getDelay();
Boolean resetValues = null;
if (ajaxBehavior.isResetValuesSet()) { resetValues = ajaxBehavior.isResetValues(); }
Collection<ClientBehaviorContext.Parameter> params = behaviorContext.getParameters();

// Needed workaround for SelectManyCheckbox - if execute doesn't have sourceId,
// we need to add it - otherwise, we use the default, which is sourceId:child, which
// won't work.
ClientBehaviorContext.Parameter foundparam = null;
for (ClientBehaviorContext.Parameter param : params) {
if (param.getName().equals("incExec") && (Boolean)param.getValue()) { foundparam = param; }
}
if (foundparam != null && !execute.contains(sourceId)) { execute = new LinkedList<String>(execute); execute.add(component.getClientId()); }
if (foundparam != null) {
try { // And since this is a hack, we now try to remove the param params.remove(foundparam); } catch (UnsupportedOperationException uoe) {
if (logger.isLoggable(Level.FINEST)) { logger.log(Level.FINEST, "Unsupported operation", uoe); }
}
}

ajaxCommand.append("mojarra.ab(");

if (sourceId == null) { ajaxCommand.append("this"); } else { ajaxCommand.append("'"); ajaxCommand.append(sourceId); ajaxCommand.append("'"); }

ajaxCommand.append(",event,'");
ajaxCommand.append(eventName);
ajaxCommand.append("',");

appendIds(component, ajaxCommand, execute);
ajaxCommand.append(",");
appendIds(component, ajaxCommand, render);

if ((onevent != null) || (onerror != null) || (delay != null) ||
(resetValues != null) || !params.isEmpty()) {

ajaxCommand.append(",{");

if (onevent != null) { RenderKitUtils.appendProperty(ajaxCommand, "onevent", onevent, false); }

if (onerror != null) { RenderKitUtils.appendProperty(ajaxCommand, "onerror", onerror, false); }

if (delay != null) { RenderKitUtils.appendProperty(ajaxCommand, "delay", delay, true); }

if (resetValues != null) { RenderKitUtils.appendProperty(ajaxCommand, "resetValues", resetValues, false); }

if (!params.isEmpty()) {
for (ClientBehaviorContext.Parameter param : params) { RenderKitUtils.appendProperty(ajaxCommand, param.getName(), param.getValue(), false); }
}

ajaxCommand.append("}");
}

ajaxCommand.append(")");

return ajaxCommand.toString();
}

Comment by cduncan [ 04/Dec/13 03:56 AM ]

It appears the MyFaces 2.2.0 implementation also automatically quotes the JavaScript parameter values when posting back. The following method is from the HtmlAjaxBehaviorRenderer.java class in the myfaces-impl-2.2.0-beta-sources.jar.

private void append(StringBuilder paramBuffer, List<String> parameterList, ClientBehaviorContext.Parameter param)

{ //TODO we may need a proper type handling in this part //lets leave it for now as it is //quotes etc.. should be transferred directly //and the rest is up to the toString properly implemented //ANS: Both name and value should be quoted paramBuffer.setLength(0); paramBuffer.append(QUOTE); paramBuffer.append(param.getName()); paramBuffer.append(QUOTE); paramBuffer.append(COLON); paramBuffer.append(QUOTE); paramBuffer.append(param.getValue().toString()); paramBuffer.append(QUOTE); parameterList.add(paramBuffer.toString()); }

What I take from this is that the JSF specification for the ClientBehaviorContext.Parameter class is not clear in regards to quoting, and as such, the JSF implementations default to automatic quoting.

In my first solution, I added a 'private boolean quoteValue' member variable to the ClientBehaviorContext.Parameter class and defaulted the value to true. This would not cause any side effects since implementations default to true anyway and would give custom component developers the power to decide if they want their JavaScript value params quoted or not.

As Manfred stated, this would require a change to the JSF spec, but from what I have seen, I believe it is the best route. I do realize that this would take some time, so I am writing my own handling of the client behaviors in my custom components. I cannot tightly couple my custom components to a particular implementation.

Please let me know how I can help further.

Thanks,
Chris

Comment by Manfred Riem [ 04/Dec/13 10:42 PM ]

Chris, thank you for doing the extra work you did. As you stated that MyFaces is also doing automatic quoting I think it might be time to move this issue to the spec issue tracker and put it on the radar for the next version of the JSF specification. What do you think?

Comment by cduncan [ 05/Dec/13 01:03 AM ]

Manfred:

I believe this needs a clarification in the JSF specification. A member variable in the ClientBehaviorContext.Parameter would remove all doubt for the JSF implementors on how to handle the value, and possible name parameter. It could be done in a way that would not affect all current implementations, since they default to quoted currently. Please see my original code solution for suggestions for the JSF specification.

Please let me know if I can help further.

Thanks,
Chris

Comment by Manfred Riem [ 05/Dec/13 07:23 PM ]

Chris, I will go ahead and move this issue to the SPEC issue tracker as it is a SPEC issue. Unfortunately that means resolution will have to wait till the next JSF specification. Thank!





[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: 27/Nov/13

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

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

Tags:
Participants: Ed Burns

 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.






[JAVASERVERFACES_SPEC_PUBLIC-1238] Enhance component referencing / findComponent Created: 15/Nov/13  Updated: 15/Nov/13

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

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

Tags:
Participants: Ed Burns and tandraschko

 Description   

Currently component referencing with the JSF API is very limited.
Keywords can currently only be used with f:ajax and not for e.g. outputLabel "for" attribute.
Also keywords cant be combined and we dont even have many keywords.

For PrimeFaces, i created a small modular API to enhance the search alogorithm as you can read here:
http://blog.primefaces.org/?p=2740

Noteable features are:

  • keywords can be used for all components
  • combinable keywords like @composite:@parent or @form:myId
  • currently a (limited) pluggable framework to allow new keywords for endusers

For the JSF API, a new artifact for resolving expression for findComponent (like ViewHandler etc.) would be great and can easily be enhanced by component libraries.
Maybe something like "ComponentExpressionResolver".

If its somehow possible, i would like to help to create and finalyze the API.

Sorry for Issue 1237 - please close it.






[JAVASERVERFACES_SPEC_PUBLIC-1237] Enhance component referencing / Created: 15/Nov/13  Updated: 15/Nov/13

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

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

Tags:
Participants: Ed Burns and tandraschko




[JAVASERVERFACES_SPEC_PUBLIC-1236] For Ajax File Uploads: Investigate the use of XMLHttpRequest2 (If available). Created: 31/Jul/13  Updated: 07/Nov/13

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

Type: Improvement Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File mojarra-trunk-xhr2-upload.patch    
Tags:
Participants: kfyten and rogerk

 Description   

Investigate the use of XMLHttpRequest (Level2) for file uploads (if available) and fall back to iframe if it is not available.



 Comments   
Comment by kfyten [ 10/Sep/13 11:27 PM ]

Reminder that ICEsoft has submitted a patch for this, would be nice if the JIRA reflected this, etc.

Also note that MyFaces has preliminary support for this already, see https://issues.apache.org/jira/browse/MYFACES-2852.

Comment by rogerk [ 30/Sep/13 05:54 PM ]

Contribution From IceSoft





[JAVASERVERFACES_SPEC_PUBLIC-1235] better integration of bv-groups Created: 31/Oct/13  Updated: 08/Nov/13

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

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

Tags:
Participants: gerhard_petracek

 Description   

in several cases different bv-groups should get used (in the validation-phase) depending on the triggered action.
(if there are e.g. multiple buttons in the same form which should lead to different bv-constraints.)

also see: https://issues.apache.org/jira/browse/EXTVAL-141






[JAVASERVERFACES_SPEC_PUBLIC-1234] HTML input elements without type attribute should be recognized as text inputs Created: 31/Oct/13  Updated: 13/Feb/14

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

Type: Improvement Priority: Minor
Reporter: kithouna Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kithouna

 Description   

As the type attribute for input elements is optional in HTML and the default value is "text" (as per HTML 4.01), input elements without type attribute should be handled like the type attribute was set to "text".

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



 Comments   
Comment by kithouna [ 12/Feb/14 03:52 PM ]

The reference implementation (Mojarra 2.2.5) has the strange behaviour that given

<input jsf:value="#{loginBean.loginName}" jsf:id="loginName"/>

the output becomes (assuming loginBean.loginName is not yet set, i. e. it’s null)

<input jsf:id="loginName"/>

so it seems as if the element is recognized as a JSF element (because the jsf:value seems to be interpreted in some way and therefore removed) but for some reason only the jsf:id attribute is not treated correctly.

Working on a new project, I spent way too much time (again) figuring out why the element was not working correctly. Having omitted the type attribute for several years on non-JSF projects, it’s a real unintuitive requirement to include it so maybe you could make sure to lift it for the next JSF version. Please? Maybe increase the priority? Reasoning: It is a major loss of function and the workaround (setting the attribute) is not exactly easy to find when you’re accustomed to rely on the default.





[JAVASERVERFACES_SPEC_PUBLIC-1233] Since 'var' is set by name on the request it is very easy to break. Created: 29/Oct/13  Updated: 08/Nov/13

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

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

Tags:
Participants: jid1

 Description   

IMO, composite components that contain tables or repeats that store variable on the request should be scoped as it very easy to get weird behaviour.
In the context of normal xhtml and includes, it could throw an error saying that the variable has already been defined, if user tries to define it again.

The reason behind the distinction is that you might end up with incompatible 3rd party components when you nest them. In addition, devs should pass the value as an attribute to the composite/custom component.






[JAVASERVERFACES_SPEC_PUBLIC-1232] Support for a Flow to start from direct URL path access Created: 28/Oct/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Major
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bruno Borges

 Description   

Support for a flow to start when user directly access the flow path from an URL.

If a user points to http://server/app/flow-folder/ the implementation throws an exception saying it couldn't find an index.xhtml page.

Right now, the only way to start a flow is by having the user accessing another page before, outside of the flow, and then an action to the flow (either by link, button, or some javascript to automatically click on something).






[JAVASERVERFACES_SPEC_PUBLIC-1231] Wrong name in spec for javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR Created: 16/Oct/13  Updated: 08/Nov/13

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

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

Tags:
Participants: lu4242

 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






[JAVASERVERFACES_SPEC_PUBLIC-1230] VDLDoc for <ui:repeat> does not have concept of rowStatePreserved which <h:dataTable> does have. Created: 14/Oct/13  Updated: 06/Mar/14

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1263 Add rowStatePreserved property to com... Open
is related to JAVASERVERFACES-2243 h:form inside nested ui:repeat fails ... Closed
Tags:
Participants: Ed Burns

 Description   

JSF 2.1 added to UIData the ability to declare that row state should be preserved on iterations. This capability should also be added to <ui:repeat>



 Comments   
Comment by Ed Burns [ 06/Mar/14 07:06 PM ]

>>>>> On Fri, 14 Feb 2014 16:17:46 -0500, Leonardo Uribe said:

LU> There is still a problem related to the component row state and its
LU> relation with the model. In few words, if you remove a row, since the
LU> state is associated to the rowIndex, the state of the removed row is
LU> passed to the next row and so on, breaking the state. Long time
LU> ago, I did a solution to the problem in tomahawk adding some
LU> attributes (rowKey and derivedRowKeyPrefix).





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

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

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Issue Links:
Related
is related to JAVASERVERFACES-2633 UIInput component state incorrect whe... Closed
Tags:
Participants: Ed Burns

 Description   

The JavaDocs for UIData have the rowStatePreserved property.

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






[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: 08/Nov/13

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
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
Tags:
Participants: Ed Burns

 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.






[JAVASERVERFACES_SPEC_PUBLIC-1227] Add <f:protectClientWindowOpenInNewTab> JavaScript behavior tag Created: 07/Oct/13  Updated: 20/Dec/13

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days

Tags:
Participants: Ed Burns, tandraschko and Thomas Asel

 Description   

With the introduction of ClientWindow in JSF 2.2, it's possible to protect against multiple tabs being open on the same view. However, components that render links allow the user to do "open in new tab" or "open in new window". This can cause a situation where there are multiple tabs that still have the same ClientWindow, which is incorrect.

This feature proposal asks for the creation of a ClientBehavior tag that, when nested inside of a component that renders as a link, will make it so a new client window is created when the link is clicked.



 Comments   
Comment by Ed Burns [ 07/Oct/13 11:49 PM ]

Here's a sketch for how this could work.

Here's how you'd use it.

<h:link outcome="callB" value="Call B via GET">
<f:protectClientWindowOpenInNewTab />
</h:link>

This would cause the link to be rendered with some javascript that listens for an onclick on the link. In the handler, check if the right mouse button was pressed and take appropriate action.

Comment by Thomas Asel [ 08/Oct/13 06:28 AM ]

I am afraid that this feature would force unintuitive behavior and also advocates a rather patronizing development style.

How about creating a client behavior that creates a window id on demand?
So instead of blocking the contextmenu we could use the oncontextmenu handler to create a new id and append it as a parameter to the link.

Comment by Ed Burns [ 08/Oct/13 12:40 PM ]

Thanks for the feedback, Thomas. We can certainly change the name to be less patronizing.

Please note that the ClientWindow will be created on demand when the request comes in without having one already. This is why it is sufficient for the context menu handler to simply strip it off.

The client behavior for this tag does two things.

1. If the link is clicked without the context menu, no action is taken. The already-existing ClientWindow is allowed to remain on the link, causing the correct ClientWindow to be carried forward.

2. If the link is clicked with the context menu (new tab or new window), the ClientWindow is removed before the browser issues the GET. This will cause a new ClientWindow to be created for the new tab (or window), this is the correct action in this case.

Comment by tandraschko [ 20/Dec/13 02:13 PM ]

@Ed
is it really possible to listen on "onclick" when the link will be openend in new tab via context menu?
I'm sure onclick won't be called.

Maybe we should never render the windowId to a link und just add via onclick.
We could store the windowId globally in a JS varable in in the listener, we could add it to the href.





[JAVASERVERFACES_SPEC_PUBLIC-1226] Inconsistent handling of null/undeclared attributes, especially with nested components Created: 07/Oct/13  Updated: 08/Nov/13

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

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

GF3 + JSF 2.1.26 or GF4 with JSF 2.2.3 with JDK7.0_45


Tags: composite composite-component null
Participants: fabmars

 Description   

The origin is here: https://java.net/jira/browse/JAVASERVERFACES-2614, but it's mainly worth reading the summary further down here.

The reproducer is on git@github.com:fabmars/JSF2614.git .
We have an outer component:

test1.xhtml
<composite:interface>
<composite:attribute name="val1" type="java.lang.String"/>
<composite:attribute name="val2" type="java.lang.String"/>
<composite:attribute name="val3" type="java.lang.String" default="#{null}"/>
<composite:attribute name="val4" type="java.lang.String" default="#{null}"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<h:outputText value="Outer1: #{cc.attrs.val1 == null ? 'null' : (empty cc.attrs.val1 ? 'empty' : cc.attrs.val1)}" />
<h:outputText value="Outer2: #{cc.attrs.val2 == null ? 'null' : (empty cc.attrs.val2 ? 'empty' : cc.attrs.val2)}" />
<h:outputText value="Outer3: #{cc.attrs.val3 == null ? 'null' : (empty cc.attrs.val3 ? 'empty' : cc.attrs.val3)}" />
<h:outputText value="Outer4: #{cc.attrs.val4 == null ? 'null' : (empty cc.attrs.val4 ? 'empty' : cc.attrs.val4)}" />
</h:panelGrid>
<sr:test2 val1="#{cc.attrs.val1}" val2="#{cc.attrs.val2}" val3="#{cc.attrs.val3}" val4="#{cc.attrs.val4}" /> 
</composite:implementation>

And an inner component:

test2.xhtml
<composite:interface>
	<composite:attribute name="val1" type="java.lang.String"/>
	<composite:attribute name="val2" type="java.lang.String" default="#{null}"/>
	<composite:attribute name="val3" type="java.lang.String"/>
	<composite:attribute name="val4" type="java.lang.String" default="#{null}"/>
</composite:interface>

<composite:implementation>
	<h:panelGrid>
		<h:outputText value="Inner1: #{cc.attrs.val1 == null ? 'null' : (empty cc.attrs.val1 ? 'empty' : cc.attrs.val1)}" />
		<h:outputText value="Inner2: #{cc.attrs.val2 == null ? 'null' : (empty cc.attrs.val2 ? 'empty' : cc.attrs.val2)}" />
		<h:outputText value="Inner3: #{cc.attrs.val3 == null ? 'null' : (empty cc.attrs.val3 ? 'empty' : cc.attrs.val3)}" />
		<h:outputText value="Inner4: #{cc.attrs.val4 == null ? 'null' : (empty cc.attrs.val4 ? 'empty' : cc.attrs.val4)}" />
	</h:panelGrid>
</composite:implementation>

And the actual page:

jsf2614.xhtml
<sr:test1 val1="AAA" val2="BBB" val3="CCC" val4="DDD"/>
<sr:test1/>
<sr:test1 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/>
<sr:test2  val1="DDD" val2="EEE" val3="FFF" val4="GGG"/>
<sr:test2/>
<sr:test2 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/>

When running one can notice a couple of odd things:

1st case:
On <sr:test1 .../>

  • feed <composite:attribute name="val1" type="java.lang.String"/> with null. Result: null
  • feed <composite:attribute name="val3" type="java.lang.String" default="#{null}"/> with null. Result: ""
    The developer, in the second line expects to get String var3 = null in the end. Instead he gets a real value.
    OK this is due to the mechanics of coertion but this is not consistent and imo should be fixed.


    2nd case:
    - Call the OUTER component dry <sr:test1/>. var1 isn't declared, so will be assumed null. In sr:test1 implementation is a call to <sr:test2 val1="#{cc.attrs.val1}"... The INNER(sr:test2) component is awaiting a String as val1 (<composite:attribute name="val1" type="java.lang.String"/>) and our non-declared attribute becomes "" (again) in the end! (see that lines 9 vs 13 of the output). In other words: feed a null to <composite:attribute name="val1" type="java.lang.String"/> directly, it stays null, feed it from a surrounding component, it becomes ""!


    3rd case:
    Calling directly the inner component <sr:test2/> and <sr:test2 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/> produce totally different results (see lines 29-32 vs 33-36 of the output). This is confusing for the developer and I'm not even sure this is a "feature".





[JAVASERVERFACES_SPEC_PUBLIC-1225] What to say about BCP47 Support? Created: 02/Oct/13  Updated: 08/Nov/13

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

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

Tags:
Participants: Ed Burns

 Description   

BCP47 defines new rules for the parsing of Locale objects. These rules are implemented in the java.util.Locale class in JDK7. There are several places in the JSF spec that place requirements on how a Locale is encoded as a String.

  • XSD for supported-locale
  • XSD for default-locale
  • Spec section "2.5.2.1 Determining the Active Locale" in the portion of that section that deals with the locale attribute on the <f:view> tag.

In all of these places statements are made regarding the use of "-" or "_" as a separator. This issue asks if we should go further and require the use of JDK7 Locale.forLanguageTag() to obtain the Locale instance before trying the existing methods of obtaining a Locale.






[JAVASERVERFACES_SPEC_PUBLIC-1224] HTML5 Form Validation Not Performed Before Ajax Submit Created: 30/Aug/13  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: rogerk

 Description   

Given an HTML5 form, with HTML% input types (such as email), form validation is not performed (for an invalid email entered) if the submit is over ajax.
This is because the current Ajax portion of the specification states specifically to collect form elements and pass on over ajax to server side.
We would need to specify (and implement) something to trigger form validation before even collecting elements for ajax submit.






[JAVASERVERFACES_SPEC_PUBLIC-1223] Facelet ui:param doesn't work in composite components (action) Created: 26/Mar/13  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: dasago Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1222 ValueChange method in POJO doesn't re... Open
Tags:
Participants: dasago, Ed Burns, Manfred Riem and Thomas

 Description   

If i have a facelet file which includes a composite component and I want to pass ui:params for the action it doesn't work

File a.xhtml includes my template myTemplate.xhtml. I want to pass parameters for an action

<ui:include src="/pages/templates/myTemplate.xhtml">
      <ui:param name="resetAction" value="reset" />
      <ui:param name="bean" value="#{myBean}" />
</ui:include>

Following works / works not in myTemplate.xhtml:

value is displayed

<h:outputText value="Bean: #{bean}" />

value is displayed

<h:outputText value="resetAction: #{resetAction}" />

Action doesn't work if i pass it into a compositeComponent

<myCom:reset resetAction="#{bean[resetAction]}" />

for a commandButton it works.

<p:commandButton value="test reset" action="#{bean[resetAction]}" />

If I don't add my composite component to a facelet tempalte the action also works:

<myCom:reset resetAction="#{myBean.reset}" />



 Comments   
Comment by Manfred Riem [ 09/Apr/13 03:55 PM ]

Can you send the entire reproducer (including all the sources) to issues@javaserverfaces.java.net?

Comment by dasago [ 10/Apr/13 08:51 AM ]

I send you an example project.. (maven based, JBoss 6.0 Final, Mojarra 2.1.17, PrimeFaces 3.5, Omnifaces 1.4.1)

First example in reset page works - pass values directly to composite component

Second example in reset page doesn't work - pass values via facelet file to composite component

Third example in reset page works - pass values via facelet file to composite component with a workaround of omnifaces

Comment by Manfred Riem [ 30/Aug/13 05:31 PM ]

You have hit upon an area with respect to composite components and ui:include that has not been ironed out as much as needed. The problem is that the context of the ui:param is not available within a retargetted expression that the action needs to actually work.

I am moving this to the spec issue tracker as the real issue still exists.

Comment by Thomas [ 30/Aug/13 09:13 PM ]

This is probably a better description of the JAVASERVERFACES_SPEC_PUBLIC-1222 issue I filed. Being a POJO or a managed bean is unrelated if I recall correctly.

I've been working around this by placing the ui:param in the view outside of the ui:include so that evaluations can find the ui:param correctly.

<ui:param name="pojoOrManagedBean" value="#{bean}"/>
<ui:include src="innerPageWithCompositeComponentWithTarget"/>
Comment by Ed Burns [ 13/Sep/13 09:21 PM ]

Manfred, do you think we can close 1222 as a duplicate of this one?

Ed





[JAVASERVERFACES_SPEC_PUBLIC-1222] ValueChange method in POJO doesn't resolve correctly when POJO is a ui:param Created: 09/Apr/13  Updated: 09/Sep/13

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

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

OS X 10.8.3


File Attachments: Zip Archive cc-ui-param.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1223 Facelet ui:param doesn't work in comp... Open
Tags:
Participants: Manfred Riem and Thomas

 Description   

Normally a composite component can resolve a valueChange method in a POJO that is a property of managed bean.

This is often used to pass a POJO to a <ui:include>:

<ui:include src="part.xhtml">
    <ui:param name="pojo" value="#{managedColors.unmanaged}"/>
</ui:include>

The using page would be:

<custom:list list="#{pojo.colors}"
             selected="#{pojo.color1}"
             valueChangeListener="#{pojo.onColorChange}">
    <f:ajax event="valueChange" execute="@this" render="@this"/>
</custom:list>

However, when the unmanaged bean (POJO) is passed as a <ui:param>, attempting to change the value will result in the following exception:

javax.faces.event.AbortProcessingException
/part.xhtml @10,62 valueChangeListener="#{pojo.onColorChange}":
The class 'com.custom.beans.PojoColors' does not have the property 'onColorChange'.

The valueChange method seems to only be resolved correctly be writing out the complete EL expression:

<custom:list selected="#{managedColors.unmanaged.color1}"
             list="#{managedColors.unmanaged.colors}"
             valueChangeListener="#{managedColors.unmanaged.onColorChange}">
    <f:ajax event="valueChange" execute="@this" render="@this"/>
</custom:list>

A simple example project for NetBeans has been attached detailing this issue.



 Comments   
Comment by Thomas [ 09/Apr/13 07:27 PM ]

I can attach a sample project reproducing this issue once I have permissions to attach files.

EDIT:
Here's a link to a sample NetBeans project detailing the issue: https://www.dropbox.com/sh/ojdj6mbykzpxr9t/svlgMUzFw4

Comment by Manfred Riem [ 09/Apr/13 08:21 PM ]

Please send your sample zip file to issues@javaserverfaces.java.net. Can you please try it on the latest 2.1 release? Thanks!

Comment by Thomas [ 09/Apr/13 09:32 PM ]

I've sent the sample zip project.

I've also reproduced this issue on the latest 2.1 release, which I believe is Implementation-Version: 2.1.20.

I did this by replacing the 2.1.6-SNAPSHOT version of javax.faces.jar in

/Applications/NetBeans/glassfish-3.1.2.2/glassfish/modules/javax.faces.jar

and confirming the new version 2.1.20 was loading via

FacesContext.class.getPackage().getImplementationVersion();

Thanks for the fast responses!

Comment by Thomas [ 10/Apr/13 07:12 PM ]

Just tried it on the latest javax.faces.jar 2.2.0-m13-SNAPSHOT and got the same type of error of:

The class 'com.custom.beans.PojoColors' does not have the property 'onColorChange'
Comment by Thomas [ 10/Apr/13 08:30 PM ]

Actually this doesn't seem to be a POJO issue, but something wrong with EL resolution on the ui:param in a composite component.

I tried passing a managed bean in a ui:param and got a property not found type of exception as well:

<ui:include src="part.xhtml">
   <ui:param name="managed" value="#{managedColors}" />
</ui:include>
<ui:composition ..>
    <custom:list list="#{managed.colors}"
               selected="#{managed.color1}"
               valueChangeListener="#{managed.onColorChange}">
      <f:ajax event="valueChange" execute="@this" render="@this"/>
  </custom:list>
</ui:composition>

Attempting to change the value results in the same type of error, except now it also occurs for a managed bean:

The class 'com.custom.beans.ManagedColors' does not have the property 'onColorChange'.
Comment by Manfred Riem [ 30/Aug/13 04:52 PM ]

You have hit upon an area with respect to composite components and ui:include that has not been ironed out as much as needed. The problem is that the context of the ui:param is not available within a retargetted method expression. And as such the resolution of the value expression is unable to find the 'pojo' variable.

You are aware that instead of using a ui:include you can pass a bean to a composite component as an attribute and then use the attribute to resolve to the valuenChange method?

I am moving this to the spec issue tracker as the real issue still exists.





[JAVASERVERFACES_SPEC_PUBLIC-1221] Please add support for populating data column headers from a list Created: 29/Aug/13  Updated: 08/Nov/13

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

Type: New Feature Priority: Major
Reporter: pratap_abhinav Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: pratap_abhinav

 Description   

Add support for populating data table headers from a managed bean list.

Eg.
Currently:

<h:datatable var="v" value=#{mybean.list}>
<h:column>
<f:facet name="header">
<h:outputText value="col1head"/>
</f:facet>
<h:outputText value=#{v.col1}/>
...
</h:column>
</h:datatable>

please add support for coding like this:
<h:datatable var="v" value=#{mybean}>
<h:columns>
<f:facet name="header">
<h:outputText value="#{v.col2headerList}"/>
</f:facet>
<h:outputText value=#{v.col1valuelist}/>

</h:columns>
...
</h:datatable>

or something like that as implemented in rich faces. It would be very useful for admin tool applications.






[JAVASERVERFACES_SPEC_PUBLIC-1220] Please add a attribute pagination="true", maxrows="" in h:datatable component of jsf. This will reduce a lot of coding and reduce dependency on another jsf implementations like primefaces. Created: 29/Aug/13  Updated: 08/Nov/13

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

Type: New Feature Priority: Major
Reporter: pratap_abhinav Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: pratap_abhinav

 Description   

Please add a attribute pagination="true", maxrows="" in h:datatable component of jsf. This will reduce a lot of coding and reduce dependency on another jsf implementations like primefaces






[JAVASERVERFACES_SPEC_PUBLIC-1219] Specify behavior in case of abandoned flow. Created: 26/Aug/13  Updated: 08/Nov/13

Status: Open
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: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 6 hours
Time Spent: Not Specified
Original Estimate: 6 hours

Issue Links:
Dependency
depends on JAVASERVERFACES-2997 None flow command actions navigation ... Closed
Tags:
Participants: Ed Burns

 Description   

Currently trying to navigate away from a flow by any means other than a flow-return or flow-call node will cause the navigation to silently fail. This approach has the nice property in that it prevents abandoned flows. Unfortunately, as JAVASERVERFACES-2997 shows, this approach is overly restrictive.

This issue calls for the spec to say what should happen when the flow is abandoned.



 Comments   
Comment by Ed Burns [ 26/Aug/13 05:11 PM ]

The fix for JAVASERVERFACES-2997 did the following.

When looking for a navigation match in the midst of the flow, if no other way of finding a match is found, look for an implicit match outside of the flow. If that's not found, look in the root navigation map using the same three step process in normal JSF navigation.





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

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

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

Tags:
Participants: AnnTea and Ed Burns

 Description   

The resource bundle for standard validation messages (see JSR-344 section 2.5.2.4) state
javax.faces.converter.ByteConverter.BYTE={2}: ''{0}'' must be a number between 0 and 255.
and
javax.faces.converter.ByteConverter.BYTE_detail={2}: ''{0}'' must be a number between 0 and 255. Example: {1}

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

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



 Comments   
Comment by Ed Burns [ 20/Aug/13 02:35 AM ]

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

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

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

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

M spec/frame/requestProcessingLifecycle.fm

  • Section 2.5.2.4

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

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

Comment by Ed Burns [ 20/Aug/13 02:20 PM ]

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

Comment by Ed Burns [ 20/Aug/13 02:21 PM ]

Hudson failures.

Comment by Ed Burns [ 20/Aug/13 02:21 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1217] EnumConverter.getAsString() javadoc contains incorrect text, conflicts with its own @returns clause Created: 15/Aug/13  Updated: 14/Feb/14

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes

Issue Links:
Related
is related to JAVASERVERFACES-2919 selectOneMenu + EnumConverter and nul... Closed
Tags:
Participants: Ed Burns

 Description   

The Javadoc for EnumConverter.getAsString() contains the text,

If the value argument is null, return null.

This is conflict with the @returns clause, and also with the super-interface declaration of the method.






[JAVASERVERFACES_SPEC_PUBLIC-1216] Inconsistent exception handling for phaselisteners Created: 14/Aug/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Major
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: frederickkaempfer

 Description   

Exception handling for phase listeners behaves differently depending on if they are registered globally in faces-config.xml or with f:phaseListener for a particular view root.

In the first (global) case any exception thrown by them gets forwarded to an exception handler as described in the spec.

In the second (per view root) case all exceptions get logged and swallowed as described in the UIViewRoot documentation.

This inconsistent behavior adds increased complexity when implementing PhaseListeners. Ideally both cases should forward any exception to the exception handler so they can be handled there.

See also the discussion of the problem in: https://java.net/jira/browse/JAVASERVERFACES-2985






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

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes

Tags:
Participants: Ed Burns

 Description   

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

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

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






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

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: Kim Haase Assignee: Kim Haase
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 28 minutes
Original Estimate: Not Specified

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

 Description   

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

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

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



 Comments   
Comment by Kim Haase [ 06/Aug/13 03:44 PM ]

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

Comment by Ed Burns [ 26/Aug/13 06:19 PM ]

Updated to avoid A11Y violations.

Comment by Ed Burns [ 26/Aug/13 06:23 PM ]

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

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

Thanks,

Ed

Comment by Kim Haase [ 26/Aug/13 06:44 PM ]

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

vdldocs/facelets/f/tld-summary.html

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

Comment by Ed Burns [ 27/Aug/13 02:42 PM ]

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

Comment by Kim Haase [ 27/Aug/13 05:46 PM ]

Thanks, Ed! The fix works.

Comment by Ed Burns [ 28/Aug/13 03:23 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1213] f:viewParam doesn't work when using xmlns:f="http://xmlns.jcp.org/jsf/core" Created: 06/Aug/13  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: irinipaci Assignee: Unassigned
Resolution: Unresolved Votes: 1
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
is duplicated by JAVAEETUTORIAL-238 NullPoint error in chapter 8.5 Compo... Closed
Tags:
Participants: irinipaci

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






[JAVASERVERFACES_SPEC_PUBLIC-1212] javax.faces.context.ExternalContext#getInitParameter : NullPointerException Restriction Needs To Be Removed. Created: 02/Aug/13  Updated: 02/Oct/13  Resolved: 02/Oct/13

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

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

Tags:
Participants: Ed Burns and rogerk

 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 07:34 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1211] UIOutput.resetValue() and UIInput.resetValue() produce unwanted state that is equal to the default values of the property accessor methods Created: 30/Jul/13  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle-1211.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-2965 UIData performance and state saving i... Closed
Tags:
Participants: Hanspeter Duennenberger

 Description   

UIOutput/UIInput resetState() call set methods that cause StateHelper to add state that actually is the same as the default values that would be returned by the respective get-methods.

Proposed state neutral solution is be to remove the state from StateHelper using getStatehelper().remove(PropertyKey.xxx).



 Comments   
Comment by Hanspeter Duennenberger [ 30/Jul/13 12:50 PM ]

if resetValue() would remove the state UIData could make use of UIInput.resetValue() while restoring descendant state iterating the rows.

Comment by Hanspeter Duennenberger [ 30/Jul/13 02:20 PM ]

Added changebundle containing the proposed changes.





[JAVASERVERFACES_SPEC_PUBLIC-1210] Account for BCP47 Created: 26/Jul/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator)
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to PORTLETSPEC3-6 Errata: Clarification for section "PL... Resolved
Tags:
Participants: Ed Burns

 Description   

Internet Best Current Practice 47 <http://tools.ietf.org/html/bcp47> defines new subtags for the "script" of a Locale. That is, the way in which the text is written. We need to update the JSF spec to account for this additional aspect of localization.

PORTLETSPEC3-6 mentions one area of impact,

<xsd:complexType name="faces-config-supported-localeType">

We also need to do this for default-locale.






[JAVASERVERFACES_SPEC_PUBLIC-1208] Allow page authors to define ordering of resources in the <head> Created: 10/Jul/13  Updated: 08/Nov/13

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

Type: New Feature Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75

 Description   

Right now, developers have no control over the ordering of resources loaded in the HEAD of the document. This can cause problems with ordering of CSS, JavaScript resources, or browser behavior. Something like PrimeFaces' solution (http://blog.primefaces.org/?p=1433) is definitely needed.

I ran into this requirement trying to force IE to use "IE 8 Standards Mode". This requires a <meta> header, but it must be the first element in the <head>. This isn't possible without a custom component or a third-party library like PrimeFaces.. See http://social.msdn.microsoft.com/Forums/ie/en-US/afb57ce6-d149-4a09-8811-63c0645c92e6/force-ie8-to-render-in-ie8-standard-mode.






[JAVASERVERFACES_SPEC_PUBLIC-1206] required attribute is not enforced for inputFile Created: 08/Jul/13  Updated: 10/Jul/13

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

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

glassfish 4.0, Firefox


Issue Links:
Related
is related to JAVASERVERFACES-2923 required attribute is not enforced fo... Closed
Tags: file file_upload require
Participants: Ed Burns, jasonzhang2002gmailcom and Manfred Riem

 Description   

When I select file at browser or not, I always have a part at server side. If no file is selected, the Part.size is zero.



 Comments   
Comment by Manfred Riem [ 08/Jul/13 08:39 PM ]

Can you please supply an example that reproduces the problem?

Comment by jasonzhang2002gmailcom [ 09/Jul/13 01:19 AM ]

This can be reproduced easily.

@RequestScoped
@Named
public class Test
{
	Part file;
	String str;
	public String getStr()
	{
		return str;
	}
	public void setStr(String str)
	{
		this.str = str;
	}
	public Part getFile()
	{
		return file;
	}
	public void setFile(Part file)
	{
		this.file = file;
	}
	public String save()
	{
		System.out.println("save is called");
		return null;
	}
}
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://xmlns.jcp.org/jsf/html"
	xmlns:f="http://xmlns.jcp.org/jsf/core"
	xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"
	xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
	
<h:body>
	<h:messages>
	</h:messages>
	<h:form enctype="multipart/form-data">
		<h:inputFile value="#{test.file}" id="file" required="true"></h:inputFile>
		<h:inputText value="#{test.str}" id="string" required="true"></h:inputText>
		<h:commandButton value="submit" action="#{test.save}">
		</h:commandButton>
	</h:form>
</h:body>
</html>
Comment by Ed Burns [ 09/Jul/13 08:33 PM ]

Manfred and I investigated this and determined that UIInput.isEmpty() doesn't correctly handle this case when there is a Part that is empty.

UIInput.isEmpty() was added in support of JAVASERVERFACES_SPEC_PUBLIC-426.





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

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

Type: Improvement Priority: Minor
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0,


Tags: html5
Participants: Ed Burns and jasonzhang2002gmailcom

 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 01:48 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1203] Empty String as Null is not effective in 2.2.0 Created: 04/Jul/13  Updated: 10/Apr/14

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

Type: Improvement Priority: Major
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0, EL 3.0


Issue Links:
Related
is related to JAVASERVERFACES-3071 javax.faces.INTERPRET_EMPTY_STRING_SU... Closed
Tags: null string
Participants: Ed Burns, jasonzhang2002gmailcom and rekiem87

 Description   

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

public class NullStringHanlder  extends ELResolver
{

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

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

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

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

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

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

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

}


 Comments   
Comment by Ed Burns [ 05/Jul/13 01:11 PM ]

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

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

Comment by jasonzhang2002gmailcom [ 05/Jul/13 08:11 PM ]

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

Comment by Ed Burns [ 08/Jul/13 01:46 PM ]

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

Comment by rekiem87 [ 10/Apr/14 08:47 PM ]

Glassfish 4.0.1 with the latest mojarra still have the issue





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

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

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

Tags:
Participants: Ed Burns

 Description   

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

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

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

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






[JAVASERVERFACES_SPEC_PUBLIC-1201] Require that the cookie used to store the Flash key is setHttpOnly(true) Created: 02/Jul/13  Updated: 02/Jul/13

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Issue Links:
Dependency
depends on JAVASERVERFACES-2911 For JSF 2.2 and beyond, do setHttpOnl... Closed
Tags:
Participants: Ed Burns

 Description   

Require that the cookie used to store the Flash key is setHttpOnly(true)






[JAVASERVERFACES_SPEC_PUBLIC-1200] Search parent naming containers for component Created: 28/Jun/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Minor
Reporter: aplossystems Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 15 minutes
Time Spent: Not Specified
Original Estimate: 15 minutes
Environment:

JSF 2.1.24


Tags:
Participants: aplossystems

 Description   

It's logical that when you have a tree of components you shouldn't look in the child naming containers for a relative id name as duplicates are likely to exist. However it doesn't seem logical to not look in the parent container and take the first avaiable component with that relative id as no duplicates will exist in a single layer above.

I've therefore made an simple update in the UIComponentBase that will look in the parent for the component for the relative id. There's a number of places that this will work more intuitively, especailly for people with a more basic knowledge of JSF. The first is when using relative id's within a dataTable or repeat, all of a sudden relative ids no longer work which is quite confusing if you don't know why. The second is that when you pass a relative id into a custom component it won't be able to find it as the custom component will do the find method relative to itself. The other is when using cc.clientId or similar within a custom component (granted you can just easily add a : beforehand in this scenario). I'm sure there's other times as well where this would come in useful.

Below is the code that would need to be put in place of the existing code, there's only about 5 lines of code actually changed, I've already run this through the JSF tests and everything appeared to pass :

[code]

// Identify the base component from which we will perform our search
UIComponent base = this;
UIComponent initialBase = null;
if (expr.charAt(0) == sepChar) {
// Absolute searches start at the root of the tree
while (base.getParent() != null) { base = base.getParent(); }
// Treat remainder of the expression as relative
expr = expr.substring(1);
} else if (!(base instanceof NamingContainer)) {
// Relative expressions start at the closest NamingContainer or root
while (base.getParent() != null) {
if (base instanceof NamingContainer) { break; }
base = base.getParent();
}
initialBase = base;
}

// Evaluate the search expression (now guaranteed to be relative)
UIComponent result = null;
String[] segments = expr.split(SEPARATOR_STRING);
for (int i = 0, length = (segments.length - 1);
i < segments.length;
i++, length--) {
result = findComponent(base, segments[i], (i == 0));
// the first element of the expression may match base.id
// (vs. a child if of base)
if (i == 0 && result == null &&
segments[i].equals(base.getId())) { result = base; }
if (result Unable to render embedded object: File (= null && () not found.(result instanceof NamingContainer)) && length > 0) { throw new IllegalArgumentException(segments[i]); }
if (result == null) { break; }
base = result;
}

if( result == null && initialBase != null && initialBase.getParent() != null ) { initialBase.getParent().findComponent(expr); }
[/code]






[JAVASERVERFACES_SPEC_PUBLIC-1199] Missing throws clauses in javadoc for implementing classes. Created: 11/Jun/13  Updated: 08/Nov/13

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

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

N/A


File Attachments: Text File file_list.txt    
Tags:
Participants: dougd

 Description   

It appears that when we leave the javadoc of an Implementing classes method(s), that we are not getting all the throws clauses that we should be.

Example:
javax.faces.validator.MethodExpressionValidator implements the javax.faces.components.Stateholder interface, and implements saveState & restoreState methods. The API documents for these methods are copied automatically fro the StateHolder interface javadocs, but the "throws" clause is not being copied. We might need to implicitly tell the javadoc too do do this by adding something like the below.

/**

  • {@inheritDoc}
    * @throws{@inheritDoc}

    */

I have attached a file that contains a list of classes that have the "Description copied from" string in there Javadoc at some point. This file should help whom ever needs to go through and clean up the classes.






[JAVASERVERFACES_SPEC_PUBLIC-1198] Specify behavior when multiple phase-listener decls with same FQCN are encountered Created: 11/Jun/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

The XSD for <phase-listener> states:

The "phase-listener" element contains the fully qualified class
name of the concrete PhaseListener implementation class that will
be registered on the Lifecycle.

What is the correct behavior if multiple decls with the exact same FQCN are encountered? I think it should be "last one wins, log a message if more than one".






[JAVASERVERFACES_SPEC_PUBLIC-1197] Support multiple attribute on h:inputFile Created: 10/Jun/13  Updated: 08/Nov/13

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

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-802 Ajax fileupload capabilities Closed
Tags:
Participants: Ed Burns

 Description   

HTML 5 has a new attribute on input file: multiple.

When present, the user agent must allow the file chooser to select multiple files.

While the pass through attributes feature allows this to render correctly:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
      xmlns:f="http://xmlns.jcp.org/jsf/core"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:p="http://xmlns.jcp.org/jsf/passthrough">
    <h:head></h:head>

    <h:form id="form" enctype="multipart/form-data" prependId="false">
        
        <p><h:inputFile id="file" value="#{fileUploadBean.uploadedFile}" p:multiple="multiple"> 
             <f:validator validatorId="FileValidator" />
           </h:inputFile>
        </p>
...

The renderer for javax.faces.Input javax.faces.File doesn't handle this case correctly.

Instead, as it iterates through the parts, it just overwrites the preceding part with each file in the uploaded collection.

I think a better strategy is to always have the value of the component be a List<Part> instead of just Part.






[JAVASERVERFACES_SPEC_PUBLIC-1196] CC-like conveniences for Facelet tags Created: 02/Jun/13  Updated: 08/Nov/13

Status: Open
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: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use ease_of_development facelets tag taglib
Participants: arjan tijms and Ed Burns

 Description   

In JSF 2.x there are composite components and Facelets tags. A prime difference between these two is that composite components become a component themselves in the component tree, while Facelets tags cause their "child" components to be inserted but they themselves do not become part of the tree.

Both these two artifacts have their own unique use cases, and thus the newer composite component cannot totally replace the older Facelet tags.

However, composite components being the more modern variant have several ease of use features such as the ability for being auto-registering when put into the /resources folder and the definition of its attributes directly into the defining .xhtml file.

Since Facelets tags are still very useful in modern JSF programming, I'd like to request them being upgraded to support auto-registering and attribute definition in the .xhtml file as well.

E.g.

/resources/mytag.xhtml
<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
    
    <ui:attribute name="foo" />
    
    ...
</ui:composition>

The above would register a Facelets tag just like the following in a -taglib.xml would do:

<tag>
    <tag-name>mytag</tag-name>
    <source>tags/mytag.xhtml</source>
    <attribute>
        <name>foo</name>	
    </attribute>
</tag>


 Comments   
Comment by Ed Burns [ 10/Jun/13 11:40 PM ]

This is a nice idea.





[JAVASERVERFACES_SPEC_PUBLIC-1195] cc.attrs not avaiable when rendering h:outputStyleSheet Created: 24/May/13  Updated: 08/Nov/13

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

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

Apache Tomcat 7.0.34 running in Windows 8


Tags: outputStyleSheet composite-component
Participants: tiagoperes

 Description   

Situation:
A composite component has its attributes declared with the "composite-attribute" tags, one of these attributes is "theme", used to specify the css file to be used by the component.

<composite:interface>
<composite:attribute name="theme" required="false" default="rose" />
...
</composite:interface>

At the component's implementation I try to import the css file using the "h:outputStyleSheet" tag.

<composite:implementation>
<h:outputStylesheet library="components" name="calendar/#{theme}/calendar.css" />
...
</composite:implementation>

Expected behavior:
If no attribute "theme" is specified by the page calling the component, "h:outputStylesheet" should import "calendar/rose/calendar.css". If a theme is specified it should import the specified theme.

Actual behavior:
"h:outputStylesheet" tries to import "calendar//calendar.css", no matter if a theme was specified or not.

My thoughts:
I tried to specify the theme directly inside the EL expression (name="#{'rose'}"), it worked, so it's not an expression problem. I think the cc.attrs variables are not available when "h:outputStylesheet" is processed.

There's a similar problem described in Stack Overflow:
http://stackoverflow.com/questions/7386344/evaluating-the-rendered-attribute-of-houtputstylesheet-inside-a-composite






[JAVASERVERFACES_SPEC_PUBLIC-1194] Make it so web-facelettaglibrary and web-facesconfig XSD files are canonically stored in javaee schemas workspace. Created: 22/May/13  Updated: 08/Nov/13

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

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File 20130523-web-partialresponse_2_2.xsds    
Tags:
Participants: Ed Burns

 Description   

This is the current workflow for updating the web-facelettaglibrary and web-facesconfig files in the javaee schemas workspace.

1. Use the NetBeans XML validator on the corresponding .xsd file
committed to the Mojarra workspace.

2. In the schema workspace, apply the instructions in doc/HOWTO to add
test content for new elements, and change test content for modified
elements, ensuring the tests are all wired up to execute in the
normal build process.

3. Copy the .xsd from the Mojarra workspace to the .xsds in the schema
workspace.

4. Ensure the tests all run cleanly.

5. Commit the changes in the schema workspace.

Instead, the workflow should be that the output from step 4. is taken to be the source of truth for the corresponding files in the JSF workspace.



 Comments   
Comment by Ed Burns [ 22/May/13 07:49 PM ]

The crux of this task is to modify the .xsds files so that what they produce is identical to what is in glassfish-4.0-b89.zip for the web-facelettaglibrary and web-facesconfig XSD files.

Comment by Ed Burns [ 23/May/13 03:45 PM ]

web-partialresponse also must be fixed.





[JAVASERVERFACES_SPEC_PUBLIC-1193] Declaring component attributes via annotations Created: 11/May/13  Updated: 08/Nov/13

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

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

Tags: ease-of-use ease_of_development no-xml annotation annotations
Participants: arjan tijms

 Description   

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

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

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

E.g.

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

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

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

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

}





[JAVASERVERFACES_SPEC_PUBLIC-1192] setProperties for validator behaviour is not there for mojarra-2.1.1 , Created: 09/May/13  Updated: 08/Nov/13

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

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

Tags:
Participants: dorarajappan

 Description   

issue reference https://issues.apache.org/jira/browse/MYFACES-1892

As shown in this dtd:
http://java.sun.com/dtd/web-facesconfig_1_1.dtd

the validator element in a faces-config.xml file should support nested attribute and property elements:

<validator>
<validator-id>xyValidtor</validator-name>
<validator-class>com.xy.XyValidator</validator-class>
<property>
<property-name>length</property-name>
<property-class>java.lang.Integer</property>
<default-value>40</default-value>
</property>
</validator>

However this appears to never have been implemented in either 1.1.x or 1.2.x of core; only validator-id and validator-class are supported. Note that the equivalent feature exists for converters, and does appear to have been implemented.

What is the reason reference implementation is not having this behaviour?






[JAVASERVERFACES_SPEC_PUBLIC-1191] SelectMany with generic collection results in ClassCastException Created: 07/May/13  Updated: 08/Nov/13

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

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

Glassfish 3.12


Tags: selectmanylistbox selectmanycheckbox generic collection
Participants: djmj

 Description   

Using a generic wrapper class similar to java.util.Map.Entry with a collection as generic value argument within a selectmany-component will result in following ClassCastException on submit:

Bean.java
private List<String> values;

private Entry<TestType, List<String>> entry;
site.xhtml
<h:selectManyMenu value="#{bean.entry.value}">
	<f:selectItems value="#{bean.values}"
		var="var" itemLabel="#{var}" itemValue="#{var}"/>
</h:selectManyMenu>

"java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to java.util.Collection"

(the Entry class does not works since it does not follows bean conventions, but its just for understanding of the generic problem)






[JAVASERVERFACES_SPEC_PUBLIC-1190] Extend facelet-taglib schema Created: 30/Apr/13  Updated: 08/Nov/13

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

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

Tags: taglib facelets
Participants: arjan tijms

 Description   

The Facelet taglib XML file has a number of limitations and it might be a good idea to improve the format.

Currently when a component inherits from another component, each and every attribute of the parent component has to be copied into the tag declaration in the taglib file. This makes taglib files very verbose and makes it hard to see which attribute the new tag introduces. A solution to this would be adding a way to declare that a tag inherits from another tag.

For instance:

<tag extends-namespace="http://java.sun.com/jsf/html" extends-tag="form">
    <tag-name>form</tag-name>
    <component>
        <component-type>org.example.Form</component-type>
    </component>

    <attribute>
        <description>
            Whether to include all URL (GET) request parameters in the action URI.
        </description>
        <name>includeRequestParams</name>
        <required>false</required>
        <type>boolean</type>
    </attribute>

    <!-- 20+ attributes of h:form such as "render", "accept", etc inherited -->
</tag>

Components in JSF can introduce an (EL) variable for their children to consume, e.g. like the var attribute of a datatable. This can however not be declared in a taglib, so tools have to have hardcoded knowledge of which tag does what with which attribute. This means tools lack behind new tags from a certain component library and only well known component libraries are supported. It would be great if it could be declared that an attribute represents the name of an introduced (EL) variable.

For instance:

<attribute>
    <description>
        Name of a request-scope attribute under which the model data for the
        row selected by the current value of the "rowIndex" property
        (i.e. also the current value of the "rowData" property) will be exposed.
    </description>
    <name>var</name>
    <required>false</required>
    <type>java.lang.String</type>
    <output>
        <scope>request</scope>
        <type-ref-attribute>value</type-ref-attribute>
        <type-ref-collection-element>true</type-ref-collection-element>
    </output>
</attribute>

In the above example var is declared to be an "output variable", that has as its type the type of the "collection element" that's bound to the value attribute. E.g. if value is bound to a List<Foo>, then the type of var is Foo. Other options would be setting a fixed type or referring directly to the type of another attribute.

Another issue is that attributes often have a default and an allowed range of values. This now has to be communicated in the description of an attribute and that description has to be kept in sync with the actual code. Tools sometimes have hardcoded knowledge of the allowed values (for auto-completion and warning flagging) for some attribute, but this too can be out of sync with newer releases of a component lib and doesn't support lesser known or internal components.

It would help a lot of this could be declared in a taglib file as well. E.g.:

<attribute>
    <description>The ordering type.</description>
    <name>type</name>
    <required>false</required>
    <type>java.lang.String</type>
    <allowed-values>lt, lte, gt, gte</allowed-values>
    <default>lt</default>
</attribute>

Some JSF components, like e.g. datatable support multiple types for a given attribute. It might be an improvement if these types could be enumerated in the attribute's declaration, e.g.

<attribute>
    <description>
        The current value of this component.
    </description>
    <name>value</name>
    <required>false</required>
    <types>
        <type>javax.faces.model.DataModel</type>
        <type>java.util.List</type>
        <type>java.lang.Object[]</type>
        <type>java.sql.ResultSet</type>
        <type>javax.servlet.jsp.jstl.sql.Result</type>
        <type>java.util.Collection</type>
        <type>java.lang.Object </type>
    <types>
</attribute>

I'm sure there might be some other areas where taglib files can be improved besides the use cases mentioned above.






[JAVASERVERFACES_SPEC_PUBLIC-1189] Flow identifier in @FlowDefinition Created: 29/Apr/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Major
Reporter: arungupta Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fishcat
Participants: arungupta

 Description   

@Produces @FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { String flowId = "flow1"; flowBuilder.id("unique", flowId); flowBuilder.viewNode(flowId, "/" + flowId + "/" + flowId + ".xhtml").markAsStartNode(); return flowBuilder.getFlow(); }

can be simplified to:

@Produces @FlowDefinition("flow1")
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { ... }






[JAVASERVERFACES_SPEC_PUBLIC-1188] Specify what should happen if the same flow is defined both in XML and via @FlowDefinition Created: 29/Apr/13  Updated: 08/Nov/13

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

The spec for FlowHandler.addFlow() requires an IllegalStateException be thrown if there is already a flow with the same identification as the one trying to be added.

The spec does not say the ordering in which flows should be added

XML then Java
Java then XML

This needs to be clarified.






[JAVASERVERFACES_SPEC_PUBLIC-1187] SelectItem ignores null value if used with converter that returns null Created: 27/Apr/13  Updated: 08/Nov/13

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

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

Glassfish 3.1.2


Tags: converter selectItem selectItems
Participants: djmj

 Description   

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

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

site.xhtml
<f:selectItem itemLabel="None" itemValue="#{null}"/>
TestConverter.java
@Override
public String getAsString(final FacesContext context, final UIComponent component, final Object value)
{
	if (value == null)
		return null;
	else
		return String.valueOf(value);
}

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

	// convert string to object here just example

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

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

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

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

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






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

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

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

Tags:
Participants: Ed Burns and marfous

 Description   

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

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

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



 Comments   
Comment by marfous [ 02/May/13 05:51 AM ]

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

Comment by marfous [ 06/May/13 07:19 AM ]

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

Thanks in advance.

Comment by Ed Burns [ 27/Aug/13 06:40 PM ]

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

Comment by Ed Burns [ 27/Aug/13 06:49 PM ]

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

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




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

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

Type: Bug Priority: Major
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bruno Borges, Ed Burns, Frank Caputo and jyeary

 Description   

Tried the following code:

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

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



 Comments   
Comment by Bruno Borges [ 13/Aug/13 05:34 AM ]

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

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

Sample A

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

Sample B

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

Either samples should end up with this:

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

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

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

Comment by Bruno Borges [ 13/Aug/13 06:37 AM ]

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

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

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

Comment by jyeary [ 13/Aug/13 03:21 PM ]

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

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

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

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

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

Comment by Bruno Borges [ 13/Aug/13 04:01 PM ]

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

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

Comment by Ed Burns [ 28/Aug/13 08:43 PM ]

From the spec section cited by John and Frank:

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

Consider Bruno's original markup:

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

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

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

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

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

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





[JAVASERVERFACES_SPEC_PUBLIC-1184] Support using JSON for component updates instead of XML Created: 22/Apr/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and kito75

 Description   

One of the primary complaints about JSF is speed. We have paid a lot
of attention to optimizing server-side state over the past few years,
but we can also optimize the processing on the client. When a
component is updated via Ajax, currently we render the entire
component, even if only one property has changed. It would be much
more efficient if we sent only the changed properties via JSON and let
the client-side representation of the component update itself
accordingly. I have implemented a limited version of this for one of
my clients, and Ajax updates are noticeably faster. Updating the spec
to support this would not be a major change (because components would
opt-in to this feature), but it would have a dramatic affect on
client-side Ajax updates.

Initial EG thread: https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/105

I will post a more formal proposal later.



 Comments   
Comment by arjan tijms [ 11/May/13 04:19 PM ]

This sounds very useful! The title may not tell the whole story though; it's thus not just about JSON vs XML, but also about doing delta updates instead of full updates, right?

Comment by kito75 [ 13/May/13 12:36 PM ]

Arjun, you're exactly right.





[JAVASERVERFACES_SPEC_PUBLIC-1183] selectMany components swallow/forgets preselected disabled SeletItems Created: 18/Apr/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2555 selectMany components swallow/forgets... Closed
Tags:
Participants: Hanspeter Duennenberger and Manfred Riem

 Description   

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

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

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

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



 Comments   
Comment by Manfred Riem [ 18/Apr/13 02:25 PM ]

Please see associated issue for attachments





[JAVASERVERFACES_SPEC_PUBLIC-1182] Implement new requirements for ViewState multi-form case in Ajax Created: 08/Nov/12  Updated: 17/Apr/13

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

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

Tags:
Participants: Ed Burns and rogerk

 Description   

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

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

EB> I added this sentence:

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

This is in jsf.js.



 Comments   
Comment by Ed Burns [ 30/Jan/13 07:38 PM ]

Move to m10.

Comment by rogerk [ 13/Mar/13 04:05 PM ]

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





Support for WAI ARIA (JAVASERVERFACES_SPEC_PUBLIC-462)

[JAVASERVERFACES_SPEC_PUBLIC-1181] Add support for WAI-ARIA to standard input components Created: 10/Apr/13  Updated: 08/Nov/13

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

Type: Sub-task Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75

 Description   

In cases where ARIA attributes have a reasonable mapping to existing component-level properties (eg. aria-required can be mapped to <h:inputText>'s required attribute, aria-invalid can be mapped to the EditableValueHolder's valid state), we should enhance the standard Renderers to automatically render the ARIA attributes. For other ARIA attributes, passthrough attributes can be used.

This task requires an analysis of the input controls to determine which ones need changes, but generally speaking any UI component that maps to a native HTML widget should support aria-invald and aria-rquired attributes, and possibly aria-readonly. For a full list of support states and properties, see: http://www.w3.org/TR/wai-aria/states_and_properties#state_prop_def.

Original thread: http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2013-03/message/124






[JAVASERVERFACES_SPEC_PUBLIC-1180] Do not include empty view params using `includeViewParams=true` Created: 07/Apr/13  Updated: 08/Nov/13

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

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

Glassfish 3.12


Tags: includeviewparams navigation
Participants: djmj

 Description   

Having a command component with an action attribute and using 'includeViewParams=true' using Navigation will include all view parameters defined in `f:metadata`.

But empty parameters are passed as String representations creating ugly url's.

'site.xhtml?key1=value1&key2=&key3='



 Comments   
Comment by djmj [ 27/Apr/13 06:28 PM ]

In my Converter's I return now null instead of empty String. Since it seems null value's won't be included.

But this leads to other issue: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1187





[JAVASERVERFACES_SPEC_PUBLIC-1179] Clarify UIComponent.encodeAll requirements Created: 04/Apr/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Minor
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: aschwart

 Description   

As requested by Manfred here:

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

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

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






[JAVASERVERFACES_SPEC_PUBLIC-1178] Remove references to old XML schema and tag library URI Created: 01/Apr/13  Updated: 08/Nov/13

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

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

Arun P. Gupta reported numerous instances of the old namespaces in the PDF. These should be fixed.






[JAVASERVERFACES_SPEC_PUBLIC-1177] Make it so com.sun.faces.faceletCache works with caching with respect to Resource Library Contracts Created: 20/Dec/12  Updated: 28/Mar/13

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2655 DefaultFaceletFactory.needsToBeRefres... Closed
Tags:
Participants: Ed Burns

 Description   

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



 Comments   
Comment by Ed Burns [ 30/Jan/13 08:35 PM ]

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





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

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

Type: New Feature Priority: Major
Reporter: djmj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: action outcome separate view logic
Participants: djmj, Ed Burns and Manfred Riem

 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 10:31 PM ]

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 11:26 PM ]

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 12:43 AM ]

Re-open.





[JAVASERVERFACES_SPEC_PUBLIC-1175] Validation error removes all url parameters Created: 18/Mar/13  Updated: 08/Nov/13

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

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

Tags:
Participants: a_ilyin and arjan tijms

 Description   

This bug was copied from Mojarra issue tracker. See details here:
http://java.net/jira/browse/JAVASERVERFACES-1653

When page has some url parameter(s) after server-side validation error or by
default navigation JSF navigates to the page with the same viewId but without
url parameters.

IMHO the problem is the POST method submits the form to viewId's url only
instead of using url with the parameters as original url has.

This issue makes problems with bookmarking such views with params after handling
some action(minor problem) and generating proper response after action handling
based on this parameters(major problem) .

P.S. Also this issue has another side effect. When handling some action the url
parameters are unavailable.

--------------------
I found some easy workaround for this problem.

I just slightly extend standard ViewHandler to add the queryString to the action
url:

public class UrlWorkaroundMultiViewHandler extends MultiViewHandler {

@Override
public String getActionURL(FacesContext context, String viewId) {

String result = super.getActionURL(context, viewId);
String queryString = ((HttpServletRequest) context.getExternalContext()
.getRequest()).getQueryString();
if (queryString != null) { result += "?" + queryString; }
return result;

}
}

and register it in the faces-config.xml

<application>

<view-handler>my.workaround.UrlWorkaroundMultiViewHandler</view-handler>
</application>

I'm not sure this will work for any cases and for all servlet containers. Also
I'm not sure about possible side effects.
I did check it with Jetty.

-----------------------------
UPDATE: I found that we have not add params when we handle new url. So I modify my workaround code to handle more cases:

@Override
public String getActionURL(FacesContext context, String viewId) {

String result = super.getActionURL(context, viewId);

HttpServletRequest request = ((HttpServletRequest) context
.getExternalContext().getRequest());

if (viewId.equals(request.getServletPath())) {
//Do it just if we are on the same page
String qs = request.getQueryString();
if (qs != null) { result += "?" + qs; }
}

return result;

}
===============================================
Conclusion: I believe that any valid url should be preserved as is(including query parameters). Even we do not use its url parmas on our page.



 Comments   
Comment by arjan tijms [ 20/Mar/13 04:02 PM ]

This looks like a duplicate of JAVASERVERFACES_SPEC_PUBLIC-1163.





[JAVASERVERFACES_SPEC_PUBLIC-1174] rendered on any html5 component Created: 17/Mar/13  Updated: 11/Nov/13  Resolved: 11/Nov/13

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

Type: New Feature Priority: Major
Reporter: gabz90 Assignee: Unassigned
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and gabz90

 Description   

Sometimes I find myself creating <h:panelGroup> or containers just to use the rendered attribute on some html markup. It would be quite amazing if I could annotate any html with the jsf:rendered attribute and have JSF create a component behind the scenes to encapsulate that markup. that way I could just do <div jsf:rendered="#{isLoggedIn}>...content...</div>. Maybe a component dedicated for that purpose could be created (just to hold the html markup that is), excuse me is this is already possible, but I often find myself wishing this feature were available.



 Comments   
Comment by Ed Burns [ 11/Nov/13 07:16 PM ]

I'm happy to report this just works with the HTML5 passthrough element support. Check this:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:myNS="http://xmlns.jcp.org/jsf">
    
    <div myNS:rendered="true">

<form myNS:id="form">
    
    <input name="textField" type="text" myNS:value="#{bean.text1}" />

    <input type="submit" myNS:id="submitButton" value="submit" />
    
    <p>submitted text: #{bean.text1}.</p>

</form>
        
    </div>

</html>

The rhs of the rendered attribute can just as well be an EL expression.





[JAVASERVERFACES_SPEC_PUBLIC-1173] Handle gracefully the case of a link to flow based page copied to new browser tab Created: 16/Mar/13  Updated: 08/Nov/13

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

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

Tags:
Participants: Ed Burns

 Description   

> LU> Hi
> LU> I have been checking the proposal for OutcomeTarget navigation in deep. In few
> LU> words, the critical point is what clientWindowTransition() should do and how
> LU> to encode GET links properly.
>
> LU> Let's consider again this use case :
>
> LU> (suppose the flow document id is flowDoc2)
>
> LU> <faces-flow-definition id="flow2">
> LU> <flow-return id="exit2">
> LU> <navigation-case>
> LU> <from-outcome>exit1</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
>
> LU> (suppose the flow document id is flowDoc1)
>
> LU> <faces-flow-definition id="flow1">
> LU> <flow-return id="exit1">
> LU> <navigation-case>
> LU> <from-outcome>mainpage</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
>
> LU> Suppose we are in /flow2/mypage.xhtml and there is a link to exit the flow. How
> LU> it should looks like? according to what I can deduct from the spec it should
> LU> be something like this:
>
> LU> http://localhost:8080/myapp/mainpage.xhtml?jffi=exit2&jftfdi=flowDoc2
>
> LU> In theory the link should work as long as the flow stack is:
>
> LU> flow2
> LU> flow1
> LU> root
>
> LU> But what happen if I copy the link into a new browser tab?
>
> That is not supposed to work because, by definition, the flow system is
> entirely built on ClientWindow, which, by definition is bound to a
> browser view (such as a tab or window).
>

Yes, I know it does not work, it should not work, but the problem is how faces
flow fails under such circumstance.

When this could happen? a session expiration is a good example. Since there
is no ViewState, there will not be ViewExpiredException, and the link will be
sent by the user without notice.

The point is if that scenario happens (which is probably), faces flow should be
able to recognize the situation with a simple check and do something like
throw an exception or exit the flow.

Other situation when this is relevant is what happen if you hit the same link
twice. The first time it gets out of the flow, but the second time you
are already
out. Again it is up to the user detect that kind of failure doing its
own logic to
check if the request is valid, but faces flow could do it for you just checking
one query param.

In a previous conversation, it was mentioned that "... a flow has a single front
door ..." and that it has "... well defined entry and exit points
...". My concern
here is that theorically it is possible to enter into a flow without go through
the start node, and there are simple exit cases with "unknown" results.






[JAVASERVERFACES_SPEC_PUBLIC-1172] ClientWindow: deal gracefully with multiple client windows having the same id Created: 13/Mar/13  Updated: 08/Nov/13

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

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

AS> + * <p>In addition to the hidden field already described. The runtime
AS> + * must ensure that any component that renders a hyperlink that causes
AS> + * the user agent to send a GET request to the Faces server when it is
AS> + * clicked has a query parameter with a name and value specified in
AS> + * {@link ResponseStateManager#CLIENT_WINDOW_URL_PARAM}. This
AS> + * requirement is met by several of the "encode" methods on {@link AS> + * javax.faces.context.ExternalContext}. See {@link AS> + * javax.faces.context.ExternalContext#encodeActionURL(java.lang.String) AS> + * } for details.</p>

AS> What is the expected behavior when the end user creates a second browser
AS> tab/window with an existing window id? For example, this can happen by:

AS> - Bookmarking an url with a window id and opening that URL in multiple tabs.
AS> - Copying and pasting an url from one tab into a second tab.
AS> - (On some browsers) Using the browser's "New Window" action.

AS> For each of the above cases, each window/tab should be assigned its own
AS> unique id, even though it would require additional work to determine
AS> when a client window id has been copied across windows/tabs






[JAVASERVERFACES_SPEC_PUBLIC-1171] Specify interaction of Stateless and CSRF protection Created: 13/Mar/13  Updated: 08/Nov/13

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

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and kithouna

 Description   

LU> 2. Stateless views that needs to be protected against CSRF attack, must
LU> include its token in javax.faces.ViewState field as if it was the view
LU> state, but only contains the info related to the secret stored in session
LU> or encoded/encrypted when client side state saving is used. In few words
LU> if the view is protected, javax.faces.ViewState generation may requires
LU> additional steps.



 Comments   
Comment by kithouna [ 14/Mar/13 09:31 AM ]

Don't stateless views also loose the implicit CSRF protection offerd by the required view state Id that stateful views have?





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

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

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Tags:
Participants: Ed Burns

 Description   

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



 Comments   
Comment by Ed Burns [ 27/Feb/13 02:08 PM ]

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

Comment by Ed Burns [ 27/Feb/13 02:11 PM ]

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

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

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

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

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

Comment by Ed Burns [ 27/Feb/13 08:53 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1169] Convert namespace URIs to use new hostname: xmlns.jcp.org instead of java.sun.com. Created: 04/Feb/13  Updated: 26/Jun/13  Resolved: 26/Jun/13

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

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 2 days, 23 hours
Time Spent: 1 hour
Original Estimate: 3 days

Issue Links:
Dependency
blocks JAVASERVERFACES-2764 Apply java.sun.com -> xmlns.jcp.org c... Closed
Tags:
Participants: Ed Burns

 Description   

Per Bill Shannon, all newly created XML namespaced artifacts in JSF 2.2 must use the new xmlns.jcp.org hostname instead of java.sun.com. For example, the faces-config.xml schema will be <http://xmlns.jcp.org/xml/ns/javaee> instead of <http://java.sun.com/xml/ns/javaee>.



 Comments   
Comment by Ed Burns [ 06/Feb/13 02:13 PM ]

EB> Pass Through Attributes
EB>
EB> http://java.sun.com/jsf/passthrough
EB>
EB> becomes

http://xmlns.jcp.org/xml/ns/jsf/passthrough

EB> Pass Through Elements
EB>
EB> http://java.sun.com/jsf
EB>
EB> becomes

http://xmlns.jcp.org/xml/ns/jsf

Comment by Ed Burns [ 06/Feb/13 02:14 PM ]

EB> * Looking at overview-summary in JSF 2.2 you can see that there are three new XSD files in JSF
EB> 2.2. They are all increments of anologous files in JSF 2.1. All of
EB> these will use the new XML ns.





[JAVASERVERFACES_SPEC_PUBLIC-1168] Make web-partialresponse_2_2.xsd w/r/t "Insert" Element Match Jsdocs. Created: 23/Feb/13  Updated: 27/Feb/13  Resolved: 27/Feb/13

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

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

Tags:
Participants: Ed Burns and rogerk

 Description   

Currently the web-partialresponse_2_2.xsd schema w/r/t insert element processing does not match the jsdocs for the implementation. This was a feature requested by ICESoft for 2.0, and based on their response we should change the schema to match the jsdocs.



 Comments   
Comment by Ed Burns [ 27/Feb/13 02:30 PM ]

Task order

1. Roger confirms the existing impl is correct with respect to design intent, and makes any necessary changes.

2. Ed updates the XSD to match the impl.

3. Roger updates the JSDoc to match the XSD and impl.

Comment by rogerk [ 27/Feb/13 05:11 PM ]

The schema must match this response format:

<partial-response id="j_id1"><changes><insert><before id="alpha"><![CDATA[This is before text]]></before></insert></changes></partial-response>

and for insert after:

<partial-response id="j_id1"><changes><insert><after id="alpha"><![CDATA[This is after text]]></after></insert></changes></partial-response>

The jsdocs will be updated as:

  • <p><i>Insert Element Processing</i></p>
  • <li>If an <code><insert></code> element is found in
  • the response with a nested <code><before></code>
  • element:
  • <pre><code><insert>
  • <before id="before id">
  • <![CDATA[...]]>
  • </before>
  • </insert></code></pre>
  • <ul>
  • <li>Extract this <code><before></code> element's <code>CDATA</code> contents
  • from the response.</li>
  • <li>Find the DOM element whose identifier matches <code>before id</code> and insert
  • the <code><before></code> element's <code>CDATA</code> content before
  • the DOM element in the document.</li>
  • </ul>
  • </li>
  • <li>If an <code><insert></code> element is found in
  • the response with a nested <code><after></code>
  • element:
  • <pre><code><insert>
  • <after id="after id">
  • <![CDATA[...]]>
  • </after>
  • </insert></code></pre>
  • <ul>
  • <li>Extract this <code><after></code> element's <code>CDATA</code> contents
  • from the response.</li>
  • <li>Find the DOM element whose identifier matches <code>after id</code> and insert
  • the <code><after></code> element's <code>CDATA</code> content after
  • the DOM element in the document.</li>
  • </ul>
  • </li>

The jsdocs update is part of http://java.net/jira/browse/JAVASERVERFACES-2752

Comment by Ed Burns [ 27/Feb/13 06:27 PM ]

The JSDocs look good.





[JAVASERVERFACES_SPEC_PUBLIC-1167] <f:selectItems> itemLabelEscaped: if not specified, behave as if true. Created: 22/Feb/13  Updated: 22/Feb/13  Resolved: 22/Feb/13

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

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 22 minutes
Time Spent: 8 minutes
Original Estimate: 30 minutes

Issue Links:
Dependency
blocks JAVASERVERFACES-2747 XSS hole: GenericObjectSelectItem inc... Closed
Tags:
Participants: Ed Burns

 Description   

See http://java.net/jira/browse/JAVASERVERFACES-2747






[JAVASERVERFACES_SPEC_PUBLIC-1166] Make it so proper license is included and linked from Javadocs Created: 19/Feb/13  Updated: 19/Feb/13  Resolved: 19/Feb/13

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

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 45 minutes
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

See http://aseng-wiki.us.oracle.com/asengwiki/display/JavaEE/JavadocsSpecLicense






[JAVASERVERFACES_SPEC_PUBLIC-1165] Leverage the default "value" attribute of an annotation to be the flow id of a @FlowScoped bean Created: 18/Feb/13  Updated: 22/Feb/13  Resolved: 22/Feb/13

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 25 minutes
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-730 Make flows reusable Closed
Tags:
Participants: Ed Burns

 Description   

Hello Experts,

This came in on the users list.

>>>>> On Mon, 11 Feb 2013 07:01:07 -0800, Edward Burns said:

>>>>> On Thu, 24 Jan 2013 17:49:23 +0000 (GMT), said:
AG> I was wondering if any discussions have happened around changing
AG> @FlowScoped(id="...") to @FlowScoped(value="..."). This will make my
AG> bean declaration cleaner.

AG> @FlowScoped("foo")
AG> public class MyBean implements Serializable { AG> }

AG> instead of

AG> @FlowScoped(id="foo")
AG> public class MyBean implements Serializable { AG> }}

AG> Comments ?

EB> Yes, I like that idea.

EB> I'll do it that way instead.

Any objections?

Ed






[JAVASERVERFACES_SPEC_PUBLIC-1164] Leverage EL 3.0 if present. Created: 15/Feb/13  Updated: 15/Feb/13  Resolved: 15/Feb/13

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 2 hours, 25 minutes
Time Spent: 35 minutes
Original Estimate: 3 hours

Issue Links:
Dependency
blocks JAVASERVERFACES-2742 Leverage EL 3.0 if present. Closed
Tags:
Participants: Ed Burns

 Description   

>>>>> On Thu, 14 Feb 2013 16:00:29 -0800, Kin-man Chung said:

KC> The amount of work to support EL 3.0 is really small
KC> The following is what is done for JSP (from the change log):

KC> 3. Support EL 3.0 (JSR 341).
KC> In JSP.2.9, add the following two ELResovers, after item 2, and renumberKC> the other ELResolvers on the list. That is, place these ELResolvers
KC> between
KC> the custom ELResolvers and the MapELResolver.

KC> 3. The ELResolver returned by ExpressionFactory.getStreamELResolver().
KC> 4. javax.el.StaticFieldELResolver.






[JAVASERVERFACES_SPEC_PUBLIC-1163] Keep State Encoded in the Request URL For Postbacks Created: 14/Feb/13  Updated: 08/Nov/13

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

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

Tags:
Participants: arjan tijms and rogerkeays

 Description   

Hi,

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

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

We can fix this fairly easily.

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

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

or

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

instead of

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

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



 Comments   
Comment by arjan tijms [ 20/Mar/13 04:24 PM ]

JAVASERVERFACES_SPEC_PUBLIC-1175 seems to ask for the same thing.

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

Comment by arjan tijms [ 20/Mar/13 04:26 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1162] Dynamically created ClientBehaviors do not call addComponentResource Created: 07/Feb/13  Updated: 08/Nov/13

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

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

Both Mojarra and MyFaces 2.1.x implementations behave the same


Tags:
Participants: kennardconsulting

 Description   
  • If I dynamically create UIComponents using the new Application.createComponent( context, componentType, rendererType ), I find they automatically add any dependent resources (JS/CSS) to the h:head. This is fantastic.
  • If I dynamically create ClientBehaviours using Application.createBehavior( id ), no dependent resources get added.

Am I supposed to add such resources manually? For example:

UIOutput js = new UIOutput();
js.setRendererType("javax.faces.resource.Script");
js.getAttributes().put("library", "mylibrary");
js.getAttributes().put("name", "bar.js");

FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().addComponentResource(context, js, "head");

If so, how am I supposed to know what they are? For example, if I am dynamically adding an AjaxBehavior the exact name of the JavaScript file depends on which JSF implementation I am using.

Also logged as https://issues.apache.org/jira/browse/MYFACES-3610 (but got no response, so I'm trying it as a spec issue)



 Comments   
Comment by kennardconsulting [ 07/Feb/13 02:45 AM ]

The MyFaces team have indicated this may be a bug in the spec:

"the reason it does not work is because javax.faces.component.behavior.AjaxBehavior does not have @ResourceDependency attached"
https://issues.apache.org/jira/browse/MYFACES-3610

Could you please discuss?

Comment by kennardconsulting [ 08/Feb/13 12:51 AM ]

I checked javax.faces.component.behavior.AjaxBehaviour.java in the latest 2.2 snapshot...

https://maven.java.net/content/repositories/snapshots/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20130207.091549-141-sources.jar

...and it doesn't appear to be annotated there either?





[JAVASERVERFACES_SPEC_PUBLIC-1161] CSRF protection cannot be used "out of the box" without create a custom component or override forcefully ExternalContext Created: 05/Feb/13  Updated: 05/Feb/13  Resolved: 05/Feb/13

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

Type: Improvement Priority: Major
Reporter: lu4242 Assignee: rogerk
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns, lu4242 and rogerk

 Description   

In JAVASERVERFACES_SPEC_PUBLIC-869 it was specified CSRF view protection for GET request but there is no way to use this improvement "out of the box".

For example, for use ClientWindow API there is an attribute called disableClientWindow for h:link and h:button.

A param in h:link / h:button like enableViewProtection or something like that could be helpful.

There are only two ways to use it?

1. override ExternalContext methods and include the param in encodeBookmarkableURL / encodeRedirectURL

or

2. create a custom link or button component, do the same stuff h:button or h:link renderer does but append the CSRF query param, and use it in every place.

One way or another, this looks bad.

The suggested way to fix it is apply the same pattern used for ClientWindow:

public static void enableViewProtection(FacesContext context)
public static void disableViewProtection(FacesContext context)
public static boolean isViewProtectionEnabled(FacesContext context)

And add a param in h:link / h:button like enableViewProtection .

The change is pretty straighforward.

My concern about this issue is that without this improvement, the CSRF solution looks broken for users (a feature that can't be used without write the same boilerplate over and over), and without it portlet compatibility looks broken too.



 Comments   
Comment by Ed Burns [ 05/Feb/13 03:20 PM ]

The CSRF protection feature was desgined to be similar to how view
protection works in Servlet. Specifically, the designation of which
views are protected is done in a central place rather than in any
specific views, or in specific UI components within views.

Leonardo, why do you feel it is necessary to pollute the view with this
information? Looking at the latest spec [1], look at the generated HTML
for the "faces-config XML Schema Documentation" link. Within there look
at the spec for faces-config-protected-viewsType. It says.

Any view that matches any of the url-patterns in this element may only
be reached from another JSF view in the same web application. Because
the runtime is aware of which views are protected, any navigation from
an unprotected view to a protected view is automatically subject to
protection.

I really don't see why this has to be a per-component decision. I'm
going to close this as "works as designed" but if after reading this
response you and someone else on this list disagree, please re-open
it. At this point, I welcome all challenges, but I have a high bar if I
think it's already designed correctly.

Remember, as we discussed yesterday, getting the view loading story
right with respect to composite components, templates and regular views
within resource libraries, contracts, and flows, is my most pressing
concern, spec wise. Anything else takes away time from that vital
concern.

Ed

[1] http://jsf-spec.java.net/SNAPSHOT/javadoc/





[JAVASERVERFACES_SPEC_PUBLIC-1160] Clarify intended workings of includeViewParams Created: 29/Jan/13  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2260 includeViewParams does not work Closed
Tags:
Participants: Manfred Riem

 Description   

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






[JAVASERVERFACES_SPEC_PUBLIC-1159] Add support for WAI-ARIA aria-live property for portions of the page updated via <f:ajax> Created: 28/Jan/13  Updated: 08/Nov/13

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

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

Tags: accessibility
Participants: Ed Burns and kito75

 Description   

Currently, JSF doesn't have any explicit support for WAI-ARIA (http://www.w3.org/WAI/intro/aria.php), except for the role attribute. <f:ajax> should be updated to use the aria-live attribute at the very least.

See EG thread here: http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2013-01/message/5



 Comments   
Comment by kito75 [ 01/Mar/13 04:27 AM ]

After looking at this in more detail, there are several attributes that one may need to apply to the element that's being updated by an Ajax:

  • role
  • aria-live
  • aria-busy
  • aria-atomic
  • aria-relevant

(See http://www.w3.org/TR/wai-aria-practices/#LiveRegions)

Only the page author (and possibly the component being re-rendered) know which attributes should be set, and what the values should be. Since the regions are denoted with these attributes up-front, perhaps there's not much for <f:ajax> to do after all, because the page author can either use pass-through attributes or HTML5-friendly markup to specify these attributes on the component that needs to be updated.

Comment by Ed Burns [ 27/Mar/13 03:28 AM ]

I like this idea, targeting for 2.3.





[JAVASERVERFACES_SPEC_PUBLIC-1158] HtmlOutcomeTargetButton and HtmlOutcomeTargetLink does not have disableClientWindow attribute defined, but h:button/h:link has it in its facelets taglibdoc Created: 22/Jan/13  Updated: 01/Feb/13  Resolved: 01/Feb/13

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

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

Tags:
Participants: Ed Burns and lu4242

 Description   

javax.faces.component.html.HtmlOutcomeTargetButton and javax.faces.component.html.HtmlOutcomeTargetLink does not have disableClientWindow attribute defined, but h:button/h:link has it in its facelets taglibdoc.

Note in h:button/h:link, disableClientWindow attribute is defined twice. Maybe it is something related to the documentation generator. Also, h:button/h:link should be marked as modified in facelets taglibdoc.






[JAVASERVERFACES_SPEC_PUBLIC-1157] javax.faces.Token must be transported by Ajax if present Created: 22/Jan/13  Updated: 22/Jan/13  Resolved: 22/Jan/13

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

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

Tags:
Participants: lu4242 and rogerk

 Description   

Checking the spec, I notice that the CSRF token
is passed under javax.faces.Token request parameter, but the javascript
documentation should "relay" the token like it does with
javax.faces.ViewState or javax.faces.ClientWindow if and only if
the token is present.

The solution is just update javascript documentation of

jsf.ajax.request(source, event, options)

to reflect this condition.



 Comments   
Comment by rogerk [ 22/Jan/13 07:02 PM ]

Closing per reporter's comments.





[JAVASERVERFACES_SPEC_PUBLIC-1156] No documentation available for AjaxBehavior.resetValues Created: 22/Jan/13  Updated: 31/Jan/13  Resolved: 31/Jan/13

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

Type: Bug Priority: Major
Reporter: lu4242 Assignee: Ed Burns
Resolution: Fixed Votes: 1
Remaining Estimate: 0 minutes
Time Spent: 20 minutes
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and lu4242

 Description   

Checking the PRD I notice an small documentation issue in these methods added
on javax.faces.component.behavior.AjaxBehavior

public boolean isResetValues()
public void setResetValues(boolean resetValues)
public boolean isResetValuesSet()

The first two does not have documentation and the last one has "Since 2.0". It should be "Since 2.2".

Also, the javascript documentation of jsf.ajax.request(source, event, options) does not have resetValues added in the "options" table, an it should be there just like "delay" option.






[JAVASERVERFACES_SPEC_PUBLIC-1155] Require FacesContext.getCurrentInstance() to work at Servlet "SessionDestroyed" event time Created: 16/Jan/13  Updated: 08/Nov/13

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

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2691 Session scoped beans and activeViewMa... Closed
Tags:
Participants: Ed Burns

 Description   

JSF 2.0 requires that FacesContext.getCurrentInstance() is valid to call at three times in the application lifecycle.

1. Startup time

2. Request processing time

3. Shutdown time

This feature request proposes adding an additional time to this list: Servlet "SessionDestroyed" event time.






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

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

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

Tags:
Participants: arturo_serrano, Ed Burns and marfous

 Description   

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

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

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

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



 Comments   
Comment by marfous [ 16/Aug/13 08:46 AM ]

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

Thanks in advance.

Comment by arturo_serrano [ 16/Aug/13 02:33 PM ]

This also affects all the JSF 2.2 releases:

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

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





[JAVASERVERFACES_SPEC_PUBLIC-1153] Make SelectItemsIterator public API Created: 03/Jan/13  Updated: 08/Nov/13

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

Type: Improvement Priority: Minor
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and Mathias Werlitz

 Description   

Make javax.faces.component.SelectItemsIterator public API since finding out the select items of a component is very complicated and this spec class already provides the required functionality.



 Comments   
Comment by Mathias Werlitz [ 03/Jan/13 06:11 PM ]

Unfortunately the class is currently package private and cannot be used in own components/converters etc. dealing with select items.

Comment by arjan tijms [ 19/May/13 12:56 PM ]

This would indeed be convenient. More than a few component libraries have reinvented the wheel for this (e.g. I created a version for OmniFaces).

Although the algorithm to collect/iterate over select items is specified, there's a small window for bugs if the component libraries use a (slightly) different version than the one the JSF implementation on which it runs is using.





[JAVASERVERFACES_SPEC_PUBLIC-1152] javax.faces.model.SelectItem should have a field for a title attribute for the option item Created: 15/Dec/12  Updated: 08/Nov/13

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

Type: New Feature Priority: Minor
Reporter: jontyl Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jontyl

 Description   

There is currently no way to set a title attribute on individual html <option> elements. This can be very useful to provide tootip hints if the options are a little cryptic.

It would be necessary to add itemTitle to javax.faces.model.SelectItem, UISelectItem, f:selectItem(s) and to have the ListboxRenderer render it. Several classes changed, but very simple changes to each one.

Given that title is an HTML specific term it might be preferable to call it itemTooltip rather than itemTitle.






[JAVASERVERFACES_SPEC_PUBLIC-1151] Cannot Attach Ajax Behavior To Html5 Elements Created: 07/Dec/12  Updated: 12/Dec/12  Resolved: 12/Dec/12

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

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

Tags:
Participants: Ed Burns, Frank Caputo and rogerk

 Description   

HTML5 passthrough elements such as <fieldset> are created as UIPanel components. This prevents a page author fromn attahcing Ajax behavior. For example, currently, this cannot be done:

<fieldset jsf:id="fieldset3">
<legend jsf:id="legend3">
FieldSet2
</legend>
<f:ajax event="click" onevent="statusUpdate"/>
</fieldset>

The component that must be created is HtmlPanelGrid.



 Comments   
Comment by rogerk [ 07/Dec/12 02:28 PM ]

The implement issue for this is: http://java.net/jira/browse/JAVASERVERFACES-2629

Comment by Frank Caputo [ 09/Dec/12 07:21 PM ]

Hi Roger,

the user would not expect any tr and td elements in the rendered output. The prototype created h:panelGroup instead of jsf:element. I think this should work fine with the fix of http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1145.

Frank

Comment by rogerk [ 12/Dec/12 06:12 PM ]

Hi Frank -

Using the current JSF trunk source, I attempted to nest an f:ajax in a <fieldset>.
I got an exception because <fieldset jsf:id="foo"... created a UIPanel component in the view.
If your intention is to create a panel group component, then it must be an HTMLPanelGroup
since that implements the ClientBehaviorHolder interface that is required for attaching Ajax
behavior.

Comment by Ed Burns [ 12/Dec/12 08:47 PM ]

The spec change for this issue will be to modify the spec for

jsf:element

to require that the underlying component implements ClientBehaviorHolder and that the default event is "click". The choice of click is supported due to section 6.1.6.2 of the HTML5 draft spec.





[JAVASERVERFACES_SPEC_PUBLIC-1150] Add @ClientWindowScoped Created: 04/Dec/12  Updated: 08/Nov/13

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

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






[JAVASERVERFACES_SPEC_PUBLIC-1149] Add method getCurrentViewScope() to javax.faces.application.ViewHandler Created: 28/Nov/12  Updated: 08/Nov/13

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

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

Tags:
Participants: Neil Griffin

 Description   

Currently, the javax.faces.flow.FlowHandler class has an abstraction that hides the CDI dependency of Mojarra's @FlowScoped annotation:

public abstract class FlowHandler { ... public abstract Map<Object, Object> getCurrentFlowScope(); ... }

This is quite helpful, because it provides JSF Portlet Bridges with the ability to decorate the FlowHandler.getCurrentFlowScope() method with an implementation that doesn't depend on CDI. (CDI+Portlet integration hasn't been formally defined yet at the JSR level).

But the same cannot be said for the new javax.faces.flow.ViewScoped annotation. In order to remedy this, I would like to propose that the following method signature be added to the javax.faces.application.ViewHandler class:

public abstract class ViewHandler { ... public abstract Map<Object, Object> getCurrentViewScope(); ... }






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

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

Type: New Feature Priority: Major