[JAVASERVERFACES_SPEC_PUBLIC-1414] f:validateWholeBean should allow the user to select the copy strategy (a copier attribute) Created: 12/Feb/16  Updated: 12/Feb/16

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

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

Payara 4.1






[JAVASERVERFACES_SPEC_PUBLIC-1396] Standardize WebSocket integration with f:websocket Created: 12/Aug/15  Updated: 06/Dec/16

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: balusc
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 8 minutes
Original Estimate: Not Specified

Attachments: Text File JAVASERVERFACES_SPEC_PUBLIC-1396.patch    

 Comments   
Comment by balusc [ 10/Dec/15 ]

Attached a git patch with initial commit of a functional f:socket tag.

As discussed, I dropped SSE support as it isn't standardized and has less browser support (no Microsoft IE/Edge), while WS is standardized, even in Java EE (JSR356), and has better browser support and is more efficient (no persistent open connection).

Comment by balusc [ 14/Dec/15 ]

After testing on various servers I have futher improved the script and logic. Also a new context param is added to explicitly enable the push (lazy initialization turned out to not work on Tyrus WS implementation).

Comment by balusc [ 19/Dec/15 ]

Proposal for PartialViewContext#getEvalScripts() has been splitted to https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1412

Comment by balusc [ 14/Jan/16 ]

Replaced git patch with current f:websocket tag.

Comment by balusc [ 28/Jan/16 ]

Replaced git patch with current f:websocket tag, now with session scope support

Comment by balusc [ 04/Mar/16 ]

Replaced git patch with current f:websocket tag, now with view scope, user-target and CDI event support.

Comment by balusc [ 10/Mar/16 ]

Replaced git patch with current f:websocket tag, now with test case.

Comment by balusc [ 10/Mar/16 ]

Committed and pushed:

https://java.net/projects/mojarra/sources/git/revision/598058f425f8894683f1d68796b0474e54cfea9e

Comment by balusc [ 10/Mar/16 ]

<f:websocket> has been added, along with 2 testcases (one to test context param and another to test three different push channels (app/session/view))

Comment by balusc [ 14/Mar/16 ]

(reopened accidentally closed issue)

Commited improvement as to handling of jsf.js script (refactored utility from AjaxHandler into RenderKitUtils so it can be reused by WebsocketHandler's WebsocketFacesListener). Initial implementation broke state saving.

https://java.net/projects/mojarra/sources/git/revision/ac4253639ed23eace38451fff3c33c6e9780be2b

Comment by balusc [ 14/Mar/16 ]

Test case failed on Hudson with development stage enabled; it has now been fixed.

https://java.net/projects/mojarra/sources/git/revision/9c65817db3c9e80421911692e83319ad8c97ac1e

Comment by balusc [ 18/Mar/16 ]

All tests have passed. Closing out issue.

Comment by balusc [ 27/Oct/16 ]

Reopening to improve spec further.

1. f:websocket needs to be an UIComponent implementing ClientBehaviorHolder
2. jsf.push.init needs to take clientID + full URL
3. jsf.push.open/close needs to take clientID instead of channel
4. ViewHandler should have a getWebsocketURL() or something like that

Comment by balusc [ 06/Dec/16 ]

1. 2. 3. are done. TODO: 4.





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

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

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

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

 Description   

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

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

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

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






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

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

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


 Description   

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

case_Ajax

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

case_MultiSubmit

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






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

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

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

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

 Description   

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

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

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

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

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



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

Sort of sub-issue of 1099





[JAVASERVERFACES_SPEC_PUBLIC-1342] Support @Inject of current flow like "@Inject Flow currentFlow" Created: 12/Dec/14  Updated: 10/Aug/15

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

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


 Description   

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

@Inject
Conversation currentConversation

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






[JAVASERVERFACES_SPEC_PUBLIC-1321] Leverage HTTP2 Server Push from JSF Created: 13/Oct/14  Updated: 08/Aug/16

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

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


 Description   

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



 Comments   
Comment by balusc [ 08/Aug/16 ]

Currently, JSF 2.3 already features JSR356 websocket based push as per https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1396





[JAVASERVERFACES_SPEC_PUBLIC-1316] Support @Inject on JSF artifacts Created: 09/Oct/14  Updated: 08/Aug/16

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

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

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

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

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

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

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

Comment by Manfred Riem [ 14/Jan/15 ]

In Progress

Comment by Manfred Riem [ 15/Jan/15 ]

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

Comment by arjan tijms [ 30/Jul/15 ]

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

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

Comment by balusc [ 08/Aug/16 ]

Injection of @FacesContext is currently not done properly. It's currently request scoped, but it should actually be "faces context scoped", as an (error) dispatch can create a new FacesContext within the very same request. The current approach will throw ISE from assertNotReleased() when the FacesContext is being referenced in EL.





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

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

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

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

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

Make sure the appropriate spec text is added for:

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

Comment by arjan tijms [ 30/Jul/15 ]

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

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

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

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

Comment by Manfred Riem [ 20/Aug/15 ]

r=mriem

Comment by arjan tijms [ 20/Aug/15 ]

Applied to 2.3 trunk:

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





[JAVASERVERFACES_SPEC_PUBLIC-1298] Resolve backward incompatible change regarding PartialResponseWriter.writePreamble() Created: 11/Aug/14  Updated: 10/Sep/15

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

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

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

 Description   

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



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

These were done at the request of the portlet community:

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

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

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

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

And Neil Griffin replied with a justification:

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

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

Comment by Ed Burns [ 11/Aug/14 ]

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

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

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

Comment by btsulliv [ 14/Aug/14 ]

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

writePreamble

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Simple:

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

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

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

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

Comment by Ed Burns [ 05/Sep/14 ]

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

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





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

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

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

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

 Description   

Consider this spec text, from section 7.4.2:

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

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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





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

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

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


 Description   

Text copied from JAVASERVERFACES-3094

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

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

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



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

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





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

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

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


 Description   

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

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

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

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



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

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





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

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

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

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

 Description   

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

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

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

E.g.

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

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

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

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

}


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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

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

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

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

Comment by Ed Burns [ 17/Aug/15 ]

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





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

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

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

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1270 JavaDoc for TagDecorator regarding pa... Resolved

 Description   

Tried the following code:

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

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



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

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

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

Sample A

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

Sample B

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

Either samples should end up with this:

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

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

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

Comment by Bruno Borges [ 13/Aug/13 ]

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

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

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

Comment by jyeary [ 13/Aug/13 ]

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

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

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

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

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

Comment by Bruno Borges [ 13/Aug/13 ]

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

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

Comment by Ed Burns [ 28/Aug/13 ]

From the spec section cited by John and Frank:

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

Consider Bruno's original markup:

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

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

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

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

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

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1150] Add @ClientWindowScoped Created: 04/Dec/12  Updated: 24/Oct/16

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

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


 Description   

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



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

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

Comment by frederickkaempfer [ 05/Oct/15 ]

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

Comment by muellermi [ 23/Oct/16 ]

A corresponding CDI scope would be great. But, how can we ensure that a user does not transfer a client window id from one tab to the other by copy and pasting the URL?

Comment by lu4242 [ 24/Oct/16 ]

There is no perfect solution for that one. For historical purposes about the browser tab problem see https://struberg.wordpress.com/2011/11/13/solving-the-browser-tab-problem/ . Right now @FlowScoped relies on client window id. MyFaces has a client window mode different from the default that uses the url called "client", extracted from MyFaces CODI.





[JAVASERVERFACES_SPEC_PUBLIC-1078] Have DataModel implementations registrable Created: 28/Feb/12  Updated: 21/Aug/15

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

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

Attachments: Text File changebundle.txt     Text File changebundle.txt     Text File changebundle3.txt     Text File changebundle4.txt     Zip Archive newfiles.zip     Zip Archive newfiles.zip     Zip Archive newfiles3.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1380 Utilize @FacesDataModel for existing ... Open
is related to JAVASERVERFACES_SPEC_PUBLIC-1103 UIRepeat and UIData supports Iterable Resolved

 Description   

There have been issues and discussions about having a DataModel implementation in the spec for java.util.Set. This is certainly a good thing. Better though, would be to have a way (via annotation and/or faces-config.xml) to register an implementation and the type of Object it supports. This would clean up code in UIData and also allow for expansions of DataModel types without having to update the spec.



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

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

Comment by arjan tijms [ 11/Jul/15 ]

Expanded @FacesDataModel support to UIRepeat

Comment by arjan tijms [ 13/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "Initial commit for https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Have DataModel implementations registerable, r=mriem"
Sending jsf-api/src/main/java/javax/faces/component/UIData.java
Adding jsf-api/src/main/java/javax/faces/model/FacesDataModel.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiExtension.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiUtils.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesMapProducer.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/FacesDataModelAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java
Adding test/javaee8/facelets
Adding test/javaee8/facelets/pom.xml
Adding test/javaee8/facelets/src
Adding test/javaee8/facelets/src/main
Adding test/javaee8/facelets/src/main/java
Adding test/javaee8/facelets/src/main/java/com
Adding test/javaee8/facelets/src/main/java/com/sun
Adding test/javaee8/facelets/src/main/java/com/sun/faces
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child1.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child11.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child111.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child11Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child1Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child21.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child21Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/DataBacking.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Parent.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/ParentModel.java
Adding test/javaee8/facelets/src/main/webapp
Adding test/javaee8/facelets/src/main/webapp/WEB-INF
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/beans.xml
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/glassfish-web.xml
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/web.xml
Adding test/javaee8/facelets/src/main/webapp/datatableCustomDataModel11.xhtml
Adding test/javaee8/facelets/src/main/webapp/datatableCustomDataModel111.xhtml
Adding test/javaee8/facelets/src/main/webapp/uirepeatCustomDataModel11.xhtml
Adding test/javaee8/facelets/src/main/webapp/uirepeatCustomDataModel111.xhtml
Adding test/javaee8/facelets/src/test
Adding test/javaee8/facelets/src/test/java
Adding test/javaee8/facelets/src/test/java/com
Adding test/javaee8/facelets/src/test/java/com/sun
Adding test/javaee8/facelets/src/test/java/com/sun/faces
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Sending test/javaee8/pom.xml
Transmitting file data ..............................
Committed revision 14837.

Comment by Manfred Riem [ 13/Jul/15 ]

Can you please address the following PMD issues

UIRepeat.java:61, UnusedImports, Priority: Normal
Avoid unused imports such as 'com.sun.faces.cdi.CdiUtils'.

DataModelClassesMapProducer.java:40, TooManyStaticImports, Priority: Normal
Too many static imports may lead to messy code.

Note it might be better to move the @interface into its own file instead of doing it as an inner class.

Comment by arjan tijms [ 14/Jul/15 ]

Avoid unused imports such as 'com.sun.faces.cdi.CdiUtils'.

I'll look at this one right away. I have the same checks running locally but this one slipped through (likely because of some noise regarding a couple of existing warnings)

DataModelClassesMapProducer.java:40, TooManyStaticImports, Priority: Normal
Too many static imports may lead to messy code.

I'll take a look at this one too. What's the limit currently set too?

Note that for JDK8 code we may want to increase the limit or remove the rule (if possible). JDK8 code puts a lot more emphasis on static imports and this is considered good practice. The PMD rule is likely still based on JDK5 style code. JDK8 provides a lot of goodies in utility classes such as Collectors (e.g; Collectors::toList that typical code does not write out fully (see basically all Oracle examples for Stream based code).

Note it might be better to move the @interface into its own file instead of doing it as an inner class.

Do you mean DataModelClassesMapProducer.DataModelClasses here? The initial idea was to keep it private to the parent class, since it was just a way to prevent an ambiguous situation when injecting Map. Code in the API project obtains the map by name only, so no new types were needed to be introduced there.

However, UIRepeat is in the impl project and could make use of utility code, so it may make sense indeed now to move it to a top level class. Additionally, if/when the API project can make use of utility code this would also allow it to obtain the map in a more strongly typed way.

Comment by arjan tijms [ 14/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Several cleanups, r=mriem"
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClasses.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesMapProducer.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java
Sending test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2Model.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Transmitting file data .......
Committed revision 14843.

Comment by arjan tijms [ 15/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Excluded tests for WLS 12.2.1, r=mriem"
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Transmitting file data ..
Committed revision 14861.





[JAVASERVERFACES_SPEC_PUBLIC-1029] viewParam value lost after validation errors Created: 02/Aug/11  Updated: 04/Sep/15

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

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

Tags: state, validation

 Description   

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

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

The following reproduces this:

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

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

    <h:body>

        <h:messages />

        #{viewParamBean.id} <br/>

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

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

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

    private long id;    
    private String text;

    public void actionMethod() {

    }

    public long getId() {
        return id;
    }

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

    public String getText() {
        return text;
    }

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

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

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

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

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

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

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

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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-947] Relative Resources Created: 09/Mar/11  Updated: 04/Sep/15

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 24
Labels: None
Σ Remaining Estimate: 5 days Remaining Estimate: 5 days
Σ Time Spent: 2 hours Time Spent: Not Specified
Σ Original Estimate: 5 days Original Estimate: 5 days

Attachments: Zip Archive sample.zip     Zip Archive sample_broken.zip    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Reopened
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Closed
is duplicated by JAVASERVERFACES-1189 #{resource['...']} not usable in <ui:... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1079 Add method ResourceHandler.isResource... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-548 Resource localization is too rigid an... Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Sub-task Reopened Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-996 The resources folder should be either... Sub-task Closed Ed Burns  
Status Whiteboard:

size_small importance_medium


 Description   

https://issues.apache.org/jira/browse/MFCOMMONS-29

The features of this ResourceHandler include the following:

  • relative paths between resources (css files referencing images
    without using #resource['..'])
  • caching resources in the client (disabled if ProjectStage == Development)
  • GZIP compression and local cache in tmp dir (disabled if
    ProjectStage == Development)
  • i18n (supporting country code and language).

In addition, it does NOT support ValueExpressions in resource files
for performance reasons.

The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css

... because it permits resources referencing other resources without
#

{resource['...']}

(e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.

Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).



 Comments   
Comment by Jakob Korherr [ 15/Apr/11 ]

add duplicate links.

Comment by Jakob Korherr [ 13/Jun/11 ]

Just found out that ICEFaces actually provides a tool for processing url() references in css files which are served by JSF 2.0. For example, this tool creates url(#

{resource['org.site.lib/images/background.png']}

) out of url(../images/background.png).

This shows the big impact of this issue, I think.

See http://wiki.icefaces.org/display/ICE/ACE+CSS+URL+Mapping for more details!

We seriously need to fix this with JSF 2.2! Such (annoying) preprocessing should not be necessary.

Comment by Hanspeter Duennenberger [ 26/Aug/11 ]

Hi Jakob,

it would be usefull if there was a way to specify resources depending on the active ProjectStage - e.g. for css and Javascript files, to allow using packaged resources normally but uncompressed css/javascript when ProjectStage is set to Development.

I was discussing this once with someone and we ended up in a possible solution for that to put additional includeProjectStage/excludeProjectStage condition attributes on @ResourceDependency annotation and probably also same attributes on outputStylesheet/outputScript tags.

Might be this ends up in an additional independent issue, but as you are going to work on ResourceHandling anyway I feel adding it here is ok.

regards
Hanspeter

Comment by lu4242 [ 29/Aug/11 ]

In MyFaces and Tomahawk a custom hack is used to check if the project stage is Development and if a resource under META-INF/internal-resources (or in tomahawk META-INF/uncompressed-js-resources), just take this instead the compressed version used in Production stage.

I believe that it could be more simple to assume a "mirror uncompressed" location, and in practice use some plugin to compress the resources, and add the logic on the default (or custom) ResourceHandler algorithm.

EB> This approach breaks down when there is not a 1:1 mapping between
EB> compressed and non-comporessed resources. For example, when you
EB> want all your JS in one compressed file at Production time, and want
EB> several smaller, non-compressed files, at Development time.

Comment by Jakob Korherr [ 04/Sep/11 ]

Hi Hanspeter,

This is a very, very nice idea! I will prototype that in my relative-resource-handler at apache-extras (see http://code.google.com/a/apache-extras.org/p/relative-resource-handler/).

Also: Since I will have more time in the next two weeks, I really do hope to get some work done for the spec!

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 03/Oct/11 ]

Hi Jakob,

any progress here?

I wanted to add something about the ProjectStage dependent resources. There might be two options for it:

1. use a project stage dependent resource path in the jar (similar to Locale handling with fallback). This is useful if the resource is the same name but only compressed for production, e.g.

myJs/some.js
myJs/production/some.js             (compressed some.js)

2. because the JS files may get pretty big, we would like to use multiple JS files for development but combine/compress a number of such JS files to one for production. This means the number of resource dependencies change depending on project stage.

myJs/funct-a.js
myJs/funct-b.js
myJs/funct-c.js
myJs/{production/}funct-all.js      (compressed combination of funct-*.js files)

So for example, it should be possible to state one component needs funct-a.js and funct-b.js when in project stage Development and only funct-all.js when in project stage Production.

I think possibility 1 is a little closer to what Leonardo mentioned about the MyFaces specific hack.
I really would like to have a specified way to handle project-stage specific resources, this might need some discussion in expert group though.

Cheers
Hanspeter

Comment by Jakob Korherr [ 06/Oct/11 ]

Hi Hanspeter,

Currently I am trying to convince a professor at Vienna university of technology to let me write about the relative resource handler for my bachelor thesis. If this will be accepted, I will have a lot more time for the resource handler.

The idea is really very, very great and I'd like to do some prototyping here. However, I don't know if we should really follow a convention-over-configuration approach. I am actually not sure if we can find a convention for the resource name that will fit in most scenarios. Maybe we need some configuration mechanism here...

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 09/Feb/12 ]

Hi all.

For multiple skins or theme support it will be necessary that the resource path may contain an optional skin or theme-path part.

 Skin-one
 /resources/skin-one/css/main.css

 Skin-two
 /resources/skin-two/css/main.css

The reference to this resource could be:

 <h:outputStylesheet name="main.css" library="css" />

I have kind of such an implementation, but it is probably to much integrated with our Skin interface. It should be a more general solution.

Regards
Hanspeter

Comment by Jakob Korherr [ 14/Feb/12 ]

Hi hanspeter,

You are totally right! In my resource handler I called it "support for multi-tenancy", however, this is not implemented yet.

Actually you need to add every information you need to determine the correct resource into the resource path, thus it somehow is a REST url. I also added a resource-version to the path in order to deal with resource-update-browser-cache problems.

Regards,
Jakob

Comment by Ed Burns [ 27/Feb/12 ]

Jakob, can you please hack upon this sample war to make it show the problem? The current war does use relative resources, but the browser is able to resolve them. Can you make it so the browser cannot resolve them?

Comment by Jakob Korherr [ 29/Feb/12 ]

Hi Ed,

Your sample is somehow funny. You use a css file in webapp/resources/library/style.css using relative paths like this: url(../../included.css) and url(../../expert-draft-bg.png). The two referenced resources, of course, are located two folders up in the directory tree (directly in webapp).

Now as it would seem to be logical that this works, it really is a coincidence. You see, style.css is loaded via the following url:

http://localhost:8080/faces/javax.faces.resource/style.css?ln=library

Thus, included.css and expert-draft-bg.png are loaded by the browser using the following urls:

http://localhost:8080/included.css
http://localhost:8080/expert-draft-bg.png

The 1st ".." removed "javax.faces.resource" and the 2nd ".." removed "faces" (however, you would actually think that the 1st ".." removes library and the 2nd ".." removes "resources"). This, of course, only works because tomcat (or any other servlet container) serves the two files directly, and it has nothing to do with the JSF resource handler (e.g. ValueExpressions won't work!).

Now, there are a number of possibilities to break the example:
1) use .jsf instead of /faces/ FacesServlet mapping
2) locate the two resources in the same folder as style.css (while removing the ".." sequences in style.css)
3) locate the two resources in the classpath (META-INF/resources)
...

I used the 2nd of the above options in my sample_broken.zip.

Here, style.css still gets loaded via:

http://localhost:8080/faces/javax.faces.resource/style.css?ln=library

But now the browser tries to locate included.css and expert-draft-bg.png using these urls:

http://localhost:8080/faces/javax.faces.resource/included.css
http://localhost:8080/faces/javax.faces.resource/expert-draft-bg.png

Which does NOT work, because the library request parameter is missing. My approach (http://code.google.com/a/apache-extras.org/p/relative-resource-handler/) creates an url in which the library is included in the url path, thus this will work.

If you have any further questions, please ask!

Regards,
Jakob

Comment by Jakob Korherr [ 29/Feb/12 ]

Added sample_broken.zip

Comment by Ed Burns [ 29/Feb/12 ]

Thanks for demonstrating to me exactly how this is broken.

Now I can proceed to better see how to fix it!

Comment by Ed Burns [ 29/Feb/12 ]

Looking at your relative-resource handler, it is immediately apparent that the ability for the relative resources to even work is based on how you are encoding the library name differently from what is specified. As stated in the javadocs for RelativeResourceHandler, you have to use

META-INF/relative-resources.xml

to declare libraries and we can't accept that requirement in the spec. Also, the stated limitation of only being able to work with prefix mapped JSF runtimes is unacceptable.

I can see why you made these decisions and how they enable the nice features of your Relative ResourceHandler, but we need to figure out how to do what you request without making unacceptable compromises.

Comment by Ed Burns [ 29/Feb/12 ]

Jakob, what is the main reason for being dissatisfied with this syntax for relative resources?

css_master.css:

@import url(#

{resource['this:layout.css']}

);

Is it performance?

Comment by Jakob Korherr [ 29/Feb/12 ]

The need to have the libraryName configured in relative-resources.xml does only exist, because I needed a way to enable the RelativeResourceHandler only for certain libraries. This would not be necessary if the standard ResourceHandler already uses the "relative-mechanism" (for all libraries).

There are many reasons:

1) Acceptance: There is no other framework (at least which I know of), in which you cannot use relative paths between resources as they would work in the file system. Nearly every IDE supports "resource-exists-checks" in css files with relative paths in the file system, and these IDEs will mark #

{resource[]}

url references as errors. Every server (http or servlet container), CDN,... supports relative paths in the URLs like a normal file system, why should JSF do this differently?

2) Effort: You need quite a lot of time to change a big CSS framework (which you will get from your designers) into a working JSF version. And remember, next day the designer may change something, then you will get a new version of the whole CSS framework, and the work starts again...

3) Performance: Actually, having ValueExpressions in resource files is not only a performance killer, it also gives the developer the impression as if she could change resource file contents in every request, whereas she really cannot, because the resource will get cached by the browser/proxy.

I actually would not use the current JSF ResourceHandler because of these points and instead let tomcat (or even weblets) handle my resources, because they both support relative paths like a calm.

Comment by Ed Burns [ 20/Mar/12 ]

A resource path from Jakob's impl looks like
"/javax.faces.resource/1.0.0/en_US/css/style.css". Does that 1.0.0
refer to library version or resource version?

Here's a clue, from RelativeResourceHandler#132.

// skip version in url (first part, only there to avoid cache problems on updates)
final int versionSlash = resourceName.indexOf('/');

But that still doesn't answer my question. What does the 1.0.0 mean?

Jakob's ResourceHandler.createResource() allows the entire resourceId to
be in the "resourceName", which it re-interprets according to its own
rules if it determines that the library is not a JSF 2.0 style resource
library.

JK> The need to have the libraryName configured in
JK> relative-resources.xml does only exist, because I needed a way to
JK> enable the RelativeResourceHandler only for certain libraries. This
JK> would not be necessary if the standard ResourceHandler already uses
JK> the "relative-mechanism" (for all libraries).

Ok, let's say we make relative libraries the default for prefix mapped
applications. If we have a jar in the classpath that contains a library
that is arranged according to the JSF 2.0 spec for resource libraries,
we now we need some way to detect that case and use the JSF 2.0 style
arrangement, right?

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





Relative Resources (JAVASERVERFACES_SPEC_PUBLIC-947)

[JAVASERVERFACES_SPEC_PUBLIC-884] Support library prefix in resource URLs Created: 17/Sep/10  Updated: 09/Sep/15

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

Type: Sub-task Priority: Critical
Reporter: cayhorstmann Assignee: Ed Burns
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-947 Relative Resources Open
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Closed
Issuezilla Id: 884
Status Whiteboard:

size_small importance_medium


 Description   

Consider a stylesheet

<h:outputStylesheet library="styles" name="skin.css"/>

Resources are loaded with URLs such as

/context path/faces/javax.faces.resource/skin.css?ln=styles

(when prefix mapping is used).

CSS files commonly contain url(...) expressions such as

.ui-icon

{ width: 16px; height: 16px; background-image: url(myicon.png); }

These url(...) expressions fail to locate the dependent resources.

This discussion further explains the problem:
http://forums.sun.com/thread.jspa?threadID=5447194.

It is not reasonable to ask the users to rewrite the URLs in the style sheet
since style sheets are often auto-generated.

While it might be possible for JSF to automatically rewrite the URLs in a style
sheet as it is loaded, that would not work for other files (e.g. JavaScript).

If instead the library name is added as a prefix, then the problem goes away:

/context path/faces/javax.faces.resource/styles/skin.css

(NB. I believe the ?ln=xxx is a vestige of an earlier time
when the version and resource prefix were also specified as request
parameters, see
http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature.)

In the interest of backward compatibility, we can to provide an application
configuration parameter

javax.faces.RESOURCE_URL_MAPPING with options prefix and param

Then
http://download-llnw.oracle.com/javaee/6/api/javax/faces/application/Resource.html#getRequestPath%28%29
needs to be changed as follows:

  1. If getLibraryName() returns non-null, discover if the resources are prefix or
    param mapped, by consulting the application configuration parameter
    javax.faces.RESOURCE_URL_MAPPING. If prefix mapped, insert "/" +
    getLibraryName() after ResourceHandler#RESOURCE_IDENTIFIER. If param mapped, ...


 Comments   
Comment by Ed Burns [ 26/Oct/10 ]

2.2

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by ramiromagalhaes [ 14/Apr/11 ]

This is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900.

Comment by lamine_ba [ 14/Apr/11 ]

It seems that someone has reported this issue since a long time . It was one of the first issue I have to deal with JSF 2.0. How to load with css an image stored in my images folder?
If my faces servlet is mapped to .faces, I can overcome this problem by doing this

background-image: url(myicon.png.faces?ln=images)

If my faces servlet is mapped to /faces/*, I can overcome this problem by doing this

background-image: url(myicon.png?ln=images)

If would be nice if we could come back to this

background-image: url(images/myicon.png)

Comment by Jakob Korherr [ 15/Apr/11 ]

The problem described by lamine_ba is exactly why I created the MyFaces commons resourcehandler module (see [1]). Fortunately I already talked with Ed about it, and we will try to address this issue by re-using some of the code/concepts from MyFaces commons resourcehandler!

[1] https://svn.apache.org/repos/asf/myfaces/commons/branches/jsf_20/myfaces-commons-resourcehandler/

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-790] javax.faces.ViewState + PPR does not work out for cross form ppr cases Created: 06/May/10  Updated: 06/Dec/16

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Bug Priority: Critical
Reporter: werpu12 Assignee: balusc
Resolution: Unresolved Votes: 59
Labels: None
Remaining Estimate: 5 days
Time Spent: Not Specified
Original Estimate: 5 days
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File 790-js-workaround.txt     Text File changebundle.txt     Text File changebundle.txt     Java Source File ExtendedViewHandler.java    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-3436 ViewScoped bean reconstructs when usi... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1093 The id attribute of javax.faces.ViewS... Open
is related to JAVASERVERFACES-1715 Missing ViewState during partial view... Closed
Issuezilla Id: 790
Status Whiteboard:

size_small importance_small


 Description   

Following problem

<h:form id="a">
    <h:commandButton action="#{TestBean.action}" value="submit"/>
</h:form>

<h:form id="b">
    <h:commandLink value="ajax ReRender" 
        onclick="jsf.ajax.request(this,event,{execute:'b a',render:'a'}); return false;"/>
</h:form> 

Cannot work out because, the viewstate is returned as separate viewstate block
(in both implementations the <update id="a"> does not pass the viewState in the
update block).

Now the specification says:

If an update element is found in the response with the identifier
javax.faces.ViewState:

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

locate and update the submitting form's javax.faces.ViewState value with the
CDATA contents from the response.

Which means in this special case that the viewState for form a is lost.
Mojarra has fixed this to some degree by setting the viewstate if a direct form
render on a happens.

However if you do following:

<h:panelGroup id="myGroup">
    <h:form id="a">
        <h:commandButton action="#{TestBean.action}" value="submit"/>
    </h:form>
</h:panelGroup>

<h:form id="b">
    <h:commandLink value="ajax ReRender" 
        onclick="jsf.ajax.request(this,event,{execute:'b a',render:'myGroup'}); return false;"/>
</h:form> 

Mojarra also fails.

The problem here lies clearly with the spec, I am not sure why the viewstate is
only updated to the issuing form.

Either all forms must be updated or at least the forms which are processed both
within the execute and render parts.

I also opened a discussion on the open mailing list regarding this, since this is
a usecase which can happen quite often in a typical rich client scenario where a
lot of detachments can happen to satisfy ie6 and multiple forms are the norm if
you have floating frames.



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

Agree for inclusion in 2.0 Rev a

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

I agree we should update all forms. Move to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by werpu12 [ 12/Jul/10 ]

Actually I personally think the only possible solution here is to offload this
to the server, instead of issuing <update id="javax.faces.ViewState"> we have to
extend the protocol here so that the client is notified which form and viewstate
element needs to be updated.
I am not sure if updating all forms automatically really resolves the issue,
because in a portlet scenario this does not work out, how about client side
state saving or even worse if someone introduces multiple viewroots
programmatically just as portlets do?

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by frederickkaempfer [ 21/Sep/11 ]

The same problem occurs (in Mojarra 2.1.3) when the entire ViewRoot is replaced via ajax. In that case none of the forms get their view state updated. You need to submit a form at least twice in order to trigger the execution of the full JSF lifecycle. The first time only a new ViewState field is created in the submitted form.

At least all forms contained in the rendered section need to have their view state field updated. In the current implementation a ViewState field is only created if the render target is it self a form (not a parent of forms).

Updating all forms on the page is also a possibility though strictly speaking forms not contained in the <update/> section of the Ajax request are not part of the newly generated view state.

Possible duplicates of this bug I found so far:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1024
http://java.net/jira/browse/JAVASERVERFACES-2199

Comment by frederickkaempfer [ 22/Sep/11 ]

I have created a fix for the issue, which updates the ViewState field for forms which are children of the specified render targets.

Furthermore it handles the case where render="@all" is used. In this case all forms in the document will have their ViewState field updated. Previously this caused forms to loose their ViewState.

Note that this fix does not update all forms in the document, but only those which have been re-rendered (thus are part of the newly generated view on the server).

Comment by werpu12 [ 22/Sep/11 ]

Actually I have similar fixes for myfaces, I basically update all forms which have render targets in or forms which are part of a render target.
Additionally to that I added a update all config option which is outside of the spec.
But nevertheless.

But that is just a hack in my opinion. The root problem is in the protocol.
The protocol simply needs to deliver a list of form ids which need a viewstate update.
So I personally think the only viable long term solution to this problem simply is to update the protocol of jsf 2.2 in this regar ala <update id="javax.faces.ViewState" updateIds="id1 id2 id3">dkghsfkjgh</update> or for backwards compatibility reasons introduce an entirely new tag like <updateViewState id="...">....

Comment by rogerk [ 22/Sep/11 ]

Your workarounds are fine for now, but clearly this needs to be a spec change for the better.

Comment by frederickkaempfer [ 22/Sep/11 ]

If it was safe to assume that the ViewState does not change during a partial request the logic can be simplified by updating ALL forms in the document (not just render targets).

In Mojarra's ServerSideStateHelper (line 200) this assumption holds true, but I did not find anything in the spec enforcing this.

Additionally this would also take care of any Form dynamically added to the view or any render ids added via facesContext.getPartialViewContext().getRenderIds().add(...);

Right now only the "javax.faces.partial.render" argument is consulted which is indeed suboptimal.

I can change the workaround to simply update all forms in the page, which would also make it less of a "Hack". What do you think?

Comment by rogerk [ 22/Sep/11 ]

I was thinking along those same lines..
In which case we would not need to introduce a new response element as Werner mentioned.
It's been sometime since we looked at this - it has been discussed before.
Are there any portlet implications (namespace related) by doing this (that was brought up - but could be for a different issue)..

Comment by werpu12 [ 22/Sep/11 ]

Actually there are portlet implications, hence i stayed away from updating all forms automatically, but made it a config option you can turn on in myfaces.

The implication is that different portlets can host different forms under different viewroots and hence have different viewstates.
Now the main problem is, we dont have any viewroot information. So it comes down to following:
a) either send the viewstate info with an altered protocol i mentioned

  • safe since every form must have a unique id in the dom no double ids are allowed

b) add viewroot information and then update all forms under the corresponding viewroot - should be safe as well but is in my opinion not as clean as option a) and probably causes an alteration of the protocol as well (ala introduction of a viewroot element) or on the api side. I am not sure if we have a scenario where we have different viewstates under one viewroot though. I never really bothered to look deeper into this aspect of the jsf spec.

c) Try to move forward with the usual hacks - worst option of all

In my personal experience this multi form issue has been a huge issue for the users, I had about 5-10 requests on the myfaces mailinglist where users had problems and thought it was an issue of the implementation.

Comment by frederickkaempfer [ 23/Sep/11 ]

It's true that updating all forms won't work in any case where there are multiple viewroots involved. Anyhow I was hoping to find a solution that is usable even with the 2.1 and 2.0 spec versions, because this bug is not an enhancement, but currently breaks a couple of basic Ajax features in JSF. To summarize them quickly:

1. Specifying parents of forms as render targets.
2. Using the @all render target on any page with multiple forms.
3. Replacing the entire viewroot, for example via <h:commandLink action="myNavigationOutcome"><f:ajax/></h:commandLink>
4. Dynamically adding RenderIds that include forms in JSF Lifecycle with facesContext.getPartialViewContext().getRenderIds().add(...)

The workaround I provided should at least make 1-3 work again. Updating all forms in the document would make 1-4 work, but as you said will break Portlet compatibility.

There is another option to consider that does not require a protocol change:

Before the doUpdate function is called for any of the changes read the view state information at the end of the partial response document and save it in a variable in the jsf.ajax.response function. the viewstate can then be passed to any call of doUpdate function, which can then take care of creating view state fields where it is appropriate. This way we would not have to redundantly send the render ids, as they already provided as the <update> ids.

Comment by frederickkaempfer [ 23/Sep/11 ]

Here is a changebundle that updates the ViewState for each form element that is replaced during the ajax update.

I wonder if a Spec change is even necessary because: If a form is processed during an update it means that its ViewState field has to be updated (or created) as well. With this patch it is now done in the doUpdate function. On the other hand, if a form is not re-rendered there is no compelling reason to update its ViewState field, because if it had been changed on the server-side this would not be visible in the browser.

So following this logic, specifying the "updateIds" in a new protocol element will always replicate the render ids which are already contained in the <update> tags (or any of the forms contained in them, which can also be found using JavaScript, like it is done in the provided patch).

Do you think this is still too "hack"-ish?

Comment by werpu12 [ 23/Sep/11 ]

Unfortunately things are not that simple. I cannot speak for mojarra, but I assume it is similar, but myfaces has a meta information in the viewstate which also pinpoints to the viewid (and the state history as well) so if you do not update a second form even if you dont have a rerender there, you basically at a submit from that form can get a cannot find viewid once it drops out of the view history.

So we have two problems
a) update all forms automatically is prevented due to the fact that it breaks in a portlet environment

b) not updating not rendered forms might break the state history information of the viewstate not updated

So a pure javascript fixup will work and might work under normal non portlet circumstances (the simplest one probably is simply to update all forms for a normal webapp) but it will break in corner cases like portlet environments. Thats one of the reasons why I implemted about three fallback modes for this problem in myfaces. So that if even one fallback fails the user can switch to another one which might suite to his environment.

Comment by frederickkaempfer [ 23/Sep/11 ]

I think Mojarra does not even change the ViewState during partial requests.

Nevertheless I suppose there are two separate issues surfacing here that are remotely related. This patch should work in a Portlet scenario as well as the unpatched version and it fixes the 4 issues I mentioned earlier including the initial bug report. Contrary to updating all forms in the document, it doesn't make it any worse for the portlet scenario. But yes, it is a preliminary hack, if you consider the following change as the right way to handle the situation:

In your last comment you basically said that on each Ajax request all forms contained in a one ViewRoot have to be updated with new state information - at least in the case of MyFaces (it would work for Mojarra as well because the ViewState doesn't change):

  • If we are in a "normal" (non-portlet) environment with just one ViewRoot, this means updating all forms contained in the entire document.
  • If we are in a portlet environment it would mean updating all forms that are contained in the current ViewRoot.

So wouldn't the best course of action be your option b): make it possible to specify the view root element's id additionally in the partial response. If it is not specified or is set to a default value, update the entire document, if not only update forms contained in the viewroot element. This would also add the possibility to rerender a complete portlet with the special render target @all, which represents entire ViewRoot element. Sadly I don't know enough about the portlet spec to tell if this is a good idea and if this change is enough to support it properly.

Providing a list of update ids would then again be redundant, because the forms that need updating depend only on the ViewRoot that is currently - partly or in whole - redisplayed.

If this sounds like the right way to do it, then applying the changebundle will be counterproductive, because it is unnecessarily complex compared to updating all forms in the current ViewRoot. On the other hand it could even be backported to 2.0 or 2.1, it does not make things worse for portlets and it fixes the 4 critical bugs/problems i mentioned.

Comment by Ed Burns [ 23/Sep/11 ]

Thank you for excellent and clear analysis. Given my desire to include sketches for JAVASERVERFACES_SPEC_PUBLIC-730, JAVASERVERFACES_SPEC_PUBLIC-517, and JAVASERVERFACES_SPEC_PUBLIC-802, in next week's EDR of the spec, I'm going to defer this til after JavaOne.

Comment by codylerum [ 02/Nov/11 ]

This also is an issue with popup panels which often have their own form that when submitted rerenders content on the main page.

Since any forms on the main page did not participate in the submit they don't rerender with a viewstate and are unusable.

Comment by mdirkse [ 06/Dec/11 ]

Added a javascript workaround that fixes this issue and can be executed via the browser onLoad event handler. There are 2 versions: a plain JS one, and a jQuerified one. Tested and confirmed for Mojarra 2.1.2 (and jQuery 1.7.x).
Mad propz to frederickkaempfer for the original JS code.

Comment by werpu12 [ 06/Dec/11 ]

Sorry to crush some hopes here, but the posted solution is exactly the one I have in myfaces for the non portlet case (you can turn it on via a config param). And there it works, but it can only work in a non portlet environment, because there you have only one viewroot. So you can update all forms under document.

In a portlet environment you can have several viewroots under document with independend viewstates and independend forms. There the patch ultimately will break your portlet environment by applying wrong viewroots to other portlets. Thats because the which dom node is the viewroot info is simply missing on the client side and/or the protocol.

As I said before unless you have the viewroot info or you know which forms you update there is no way to resolve that issue for the portlet and non portlet case at the same time. The problem really is a problem of the protocol not the implementation.

Comment by rogerk [ 06/Dec/11 ]

I agree with Wevner's earlier assessment - that to handle the portlet case - multiple independent view root (eaxh with one or more forms) - we do need a new "server to client" message protocol that draws the association of which forms the view state should apply.

Comment by mdirkse [ 06/Dec/11 ]

werpu12 is right, the workaround I posted only works for the non-portlet case (and is only verified for mojarra 2.1.2)

Comment by sharath.naik [ 29/Dec/11 ]

Updating the MultiViewHandler's [ public void writeState(FacesContext context) throws IOException ] seems to fix the issue. The change made is to add the view state hidden field for forms, even when is a ajax request.

What is the purpose of not writing the view state if it is a partial request in this method?

Attaching the custom ViewHandler to override this method. would this be a fix that can be considered to be moved to MultiViewHandler?

Comment by frederickkaempfer [ 02/Jan/12 ]

@ sharath.naik: It's probably left out because the jsf ajax response already includes the view state information in an <update> tag, so the field can be created using JavaScript.

As I said earlier, the minimum a JSF implementation should do is update the view state information for all forms included in the render target list. I don't see how this creates any new problem in the portlet environment and that is what the latest changebundle I submitted does. Currently the algorithm detailed in the spec is not general enough and should be corrected.

A broader approach is to update all forms under the current view root. For that a protocol extension is necessary which tells the client which DOM element represents the view root. It would also enable scenarios where the whole view root is replaced (like @all and navigation) for the portlet environment. In my opinion for this a new spec enhancement should be issued.

Comment by codylerum [ 15/Feb/12 ]

Is the attached workaround meant to be called from the oncomplete of an ajax component or am I missing another way to trigger it?

Comment by frederickkaempfer [ 22/Feb/12 ]

@codylerum: it should be enough to execute the script once on a page load, after jsf.js is loaded of course.

Comment by Ed Burns [ 03/May/12 ]

TG> (First of all, javax.faces.ViewState should not be modified for Ajax
TG> updates using server-side state-saving, but this simple approach
TG> does not appear to be the current direction.)

Can you please elaborate more on what you mean by this? The issue
doesn't mention anything about Ajax specifically. Is this a separate
concern you are raising, Ted?

TG> We are a bit unclear on how the current implementation is intended
TG> to work, but expect that something like the following is necessary:

TG> When the request is submitted, call
TG> getElementsByName('javax.faces.ViewState') and store the list of IDs
TG> for all with equal value to that of the javax.faces.ViewState in the
TG> submitting form. In the case of future JSP inclusion or current
TG> Portlets, there will be javax.faces.ViewState fields not associated
TG> with the current view. They will have different values and are not
TG> included in the list.

TG> When the partial response is generated, it may contain rendered
TG> hidden inputs with name javax.faces.ViewState and unique IDs, but
TG> also contains the special case <update
TG> id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously
TG> stored list of IDs are now all updated to use the new value. Any
TG> javax.faces.ViewState hidden fields that have been modified by the
TG> page update itself (potentially now having different IDs) have the
TG> correct value anyway because they were just updated.

These two comments are better suited to JAVASERVERFACES_SPEC_PUBLIC-790,
so I'll copy them there. Ted, can you please take a look at 790 and see
if you agree that your comments pertain more to that issue than this
one?

Comment by tedgoddard [ 07/May/12 ]

At least in the case of MyFaces, this complicates things considerably:

"Unfortunately things are not that simple. I cannot speak for mojarra, but I assume it is similar, but myfaces has a meta information in the viewstate which also pinpoints to the viewid (and the state history as well) so if you do not update a second form even if you dont have a rerender there, you basically at a submit from that form can get a cannot find viewid once it drops out of the view history."

It makes it necessary to update the ViewState key for every request. I was under the impression that a similar strategy was being considered for Mojarra.

In my above comments, I assume that the form Renderer would be modified to always write out the ViewState (even for partial rendering). Alternatively, the javax.faces.ViewState fields could be updated via two cases:

  • javax.faces.ViewState found in the current HTML document that match the submitting javax.faces.ViewState will be updated after the current response
  • javax.faces.ViewState found in the updated regions will be updated after the current response

This should handle portlet, servlet inclusion, and multiple form cases.

Comment by boogi [ 31/May/12 ]

Hi,
It says on fix version "2.2 Sprint 12" but it appears as unresolved on that sprint.
Do you a new estimation for the solution of this issue?

Comment by javaone9 [ 02/Nov/12 ]

I tried 2.1.14. it did not work.
I think this issue is urgent for any applications.

Comment by frederickkaempfer [ 18/Apr/13 ]

Please don't forget this issue for 2.2. It's one of the most annoying and frustrating aspects of the JSF Ajax experience. It would be a shame if the JSF community would have to wait another spec release -possibly another year- before this gets fixed.

tedgoddard made it very clear how to proceed with this issue in the previous comment.

Thanks a lot.

Comment by kfyten [ 25/Apr/13 ]

Roger/Ed - Just wanted to make it clear that this issue is currently blocking ICEfaces support for JSF 2.2. From a roadmap perspective it would be very helpful to us if this JIRA could be updated to reflect the current reality in terms of whether/when this issue may be resolved prior to 2.2 final release.

Thx.

Comment by rogerk [ 26/Apr/13 ]

Unfortunately I don't believe this made it into 2.2.

Comment by balusc [ 08/May/13 ]

This is really unfortunate.

In the meanwhile, developers can use this script to workaround the issue: http://balusc.blogspot.com/2011/09/communication-in-jsf-20.html#AutomaticallyFixMissingJSFViewStateAfterAjaxRendering

Comment by frederickkaempfer [ 08/May/13 ]

@balusc: I think that the workaround scripts have to be changed for 2.2, because the id of the ViewState field has been changed slightly. I didn't yet have time to look into it.

Comment by arjan tijms [ 08/May/13 ]

I think that the workaround scripts have to be changed for 2.2, because the id of the ViewState field has been changed slightly. I didn't yet have time to look into it.

They have changed indeed, see http://jdevelopment.nl/jsf-22/#220 and JAVASERVERFACES_SPEC_PUBLIC-220 for more details about this.

Comment by codylerum [ 08/May/13 ]

This is one of the larger pain points for developers utilizing ajax so it is very unfortunate that we are likely looking at years for resolution. Can anything be done at this point to speed that up?

Currently this issue has almost 2x the votes of the next closest issue.

Comment by swathireddy12 [ 22/Aug/13 ]

I am making use of JSF 1.2 version of jars (myfaces-api-1.2.9.jar ,myfaces-impl-1.2.9.jar,trinidad-api-1.2.13.jar,trinidad-impl-1.2.13.jar).
I am trying to retrieve the javax.faces.ViewState using the id attribute in a Javascript which works.

But i still don't see the id attribute in the loaded page
<input type="hidden" name="javax.faces.ViewState" value="!-14uywjgjai">

Could you please tell me if this is an issue with JSF 1.2 version as well?
Or once the page is rendered the id attribute associated with "javax.faces.ViewState" is not seen anymore.

Comment by werpu [ 22/Aug/13 ]

No this is a JSF 2.x issue only. This has nothing to do with JSF 1.2.

Comment by balusc [ 13/Jan/14 ]

This is one of the larger pain points for developers utilizing ajax so it is very unfortunate that we are likely looking at years for resolution. Can anything be done at this point to speed that up?

For exactly this reason, it has been added to OmniFaces 1.7: http://showcase.omnifaces.org/scripts/FixViewState

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by donvip [ 25/May/16 ]

Is this issue going to be fixed in JSF 2.3?

Comment by arjan tijms [ 25/May/16 ]

Is this issue going to be fixed in JSF 2.3?

I think we should definitely address this for 2.3. Thanks for the reminder!

Comment by balusc [ 30/May/16 ]

I'm currently looking at this.

As far as I see there are several solutions being proposed:

  1. Let JS blindly update/add view state of every single form in document - bad, might not work in portlet and might add noise to GET forms and/or non-JSF forms.
  2. Let JS update only missing view state of every single POST form in document - unclear if this works in portlets too.
  3. Let JS update only view states of all POST forms covered in ajax update targets - unclear if this works in portlets too.
  4. Always write view state to response - requires major spec change in ViewHandler#writeState(). I'd rather not do that.
  5. Include client IDs of all POST forms covered in ajax update targets in meta information of partial response.

I tend to implementing #3. Who can confirm if that will indeed work for portlets? Otherwise we'd better go for #5.

OmniFaces FixViewState by the way follows #2.

Comment by werpu [ 30/May/16 ]

The way I see it the ultimate fix on this issue, is a protocol change for the ajax response, we simply need the meta information there which viewstates in which forms need to be updated.
Everything else is a hack.

Comment by balusc [ 30/May/16 ]

Completely agree that. I updated the previous comment.

Comment by balusc [ 02/Jun/16 ]

Still no feedback from portlet guys.

I checked how MyFaces did it. They basically follows #2 with two little differences: it (incorrectly) updates GET forms too, and it skips everything when running in portlet environment.

Comment by werpu [ 02/Jun/16 ]

For multiform scenarios in no portlet environemnts I also added a config param which basically allows to override the default behavior and updates all forms reachable. This solved the multiform problem for many users since portlets are rather seldomly used.

Comment by werpu [ 02/Jun/16 ]

#2 simply turned out to be incorrect in multiform non portlet scenarios because the viewstate is kept over more than one form in the standard cases.
but also updating all forms is a no go for portlets, hence the config hack on my side.

Comment by balusc [ 02/Jun/16 ]

It's still not clear to me if #3 works for portlets. If it does, then #5 could be specified and implemented following same logic (i.e. update only JSF forms which are covered in ajax update targets).

Comment by donvip [ 02/Jun/16 ]

@balusc: thanks for the updates. The status on MyFaces is interesting, I didn't know they had implemented a workaround. Can you please tell me where I can find it? Is there an existing bug report/pull request concerning their incorrect implementation?

Comment by Neil Griffin [ 03/Jun/16 ]

@balusc, @werpu: Thank you for considering the portlet use-case. I think we can make #3 work in a portlet environment, but need to make sure that the javax.faces.ViewState hidden field values are only updated for forms that are associated with the portlet that invoked the XHR. (In other words, there could be other JSF portlets that are part of the HTML document that should not be touched by jsf.js, even though they share the same jsf.js resource).

In a portlet environment the UIViewRoot implements NamingContainer, thanks to javax.portlet.faces.component.PortletNamingContainerUIViewRoot

Because of this, the "id" attribute of forms is namespaced with the portlet id. For example, given this XHTML:

<h:form id="a">...</h:form>
<h:form id="b">...</h:form>

The following HTML would be rendered to the response:

<form id="Pluto_test_portlet_1__24955534_0_:a">...</form>
<form id="Pluto_test_portlet_1__24955534_0_:b">...</form>

If you consider the following XHR response:

<partial-response id="Pluto_test_portlet_1__24955534_0_">
  <changes>
    <update id="Pluto_test_portlet_1__24955534_0_:javax.faces.ViewState:0">
      <![CDATA[4617973942428228781:-2797886012162436717]]>
    </update>
  </changes>
</partial-response>

Then jsf.js could use the Pluto_test_portlet_1_24955534_0 namespace to make sure it only updates javax.faces.ViewState hidden fields in forms that contain that namespace in their "id" attribute.

As a side note, the portlet namespace is known to Mojarra as "namingContainerId" when it builds up mojarra.ab JavasScript. For more information, see AjaxBehaviorRenderer.java and jsf.js. Mojarra uses it to namespace XHR parameters such as javax.faces.partial.ajax in a portlet environment that requires strict parameter namespacing. The XHR parameter namespacing feature is unique to Mojarra – it has not yet been contributed to MyFaces.

Comment by balusc [ 06/Jun/16 ]

OK, I will propose the following API changes for JSF 2.3:

1. PartialResponseWriter#startDocument(): if UIViewRoot is available, then write UIViewRoot#getContainerClientId() as value of the id attribute of the <partial-response> element. Both Mojarra and MyFaces already implement this (although currently unspecified). In Mojarra's jsf.js, this value must replace/substitute the Mojarra-specific namingContainerId variable (which however appears to be already partially prepared for this, given the presence of a partialResponseId variable in doUpdate function which is totally unused). Portlets can then interpret this value as their parameter namespace (this is exactly what the Mojarra-specific namingContainerId did).

2. Correct an incorrect statement in the javadoc of ViewHandler#writeState() - it currently says that the <update> for javax.faces.ViewState is written into Ajax response during UIViewRoot#encodeEnd(). But this is untrue, in both Mojarra and MyFaces it actually takes place during PartialViewContext#processPartial(). I'll leave the reasoning for this deviation in the middle as this appears to be an oversight. Although I personally find that it makes more sense if it takes place during PartialResponseWriter#endDocument.

3. Update PartialViewContext#processPartial() to specify that during render response phase, the <update> for javax.faces.ViewState will be written, along with id attribute of exactly UIViewRoot#getContainerClientId() + UINamingContainer#getSeparatorCharacter() + ResponseStateManager#VIEW_STATE_PARAM. Currently, both Mojarra and MyFaces already implement this with one minor difference: an incremental counter identifying the form is being suffixed, this is now unnecessary.

4. Update the JSF 2.2 section (orange) of jsf.ajax.response jsdoc to remove <UNIQUE_PER_VIEW_NUMBER> altogether as below (changes in bold, strikeout means removal):

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

<update id="<VIEW_ROOT_CONTAINER_CLIENT_ID><SEP>javax.faces.ViewState">
   <![CDATA[...]]>
</update>

locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response. <SEP>: is the currently configured UINamingContainer.getSeparatorChar(). <VIEW_ROOT_CONTAINER_CLIENT_ID> is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated. <UNIQUE_PER_VIEW_NUMBER> is a number that must be unique within this view, but must not be included in the view state. This requirement is simply to satisfy XML correctness in parity with what is done in the corresponding non-partial JSF view. Locate and update the javax.faces.ViewState value for all forms specified covered in the render target list whose ID starts with the same <VIEW_ROOT_CONTAINER_CLIENT_ID> value.

The <UNIQUE_PER_VIEW_NUMBER> has no value in the API

@werpu: what do you think?
@Neil: is this acceptable for portlets?

Comment by Neil Griffin [ 06/Jun/16 ]

@balusc: Thank you for taking the time to propose these changes. Before I comment on your changes, I would like to make you aware of some portlet incompatibilities at are related to javax.faces.ViewState. When you get an opportunity, please read the class-level JavaDoc in ResponseWriterBridgeImpl.java and let me know if it might be appropriate to fix these incompatibilities for JSF 2.3. Thank you.

Comment by balusc [ 07/Jun/16 ]

I gather you're talking about limitation #3 in that javadoc? This should already be solved since JSF 2.2 where the javax.faces.ViewState hidden input field ID became namespaced with container client ID.

Comment by Neil Griffin [ 10/Jun/16 ]

@balusc: I'm referring mainly to #2 and #3 in the class-level JavaDoc in ResponseWriterBridgeImpl.java.

#2 is a workaround for the code in jsf.js that interprets <update id="javax.faces.ViewRoot">...</update> to mean replacing the <body>...</body> of the HTML document. I just created JAVASERVERFACES_SPEC_PUBLIC-1421 in order to see if the JSF EG would consider fixing jsf.js – it might be that the EG decides that this is a bridge concern and that the workaround should become a bridge requirement in JSR 378.

#3 is a workaround that causes the javax.faces.ViewState hidden field to always be rendered before the closing </form> tag when a partial-response is being written. It works around the code in jsf.js that attempts to add the hidden field to the DOM which fails in a portlet environment. This problem happens when a navigation-rule executes during an XHR. Specifically, the form that was submitted via f:ajax is no longer part of the DOM, since the entire portlet <div>...</div> section was replaced due to navigation to a different viewId. I suppose that the appropriateness of this workaround might be determined by the outcome of JAVASERVERFACES_SPEC_PUBLIC-1421.

Since this is all somewhat off-topic, I will provide feedback on your proposed API changes in a follow-up comment.

Comment by Neil Griffin [ 11/Jun/16 ]

@balusc: Your proposed API changes look good. However, should jsf.js need to add a javax.faces.ViewState hidden field to the DOM on-the-fly, the value of the name attribute should be prefixed by the namingContainerId. Looks like there is a bug in jsf.js in this regard. If you have time in your schedule, it would be great if you could fix the bug as part of your prototype work. Thanks, Neil.

Comment by balusc [ 11/Jun/16 ]

#2 is unrelated to the current issue. It's good you created issue 1421 on this.

I will keep the field name bug in mind. I only think it should be prefixed at the moment ajax request is to be sent, as done for all other params, not at the line you pointed out.

Comment by Neil Griffin [ 13/Jun/16 ]

That's fine to prepend the namespace at the time the request is sent. At first glance it looked like a bug to me because the bridge causes the namespace to be prepended when a component is rendered to the response.

Comment by Neil Griffin [ 14/Jun/16 ]

@balusc: Regarding the lines I mentioned in jsf.js – after the element is added to the DOM dynamically, then if the form is subsequently submitted without f:ajax (full-page postback) then the lack of a prepended namespace would be a problem.

Comment by balusc [ 17/Jun/16 ]

I see, will keep that in mind.

Comment by balusc [ 20/Jun/16 ]

Pushed: https://java.net/projects/mojarra/sources/git/revision/ff26c4dccafd50d22757ce8562230e31f9768033

@Neil: please let me know if that works for portlets as well and you could further reduce current workarounds in portlet side. FYI: the initial Mojarra implementation incorrectly omitted namingcontainer separator character from namespace prefix in ajax specific parameters. I have fixed that as well (and renamed Mojarra-specific RequestParameterMap#getNamingContainerId() to RequestParameterMap#getNamingContainerPrefix(), just in case you were relying on it).

@werpu: please let me know if the JSF/JS API changes are clear enough for MyFaces. Here's a summary:

ViewHandler#writeState(FacesContext)

@@ -737,8 +737,9 @@ public abstract class ViewHandler {
      * <code>Ajax</code> requests, the state is obtained by calling
      * {@link StateManager#getViewState}
      * and then written into the <code>Ajax</code> response during final
-     * encoding 
-     * ({@link javax.faces.component.UIViewRoot#encodeEnd}. 
+     * encoding <span class="changed_modified_2_3">
+     * ({@link javax.faces.context.PartialViewContext#processPartial(javax.faces.event.PhaseId)})
+     * </span>.
      * </p>
      *
      * @param context {@link FacesContext} for the current request

PartialViewContext#processPartial(PhaseId)

@@ -314,6 +317,17 @@ public abstract class PartialViewContext {
      * <code>Collection</code> returned from {@link #getExecuteIds} 
      * and {@link #getRenderIds} will be processed.</p>  
      *
+     * <p class="changed_added_2_3">When the indicated <code>phaseId</code>
+     * equals {@link PhaseId#RENDER_RESPONSE}, then obtain the state by calling
+     * {@link StateManager#getViewState} and write out it as an update element
+     * with an identifier of
+     * <code>&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;&lt;SEP&gt;javax.faces.ViewState</code>
+     * where <code>&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;</code> is the return
+     * from {@link UIViewRoot#getContainerClientId(FacesContext)} on the view
+     * from whence this state originated, and <code>&lt;SEP&gt;</code> is the
+     * currently configured
+     * {@link UINamingContainer#getSeparatorChar(FacesContext)}.</p>
+     *
      * @param phaseId the {@link javax.faces.event.PhaseId} that indicates
      * the lifecycle phase the components will be processed in. 
      */ 

PartialResponseWriter#startDocument()

@@ -113,6 +116,10 @@ public class PartialResponseWriter extends ResponseWriterWrapper {
 
     /**
      * <p class="changed_added_2_0">Write the start of a partial response.</p>
+     * <p class="changed_added_2_3">If {@link UIViewRoot} is an instance of
+     * {@link NamingContainer}, then write
+     * {@link UIViewRoot#getContainerClientId(FacesContext)} as value of the
+     * <code>id</code> attribute of the root element.</p>
      *
      * @throws IOException if an input/output error occurs
      * @since 2.0

jsf.ajax.request

@@ -2048,7 +2061,8 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * <p><b>Implementation Requirements:</b></p>
              * This function must:
              * <ul>
-             * <li>Be used within the context of a <code>form</code>.</li>
+             * <li>Be used within the context of a <code>form</code><span class="changed_added_2_3">,
+             * else throw an error</span>.</li>
              * <li>Capture the element that triggered this Ajax request
              * (from the <code>source</code> argument, also known as the
              * <code>source</code> element.</li>
@@ -2059,6 +2073,16 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * <li>If the <code>source</code> argument is a <code>string</code>, find the
              * DOM element for that <code>string</code> identifier.
              * <li>If the DOM element could not be determined, throw an error.</li>
+             * <li class="changed_added_2_3">If the <code>javax.faces.ViewState</code> 
+             * element could not be found, throw an error.</li>
+             * <li class="changed_added_2_3">If the <code>javax.faces.ViewState</code> 
+             * element has a <code>&lt;update id="&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;&lt;SEP&gt;</code>
+             * prefix, where &lt;SEP&gt; is the currently configured
+             * <code>UINamingContainer.getSeparatorChar()</code> and
+             * &lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt; is the return from
+             * <code>UIViewRoot.getContainerClientId()</code> on the
+             * view from whence this state originated, then remember it as <i>namespace prefix</i>.
+             * This is needed during encoding of the set of post data arguments.</li>
              * <li>If the <code>onerror</code> and <code>onevent</code> arguments are set,
              * they must be functions, or throw an error.
              * <li>Determine the <code>source</code> element's <code>form</code>
@@ -2175,7 +2199,10 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * </li>
              * </ul>
              * </li>
-             * <li>Encode the set of post data arguments.</li>
+             * <li>Encode the set of post data arguments. <span class="changed_added_2_3">
+             * If the <code>javax.faces.ViewState</code> element has a namespace prefix, then
+             * make sure that all post data arguments are prefixed with this namespace prefix.
+             * </span></li>
              * <li>Join the encoded view state with the encoded set of post data arguments
              * to form the <code>query string</code> that will be sent to the server.</li>
              * <li>Create a request <code>context</code> object and set the properties:

jsf.ajax.response

@@ -2613,8 +2639,9 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * correctness in parity with what is done in the
              * corresponding non-partial JSF view.  Locate and update
              * the <code>javax.faces.ViewState</code> value for all
-             * forms specified in the <code>render</code> target
-             * list.</li>
+             * POST forms covered in the <code>render</code> target
+             * list whose ID starts with the same 
+             * &lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt; value.</li>
 
              * <li class="changed_added_2_2">If an
              * <code>update</code> element is found in the response with
@@ -2639,8 +2666,9 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * correctness in parity with what is done in the
              * corresponding non-partial JSF view.  Locate and update
              * the <code>javax.faces.ClientWindow</code> value for all
-             * forms specified in the <code>render</code> target
-             * list.</li>
+             * POST forms covered in the <code>render</code> target
+             * list whose ID starts with the same 
+             * &lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt; value.</li>
 
 
              * <li>If an <code>update</code> element is found in the response with the identifier
Comment by Neil Griffin [ 25/Jun/16 ]

@balusc: Thank you for making the commit. I hope to have time on Monday June 25 to review the code changes.

Comment by Neil Griffin [ 27/Jun/16 ]

@balusc: On line 1022 of Util.java, instead of:

Util.java
return viewRoot.getContainerClientId(context) + UINamingContainer.getSeparatorChar(context);

Would you instead consider:

Util.java
return viewRoot.getContainerClientId(context);

I admit that it is inconsistent to have UIInput name attribute values to be rendered as namespace + ":" + clientId but not include ":" for hidden fields like javax.faces.ViewRoot.

However, that's the way it was implemented in Mojarra 2.2 and it fits more naturally with the Faces Bridge as well as the method of namespacing parameters encouraged by the Portlet API. Thank you.

Comment by balusc [ 28/Jun/16 ]

How does that work for regular input fields? They are also namespaced this way. With those JSF API changes, it should theoretically not be necessary anymore to override the request parameter map this way and just rely on standard JSF implementation. Those API changes are meant to further reduce code in Portlet bridge and let JSF do the work.

Comment by Neil Griffin [ 28/Jun/16 ]

The Faces Bridge's implementation of ExternalContext.getRequestParameterMap() decorates a PortletRequest, so it is not possible to use com.sun.faces.context.RequestParameterMap since it decorates a ServletRequest.

The reason why input fields work is because decode methods automatically include the namespace prefix (and the separator char) by asking for a parameter value with getClientId() as the parameter name, like this:

FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap(uiInput.getClientId());

For example, see HtmlBasicRenderer.java

Lookups for request parameters like javax.faces.ViewState do not automatically include the namespace prefix, which means that the Faces Bridge's implementation of ExternalContext.getRequestParameterMap() must account for this.

A good example is ResponseStateManagerImpl.java.

Comment by balusc [ 04/Jul/16 ]

I see, the problem boils down to that JSF impl is internally not prefixing the standard parameters with naming container client ID when the UIViewRoot is an instance of NamingContainer. If that part is fixed, then the whole RequestParameterMap approach becomes unnecessary. And, then the portlet case will also start to work correctly, right?

Comment by balusc [ 04/Jul/16 ]

Neil/Werpu, how about this change on UIViewRoot#encodeChildren()?

     * <p class="changed_added_2_3">If this {@link UIViewRoot} is an instance of {@link NamingContainer}, then the JSF
     * implementation must ensure that all encoded POST request parameter names are prefixed with
     * {@link UIViewRoot#getContainerClientId(FacesContext)} as per rules of {@link UIComponent#getClientId(FacesContext)}.
     * This also covers all predefined POST request parameters such as {@link ResponseStateManager#VIEW_STATE_PARAM},
     * {@link ClientBehaviorContext#BEHAVIOR_SOURCE_PARAM_NAME} and {@link PartialViewContext#PARTIAL_EVENT_PARAM_NAME}.
     * </p>
 

I implemented this locally on Mojarra and all unit tests have passed. I didn't yet remove Mojarra internal RequestParameterMap just to ensure backwards compatibility.

Comment by balusc [ 06/Jul/16 ]

Neil, above proposed implementation changes have been committed as per https://java.net/projects/mojarra/sources/git/revision/3b1d1e2a1330c6789f566f36597b6b9fcb81d509 so you have the opportunity to test it against your Portlet case.

Only API change (the above Javadoc proposal) has not been committed yet due to lack of confirming feedback.

Comment by lu4242 [ 20/Jul/16 ]

Other post parameters that could be included are javax.faces.RenderKitId (ResponseStateManager#RENDER_KIT_ID_PARAM) and javax.faces.ClientWindow (ResponseStateManager#javax.faces.ClientWindow).

Comment by balusc [ 20/Jul/16 ]

Indeed. There are more. Should we specify them all? I have in Mojarra at least collected them as RenderKitUtils.PredefinedPostbackParameter enum. There are so far 9 of those: https://github.com/javaserverfaces/mojarra/blob/3b1d1e2a1330c6789f566f36597b6b9fcb81d509/jsf-ri/src/main/java/com/sun/faces/renderkit/RenderKitUtils.java#L181

Comment by balusc [ 21/Jul/16 ]

I've pushed the javadoc changes: https://java.net/projects/mojarra/sources/git/revision/1569145562d8c20cc924f0eb5343b5e931df352d. For now, the issue is technically solved in JSF API and Mojarra impl.

Before I close off the issue, please let me know if there are any things unclear or missing, particularly with regard to Portlets and MyFaces.

Comment by werpu [ 21/Jul/16 ]

Hi sorry for being so silent, fact is I was extremely busy. I will check the changes tonight and will give my comment either tonight or tomorrow morning. So please keep the issue open at least until tomorrow.

Comment by werpu [ 21/Jul/16 ]

Ok, again sorry for not commenting on this issue for such a long time, I personally like the ViewRoot prepending to javax.faces.ViewState in the id is a reasonable way to go. I can only comment on the ajax client side however. I personally think this solves the problem for me. The original problem was as far as I remember that in the original specs following was written.

If an update element is found in the response with the identifier javax.faces.ViewState:
<update id="javax.faces.ViewState">
<![CDATA[...]]>
</update>
locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response.

Which was clearly wrong, since the viewstate should be the same for all forms under one viewroot. Adding the viewroot id fixes this problem once and for all for all cases.
Thanks for your efforts on fixing this long outstanding issue.

Comment by balusc [ 21/Jul/16 ]

Great, thank you for your feedback! Now yet a confirmation from Portlet guys.

Comment by Neil Griffin [ 22/Jul/16 ]

@balusc: I have begun reviewing your recent commits for this issue. Also, I have rebuilt Mojarra 2.3.0-m07 from source and have it running under Pluto 3.0. My goal is to report back tomorrow with more information. Thanks for your patience, Neil.

Comment by Neil Griffin [ 23/Jul/16 ]

@balusc: I have done preliminary testing and have seen good results so far. I still need to do more testing so I ask that you please keep this issue open. Regarding the namespace prefix, please consider the changes in the following pull request: https://github.com/javaserverfaces/mojarra/pull/3

The changes in the pull request remove the separator char from the namespace prefix. That's the way it is implemented in Mojarra 2.2 and it fits more naturally with the Faces Bridge as well as the method of namespacing parameters encouraged by the Portlet API. In addition, component suites like PrimeFaces and ICEfaces namespace their own predefined postback parameters without using the separator char. Thank you.

Comment by balusc [ 23/Jul/16 ]

Namespacing without separator character does not fit naturally in JSF API. I imagined that doing all the namespacing job in JSF side should reduce the work in the Faces Bridge. What work exactly is left in the Faces Bridge that it still needs its own way of namespacing? Then we can look for ways reducing/removing that work. Perhaps a new JSF API method to obtain a namespaced predefined postback parameter without the need to manually check and prefix it?

Comment by Neil Griffin [ 24/Jul/16 ]

@balusc: The convenience of being able to pass a non-namespaced parameter name to the externalContext.getRequestParameterMap().get(String) method has been assumed since JSR 301, and perhaps even by JSF portlet developers over the years. Removing that functionality from the bridge's ExternalContextImpl could be a breaking change for legacy JSF portlets. In fact, there are several places in the Bridge TCK (the TCK that JSR 378 inherited from Oracle) that call externalContext.getRequestParameterMap().get(ResponseStateManager.VIEW_STATE_PARAM) (click here for one example). If you feel that it is important to include the separator char, then we can make an accommodation for that in the bridge's ExternalContextImpl.

BTW I have completed my testing. I am happy to report that the original use-case reported in the description of this issue is now working for portlets. There is just one small bug in jsf.js that needs to be fixed. Line 495 reads:

add(document.getElementById(clientIds[i]));

but it needs to be:

add(document.getElementById(namingContainerPrefix + clientIds[i]));

Thank you, Neil

Comment by balusc [ 24/Jul/16 ]

The convenience of being able to pass a non-namespaced parameter name to the externalContext.getRequestParameterMap().get(String) method has been assumed since JSR 301, and perhaps even by JSF portlet developers over the years

As you can see in Mojarra's source code, this should keep working. I've indeed kept it in for sake of backwards compatibility.

String mapValue = request.getParameter(mapKey);
if (mapValue == null && !mapKey.startsWith(getNamingContainerPrefix())) {
    // Support cases where enduser manually obtains a request parameter while in a namespaced view.
    mapValue = request.getParameter(getNamingContainerPrefix() + mapKey);
}

This is however unspecified in API of the request parameter map. Do you think specifying in API is necessary? In that case, we could probably remove the explicit requirement to namespace predefined postback parameters as it will then happen "automatically" in request parameter map.

Thanks for the jsf.js bug report, I will investigate and fix it.

Comment by balusc [ 24/Jul/16 ]

As to line 495 of jsf.js, this part is fine. The clientIds[i] or f:ajax render is already namespaced (as it is generated by server). The test case associated with issue 790 would otherwise have failed. Line 2501 of jsf.js contains similar part with ids[i] of f:ajax execute which is also already namespaced. This is only not covered by the unit test yet. I will improve the unit test to make sure it's properly being dealt with.

Or did you encounter a problem with this in your test application?

Comment by Neil Griffin [ 25/Jul/16 ]

@balusc: In my testing of line 495 using the JS debugger, clientIds[i] is a JavaScript array of length 1 and the value of clientIds[0] is simply 'a' (it is not namespaced). I can provide you with a downloadable Pluto 3 ZIP if you'd like to try it.

Comment by Neil Griffin [ 25/Jul/16 ]

Do you think specifying in API is necessary?

Yes, I think it would be good to add a sentence to ExternalContext#getRequestParameterMap() and ExternalContext#getRequestParameterValuesMap() that says the map's get(String key) method should first try calling getParameter(key) on the underlying request object, but if it returns null, it should try getParameter(namespacePrefix + key). I suppose that ExternalContext. getRequestParameterNames() method should probably return the namespaced version of the key.

In that case, we could probably remove the explicit requirement to namespace predefined postback parameters as it will then happen "automatically" in request parameter map.

I think it is good to have the requirement that the namespace prefix be written as part of the name attribute of hidden fields. However, if we added the map requirements I mentioned, then line 204 of RenderKitUtils.java would not need to prepend the namespacePrefix.

Comment by balusc [ 25/Jul/16 ]

In my testing of line 495 using the JS debugger, clientIds[i] is a JavaScript array of length 1 and the value of clientIds[0] is simply 'a' (it is not namespaced). I can provide you with a downloadable Pluto 3 ZIP if you'd like to try it.

Is the portlet rendering non-namespaced client IDs? This is confusing. I'd like to see the ZIP and try it, yes.

I think it is good to have the requirement that the namespace prefix be written as part of the name attribute of hidden fields. However, if we added the map requirements I mentioned, then line 204 of RenderKitUtils.java would not need to prepend the namespacePrefix.

I'd prefer consistency over convenience. Otherwise things will be too confusing in long term. If the UIViewRoot is an instance of NamingContainer, it's expected that its ID is prefixed over all place.

Comment by balusc [ 27/Jul/16 ]

While working on https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1372 I think I discovered your problem: invalid client IDs in f:ajax execute/render are not namespaced. I could reproduce it when replacing e.g. render="validClientId" by render="thisDoesNotExist". Can you please reverify?

Comment by balusc [ 25/Sep/16 ]

@Neil: coming back to the deviating view root namespacing in portlets, one way to bridge this difference is to bring back the context param com.sun.faces.namespaceParameters which will then be used to drop the separator character from view root client ID. This way existing applications using older portlet impls will remain unaffected while upgrading JSF. In the meanwhile, you could have all time to fix it at portlet side to align with standard JSF namespacing rules.

Comment by Neil Griffin [ 18/Oct/16 ]

@balusc: Thank you for the suggestion regarding com.sun.faces.namespaceParameters. I will spend some time working on the bridge and if bringing back that context param becomes necessary, then I will let you know.

Regarding the problem with non-namespaced clientIds, in the Pluto+Tomcat bundle I have a demo JSF portlet that contains the following XHTML:

<h:form id="a">
	<h:outputText value="This is 'form a'" />
	<h:outputLabel for="foo" value="Enter a new value for foo:" />
	<h:inputText id="foo" value="#{testBean.foo}" />
	<h:commandButton action="#{testBean.action}" value="click me to execute 'form a' and 'form b' but re-render 'form b'">
		<f:ajax execute="a b" render="b" />
	</h:commandButton>
</h:form>
<h:form id="b">
	<h:outputText value="This is 'form b'" />
	<h:outputLabel for="foo" value="Enter a new value for foo:" />
	<h:inputText id="foo" value="#{testBean.foo}" />
	<h:commandLink value="click me to execute 'form a' and 'form b'  but re-render 'form a'"
		onclick="jsf.ajax.request(this,event,{execute:'a b',render:'a'}); return false;"/>
</h:form>

The h:commandButton in form a renders to:

<input id="Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:a:j_idt9" type="submit" name="Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:a:j_idt9" value="click me to execute 'form a' and 'form b' but re-render 'form b'" onclick="mojarra.ab(this,event,'action','Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:a b','b');return false">

The h:commandLink in form b renders to:

<a href="#" onclick="jsf.util.chain(this,event,'jsf.ajax.request(this,event,{execute:\'a b\',render:\'a\'}); return false;','mojarra.jsfcljs(document.getElementById(\'Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:b\'),{\'Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:b:j_idt18\':\'Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:b:j_idt18\'},\'\')');return false">click me to execute 'form a' and 'form b'  but re-render 'form a'</a>
Comment by balusc [ 28/Nov/16 ]
<f:ajax execute="a b" render="b" />

This is not valid in first place. It should have been

<f:ajax execute="a :b" render=":b" />

Relative client ids are interpreted relative to current naming container. The b would be interpreted as a:b.

Comment by Neil Griffin [ 30/Nov/16 ]

@balusc: You are exactly right. I must have copied the jsf.js.ajax(...) code from the original description in this ticket and duplicated the problem in the <f:ajax/> example as well. I fixed the portlet example according to your recommendations and the preliminary results look good. I will continue testing and report back with final results. Thanks for your help – Neil.

Comment by Neil Griffin [ 01/Dec/16 ]

@balusc: In my testing I found that the "replacing the entire viewroot" use-case mentioned by frederickkaempfer on 23-Sep-2011 still seems to be unsupported in both webapps and portlets.

Given the following two views:

view1.xhtml
<?xml version="1.0"?>
<f:view
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://xmlns.jcp.org/jsf/core"
    xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head />
    <h:body>
        <h:form>
            <h:commandButton action="/views/view2.xhtml" value="Navigate to view2">
                <f:ajax execute="@form" render="@all" />
            </h:commandButton>
        </h:form>
    </h:body>
</f:view>
view2.xhtml
<f:view
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://xmlns.jcp.org/jsf/core"
    xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head />
    <h:body>
        <h:panelGroup>
            <h:form id="view2Form">
                <h:commandButton action="/views/view1.xhtml" value="Navigate to view1" />
            </h:form>
        </h:panelGroup>
    </h:body>
</f:view>

When clicking on the "Navigate to view2" button, the javax.faces.ViewState hidden field is lost. This is because the submitting form on view1 went away, as detected by lines 1248-1252 of jsf.js:

jsf.js
if (!stateForm || !stateForm.elements) {
    // if the form went away for some reason, or it lacks elements 
    // we're going to just return silently.
    return;
}
Comment by stiemannkj1 [ 02/Dec/16 ]

Neil Griffin, balusc,
I'm going to work on a fix for this @all/Ajax navigation problem in jsf.js (hopefully one which will be compatible with webapps and portlets).

- Kyle

Comment by stiemannkj1 [ 02/Dec/16 ]

Here's my current work on this if anyone wants to look it over (unfortunately the diff is kinda ugly): https://github.com/stiemannkj1/mojarra/commit/e8f7f196636c17fe87e870030626d38a49be23fc. I still need to test this in both webapps and portlets for ViewState and ClientWindow. I also need to make the style more consistent (tabs vs. spaces) etc. So it's not quite ready yet, but hopefully it will be by Monday.

Branch on github: https://github.com/stiemannkj1/mojarra/tree/fix-render-%40all-JSF-SPEC-790

Comment by stiemannkj1 [ 02/Dec/16 ]

Here's a better diff with the tabs converted to spaces: https://github.com/stiemannkj1/mojarra/commit/1a8993c9f6ae2857c0310f6600dc0ea82ed56c26. Hopefully that's clearer.

Comment by stiemannkj1 [ 05/Dec/16 ]

I think I've finished the code, but I'm having some trouble with HtmlUnit tests. Gonna work more on this tomorrow, but you can see the diff here: https://github.com/javaserverfaces/mojarra/compare/26174a11...stiemannkj1:fix-render-@all-JSF-SPEC-790?expand=1

Comment by balusc [ 06/Dec/16 ]

I will look at it once I'm finished with 1396.





[JAVASERVERFACES_SPEC_PUBLIC-559] Support for the "Synchronizer Token" pattern (avoiding double submits) Created: 05/May/09  Updated: 11/Sep/15

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

Type: New Feature Priority: Critical
Reporter: kito75 Assignee: kito75
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File jsf2csrf.war     File jsf2token.war    
Issuezilla Id: 559
Status Whiteboard:

cat2 frame size_medium importance_large cat3 draft


 Description   

This is a very common web application problem
(http://www.javajunkies.org/index.pl?lastnode_id=3361&node_id=3355) – avoiding
double submits. Struts had built-in support for this. JSF-related implementations:

Spring Web Flow, Struts 2, and Grails 1.1
(http://www.grails.org/1.1+Release+Notes) also support this natively.

I'd really like to see this in JSF 2.1 at the very latest.



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

Move to 2.1. Also make this handle Dan's concern here:

DA> It's crucial that the enablement of this feature be accompanied by a
DA> secure token being exchanged in the case of server-side state
DA> saving.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

lifecycle

Comment by Ed Burns [ 07/May/10 ]

Transaction token has been requested many times over the years.

Comment by kito75 [ 08/May/10 ]

I've got some code I wrote for a client based on Shale's token that I can clean up and submit as a
prototype. If you're interested, just let me know when it's time.

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

xsrf

Security related, target for GlassFish 3.1 M3

Comment by Ed Burns [ 30/Jun/10 ]

cat3

Comment by rogerk [ 01/Jul/10 ]

Hey Kito -

It's time. Let's see what you have. If you can also submit a proposal that
would be helpful as well.

-roger

Comment by rogerk [ 01/Jul/10 ]

This could probably reside in the core namespace - like f:token ?

Comment by Ed Burns [ 01/Jul/10 ]

Roger, please take a look at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812 for more
valuable information.

Comment by rogerk [ 01/Jul/10 ]

Ahh yes - thanks for the pointer. Apparently there are many ways to skin this
cat ....

Comment by kito75 [ 14/Jul/10 ]

Created an attachment (id=255)
Sample CSRF Solution (JSF 1.2)

Comment by kito75 [ 14/Jul/10 ]

Created an attachment (id=256)
Sample CSRF Solution (JSF 1.2) – the other file is for avoiding double submits

Comment by kito75 [ 14/Jul/10 ]

I have attached two samples:

  • jsf2token.war – sample UIToken component specifically for avoiding double submits (but would
    probably handle CSRF attacks too)
  • jsf2csrf.war – sample solution for handing Cross-site Request Forgery (CSRF) attacks only.

The source for both is in the WEB-INF/classes directory.

The token approach uses a standard JSF component that outputs a hidden field in the form. The hidden
field is created based on a server-generated secret key plus other information, such as the current view
id. What's a little different is that a phase listener decodes the component before Apply Request Values.
The goal here was to check the token before any other decoding takes place. Also, the token isn't
released until after Invoke Application to ensure that application processing has occurred.

For JSF 2, I think either enhancing UIForm, providing an alternate UIForm, or using a ClientBehavior
might be a better option than a separate component. Using UIForm would avoid the need to handle
decoding in the PhaseListener.

The CSRF approach is a little different. It still generates a special token based on a server-generated
secret key, but it does so based on the session, not on the view. It then appends the token to every JSF-
generated request through ViewHandler.getActionURL(). It uses a PhaseListener to ensure that every
incoming request has a valid token.

It's possible to combine these approaches, but I like the way the CSRF approach doesn't require anything
on the part of the developer. The caveat is that since it's session-based, it's probably not secure as a
form-based approach. Also, a form-based variant is required to avoid double-submits.

I'm not familiar with back button solutions, so I can't comment on how this code is applicable.

Comment by kito75 [ 14/Jul/10 ]

We should also consider the Seam <s:token> approach
(http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF). This is
component-based approach by Dan Allen with two key artifacts:

This approach also uses a cookie to ensure the requests are coming from the same browser, which is a
nice feature (but it should be optional). It also has explicit support for client-side state saving, which
my solution does not.

Comment by rogerk [ 22/Jul/10 ]

re-target

Comment by rogerk [ 23/Jul/10 ]

I've created a separate spec issue for CSRF:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869
as it solves a different problem.

Comment by rogerk [ 13/Aug/10 ]

target

Comment by rogerk [ 13/Aug/10 ]

Starting

Comment by rogerk [ 27/Aug/10 ]

reset priority

Comment by rogerk [ 13/Sep/10 ]

target 2.2

Comment by joshbrookes [ 18/May/11 ]

This issue has remained untouched since mid-Sept of 2010. Is this still being targeted for development or is there a recommended 3rd-party utility that can be used with Mojarra?

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by codylerum [ 23/Mar/15 ]

While Seam is out of date, https://deltaspike.apache.org/documentation/jsf.html#_double_submit_prevention is a more current solution.

Inclusion into 2.3 would be a huge help to a common problem.

Comment by Manfred Riem [ 06/Aug/15 ]

Kito, can you take charge of this issue and look for an implementation strategy? Thanks!

Comment by kito75 [ 10/Aug/15 ]

Sure, I can.

Comment by gerhard_petracek [ 11/Sep/15 ]

fyi:
DeltaSpike keeps the valid token in a window-scoped bean -> there is only one known token per window/tab -> there is no impact on the state of the component tree and it isn't possible to "reactivate" a previous key -> ds:preventDoubleSubmit just renders the current key.





[JAVASERVERFACES_SPEC_PUBLIC-49] JS function for "give me the clientId" Created: 04/Oct/04  Updated: 26/Jan/15

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

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

Operating System: All
Platform: Sun


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

EGTop5 effort_hard cat2 jsdoc size_medium importance_small draft


 Description   

EB> R1 something you can stick in your page, that will evaluate to the full,
EB> absolute, clientId of the named thing when the page is rendered. Like
EB> this:

AVK> <h:button id="button1"
AVK> onclick="button_setEnabled(button2,
AVK> false);button_clicked(button1);return"
AVK> ... />
AVK> <h:button id="button2" ... " />

AVK> then I want the result of the first one to be

AVK> <input type="submit" id="myform:button1"
AVK> onclick="button_setEnabled('myform:button2', false);
AVK> button_clicked('myform:button1'); return;"
AVK> ... />

EB> R2 This thing can be presenent in an attribute value, or as template
EB> text.

AVK> Definitely needed in an attribute value, for the method invocation. I
AVK> don't know whether it is necessary in tempate text. I have a feeling
AVK> some JavaScript interpreters barf if you mention the id before the
AVK> element is present.

EB> R3 This thing must only work within the scope of a naming
EB> container. In other words, I can't use this mechanism to refer
EB> to something in form B if I'm inside Form A.

EB> R4 This thing must work in a multi-include page scenario

EB> R5 This thing must work in a portlet scenario



 Comments   
Comment by Ed Burns [ 23/Feb/05 ]

push to 2.0

Comment by Ed Burns [ 09/Sep/08 ]

EGTop5

Comment by Ed Burns [ 12/Sep/08 ]

effort_hard

Comment by Ed Burns [ 21/Oct/08 ]
      • Issue 293 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 21/Oct/08 ]

Change summary

Comment by Ed Burns [ 06/Nov/08 ]

Given the #

{component}

and #

{compositeComponent}

implicit objects, and the ability to use them on the
server side, in XHTML, and in resources, having the ability to say #

{component.clientId}

would be nice. To
do this, we need to add to UIComponent, String getClientId(). This just does
FacesContext.getCurrentInstance() and calls the other getClientId().

Comment by Ed Burns [ 06/Nov/08 ]

Created an attachment (id=163)
Fix for this bug, first iteration.

Comment by Ed Burns [ 28/Jul/09 ]

Push out to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

jsdoc

Comment by Ed Burns [ 27/Apr/10 ]

no sig change

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

target

Comment by Ed Burns [ 04/Feb/12 ]

Remove from consideration for 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting to Critical, verify if it is already done or not.





[JAVASERVERFACES_SPEC_PUBLIC-1433] Add Option to expand meaning of required="true" for UIInput Created: 29/Nov/16  Updated: 29/Nov/16

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

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


 Description   

When you say required="true" on a UIInput component, the validation
must always take place, even when there is no entry in the request
corresponding to that component.

Background:

Consider this login page:

<h:inputText id=“userName” required=“true” 
             value=“#{backingBean.userName}” />

<h:inputSecret id=“password” required=“true” 
               validator=“#{backingBean.validatePassword}” 
               value=“#{backingBean.password}” />

<h:commandButton action=“/views/authenticatedUser.xhtml” />

If the postback is hacked such that the userName is present as a request
parameter, but the password is not, the password validator would be
bypassed. If the password validator is used as the entry point to
perform authentication, this could cause problems.

Now, it must be said that using a validator on a password field as the
entry point to perform authentication is a particular design choice.
This design choice runs a bit counter to the stated purpose of the
validation system, which is to ensure syntactic and some level of
semantic validity of fields. There are other ways to perform
authentication that do not rely on the validation system for this
purpose.

Nonetheless, we would like to accomodate this use case.

Proposal:

For JSF 2.3, I propose the following.

Modify PDF section 3.5.4 to read:

Spec> *The render-independent property required is a shorthand for the
Spec> function of a required validator. If the value of this property is
Spec> true, **there is an entry in the request payload corresponding to
Spec> this component**, and the component has no value, the component is
Spec> marked invalid and a message is added to the FacesContext
Spec> instance.*

Modify the JavaDoc for UIInput.validate(). Modify the first bullet
point to read:

Spec> Retrieve the submitted value with getSubmittedValue(). If this
Spec> returns null, and the
Spec> javax.faces.component.UIInput.ALWAYS_PERFORM_VALIDATION_WHEN_REQUIRED_IS_TRUE
Spec> context-parameter is set to true (ignoring case), examine the
Spec> value of the "required" property. If the value of "required" is
Spec> true, continue as below. If the value of "required" is false, the
Spec> "required" attribute is not set not set, exit without further
Spec> processing. If the context-paramater is not set, or is set to
Spec> false (ignoring case) exit without further processing. (This
Spec> indicates that no value was submitted for this component.)

With these changes, the javadoc for UIInput.validateValue() can remain
unchanged.






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

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

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


 Description   

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

Forward:
return "index.xhtml"

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

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

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

{ return "index.xhtml"; }




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

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

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

Portlets



 Description   

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

Portlet Incompatibility #1

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

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

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

Portlet Incompatibility #2

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

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

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

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

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

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

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

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

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

For example, given the following JSF view:

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

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

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

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



 Comments   
Comment by balusc [ 11/Jun/16 ]

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

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

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

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

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

Comment by Neil Griffin [ 14/Jun/16 ]

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

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

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

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

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

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





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

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

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


 Description   

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

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

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

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

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

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

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

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






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

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

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


 Description   

e.g. HtmlInputText#EVENT_NAMES should contain oninput

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

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



 Comments   
Comment by WarriorDog [ 30/Jul/16 ]

I"d suggest this one http://www.w3schools.com/tags/ref_eventattributes.asp





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

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

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

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

 Description   

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

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






[JAVASERVERFACES_SPEC_PUBLIC-1417] Deprecate types in javax.faces.bean package Created: 18/May/16  Updated: 26/May/16

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

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

Issue Links:
Related
is related to JAVASERVERFACES-4145 Implement deprecate types in javax.fa... Closed

 Description   

JSF has for some time been emphasising to use CDI instead of its own native bean facility. Specifically, newer features such as @FlowScoped that were introduced in JSF 2.2 require CDI and won't work with the native bean facility.

Having the old native managed bean facility available is not rarely confusing to users. E.g. it's common to accidentally import javax.faces.bean.RequestScoped instead of javax.enterprise.context.RequestScoped.

Because of this I'd like to propose deprecating all the types in the javax.faces.bean package as well as the package itself via the @Deprecated annotation and/or javadoc, and mention what the alternatives are.






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

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

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


 Description   

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

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

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

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

E.g.

@FacesConfig
public class JustAClass {

}

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

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

E.g.

@FacesConfig(
    stateSavingMethod = "server"
)

Or a new option, to indicate the JSF version:

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

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

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

E.g.

@FacesConfig 
public class MyConfig {

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

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

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






[JAVASERVERFACES_SPEC_PUBLIC-1410] Define the result when the same namespace is used in annotation defined and tag library defined components. Created: 04/Nov/15  Updated: 04/Nov/15

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

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


 Description   

I cannot see anywhere in the specification that defines what should happen when the same namespace is used to define components using both the javax.faces.component.FacesComponent annotation and also in a tag library *.taglib.xml file.

For example:

@FacesComponent(value="xforms.input", createTag=true, namespace="http://www.w3.org/2002/xforms", tagName="input")
public class Input ...
<facelet-taglib version="2.2"
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee   http://xmlns.jcp.org/xml/ns/javaee/web-facelettaglibrary_2_2.xsd">

    <namespace>http://www.w3.org/2002/xforms</namespace>

    <tag>
        <tag-name>model</tag-name>
        <handler-class>my.custom.xforms.ModelTagHandler</handler-class>
    </tag>

</facelet-taglib>

See this Stack Overflow question for the full example.

The observed behaviour in Mojarra 2.2.12 is that the tag library defined components are available but the annotation defined ones are not. Reading the comments on the SO issue, the MyFaces implementation appears to make both components avaiable.

I think the specification should clearly define what should happen in this case.

From there, I'd suggest that the MyFaces behaviour of making both components available is more intuitive. If there is a conflict then the taglib version should probably win.






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

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

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


 Description   

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

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






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

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

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

Tags: state, state_saving, state_saving_method

 Description   

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

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

The options can be as follows:

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





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

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

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

Tags: state, state_saving, state_saving_method, stateless

 Description   

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

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

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

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






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

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

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

Tags: state, state_saving, state_saving_method

 Description   

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

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

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






[JAVASERVERFACES_SPEC_PUBLIC-1400] ui:repeat does not resolve (nested structures of) map.values Created: 19/Aug/15  Updated: 23/Oct/16

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

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

Checked with Windows 6.1 "7" and 6.3 "8.1"
and Java 1.8 "8"



 Description   

Given a class containing a map

Map<Integer, AccountNode> _children = new LinkedHashMap<>();

AccountNode wraps an object Account inside, which can be obtained by a getter.

The values of this map might be accessed by this getter

public Collection<AccountNode> getChildren() {
    return _children.values();
}

This should be used from facelets like in following code

 <c:forEach items ="#{treeController.rootNode.children}" var="child">
    <p>#{child.account.name}</p>
</c:forEach>

Using the tag handler "forEach", everything is fine.
But moving on to the component "repeat", the app fails.

<ui:repeat value ="#{treeController.rootNode.children}" var="child">
    <p>#{child.account.name}</p>
</ui:repeat>

"/index.xhtml: The class 'java.util.LinkedHashMap$LinkedValues' does not have the property 'account'."

Workaround: If the values get copied into another list, "repeat" works fine too.

public Collection<AccountNode> getChildren() {
    return new ArrayList<AccountNode>(_children.values());
}


 Comments   
Comment by muellermi [ 23/Oct/16 ]

Will this become obsolete due to the extended collection / map handling?





[JAVASERVERFACES_SPEC_PUBLIC-1398] Cleanup for unused Flows Created: 16/Aug/15  Updated: 01/Sep/15

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

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


 Description   

One thing missing from the faces flow spec that exists with @ConversationScoped are access timeouts after which the current scope is invalidated and destroyed.

Consider the case where a flow is not exited through the flow return, but instead simply abandoned by the user (via the back button, bookmarks or after closing a window). In this case the flow scoped beans will stay in the session, until the session is destroyed. In a web application with flows that is used intensively by its users for a long time it's easily possible that 100s of flow instances stay in the session before they are cleaned up and thus wasting a lot of memory.

To solve this problem either

  • a timeout could be introduced - similar to Conversations. This timeout could be specified for all flow as a web context param or on a flow level in the flow definition.
  • or alternatively a maximum of client window instances per flow could be set globally (implemented like ViewMaps by a LRU Map).


 Comments   
Comment by lu4242 [ 01/Sep/15 ]

Implemented in MyFaces. See: https://issues.apache.org/jira/browse/MYFACES-3938





[JAVASERVERFACES_SPEC_PUBLIC-1397] Provide documentation and tuning options for activeViewMaps Created: 13/Aug/15  Updated: 13/Aug/15

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

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


 Description   

We are using JSF 2.2.12 with server side state saving and plenty of ViewScoped ManagedBeans. After investigating our load tests it turned out that the data in our ViewScoped Beans is kept in session memory for quite some time. We were debugging Mojarra and found that the ViewScopeManager holds all ViewScoped beans of the last 25 used views. Even when you set numberOfLogicalViews to 1, it will still keep the last 25.

Now there is also an undocumented parameter com.sun.faces.application.view.activeViewMapsSize. When tuning JSF applications it would be very interesting to know why 25 and which impact this parameter has in conjunction with numberOfLogicalViews and numberOfViewsInSession.

I created also a stackoverflow post about this: http://stackoverflow.com/questions/31959982/jsf-2-2-memory-consumption-why-does-mojarra-keep-the-viewscoped-beans-of-the-la



 Comments   
Comment by fischermatte [ 13/Aug/15 ]

sorry, this issue belongs to mojarra not to spec. unfortunately i am not allowed to delete or move this issue here. I created the same here for mojarra now: https://java.net/jira/browse/JAVASERVERFACES-4015





[JAVASERVERFACES_SPEC_PUBLIC-1381] Specify forbidding of use of EL expressions in query params Created: 24/Jul/15  Updated: 24/Jul/15

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3832 Re-evaluation on EL expressions in JS... Closed
is related to JAVASERVERFACES-3997 Side effect of the fix of JAVASERVERF... Closed

 Description   

The resolution of Mojarra issue JAVASERVERFACES-3832 is to sanitize rhs of query params to not have EL expressions. If an EL expression is encountered, the whole rhs is replaced with the empty string and an INFO message is logged.

This needs to be included in the specification of 7.4.2 Default NavigationHandler Algorithm.



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

Section 7.4.2 Default NavigationHandler algorithm must also be fixed to replace <view-param> within <redirect> with <redirect-param>.

Also, EL expressions as the <value> of a <redirect-param> should be permitted since these are safe because they can never come from user input, whereas query params can come from user input.





[JAVASERVERFACES_SPEC_PUBLIC-1378] Clear the view map on session destroy or when the ACTIVE_VIEW_MAPS_SIZE is reached and a view map is thrown away Created: 04/Jun/15  Updated: 04/Jun/15

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

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


 Description   

The full discussion is at JAVASERVERFACES-3947.
In brief: when the session is destroyed, the beans of all the active view maps are destroyed, however the view maps themselves are not cleared (hence, no PreDestroyViewMapEvent is fired).
The same happens when the eldest view map is thrown away because the ACTIVE_VIEW_MAPS_SIZE is reached.

However, when JSF is integrated with other CDI-like frameworks, like the Spring Framework, for instance through an appropriate EL resolver (org.springframework.web.jsf.el.SpringBeanFacesELResolver in this case) and appropriate hooks on the PostConstructViewMapEvent}}s and {{PreDestroyViewMapEvent}}s, view-scoped beans created by the external framework won't be cleared on the above cases because no {{PreDestroyViewMapEvent is fired (the Mojarra ViewScopeManager takes care of just destroying view-scoped beans managed by JSF BeanManager itself).

Manfred Riem says this is a specification problem, because no strict requirement is stated on this.






[JAVASERVERFACES_SPEC_PUBLIC-1376] Missing StateHolder in Behaviour API for usage in dataTable and alike Created: 22/May/15  Updated: 22/May/15

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

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


 Description   

Recently I came across the fact that the Behaviour API is not using the StateHolder.

This means that EL Expressions in attributes of custom ClientBehaviours are executed during the buildView step and not during the 'rendering' (getScript() ) of the clientBehaviour.

As a consequence, the EL can't reference a var defined in the dataTable.






[JAVASERVERFACES_SPEC_PUBLIC-1375] Faces Flows CDI Bean Defining Annotations Clarification Created: 19/May/15  Updated: 02/Jul/15

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

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


 Description   

The Faces Flow annotation @FlowScoped is clearly defined as a CDI scope. In the CDI spec, however, it's not defined as a "bean defining annotation" http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations

The default bean discovery mode is "annotated", so it seems that with the default CDI configuration @FlowScope beans aren't discovered. The beans are discovered correctly with a bean-discovery-mode="all", which is set via beans.xml

Is it desirable to require this kind of explicit configuration, which can possibly lead to confusion?



 Comments   
Comment by wtlucy [ 02/Jul/15 ]

I've misunderstood the issue here. @FlowScoped is, in fact, a "bean defining annotation" as per the mentioned CDI spec: it falls under the "all other normal scope types" category. From the FlowScoped annotation documentation http://docs.oracle.com/javaee/7/api/javax/faces/flow/FlowScoped.html :

@NormalScope
@Inherited
@Documented
@Target(value=TYPE)
@Retention(value=RUNTIME)
public @interface FlowScoped

So, explicit configuration of the CDI bean-discovery-mode should not be required.





[JAVASERVERFACES_SPEC_PUBLIC-1374] Disable client window through parameter Created: 18/May/15  Updated: 18/May/15

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

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


 Description   

When exiting a flow, I sometimes need to redirect the user to some page where the client window id is not relevant anymore. It would be nice if the jfwid parameter could be dropped by simply adding "disable-client-window=true" in the url.

flowBuilder.returnNode("returnFromFlow").fromOutcome("/index.xhtml?faces-redirect=true&disable-client-window=true");





[JAVASERVERFACES_SPEC_PUBLIC-1373] @FlowScoped should be allowed on method and annotation Created: 14/May/15  Updated: 14/May/15

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

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


 Description   

Currently, @FlowScoped annotation can only target types. This makes it impossible to create flowscoped beans through @Produces methods or use @FlowScoped on a @Stereotype annotation.






[JAVASERVERFACES_SPEC_PUBLIC-1371] 11.4.3.3 (Packaging Flows in Directories) ambiguity Created: 04/May/15  Updated: 02/Sep/15

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3883 faces flow "containing directory" con... Open

 Description   

SH> The relevant spec is JSF 2.2 11.4.3.3 (Packaging Flows in Directories): there it says "The following conventions apply to
SH> flows defined in this manner. Any flow definition in the
SH> corresponding -flow.xml
SH> file will override any of the conventions in the case of a conflict.
SH> Every vdl file in that directory is a view node of that flow.
SH> The start node of the flow is the view whose name is the same as the name of the flow.
SH> ..."
SH> (note the ambiguity - "Every vdl file in that directory" ... which directory?)

EB> "that directory" is the directory containing the corresponding
EB> -flow.xml file. For example, in the case of the following
EB> convention match, "bounded-task-flow/bounded-task-flow-flow.xml",
EB> "that directory" is "bounded-task-flow/".



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

Ok, I looked at the built multipagewebinf WAR and see the following
files:

Archive: ./dist/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/jsf_flows_multipagewebinf_web.war
testing: META-INF/ OK
testing: META-INF/MANIFEST.MF OK
testing: WEB-INF/ OK
testing: WEB-INF/classes/ OK
testing: WEB-INF/classes/com/ OK
testing: WEB-INF/classes/com/sun/ OK
testing: WEB-INF/classes/com/sun/ts/ OK
testing: WEB-INF/classes/com/sun/ts/tests/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/beans/ OK
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/beans/FlowBean.class OK
testing: WEB-INF/bounded-task-flow/ OK
testing: WEB-INF/bounded-task-flow/bounded-task-flow-flow.xml OK
testing: WEB-INF/beans.xml OK
testing: bounded-task-flow/ OK
testing: bounded-task-flow/bounded-task-flow.xhtml OK
testing: bounded-task-flow/next_a.xhtml OK
testing: bounded-task-flow/next_b.xhtml OK
testing: index.xhtml OK
testing: nonFlow.xhtml OK
testing: return1.xhtml OK
testing: WEB-INF/web.xml OK

This is indeed strange that there is both a

testing: WEB-INF/bounded-task-flow/ OK

and a

testing: bounded-task-flow/ OK

directory. The spec doesn't say what to do in that case, but it is
clear that in this specific case MyFaces is behaving correctly while
Mojarra is not.

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

Hi Ed,

Can you make this more clear to me? you mean the work flow can be defined both under webapp / directory and WEB-INF/ and that defined in the webapp / should take higher priority, right? what's the current behavior of Mojarra?

BR,
Zhijun





[JAVASERVERFACES_SPEC_PUBLIC-1369] <protected-views><url-pattern> does not work as per Servlet 12.1 and is compared against JSF view ID instead of request URL Created: 18/Mar/15  Updated: 26/Aug/15

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

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


 Description   

Trigger: http://stackoverflow.com/q/29104597/157882

Problem 1: <protected-views><url-pattern> does not work as per Servlet 12.1. It does merely an exact match and wildcards are not supported. It's also nowhere in JSF 2.2 specification documented how exactly this should be used in faces-config.xml.

Problem 2: During generating action URL, <protected-views><url-pattern> is not compared against final action URL, but against JSF view ID, causing failures when there's a virtual URL based mapping like *.faces or /faces/*.

Another non-related problem 3: the current approach is inefficient. It's for every single view checked on a per-request basis while it could easily be (lazily) checked and stored in view/facelet metadata on an application wide basis.






[JAVASERVERFACES_SPEC_PUBLIC-1368] Static EL Resolution Doesn't Work Created: 28/Apr/15  Updated: 28/Apr/15

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

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


 Description   

EL 3.0 static field resolution on imported classes does not currently work in any JSF implementation, and it seems to come down to a spec issue. For example, the expression

<h:outputText value="#

{Boolean.TRUE}

" />

Prints out nothing, while it should print "true". Since ScopedAttributeELResolver must be the last resolver in the chain, modifying that resolver to resolve classes (via the importhandler, for example) allows these expressions to be resolved properly.

That fix was implemented by the Tomcat project here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57141
Related Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3362
Related UEL issue: https://java.net/jira/browse/UEL-40






[JAVASERVERFACES_SPEC_PUBLIC-1366] Within Resource Identifier, allow resourceName to have path separator Created: 05/Mar/15  Updated: 03/Feb/16

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

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

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1141 Specify that all parts of a resource ... Closed

 Description   

The expert group discussion for JAVASERVERFACES_SPEC_PUBLIC-1141 concluded that resourceName should be allowed to contain path separators.

An insufficient response to this conclusion was the following change to ResourceHandler.createResource()

  • Added this text to createResource(string)

For historical reasons, this method operate correctly when the
argument resourceName is of the form libraryName/resourceName, even
when resourceName contains '/' characters.

The following additional spec actions must be taken.

1. Fix the wording of the text of createResource() to be:

For historical reasons, this method must operate correctly when the argument resourceName is of the form libraryName/resourceName, even when resourceName contains '/' characters.

2. In section 2.6.1.3 modify the sentence starting with "The set of characters..." to be:

The set of characters that are valid for use in the localePrefix, libraryName, libraryVerison, resourceName and resourceVersion segments of the resource identifier is specififed as XML NameChar excluding the path separator and ‘:’ characters, with the exception of resourceName, which may contain the path separator character.



 Comments   
Comment by Arend v. Reinersdorff [ 18/Mar/15 ]

If resourceName may contain path separators, could that not create ambiguity with libraryVersion or resourceVersion?

For example the resourceIdentifier "libName/1_0/resName/2_0" might mean
libraryName=libName, libraryVersion=1_0, resourceName=resName, resourceVersion=2_0
or
libraryName=libName, libraryVersion=<empty>, resourceName=1_0/resName/2_0, resourceVersion=<empty>

libraryName is restricted to prevent ambiguity with libraryVersion (JSF 2.2 Spec, page 78). Maybe resourceName should have a similar restriction?

Or maybe this ambiguity is already dealt with elsewhere? For instance I didn't read through the whole algorithm in 2.6.1.4.

Comment by Arend v. Reinersdorff [ 18/Mar/15 ]

Other possible problems:

  • path separator charactar at the beginning or end "/resName/"
  • multiple path separators "res//Name"
Comment by Arend v. Reinersdorff [ 03/Feb/16 ]

Not addressed by JSF 2.3 Early Draft Review.





[JAVASERVERFACES_SPEC_PUBLIC-1363] Add cols attribute to selectManyCheckbox Created: 12/Feb/15  Updated: 12/Feb/15

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

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


 Description   

If a bigger list of checkboxes should be displayed, either the page gets very wide or height. It would be useful to display two or more columns of checkboxes. Frankly, the layout should be restricted to a spcified number of columns and automatically gets extended in height.

add attribute "cols" of type int to selectManyCheckBox. If omitted, assume a default of 1.

If layout="pagedirection" (vertical) than cols > 2 creates multiple cols of checkboxes. The checkboxes will be created from left to right until a count of "cols" is reached. Then the layout continues with the next line. Thus, the total height is apx. n/cols.

If layout="linedirection", than cols is ignored. Optionally, an attribute lines is used for this layout. Now n/lines cols will be created.



 Comments   
Comment by muellermi [ 12/Feb/15 ]

example:

layout="pagedirection"
[] item1
[] item2
[] item3
[] item4
[] item5

layout="pagedirection" cols="2"
[] item1 [] item2
[] item3 [] item4
[] item5

ayout="linedirection" lines="2"
[] item1 [] item2 [] item3
[] item4 [] item5





[JAVASERVERFACES_SPEC_PUBLIC-1358] Enhance conversation handling Created: 02/Feb/15  Updated: 03/Feb/15

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

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


 Description   

During a process flow, using @ConversationScoped beans, sometime it is useful to start a new (second, third, ...) conversation.
Using the standard postback navigation, JSF always injects the same conversation instance.
One approach to force a fresh conversation is to use <h:link ...> instead of <h:commandLink...>
Since the outcome of link is computed whilst rendering the page, navigation is static.
commandLink on the other hand allows to compute the navigation on click.
I propose these enhancements:

<h:commandLink createConversation="true" ...>

With this optional argument JSF does not inject the existing instance of a session but a fresh one.

<h:link output="#{...}" lazyCalculation="true" ...>

This renders a link without target <a href="" onclick="#{bean.navigationFunction}">...</a> and an onclick handler.
The handler's duty is to perform a partial request, retrieve the result of bean.navigationFunction (return value is String) and then perform a get navigation, e.g. by window.location.href = navOutcome;






[JAVASERVERFACES_SPEC_PUBLIC-1357] Make enum constants accessible from EL. Created: 01/Feb/15  Updated: 01/Feb/15

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

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


 Description   

Enum constants shall be accessible

Let me explain this by an example. Given an enum

public enum Page {

  Welcome("/welcome"),
  // many more...
  AdminWelcome("/admin/welcome");
  
  private Page(String url) {
    _url = url;
  }
  private final String _url;

  public String getUrl() {
    return _url + ".xhtml";
  }

  public String getRedirectUrl() {
    return _url + ".xhtml?faces-redirect=true";
  }
}

The goal is to access an URL of a specific member of that enum from an EL.

Declaring the enum as a named CDI bean (@Named) grants access to the methods, but the constants.

By now, there is an ugly workaround by mapping all entries and delegating from another bean to this

{enum Page)

  private static Map<String, String> _pages;

  public static Map<String, String> getPages() {
    if (_pages == null) {
      _pages = new HashMap<>();
      for (Page page : Page.values()) {
        _pages.put(page.name(), page.getUrl());
      }
    }
    return _pages;
  }

(otherBean)

  public Map<String, String> getPages() {
    return Page.getPages();
  }

Now access within EL is possible:

#{otherBean.pages.AdminCategoryEditor}}

--> The goal is to directly access the enum

#{page.AdminCategoryEditor.url}

The enum is used in a method

(otherBean)

  public String navigate(String topic) {
    // perform some useful stuff
    return topic;
  }

This can be used from EL

#{otherBean.navigate(otherBean.pages.AdminWelcome)}

It would be preferred to use an enum in the navigation method:

(otherBean)

  public String navigate(Page page) {
    // perform some useful stuff
    return page.getUrl();
  }

--> The goal is to directly access the enum

#{otherBean.navigate(page.AdminWelcome)}


 Comments   
Comment by muellermi [ 01/Feb/15 ]
{otherBean.navigate(AdminWelcome)}

should be

{otherBean.navigate(page.AdminWelcome)}




[JAVASERVERFACES_SPEC_PUBLIC-1354] Allow specify node-on-return in flow call node Created: 23/Jan/15  Updated: 23/Jan/15

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

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


 Description   

Nested flow has to know where to go (name of node in calling flow) when returning back to calling flow.
To encapsulate nested flow we should allow to specify node where to go after return from nested flow in the flow-call-node.

Conversation from another Jira issue:
Ed>You mean you'd like the "where to go after return" to be specified in
Ed>the flow-call node? That's not a bad idea. I can see adding that,
Ed>making it trump whatever value is returned from the called flow. Would
Ed>that satisfy?

Yes, that would be great. The nested flow would be encapsulated and it wouldn't have to know anything about calling flow's node names. It would be like when calling nested flow - you specify nested flow name, but not node name in nested flow.






[JAVASERVERFACES_SPEC_PUBLIC-1352] More clearly define requirements for one request cycle especially with respect to concurrency Created: 21/Jan/15  Updated: 26/Aug/15

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3690 Possible Concurrency Issues in UIRepeat Closed




[JAVASERVERFACES_SPEC_PUBLIC-1348] Better define usage of Flash, specifically with respect to response buffer size Created: 12/Jan/15  Updated: 30/Nov/16

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1320 Expose Flash for use from MVC Closed

 Comments   
Comment by Manfred Riem [ 30/Nov/16 ]

As this is not adding any value beyond clarification I am lowering its priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1341] Default value for viewParam Created: 10/Dec/14  Updated: 19/Jun/15

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

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


 Description   

What about allowing the definition of a default value for a view-parameter?

Example

Defining number of displayed items (pagination feature) as a view-parameter but still keeping default value within xhtml and not java bean.

Following example is a very clean approach provinding a default value.

<f:viewParam name="pageSize" value="#{bean.pageSize}" default="10"/>
<p:dataTable rows="#{bean.pageSize}"/>

Currently there are two workarounds which have no clean separation between markup and java code:

Workaround 1

Passing the default value to bean.

<f:viewParam name="pageSize" value="#{bean.pageSize}"/>
<f:event type="preRenderView" listener="#{bean.initPreRenderView(10)"/>
<p:dataTable rows="#{bean.pageSize}"/>
private int pageSize;

public void initPreRenderView(int pageSize)
{
	if (this.pageSize == 0)
		this.pageSize == pageSize;
}

Workaround 2

Hardcoding the default value in bean. But markup should be responsible and not bean.

<f:viewParam name="pageSize" value="#{bean.pageSize}"/>
<p:dataTable rows="#{bean.pageSize}"/>
private int pageSize = 10; 


 Comments   
Comment by djmj [ 19/Jun/15 ]

When using `ìncludeViewParams=true` on a link or command or using programmatically `getBookmarkableURL` the view parameters who's value equal their default value can be ignored.

This solves the problem of irrelevant parameters appended to link components. This behavior can be optional or optionally be deactivated using a param like `index.xhtml?appendDefaultValues=true`

A `<h:link>` with `<f:param name="pageSize" value="10">` can be ignored in the final URL.





[JAVASERVERFACES_SPEC_PUBLIC-1340] Allow ViewHandler to be injectable Created: 04/Dec/14  Updated: 26/Aug/15

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JAVASERVERFACES_SPEC_PUBLIC-1336] ViewScope and client side state saving is broken Created: 04/Nov/14  Updated: 04/Nov/14

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

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


 Description   

Easy to reproduce: use CS state saving... store something in view scope... stop your server (ensure it doesn't restore sessions)... start server and observe viewScope data is lost.



 Comments   
Comment by lu4242 [ 04/Nov/14 ]

JSF 2.2 javadoc of UIViewRoot.getViewMap(boolean create) says this:

"... For reasons made clear in ViewScoped, this map must ultimately be stored in the session. For this reason, a true value for the create argument will force the session to be created with a call to ExternalContext.getSession(boolean). ..."

Before JSF 2.2, view scope was stored with the view state on client side state saving.





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

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

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

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

 Description   

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

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



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

Not enough information in the bug report to take action.

Comment by Ed Burns [ 27/Aug/15 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1299] jsf.ajax.response should not send 'success' events in case of an error Created: 14/Aug/14  Updated: 14/Aug/14

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

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


 Description   

This is a followup of JAVASERVERFACES-3103.

If the ajax response contains an error the clientside JS (jsf.ajax.response) sends an "serverError" event to the registered listeners AND just after this an "success" event to registered listeners. This leads to malfunctions if the application depends on both of these events. The "success" event is unexpected in the server side error (e.g. Exception in the triggered ajax listener) case here.

jsf.js
line 2255: sendError(request, context, "serverError", null, errorName, errorMessage);
line 2256: sendEvent(request, context, "success");

At the moment this behavior is by design but it does not make sense:
Two concerns are mixed up here: processing the response on the client side and processing the request on the server side.

The response is indeed successfully processed on the client side. But the client side does not need to be notified by this explicitly in that case. The processed result is already available in the onerror event handler.
There is no more information available in the "success" event and this behaviour makes it complicated to handle server side errors on the client.

For the enduser the result of a failed processed request or a successfully proccessed server side error is the same: there is an error not a successfully performed action.

So how can one dedect a "success" event in a server error case at the moment:

  • explicitly analyse the data transmitted
  • remember there was already an error event before

Both options are not necessary if the spec would not require to send the "success" event in a server error case.

Manfred Riem agrees with me.






[JAVASERVERFACES_SPEC_PUBLIC-1296] Clarify when it is valid to instantiate and use a PartialResponseWriter Created: 30/Jul/14  Updated: 13/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3358 Allow for creation of PartialViewCont... Closed

 Description   

The spec makes an implicit assumption about when it is valid to instantiate a PartialViewContext(). This assumption is: the current execution context must have FacesServlet.service() above on the callstack, which implies the existence of a FacesContext.



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1295] Add default implementation for UIComponent#getFamily() Created: 20/Jul/14  Updated: 01/Aug/14

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

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

Tags: ease-of-use, ease_of_development

 Description   

Custom components inheriting from UIComponentBase are currently required to provide an implementation for UIComponent#getFamily() as it's an abstract method.

This is a small nuisance for simple custom components (e.g. ones used internally by some application), which rarely have any need for distinguishing components based on family.

Typically those components just return the empty string or null (JAVASERVERFACES_SPEC_PUBLIC-1267) or some nonsense string like "whatshouldido.with.this".

If developers are not providing any meaningful return value for this method, I guess JSF might just as well provide a default implementation in UIComponentBase (e.g. a method just returning null), thereby making custom components yet again a tiny bit easier to create.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1291] RFE: Ability for h:messages to display a single custom message whenever the component has received any faces message. Created: 11/Jul/14  Updated: 01/Aug/14

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

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

Attachments: PNG File single message.png    

 Description   

In OmniFaces you can use h:messages to display a single message at the top of the screen such as "There are validation errors. Please fix them.", and then display component specific messages beside the components. They have added a "for" attribute to h:messages that points to the form component, and a "message" for the message to display. I will attach a screenshot.

http://showcase.omnifaces.org/components/messages

I've had customers ask me to do this very thing in our production applications.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1290] RFE: Add a var attribute to h:messages that enables the developer to fully control output styling Created: 11/Jul/14  Updated: 13/Aug/14

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

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


 Description   

Please see the OmniFaces messages component:

http://showcase.omnifaces.org/components/messages

"Control iteration markup fully by the new var attribute which sets the current FacesMessage in the request scope and disables the default table/list rendering."

<o:messages var="message">
<li class="#

{fn:toLowerCase(message.severity)}

">#

{message.summary}

</li>
</o:messages>



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1289] RFE: When the required attribute of a checkbox is set to true, a validation error should occur when the form is submitted and the checkbox is not checked Created: 11/Jul/14  Updated: 01/Aug/14

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

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


 Description   

See the RequiredCheckboxValidator in OmniFaces for a discussion of the issue:

http://showcase.omnifaces.org/validators/RequiredCheckboxValidator

The default behavior in JSF is non-intuitive and causes seemingly unnecessary work to be required in the action method.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1288] Clarify that default locale is implicitly a supported locale Created: 10/Jul/14  Updated: 13/Aug/14

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

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


 Description   

Section "2.5.2.1 Determining the active Locale"

gives an example of locale configuration:

This application’s default locale is en, but it also supports de, fr, and es locales. These elements cause the Application instance to be populated with Locale data. Please see the javadocs for details.

This seems to imply that the default locale is implicitly a supported locale. I think we should state this explicitly.



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1285] f:selectItems ignore itemDescription within h:selectOneListbox and related components Created: 19/Jun/14  Updated: 01/Aug/14

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

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


 Description   

Facelets tag lib documentation shows the following properties as valid for f:selectItems:

itemValue
itemLabel
itemDescription
itemDisabled
itemLabelEscaped
...

But in both Mojarra and MyFaces the attribute itemDescription, itemDisabled, itemLabel are ignored.

But taking a look at the renderkit spec javadoc of javax.faces.SelectMany/javax.faces.Listbox in the section "Rendering the "option" elements" it says this:

"... If the current child is a UISelectItem create a SelectIteminstance from its itemValue, itemLabel, itemEscaped, and itemDescription properties, add it to the list. If the current child is a UISelectItems instance, call its getValue() method. If the result is a SelectItem bean, add it to the list. If the result is an array of SelectItem beans, add each one to the list. If the result is a Collection of SelectItem beans, add each one to the list. If the result is a Map, create a SelectItem bean for each entry in the Map using the key as the label, the value as the value, and null as the description. ..."

So, these properties are supposed to be used with f:selectItem, not with f:selectItems. But the user perceive this as a bug, which is something logic. See:

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

In JSF 2.2 with HTML5 friendly markup, it is supposed that f:selectItems can have passthrough attributes. See:

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

But in MyFaces we found that it doesn't work for h:selectOneRadio or h:selectManyCheckbox.

The thing is the fix for this issue is pretty similar for the one that needs to be done for HTML5 friendly markup.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1281] Extend vdl.createComponent with support of ui:includes and user tags Created: 31/May/14  Updated: 21/Aug/14

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

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


 Description   

Myfaces implementation extends their vdl.createComponent with support of ui:include and custom or composite tags. This great solution completely replace a set of strange workarounds from network or OpenFaces.

Mojarra in vdl.createComponent and DefaultFaceletFactory._createComponent supports only standard UIComponents and tags from api. There is no reason to support only tags from api.
Problem was registered as https://java.net/jira/browse/JAVASERVERFACES-3281 but unfortunately closed.

Test examples
-mojarra-2.2.6\test\agnostic\component\programmaticComponentCreation\src\main\java\com\sun\faces\test\agnostic\component\programmaticComponentCreation\CreateComponentBean.java
-http://svn.apache.org/repos/asf/myfaces/core/trunk\impl\src\test\java\org\apache\myfaces\view\facelets\pool\
-http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/test/java/org/apache/myfaces/view/facelets/pss/acid



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by krokodylowy3 [ 21/Aug/14 ]

This extension is also performance improvement. We no longer need use a set of permanent includes and tags for temporary visible popups and views which was a old headache of jsf framework. Code can be truly dynamic and well separated.





[JAVASERVERFACES_SPEC_PUBLIC-1276] FacesEvent not serializable with PhaseId Created: 01/May/14  Updated: 13/Aug/14

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

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


 Description   

FacesEvent (and its derivative objects) are marked as serializable, yet they are not if a phaseId is provided. The following test class:

public class Test
{
public static void main(String[] argv)
{
ActionEvent event = new ActionEvent(new UIOutput());
event.setPhaseId(PhaseId.APPLY_REQUEST_VALUES);

ByteArrayOutputStream out = new ByteArrayOutputStream();
ObjectOutputStream oout;
try

{ oout = new ObjectOutputStream(out); oout.writeObject(event); }

catch (IOException e)

{ e.printStackTrace(); }

}
}

Yields the following error:

java.io.NotSerializableException: javax.faces.event.PhaseId
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1165)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1535)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1413)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1159)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:329)
at test.Test.main(Test.java:31)

This is because PhaseId is not serializable. Regardless of PhaseId's ability to be serialized, FacesEvent must honor the serializable contract and be able to be serializable.



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

Unfortunately, because PhaseId is a javax.faces class, we cannot change its signature without revising the JSF specification. We will tackle this in 2.3.

Comment by Ed Burns [ 01/May/14 ]

I may be able to come up with a workaround to make this work in the meantime.

Comment by Hanspeter Duennenberger [ 12/May/14 ]

Would below change affect signature as well?
As workaround this would use the PhaseId ordinal as serialized value in FacesEvent:

Index: jsf-api/src/main/java/javax/faces/event/FacesEvent.java
===================================================================
--- jsf-api/src/main/java/javax/faces/event/FacesEvent.java	(revision 13233)
+++ jsf-api/src/main/java/javax/faces/event/FacesEvent.java	(working copy)
@@ -86,7 +86,9 @@
 
     }
 
-    private PhaseId phaseId = PhaseId.ANY_PHASE;
+    private int phaseOrdinal = PhaseId.ANY_PHASE.getOrdinal();
+
+    private transient PhaseId phaseId = PhaseId.VALUES.get(phaseOrdinal);
 
     /**
      * <p>Return the identifier of the request processing phase during
@@ -112,6 +114,7 @@
 	    throw new IllegalArgumentException();
 	}
 	this.phaseId = phaseId;
+	this.phaseOrdinal = phaseId.getOrdinal();
     }
 

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1271] Simplify overriding a component's renderer Created: 27/Mar/14  Updated: 01/Aug/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: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 {
    // ...
}


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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[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: 01/Aug/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: 2
Labels: None
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 ... Closed

 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.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





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

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

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

Attachments: Zip Archive i_spec_1253-reproducer.zip     Text File i_spec_1253.patch    

 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 ]

Diff of reproducer.

Comment by Ed Burns [ 17/Jan/14 ]

zip of reproducer.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





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

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

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


 Description   

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



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

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

Comment by Ed Burns [ 13/Aug/14 ]

Bean Validation 1.1 added this, so it's high time we do the same.





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

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

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


 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.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





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

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

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


 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 ]

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.

Comment by Ed Burns [ 01/Aug/14 ]

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





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

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: Unassigned
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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.



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

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

Comment by Ed Burns [ 13/Aug/14 ]

This area is very sensitive to performance problems.

Comment by tandraschko [ 26/Sep/15 ]

The performance won't be affected for existing applications as the new search expression logic is only used if the whole expression string contains a "@".
Some expressions are faster, some are slower but the overall performance is very good and i did a lot of optimization for it.

Would great to see it in the next API release. BootsFaces implemented a similiar API.
As i said, i would take care of it and would contribute my ideas to the JSF API.

Comment by stephanrauh [ 26/Sep/15 ]

I agree with Thomas. I consider the advanced search expressions very useful. So useful, that I implemented them in BootsFaces 0.8.0 myself. As for the performance considerations: granted, we should keep the performance in mind. However, I'm using the PrimeFaces search expressions for years now without noting a performance penalty. In particular, the expressions I use most frequently - @parent, @next and @previous - are implemented in a very efficient way.

Comment by balusc [ 20/Jun/16 ]

This is one of the things I'd like to see in JSF 2.3 as well. Community contribution is very welcome.





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

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File mojarra-trunk-xhr2-upload.patch    

 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 ]

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 ]

Contribution From IceSoft

Comment by Ed Burns [ 01/Aug/14 ]

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





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

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

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


 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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by muellermi [ 08/Feb/16 ]
  • add an attribute validateGroup="someGroup" to the f:validateBean tag,
    e.g.
    <f:validateBean validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Email" validateGroup="de.muellerbruehl.jsf23.Email"/>

At the time, the validator is executed (on submit, immediate if ajaxified), do not validate according to the default group, which is default if validateGroup is missing, but according to the given group. If this group performs a multi field validation, create a copy of the model, apply new values (if applicable) and perform the validation.

Comment by muellermi [ 08/Feb/16 ]

Maybe a "validate" attribute for the f:ajax would be a good place to trigger (multi field) group validation.

<h:message for="ageValidator"/>
<h:inputText id="ageDays" value="#

{grouper.ageDays}

">
<f:validateBean id="ageValidator" validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Age"/>
<f:ajax render="msgAgeDays ageValidator" validate="de.muellerbruehl.jsf23.Age"/>
</h:inputText>
<h:message id="msgAgeDays" for="ageDays"/>

<h:inputText id="ageYears" value="#

{grouper.ageYears}

">
<f:validateBean validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Age"/>
<f:ajax render="msgAgeYears ageValidator" validate="de.muellerbruehl.jsf23.Age"/>
</h:inputText>
<h:message id="msgAgeYears" for="ageYears"/>





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

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: 6
Labels: None
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days


 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 ]

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 ]

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 ]

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 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by muellermi [ 17/Sep/15 ]

The idea behind this issue only protects the browser to open a new tab or window using the same client id.

Sadly the user still is able to copy the url and paste it into a manually opened new tab. What we really need is some information to determine the "right" window.

Comment by muellermi [ 17/Sep/15 ]

Maybe window.name (JavaScript) would be helpful to perform this task.

Comment by tandraschko [ 17/Sep/15 ]

window.name is also used in DeltaSpike.
Please have a look at it: http://deltaspike.apache.org/documentation/jsf.html#AvailableModes
CLIENT_WINDOW is the most complete and 100% working mode.

I will complete the docu these days, LAZY mode is described much more detailed.





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

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: 4
Labels: None
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

 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 ]

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

Comment by dasago [ 10/Apr/13 ]

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 ]

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 Lee [ 30/Aug/13 ]

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 ]

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

Ed

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





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

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

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

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

 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 ]

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.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[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: 01/Aug/14

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 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 ]

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 ]

Added changebundle containing the proposed changes.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





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

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

Type: Bug Priority: Major
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
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

 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 ]

Can you please supply an example that reproduces the problem?

Comment by jasonzhang2002gmailcom [ 09/Jul/13 ]

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 ]

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.

Comment by Ed Burns [ 01/Aug/14 ]

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





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

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

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

 Description   

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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1197] Support multiple attribute on h:inputFile Created: 10/Jun/13  Updated: 01/Aug/14

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
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

 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.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[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: 13/Aug/14

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

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

Attachments: File 20130523-web-partialresponse_2_2.xsds    

 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 ]

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 ]

web-partialresponse also must be fixed.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1191] SelectMany with generic collection results in ClassCastException Created: 07/May/13  Updated: 01/Aug/14

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.12


Tags: collection, generic, selectmanycheckbox, selectmanylistbox

 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)



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1189] Flow identifier in @FlowDefinition Created: 29/Apr/13  Updated: 11/Aug/15

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: fishcat

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


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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1184] Support using JSON for component updates instead of XML Created: 22/Apr/13  Updated: 13/Aug/14

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: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

Arjun, you're exactly right.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1183] selectMany components swallow/forgets preselected disabled SeletItems Created: 18/Apr/13  Updated: 01/Aug/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: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2555 selectMany components swallow/forgets... Closed

 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 ]

Please see associated issue for attachments

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1178] Remove references to old XML schema and tag library URI Created: 01/Apr/13  Updated: 13/Aug/14

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

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


 Description   

Arun P. Gupta reported numerous instances of the old namespaces in the PDF. These should be fixed.



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1177] Make it so com.sun.faces.faceletCache works with caching with respect to Resource Library Contracts Created: 20/Dec/12  Updated: 25/Feb/15

Status: Reopened
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
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2655 DefaultFaceletFactory.needsToBeRefres... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1346 Parties that decorate FaceletCacheFac... Resolved

 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 ]

Ed will read through Leonardo's comments on this matter on the thread he started on 14 January 2013 on the EG list.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1172] ClientWindow: deal gracefully with multiple client windows having the same id Created: 13/Mar/13  Updated: 13/Aug/14

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

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


 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



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1171] Specify interaction of Stateless and CSRF protection Created: 13/Mar/13  Updated: 01/Aug/14

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2