[JAVASERVERFACES_SPEC_PUBLIC-898] Please, one "upload file" component in standard. Created: 23/Oct/10  Updated: 01/Aug/14  Resolved: 31/Jan/11

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

Type: New Feature Priority: Blocker
Reporter: angelcervera Assignee: rogerk
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 898
Status Whiteboard:

size_medium importance_large


 Description   

All developers go on crazy when need upload files using JSF.
Each JSF implementation uses her own component, breaking portability in
applications.
Why is not this common component included in standard? Are there problems with
multipart request? Ok, is not this place and moment to find a solution?

Thanks a lot.



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 31/Jan/11 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-881] media attribute absent in h:outputStylesheet tag Created: 01/Sep/10  Updated: 01/Aug/14  Resolved: 14/Sep/10

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

Type: Improvement Priority: Blocker
Reporter: Jan-Kees van Andel Assignee: Ed Burns
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 881

 Description   

I'm currently building an iPad enabled website using JSF and I use the media attribute (on
the HTML link tag) to conditionally use a particular CSS file, depending on whether I'm
holding the iPad in landscape or portrait mode (can be tested in any browser by resizing
it in such a way that it's higher than it's wide).

I do something like this:
<link rel="stylesheet" media="screen and (orientation:portrait)"
href=".....portrait.css"/>
<link rel="stylesheet" media="screen and (orientation:landscape)"
href=".....landscape.css"/>

This works, but unfortunately, I bypass JSF this way, so EL expressions in my CSS files
aren't executed. This is particularly annoying when defining image URL's, like this:

div#hello {
background: url(/parleys/resources/ipad/image.jpg);
}

As you can see, this has the context root hard coded, which is not desirable.

I would like to be able to do this:
div#hello {
background: url(#

{resource['ipad:featuredphoto_paging_btn.jpg']}

);
}

which appends the context root dynamically.

Support for the media attribute is also useful in other use cases, like a print layout.



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

Jan-Kees, can I close this as a dup of issue 444?

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=444

FYI: we've had this feature in Mojarra for over a year!

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-863] Specify use of ServletContainerInitializer. Created: 02/Jul/10  Updated: 01/Aug/14  Resolved: 20/Sep/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.1

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

Operating System: All
Platform: All


Issuezilla Id: 863
Status Whiteboard:

size_small importance_large

Tags: changelog_2_1

 Description   

Mojarra implements this, but it's not been specified. Time to specify it.



 Comments   
Comment by Ed Burns [ 02/Jul/10 ]

triage, milestone, ownership

Comment by Ed Burns [ 14/Jul/10 ]

Fix checked in.

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-859] Composite components only support one action attribute Created: 28/Jun/10  Updated: 01/Aug/14  Resolved: 28/Oct/10

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

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

Operating System: All
Platform: All


Attachments: Text File 859-cc-attribute-methodType.patch     Text File changebundle.txt     Zip Archive composite-component-targets-test-3.zip     File composite-component-targets-test.war    
Issuezilla Id: 859
Status Whiteboard:

size_medium importance_large


 Description   

As far as I have seen there is no way to make a composite component properly
support more than one action (actionListener...) attribute. While the
re-targeting works fine for one action attribute, it is not possible to have two
action sources with two independant action attributes.

Here is a very simple and not so uncommon example of what I mean:

<cc:interface>
<cc:attribute name="submitAction" targets="submitButton"/>
<cc:attribute name="cancelAction" targets="cancelButton"/>
<cc:actionSource name="submitButton"/>
<cc:actionSource name="cancelButton"/>
</cc:interface>

The attributes are not handled completely (can be a string or a method
expression) as they are not named action.

One solution for this problem might be to have a targetName attribute:

<cc:interface>
<cc:attribute name="submitAction" targets="submitButton" targetName="action"/>
<cc:attribute name="cancelAction" targets="cancelButton" targetName="action"/>
<cc:actionSource name="submitButton" targets="myForm:submitBtnId"/>
<cc:actionSource name="cancelButton" targets="myForm:cancelBtnId"/>
</cc:interface>



 Comments   
Comment by rogerk [ 28/Jun/10 ]

triage

Comment by rogerk [ 07/Jul/10 ]

retarget

Comment by rogerk [ 26/Aug/10 ]

triage

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=326)
Patch proposed adding cc:attribute methodType property (prefer that name than targetName)

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=327)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=328)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by ganeshpuri [ 27/Oct/10 ]

From JSR-314-open:

2010/10/27 Ganesh <ganesh@j4fry.org>
G> Can you please give a use case for multiple method signatures?
G> The use cases that come to my mind would work fine with:

G> <cc:attribute name="testAction" method-signature="String method()" />

LU> "action" could receive the following signatures:
LU> String method()
LU> Object method()
LU> void method()
LU>
LU> Really the most clear case is "actionListener":
LU>
LU> void method(javax.faces.event.ActionEvent )
LU> void method()
LU>

Comment by ganeshpuri [ 27/Oct/10 ]

In which case would you need an actionListener with the signature "void
method()"? Wouldn't you always pass this parameter to UICommand thus requiring
the signature "void method(javax.faces.event.ActionEvent )"?

Same for action: Why do you propose allowing signatures "Object method()" and
"void method()" though the underlying UICommand will definitely require "String
method()"?

Comment by michael_kurz [ 28/Oct/10 ]

Please keep in mind, that an action attribute is not necessarily a method
expression but can also be an outcome String.

I prefer targetName over methodType as it takes in fact the name of the
attribute for re-targeting.

Comment by Ed Burns [ 28/Oct/10 ]

take ownership

Comment by Ed Burns [ 28/Oct/10 ]

Thanks so much for submitting a patch, Leonardo. I looked at your patch and ended up writing my own
which turned out to be very similar.

Please review it. Not that my patch also includes an automated test, which is, in fact, required to be a
good citizen committer to Mojarra.

Comment by Ed Burns [ 28/Oct/10 ]

Created an attachment (id=329)
Alternat patch, includes spec language, feature, and automated test

Comment by Ed Burns [ 28/Oct/10 ]

>>>>> On Thu, 28 Oct 2010 12:11:52 +0200, Jakob Korherr <jakob.korherr@irian.at>
said:

JK> The patch looks very good, however I don't really like the idea of
JK> pushing the "target-approach". By reasons explained on the
JK> jsr-314-open list it is much easier for the user to refer from the
JK> implementation to the interface via #

{cc.attrs.submitAction}

or
JK> #

{cc.attrs.cancelAction}

.

Yes, and this is the crux of issue 755. I do not feel the two are mutually
exclusive.

Comment by Ed Burns [ 28/Oct/10 ]

Committed revision 8688.

Comment by Ed Burns [ 28/Oct/10 ]

Marking fixed.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-804] ResourceBundleELResolver.getType() regression Created: 19/May/10  Updated: 01/Aug/14  Resolved: 19/May/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: EL
Affects Version/s: 1.2
Fix Version/s: 2.0 Rev a

Type: Bug Priority: Blocker
Reporter: Ed Burns Assignee: javaserverfowner
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 804

 Description   

The JSF 1.2 spec, section 5.6.1.3, states that getType() on the ResourceBundleELResolver for Faces
should return ResourceBundle.class.

After applying the 20100406 patch, this now returns PropertyResourceBundle.class.



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

This should be an impl issue, not a spec issue.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-780] DelegatingMetaTagHandler.applyNextHandler is not documented Created: 31/Mar/10  Updated: 01/Aug/14  Resolved: 22/Jun/10

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

Type: Bug Priority: Blocker
Reporter: arobinson74 Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://goo.gl/JB1n


Issuezilla Id: 780
Status Whiteboard:

changelog


 Description   

Neither applyNextHandler of DelegatingMetaTagHandler or nextHandler of TagHandler
are documented.

http://goo.gl/JB1n
http://goo.gl/AUr3

This is problematic as it is not obvious what it really does. Does this include
the next tag, or the first child tag? It would be nice to know.



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

P1 for 2.0 Rev a.

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 26/May/10 ]

Fix checked in.

Comment by Ed Burns [ 26/May/10 ]

Blast, forgot to mark fixed.

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-758] Support view actions that execute before tree is built w/ navigation support Created: 03/Mar/10  Updated: 10/May/13  Resolved: 10/May/13

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Blocker
Reporter: mojavelinux Assignee: Ed Burns
Resolution: Fixed Votes: 10
Labels: None
Σ Remaining Estimate: 1 week, 2 days, 23 hours, 10 minutes Remaining Estimate: 1 week, 2 days, 23 hours, 10 minutes
Σ Time Spent: 11 hours, 4 minutes Time Spent: 11 hours, 4 minutes
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://seamframework.org/Documentation/JSFEnhancementViewActions


Attachments: Text File 20110615_i_spec_758.patch     Text File 20110729-01-i_spec_758.patch     Text File 20110810-i_spec_758.patch     Text File 20110812-i_spec_758.patch     Text File 20110818-i_spec_758.patch     Text File changebundle.txt     Text File diffs.patch     Text File diffs.patch     Zip Archive i_spec_758_war.zip     Zip Archive newfiles.zip    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-762 Only short-circuit a non-faces reques... Closed
depends on JAVASERVERFACES-2165 Verify that an <f:viewAction> with ne... Closed
depends on JAVASERVERFACES-2269 Verify implementation of CSRF protection Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-340 Portlet Bridge Issue: Add ability to ... Sub-task Closed javaserverfowner  
JAVASERVERFACES_SPEC_PUBLIC-968 Improve Event Handling Sub-task Resolved  
JAVASERVERFACES_SPEC_PUBLIC-975 Provide response headers in Event Dat... Sub-task Open  
Issuezilla Id: 758
Status Whiteboard:

size_medium importance_large 20110201-tag


 Description   

JSF should provide a view metadata component that defines a method expression to
be invoked before the component tree is built (or restored), with support for
navigating to an alternative view afterward using navigation rules. Navigation
may be the result of a constraint violation, a security restriction, or because
the request was for a pseudo-view.

As an example, the developer might use a view action to load a blog entry before
the view is displayed. If the entry cannot be found, the user would be
redirected to another page using a navigation rule.

<f:view>
<f:metadata>
<f:viewParam name="id" value="#

{blogController.id}

"/>
<f:viewAction execute="#

{blogController.loadEntry}" onPostback="false"/>
</f:metadata>
</f:view>

<navigation-case>
<from-action>#{blogController.loadEntry}

</from-action>
<from-outcome>false</from-outcome>
<to-view-id>/entries.xhtml</to-view-id>
<redirect/>
</navigation-case>

This feature relates to view parameters, as the example suggests. View
parameters were introduced in JSF 2.0 to provide a declarative value binding
between query string parameters and model properties. They go a long way towards
accommodating the action-oriented scenario in JSF. But view actions are a
necessary part of the equation.

<f:event type="preRenderView"> is similar to <f:viewAction>, but is insuffient
as a front controller. <f:event> gets you by if the purpose is to perform
processing at the start of the request. <f:viewAction> is intended for when you
have to perform logic to verify that the view can even be rendered. View-level
security is one example. Another is verifying that preconditions are met. And
the key is to make navigation away from the view an integrated part when it's
determined that the view cannot and should not be rendered.



 Comments   
Comment by mojavelinux [ 03/Mar/10 ]

Change target milestone.

Comment by mojavelinux [ 03/Mar/10 ]

Andy Schwartz clarifies:

1. View actions would be processed during invoke application phase.
PreRenderView events are delivered during the render response phase.

2. View actions would be integrated with the navigation system (allow navigation
rules to be applied). PreRenderView events require programmatic interaction with
the NavigationHandler.

3. View actions would be part of the view metadata (like view parameters) and
thus would be available before the full component tree has been created.
PreRenderView event listeners are registered (via <f:event>) when the full
component tree is created.

Comment by Ed Burns [ 22/Jun/10 ]

sheetalv

Comment by Ed Burns [ 03/Aug/10 ]

Lincoln also shared http://docs.jboss.org/seam/3/faces/reference/snapshot/en-US/html_single/#viewaction

Comment by Jan-Kees van Andel [ 04/Aug/10 ]
      • Issue 867 has been marked as a duplicate of this issue. ***
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 09/Jun/11 ]

Move viewParameters automated test to jsf-test

Comment by Ed Burns [ 09/Jun/11 ]

In progress.

Comment by Ed Burns [ 14/Jun/11 ]

Brian, if you could please hack upon this and make it a simple sample of s:viewAction, I'd really appreciate it.

Comment by Ed Burns [ 14/Jun/11 ]

Brian, if you could please simply hack upon this and turn it into a simple example of s:viewAction, that would be great.

Comment by Ed Burns [ 16/Jun/11 ]

Sending jsf-api/build.xml
Adding jsf-api/doc/expert-draft-bg.graffle
Adding jsf-api/doc/expert-draft-bg.png
Adding jsf-api/doc/jsdoc-template
Adding jsf-api/doc/jsdoc-template/static
Adding jsf-api/doc/jsdoc-template/static/default.css
Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-api/doc/standard-html-renderkit.xml
Adding jsf-api/doc/uiviewaction-props.xml
Adding jsf-api/src/main/java/javax/faces/component/UIViewAction.java
Sending jsf-api/src/main/java/javax/faces/context/ExternalContextWrapper.java
Sending jsf-api/src/main/java/javax/faces/event/PhaseId.java
Sending jsf-api/src/main/resources/jsf-api.css
Sending jsf-demo/build.xml
Sending jsf-ri/build.xml
Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
Sending jsf-ri/conf/share/facelets_jsf_core.tld
Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentSupport.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/core/CoreLibrary.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/Issue758TestCase.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsIndex.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsReader.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsStory.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/events.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page01.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page02.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page03.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/template.xhtml
Sending jsf-test/build.xml
Sending jsf-tools/src/main/resources/com/sun/faces/generate/facesdoc/stylesheet.css
Transmitting file data ................................
Committed revision 9173.

Checkpoint. Specified but not implemented.

Comment by Ed Burns [ 29/Jul/11 ]

snapshot. Brian Leathem's simple testcase works.

Comment by Ed Burns [ 10/Aug/11 ]

Snapshot, sample app based on Dan Allen's original NewsReader testcase works.

Comment by Ed Burns [ 11/Aug/11 ]

Snapshot to run automated tests on ADC machine.

Comment by Ed Burns [ 11/Aug/11 ]

The i_spec_915 testcase caught a mod in this changebundle that introduced breakage. The jsf-ri-config.xml does not need to be modified and I'm not sure why it was. Victory for automated tests.

Comment by Ed Burns [ 12/Aug/11 ]

Resolution attempt one realized http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-758

SECTION: Modified Files
----------------------------
M applicationIntegration.fm

  • 7.4.2 Rewrite the paragraph on how to handle a redirect as follows.

If a matching <navigation-case> element was located, and the
<redirect/> element was specified in this <navigation-case>

+ or a call to UIViewAction.isProcessingBroadcast() returns true,

call getRedirectURL() on the ViewHandler, passing the current
FacesContext, the <to-view-id>, any name=value parameter pairs
specified within <view-param> elements within the <redirect> element,
and the value of the include-view-params attribute of the <redirect />
element if present, false, if not. The return from this method is the
value to be sent to the client to which the redirect will occurr. Call
getFlash().setRedirect(true) on the current FacesContext. Cause the
current response to perform an HTTP redirect to this path.

+ If the preceding call to UIViewAction.isProcessingBroadcast() had
+ returned true, also call setKeepMessages(true) on the flash.

Call responseComplete() on the FacesContext instance for the current
request. If the content of <to-view-id> is a value expression, first
evaluate it to obtain the value of the view id.

M jsf-api/src/main/java/javax/faces/component/UIViewAction.java

  • complete spec for this feature
  • rename "if" attribute of f:viewAction to "rendered".

M jsf-ri/conf/share/facelets_jsf_core.tld

  • rename "if" attribute of f:viewAction to "rendered".

M jsf-ri/src/main/java/com/sun/faces/application/NavigationHandlerImpl.java

  • implement changes to 7.4.2

M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/build.xml
M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsReader.java
M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page02.xhtml

A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war/ViewActionTestBean.java
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/main.xhtml
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF/web.xml
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/result.xhtml
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/pom.xml
A + jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/Issue758SimpleTestCase.java

Comment by Ed Burns [ 12/Aug/11 ]

Sending jsf-api/src/main/java/javax/faces/component/UIViewAction.java
Sending jsf-ri/conf/share/facelets_jsf_core.tld
Sending jsf-ri/src/main/java/com/sun/faces/application/NavigationHandlerImpl.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/Issue758SimpleTestCase.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war/ViewActionTestBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/main.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/result.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/java/com/sun/faces/regression/i_spec_758/NewsReader.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_war/src/main/webapp/page02.xhtml
Transmitting file data ............
Committed revision 9254.

Sending applicationIntegration.fm
Sending preface.fm
Transmitting file data ..
Committed revision 1027.

Committed to trunk.

Comment by Ed Burns [ 18/Aug/11 ]

snapshot

Comment by Ed Burns [ 18/Aug/11 ]

Corner cases on using viewAction to go back to the same page http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-758

SECTION: Modified Files
----------------------------
M applicationIntegration.fm

  • 7.4.2 now has this text

If a matching <navigation-case> element was located, proceed as follows.

+ * If UIViewAction.isProcessingBroadcast() returns true, call
+ getFlash().setKeepMessages(true) on the current FacesContext. Compare
+ the viewId of the current viewRoot with the <to-view-id> of the
+ matching <navigation-case>. If they differ, take any necessary actions
+ to effectively restart the JSF lifecycle on the<to-view-id> of the
+ matching <navigation-case>. Care must be taken to preserve any view
+ parameters or navigation case parameters, clear the view map of the
+ UIViewRoot, and call setRenderAll(true) on the
+ PartialViewContext. Implementations may choose to meet this
+ requirement by treating this case as if a <redirect /> was specified
+ on the matching <navigation-case>. If the viewIds do not differ,
+ continue on to the next bullet point.

+ * If the <redirect/> element was not specified in this <navigation-case>
(or the application is running in a Portlet environment, where
redirects are not possible), use the <to-view-id> element of the
matching case to request a new UIViewRoot instance from the
ViewHandler instance for this application, and pass it to the
setViewRoot() method of the FacesContext instance for the current
request. Then, exit the algorithm. If the content of <to-view-id> is a
value expression, first evaluate it to obtain the value of the view
id.

+ * If the <redirect/> element was specified in this <navigation-case>,
call getRedirectURL() on the ViewHandler, passing the current
FacesContext, the <to-view-id>, any name=value parameter pairs
specified within <view-param> elements within the <redirect> element,
and the value of the include-view-params attribute of the <redirect />
element if present, false, if not. The return from this method is the
value to be sent to the client to which the redirect will occurr. Call
getFlash().setRedirect(true) on the current FacesContext. Cause the
current response to perform an HTTP redirect to this path, and call
responseComplete() on the FacesContext instance for the current
request. If the content of <to-view-id> is a value expression, first
evaluate it to obtain the value of the view id.

M jsf-api/src/main/java/javax/faces/component/UIViewAction.java

  • Fix logic error that would cause multiple f:actionEvents to fail.

M jsf-ri/src/main/java/com/sun/faces/application/NavigationHandlerImpl.java

  • Implement new 7.4.2 spec

M jsf-test/build.xml

  • wire up testcases

M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/java/com/sun/faces/regression/i_spec_758_simple_war/ViewActionTestBean.java
A + jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/pageAviewActionPageA.xhtml
A + jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/pageAviewActionEmpty.xhtml
A + jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/pageAviewActionPageAExplicitRedirect.xhtml
A jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/WEB-INF/faces-config.xml
A + jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_simple_war/src/main/webapp/pageAviewActionNull.xhtml
M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/Issue758SimpleTestCase.java
D jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/Issue758TestCase.java
A + jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/i_spec_758_htmlunit/src/main/java/com/sun/faces/regression/i_spec_758/ViewParametersTestCase.java
M jsf-test/JAVASERVERFACES_SPEC_PUBLIC-758/build.xml

  • Exercise corner cases, also HtmlUnit test for ViewParameters
Comment by Ed Burns [ 18/Aug/11 ]

Committed frame changes.

Sending applicationIntegration.fm
Transmitting file data .
Committed revision 1028.
Rhombus:frame edburns$

Comment by lamine_ba [ 01/Dec/11 ]

Hi,

Regarding the instruction below


<f:view>
<f:metadata>

<f:viewParam name="id" value="#{blogController.id}"/>
<f:viewAction execute="#{blogController.loadEntry}" onPostback="false"/>

</f:metadata>
</f:view>

I'm wondering if we could have this short variation


<f:view>
<f:metadata>

<f:viewAction param-name="id" param-value="#{blogController.id}" 
execute="#{blogController.loadEntry}" onPostback="false"/>

</f:metadata>
</f:view>

Thanks

Comment by Ed Burns [ 14/Dec/11 ]

Closed pending verification of implementation.

Comment by Ed Burns [ 14/Dec/12 ]

Leo found some additional work for this issue.

Comment by arjan tijms [ 09/May/13 ]

Now that the JSF 2.2 spec has been finalized, shouldn't this issue be closed as well?





[JAVASERVERFACES_SPEC_PUBLIC-754] Spec is not backwards compatible with extension behavior for decorating NavigationHandler (and other updated extension points) between jsf1.x and 2.0 Created: 24/Feb/10  Updated: 01/Aug/14  Resolved: 15/May/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

Type: Bug Priority: Blocker
Reporter: lincolnbaxter Assignee: Ed Burns
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 754
Status Whiteboard:

cat1 frame


 Description   

It is currently possible to decorate the NavigationHandler by configuring a
custom NavigationHandler that accepts as a constructor argument, the currently
configured NavigationHandler.

public MyCustomNavigationHandler(NavigationHandler handler)

JSF2 specifies that JSF2 compliant navigation handlers must extend
ConfigurableNavigationHandler. There is a problem exposed when backwards
compatability is considered.

If a JSF2 compliant ConfiguraleNavigationHandler is passed as a constructor
parameter, a legacy NavigationHandler instance, delegation will be broken (such
as ClassCastException,) when the ConfigurableNavigationHandler attempts to
delegate to the parent. Or when the JSF2 Application attempts to utilize methods
available in ConfigurableNavigationHandler that are not in NavigationHandler.

If a legacy NavigationHandler is encountered (a NavigationHandler that does not
extend from ConfigurableNavigationHandler,) then the following wrapper (or
something similar) should be applied around the legacy NavigationHandler before
it is set into the Application.

It needs to be specified that decorated elements must be wrapped or encapsulated
from the application in order to preserve functionality.

javax.faces.application.NavigationHandler should be deprecated.

-------------
public class LegacyNavigationHandlerWrapper extends
ConfigurableNavigationHandler {

private NavigationHandler legacyHandler;
private ConfigurableNavigationHandler parentHandler;

public LegacyNavigationHandlerWrapper(ConfigurableNavigationHandler parent,
Class<?> clazz)

{ legacyHandler = // instantiate clazz with "parent" as the constructor // argument. parentHandler = parent; }

@Override
public NavigationCase getNavigationCase(FacesContext arg0, String arg1,
String arg2)

{ return parentHandler.getNavigationCase(arg0, arg1, arg2); }

@Override
public Map<String, Set<NavigationCase>> getNavigationCases()

{ return parentHandler.getNavigationCases(); }

@Override
public void handleNavigation(FacesContext arg0, String arg1, String arg2)

{ legacyHandler.handleNavigation(arg0, arg1, arg2); }

}
---------------
The same problem will also be encountered with ViewHandler and other SPI
extension points that have been updated in JSF2, but those have not been
addressed by this issue report.



 Comments   
Comment by Ed Burns [ 25/Feb/10 ]

Hi Lincoln,

I have to point out that the suggested solution has at least on wrinkle.

First, the legacy NavigationHandler will be instantiated at this point,
in Mojarra.

com.sun.faces.systest.NewNavigationHandler.<init>(NewNavigationHandler.java:48)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java
:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.jav
a:259)
com.sun.faces.config.processor.ApplicationConfigProcessor.setNavigationHandler(ApplicationConfig
Processor.java:473)
com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java
:285)
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:1
10)
com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:112)
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:1
10)
com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:219)
com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:331)
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:220)
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4591)

Shortly thereafter it is set into the Application, as you noted:

com.sun.faces.application.ApplicationImpl.setNavigationHandler(ApplicationImpl.java:673)
com.sun.faces.config.processor.ApplicationConfigProcessor.setNavigationHandler(ApplicationConfig
Processor.java:484)
com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java
:285)
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:1
10)
com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:112)
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:1
10)
com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:219)
com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:331)
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:220)
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4591)

Currently, we don't maintain a reference to the preceding
NavigationHandler so we can't do as you suggest with the wrapper without
some larger scale modifications to the config system. However, what you
suggest is possible, in spirit.

I'm working on it now.

Ed

Comment by Ed Burns [ 25/Feb/10 ]

started

Comment by Ed Burns [ 25/Feb/10 ]

One problem with the suggested approach is that the party providing the legacy NavigationHandler
may be counting on it being of the type specified in their faces-config.xml. When we wrap it, it will
no longer be of that type.

Ed

Comment by Ed Burns [ 25/Feb/10 ]

Finally, I note that all of the usages of ConfigurableNavigationHandler perform the following check,
thus avoiding the classcast exception.

This is from OutcomeTargetRenderer

protected NavigationCase getNavigationCase(FacesContext context, UIComponent component) {
NavigationHandler navHandler = context.getApplication().getNavigationHandler();
if (!(navHandler instanceof ConfigurableNavigationHandler)) {
if (logger.isLoggable(Level.WARNING))

{ logger.log(Level.WARNING, "jsf.outcome.target.invalid.navigationhandler.type", component.getId()); }

return null;
}

Can you attach a testcase that shows this is in fact a problem? For example, one that shows a
ClassCastException?

I'll attach the diffs I made to the system to perform investigation.

Ed

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

frame

Comment by Ed Burns [ 09/May/10 ]

I'm closing this as invalid because I haven't see the reproducible case

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-744] facelet-taglib_1_0 support Created: 14/Feb/10  Updated: 01/Aug/14  Resolved: 22/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

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

Operating System: All
Platform: All


Issuezilla Id: 744
Status Whiteboard:

cat1 frame changelog


 Description   

From spec rev 2.0, chapter 10.1.2, Facelets taglibs containing only xhtml
templates that follow http://java.sun.com/dtd/facelet-taglib_1_0.dtd should work
with JSF 2.0

OTOH from Appendix A, 1.2 one could think that only taglibs that follw
http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd are supportet
with JSF 2.0

We had long discussions on this on the MyFaces dev list, because Mojarra allows
http://java.sun.com/dtd/facelet-taglib_1_0.dtd, but MyFaces 2.0 beta doesn't.
Please add a clarification on this issue to 2.0 rev a, so either MyFaces adds or
Mojarra removes support.

Suggestion - Add this phrase to the beginning of Appendix A, 1.2:

"To allow backward compatibility Facelets taglibs may choose to follow either
http://java.sun.com/dtd/facelet-taglib_1_0.dtd or the schema presented with this
spec."



 Comments   
Comment by ganeshpuri [ 14/Feb/10 ]

Here's the reference to the MyFaces 2.0 discussion on this topic:
https://issues.apache.org/jira/browse/MYFACES-2543

Comment by Ed Burns [ 16/Feb/10 ]

Target 2.0 rev a. Schema should be modified to allow previous versions of taglib.

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

frame

Comment by Ed Burns [ 09/May/10 ]

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=698

Include deprecation text on <redirect><view-param> element.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=744

  • integrationWithFacelets.fm

Section 10.3.2. Correct xref to point to section in appendix that
includes the facelet taglib schema.

  • appendixA-metadata.fm

To ease migration for Facelet taglibraries declared using pre-JSF 2.0
versions of Facelets, implementations must support loading facelet
taglibrary files that conform to the pre-JSF 2.0 Facelets DTD. Per DTD
conventions, Facelet taglibrary files declare conformance to this DTD
by including text similar to the following in at the top of their
declaring file.

<!DOCTYPE facelet-taglib PUBLIC
"-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
"http://java.sun.com/dtd/facelet-taglib_1_0.dtd">

Use of this DTD is officially deprecated. This DTD is included for
reference in Section 1.2.1 "Deprecated DTD for Facelet Taglibraries
Used by Versions of Facelets Prior to JSF 2.0". It is expected that
proper JSF 2.0 Facelet Taglibraries will declare conformance to the
following schema, rather than the deprecated DTD

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=588

  • jsf-api/doc/standard-html-renderkit-base.xml

insert <p> around text for h:link and h:button

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=639

  • jsf-ri/conf/share/facelets_jsf_core.tld

change "name" to "type" on description of f:event tag

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=509

  • jsf-ri/conf/share/jstl-core.taglib.xml
  • jsf-ri/conf/share/jstl-core.tld

Declare that the old, incorrect, Facelets decaration of the uri for
the JSTL Core taglib be honored, as well as the new, correct one.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=673

  • jsf-api/doc/standard-html-renderkit-base.xml

Clarify what should happen if the target attribute is not specified.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=642

  • javascriptAPI.fm

table 14.4.1, change responseTxt to responseText

reorder rows in table 14.3

make use case for event listeners be correct.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=635

  • userInterfaceComponentModel.fm

3.5.3, 3.5.6.1: remove references to UInput.encodeEnd(). Not for a
very long time has this method been used to instigate validation.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=740

  • requestProcessingLifecycle.fm
  • 2.6.1.3 Tighten spec for the localePrefix, libraryName, and
    resourceVersion segments of the resource identifier
Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-724] run scripts from AJAX response Created: 19/Jan/10  Updated: 01/Aug/14  Resolved: 03/Sep/10

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

Type: Bug Priority: Blocker
Reporter: ganeshpuri Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 724
Status Whiteboard:

cat2 jsdoc size_small importance_large


 Description   

Script execution is standard in modern ajax engines like rich, ice or fry.

If a piece of XHTML comes in via xhr and contains <script> tags the ajax engine
should automatically trigger execution of these scripts. This is important if
you want to replace a js function or if the scripts somehow initialize UI
elements. It depends on a combination of the js replacement code
(innerHTML/adjacentHTML/contextualFragment/...) and the browser platform whether
the browsers automatically run these scripts, IE mostly doesn't run them FF
mostly does so. The ajax engine should know whether the browser does
automatically run the scripts and if it doesn't they should be triggered via js.



 Comments   
Comment by ganeshpuri [ 19/Jan/10 ]

MyFaces 2.0 does execute script, Mojarra doesn't, spec needs to clarify for
unification

Comment by driscoll [ 19/Jan/10 ]

Actually, Mojarra runs scripts just fine.

Comment by ganeshpuri [ 20/Jan/10 ]

Thanks, Jim, you're right, I hadn't tested the latest Mojarra release. Works great!

As both impl already do this, we could include it with spec 2.0 rev a, thus
changing target milestone...

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

jsdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 28/Jun/10 ]

2.1_gf31_m5

Comment by rogerk [ 03/Sep/10 ]

starting

Comment by rogerk [ 03/Sep/10 ]

I'm adding this section to the ajax.response jsdocs:

"The implementation must check if <script> elements in the response can
be automatically run, as some browsers support this feature and some do not.
If they can not be run, then scripts should be extracted from the response and
run separately."

Comment by rogerk [ 03/Sep/10 ]

Checked In.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-699] includeViewParams implicit navigation flag should be faces-include-view-params Created: 13/Dec/09  Updated: 01/Aug/14  Resolved: 22/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

Type: Bug Priority: Blocker
Reporter: mojavelinux Assignee: javaserverfowner
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 699
Status Whiteboard:

cat1 schema changelog


 Description   

When using implicit navigation, you can pass flags through the query string that
alter the behavior of the navigation. The first is a redirect flag, the second
is a hint to include view parameters in the outgoing query string.

  • faces-redirect
  • includeViewParams

As you can see, there are two problems with the includeViewParams flag. First,
it uses camel case instead of hyphen delimiters between words and it is not
prefixed with faces-.

When this feature was being discussed, there was a concern that the hints would
collide with query string parameters used by the application. As a result, a
prefix was added to the redirect hint, making it faces-redirect. However,
includeViewParams was not updated.

Here's the following change that needs to happen in the spec:

includeViewParams ==> faces-include-view-params

And in use:

/entry?faces-redirect=true&faces-include-view-params=true

In the long run, we need to find a cleaner (perhaps type-safe) way of indicating
an implicit navigation. Using the query string really isn't great. Perhaps under
the covers the implicit navigation is communicated this way, but we provide a
Java API that generates this in toString()

return new Navigation("entry", true, true);



 Comments   
Comment by mojavelinux [ 13/Dec/09 ]

P1 and milestone 2.0

Comment by mojavelinux [ 15/Dec/09 ]

Update milestone to 2.1 (really 2.0 MR1)

Comment by mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.0 Rev a

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

schema

Comment by Ed Burns [ 23/Apr/10 ]

Fix checked in.

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-698] view-param element should be redirect-param in navigation rules Created: 13/Dec/09  Updated: 01/Aug/14  Resolved: 22/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

Type: Bug Priority: Blocker
Reporter: mojavelinux Assignee: javaserverfowner
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 698
Status Whiteboard:

cat1 schema changelog


 Description   

The <view-param> element that was introduced as a child of the <redirect>
element was supposed to be called <redirect-param>. Unfortunately, something got
lost in translation and the terminology for "view parameters" got mixed up with
redirect parameters.

I'll explain the difference. A view parameter is a mapping between a request
parameter and a bean property and is associated with a particular view ID. If
you are linking or redirecting to that view ID, you can have those mappings run
in reverse to build a query string. This is activated with the "include view
parameters" switch on the link (UIOutcomeTarget) component or <redirect> element.

A redirect parameter in the navigation is equivalent to an <f:param> on a button
or link. It is a manual setting, which may (or may not) override the value of a
view parameter. A perfect example is when you want to create a link to the
previous page of a paginated list. You manually override "page" so that it is
one less than the current page. <f:param name="page" value="#

{nav.page - 1}

"/>

<view-param> has no business being a child of <redirect> and should be renamed
to <redirect-param>.



 Comments   
Comment by mojavelinux [ 13/Dec/09 ]

A 2.0 issue.

Comment by mojavelinux [ 15/Dec/09 ]

Update milestone to 2.1 (really 2.0 MR1)

Comment by mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.0 Rev a

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

schema

Comment by Ed Burns [ 09/May/10 ]

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=698

Include deprecation text on <redirect><view-param> element.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=744

  • integrationWithFacelets.fm

Section 10.3.2. Correct xref to point to section in appendix that
includes the facelet taglib schema.

  • appendixA-metadata.fm

To ease migration for Facelet taglibraries declared using pre-JSF 2.0
versions of Facelets, implementations must support loading facelet
taglibrary files that conform to the pre-JSF 2.0 Facelets DTD. Per DTD
conventions, Facelet taglibrary files declare conformance to this DTD
by including text similar to the following in at the top of their
declaring file.

<!DOCTYPE facelet-taglib PUBLIC
"-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
"http://java.sun.com/dtd/facelet-taglib_1_0.dtd">

Use of this DTD is officially deprecated. This DTD is included for
reference in Section 1.2.1 "Deprecated DTD for Facelet Taglibraries
Used by Versions of Facelets Prior to JSF 2.0". It is expected that
proper JSF 2.0 Facelet Taglibraries will declare conformance to the
following schema, rather than the deprecated DTD

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=588

  • jsf-api/doc/standard-html-renderkit-base.xml

insert <p> around text for h:link and h:button

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=639

  • jsf-ri/conf/share/facelets_jsf_core.tld

change "name" to "type" on description of f:event tag

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=509

  • jsf-ri/conf/share/jstl-core.taglib.xml
  • jsf-ri/conf/share/jstl-core.tld

Declare that the old, incorrect, Facelets decaration of the uri for
the JSTL Core taglib be honored, as well as the new, correct one.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=673

  • jsf-api/doc/standard-html-renderkit-base.xml

Clarify what should happen if the target attribute is not specified.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=642

  • javascriptAPI.fm

table 14.4.1, change responseTxt to responseText

reorder rows in table 14.3

make use case for event listeners be correct.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=635

  • userInterfaceComponentModel.fm

3.5.3, 3.5.6.1: remove references to UInput.encodeEnd(). Not for a
very long time has this method been used to instigate validation.

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=740

  • requestProcessingLifecycle.fm
  • 2.6.1.3 Tighten spec for the localePrefix, libraryName, and
    resourceVersion segments of the resource identifier
Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-696] Option to suppress xml declaration in Facelets Created: 11/Dec/09  Updated: 01/Aug/14  Resolved: 03/Nov/10

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

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

Operating System: All
Platform: All


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

size_large importance_large

Tags: adf, changelog_2_1

 Description   

The XML declaration is added to the Facelets template to make the tooling happy,
but Facelets allows this markup to pass straight through the browser. The
problem is that there are certain browsers which choke (or behave differently)
when the XML declaration is included in the rendered response.

The XML declaration really has no business being in the rendered output, so the
best approach is to have Facelets suppress this markup. But if there are
developers who prefer it, perhaps because they are using Facelets to generate an
XML feed, then there should be a setting somewhere that allows them to control
the terminus of the declaration (either suppressed or passed through). This is
no different than the "omitXmlDeclaration" setting on most XML printers,
including XSLT.

What's odd is that Facelets does not pass through the DTD declaration, which is
arguably even more of a problem. However, there is an easy workaround. Simply
include a DTD-generating tag.



 Comments   
Comment by mojavelinux [ 11/Dec/09 ]

Target milestone.

Comment by mojavelinux [ 11/Dec/09 ]

Also, the same problem exists for CDATA.

We (quoting Andy Schwartz) run into similar problems with CDATA sections. For
example, the following code uses the Trinidad trh:script component to insert a
script into the page:

<trh:script>
<![CDATA[
if (0 < 1) alert("Woohoo! Zero is less than one!");
]]>
</trh:script>

The CDATA section is meant to apply to the Facelets page itself - not to the
generated content. That is, the CDATA section provides a way to tell the
Facelets parser not to parse the specified character data. This is not intended
to be used as an instruction to the browser (just to Facelets XML parser).
However, Facelets passes the CDATA through to the browser. As a result, in the
case where we render HTML content, we end up with bogus CDATA sections inside of
our generated HTML document, which causes the browsers to get confused.

Comment by driscoll [ 11/Dec/09 ]

Unforunately, unlike the xml declaration (which you'll almost always want to
leave off, thanks MS), CDATA is something that you'll often want to include in
your page.

In fact, CDATA is something that users may want to include in the page sent to
the browser in the same page as a CDATA block that they don't want to send to
the browser. Ick.

In the specific case mentioned, the Trinidad script component, it should be
possible for the component to detect and properly process the included text -
that's what Mojarra does for script tags, in fact.

So, I'd love to see a different example, if anyone has one.

Comment by mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.0 Rev a

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 17/May/10 ]

Move to 2.1

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 22/Jul/10 ]

Move to M4. Add ADF keyword because it's related to issue 697.

Comment by Ed Burns [ 26/Jul/10 ]

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

Comment by Ed Burns [ 27/Jul/10 ]

Fix checked in. r8517

Comment by Hanspeter Duennenberger [ 27/Jul/10 ]

r=dueni

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Ed Burns [ 01/Nov/10 ]

This needs to be removed from the spec in favor of what we have in <facelets-processing>

Comment by Ed Burns [ 01/Nov/10 ]

Roger.

Comment by Ed Burns [ 03/Nov/10 ]

Committed revision 8701.
Rolled this out in favor of what we did on issue 490.

Comment by Ed Burns [ 03/Nov/10 ]

Resolved in issue 490.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-697] more XML-centric model for Facelets Created: 11/Dec/09  Updated: 01/Aug/14  Resolved: 11/Aug/10

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

Type: Bug Priority: Blocker
Reporter: mojavelinux Assignee: Ed Burns
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: HTML File issue-697-mail-digest    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-793 A comment different than <!-- -->, no... Open
Issuezilla Id: 697
Status Whiteboard:

size_large importance_large


 Description   

Facelets templates should be treated as an XML template language that produces
output as determined by the renderkit. Right now the linkage to XHTML is too
strong, such that Facelets pretends to be XHTML, but really it isn't.

The action here would be to introduce tags, such as h:document, h:doctype and an
attribute on f:view to output an XML declaration (or not). There should also be
control on how comments and CDATA are handled. There shouldn't be an assumption
that what is in the template should be passed directly to the browser, but
rather have more control over what gets passed and what doesn't.

Here are the linked issues:

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=489
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=490



 Comments   
Comment by mojavelinux [ 11/Dec/09 ]

I also think that the jsfc attribute in Facelets should be killed because it is
a totally leaky abstraction that simply has no practical application. Even Jacob
pulled away from it shortly after it was introduced.

"It's just dumb to use 'jsfc' and 'jwcid'. Those two things would be great if
the semantics were the same between html and components, but they aren't. And
even if they do parallel, the next concern is that there should be dummy content
for the designer to play with, you have to remove it. I say don't even bother
with it in the first place and stop expressing concerns within the same document."

http://hookom.blogspot.com/2005/09/more-on-programmer-pages.html

Comment by mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.1

Comment by Ed Burns [ 01/Jun/10 ]

One thing that makes calling Facelets VDL just plain XML is that XML does not have all the character
entities commonly in use in HTML or XHTML.

See http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

Comment by Ed Burns [ 01/Jun/10 ]

We'll have to do something like we do in the Ajax case, where we force the manual declaration of entities
that are used in the page.

Comment by Ed Burns [ 01/Jun/10 ]

Created an attachment (id=237)
Unix Mail Digest of jsr-314-open discussion on this issue

Comment by Ed Burns [ 03/Jun/10 ]

Add keywords.

Comment by Ed Burns [ 08/Jun/10 ]
      • Issue 498 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 11/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 28/Jun/10 ]

Target Milestone 4

Comment by Ed Burns [ 22/Jul/10 ]

p1

Comment by Ed Burns [ 11/Aug/10 ]

Closing this issue as WORKSFORME because its intent is covered by other
issues.

Re: 489 Use XML Schema as the TLD language

------- Additional comments from edburns Thu Jul 22 20:30:05 +0000 2010 -------

I discussed this on IRC with Andy Schwartz today. We have some basic
questions. I looked Dan's blog entry
http://in.relation.to/Bloggers/ItsTimeForFaceletsToStartUsingXSD and
even in his attachment the .xsd files do not have enough information for
the runtime to wire up the components to the renderers, and whatever
other taglib metadata we need.

Re: 490

I assert that this one is the important one to fix for GlassFish 3.1 M4.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-308] ViewExpiredException should be listed as an incompatible change going from 1.1 Created: 19/Sep/07  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 1.2

Type: Bug Priority: Blocker
Reporter: Ryan Lubke Assignee: javaserverfowner
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 308

 Description   

1.1, if a view couldn't be restored due to session expiration, we'd create a new
one and go to render response.

In 1.2, this is not the case. We now throw a ViewExpiredException.

1.1-based applications may rely on the old behavior to forward to a login page
when a session expired. 1.2 circumvents this.

This should be listed as an incompatible change between 1.1 and 1.2 in the 1.2
preface.



 Comments   
Comment by Ed Burns [ 15/Oct/08 ]

fixed

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-263] Need to specify behavior of f:loadBundle with respect to Tree Creation in JSF 1.2 Created: 31/May/07  Updated: 01/Aug/14  Resolved: 08/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.2
Fix Version/s: 2.1

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

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


Issuezilla Id: 263
Status Whiteboard:

cat2 vdldoc


 Description   

Please see the impl issue tracker
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=578



 Comments   
Comment by Ed Burns [ 31/May/07 ]

The impl issue is <https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=577>.

Comment by Ed Burns [ 31/May/07 ]

accept

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

This is so unimportant that I am closing it as WONTFIX.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-233] JSF/Spring integration - managed-property problem Created: 07/Jan/07  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.1
Fix Version/s: 1.2

Type: Bug Priority: Blocker
Reporter: mail2bansi Assignee: javaserverfowner
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 233

 Description   

I am using JSF 1.1_01 (MyFaces 1.1), Spring 1.2, Ajax4Jsf.
The JSF application has h:selectOneMenu .

On change event of h:selectOneMenu sets "selectedValue" into backing bean as
shown below:

------------------
page.jsp
-------------------

<h:selectOneMenu value="#

{test.selectedDevice}" >

<f:selectItem itemValue="0" itemLabel="-New-"/>
<f:selectItem itemValue="1" itemLabel="WorkStation"/>
<f:selectItem itemValue="2" itemLabel="Router"/>
<f:selectItem itemValue="3" itemLabel="Switch"/>
<ajax:support action="#{test.loadDevice}" event="onchange"
reRender="t2,t3,t4,t5"/>
</h:selectOneMenu>

-----------------------
TestBean.java (Backing Bean)
-----------------------

public String getSelectedDevice() {
logger.info(" *** In getSelectedDevice *** ");
if (selectedDevice == null) {

selectedDevice = "0"; // This will be the default selected item.
}
return selectedDevice;
}


public void setSelectedDevice(String selectedDevice) {
logger.info(" *** In setSelectedDevice *** ");
this.selectedDevice = selectedDevice;
}

Here are the configuration file snippets for integrating JSF Spring
-------------
web.xml
-------------
<listener>
<listener-
class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
---------------------------
faces-config.xml
---------------------------
<application>
<variable-
resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-
resolver>
</application>

<managed-bean>
<managed-bean-name>test</managed-bean-name>
<managed-bean-class>test.TestBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>deviceManager</property-name>
<property-class> test.DeviceTypeManager </property-class>
<value>#{deviceManager}</value>
</managed-property>
</managed-bean>

The above code results in the following error

javax.faces.FacesException: Cannot get value for expression '#{test.selectedDevice}

'

The error occurs only if i include <managed-property> inside the <managed-bean>
in faces-config.xml.
The moment i remove <managed-property> from face-config.xml the error
disappears & page gets rendered properly.

The purpose in having <managed-property> inside managed-bean is to call
Spring's Manager class (i.e. deviceManager) from JSF application

Any pointers/suggestions in resolving the error will be highly appreciated

Regards
Bansi



 Comments   
Comment by mail2bansi [ 07/Jan/07 ]

TestBean do have a property for DeviceManager along with setter/getter methods
as shown below. Sorry for not including in earlier posting

--------------
TestBean.java (Backing Bean)
---------------
private DeviceTypeManager deviceManager;
public DeviceTypeManager getDeviceManager()

{ return deviceManager; }

public void setDeviceManager(DeviceTypeManager deviceManager)

{ this.deviceManager = deviceManager; }

Here are the two scenarios

Scenario 1 : without <managed-property> the code works fine

Scenario 2 : with <managed-property> the code results in following error

javax.faces.FacesException: Cannot get value for expression '#

{test.selectedDevice}'


Scenario 1 has only JSF whereas Scenario 2 has JSF-Spring integration

The Scenario 1 works absolutely fine as the expression '#{test.selectedDevice}

' gets its value from setter/getter method in the backing
bean(TestBean.java) . This is expected behaviour & wondering why it doesn't
work similarly in Scenario 2 instead it complains
Cannot get value for expression '#

{test.selectedDevice}

'

I am willing to upload the war file. Any pointers/suggestions in resolving the
error will be highly appreciated

Regards
Bansi

Comment by Ed Burns [ 20/Aug/08 ]

Per 20080820 EG meeting, I am taking action on these issues.

Comment by Ed Burns [ 20/Aug/08 ]

Per 20080820 EG meeting, marking these as WONTFIX. In some cases, this means the issue was fixed
already, under another issue. In other cases, this means the issue is too vague to fix. In still other cases,
this means the EG deemed that the issue isn't appropriate for fixing.

If you strongly disagree with this resolution, please contact jsr-314-comments@jcp.org.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "implementation" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-216] Backing bean with PhaseListener Created: 11/Oct/06  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.1
Fix Version/s: 1.2

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

Operating System: Solaris
Platform: Sun


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-288 PhaseListener improvements Closed
Issuezilla Id: 216

 Description   

I am NOT SURE whether i will get ANSWER to my QUERY so i am quite PESSIMISTIC
with this Forum as i am yet to get an ANSWER for my early query

Anyhow here is my posting
My requirement is
" Our users are Authenticated by External System . On successful
authentication the external system returns header variables viz. userId,
firstName, lastName etc to our System.
Currently I am able to retrieve these header variables using
request.getHeader("userId") in my JSP page.
But this is certainly not the best practice. I am thinking of storing this
information in Backing Bean via Phase Listener for further use like
1) retrieving user Roles from the Database based on userId and
2) displaying JSP page based on user roles

I am not sure how to tie up PhaseListener with the Backing Bean .
What are the Best Practices

Here are my snippets of code

--------------------
Faces-config.xml :
--------------------
<lifecycle>
<phase-listener>
com.mycompany.MyPhaseListener
</phase-listener>

<managed-bean>
<managed-bean-name>greetingForm</managed-bean-name>
<managed-bean-class>com.mycompany.GreetingForm</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>id</property-name>
<value>#

{param.id}

</value>
</managed-property>
<managed-property>
<property-name>testSpringBean</property-name>
<property-class>
com.mycompany.TestSpringBean
</property-class>
<value>#

{testSpringBean}

</value>
</managed-property>
</managed-bean>

--------------------
MyPhaseListener
--------------------
public void afterPhase(PhaseEvent pe)

{ System.out.println("after - " + pe.getPhaseId().toString()); if (pe.getPhaseId() == PhaseId.RENDER_RESPONSE) System.out.println("Done with Request!\n"); Map requestHeaderMap = new HashMap(); requestHeaderMap = pe.getFacesContext().getExternalContext().getRequestHeaderMap(); System.out.println("Hash Map Size:"+requestHeaderMap.size()); String bemsId = (String)requestHeaderMap.get("USERID"); System.out.println("userId="+userId); }

Any pointers/suggestions with little snippets of code will be highly
appreciated

Regards
Bansi



 Comments   
Comment by kito75 [ 08/Apr/08 ]

I would think we could close this issue, as this is possible using the
phaseListener attribute on the <f:view> tag or the <f:phaseListener> tag in JSF 1.2.

Comment by Ryan Lubke [ 20/Aug/08 ]

This is a user, and possibly an implementation issue, but not an issue with the
spec (agree with Kito that the 1.2 phase listeners on the UIViewRoot can
associate be associated with a specific bean)

Comment by Ed Burns [ 20/Aug/08 ]

Per 20080820 EG meeting, I am taking action on these issues.

Comment by Ed Burns [ 20/Aug/08 ]

Per 20080820 EG meeting, marking these as WONTFIX. In some cases, this means the issue was fixed
already, under another issue. In other cases, this means the issue is too vague to fix. In still other cases,
this means the EG deemed that the issue isn't appropriate for fixing.

If you strongly disagree with this resolution, please contact jsr-314-comments@jcp.org.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "implementation" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-195] forbid to JSF to change user defined id Created: 25/Jul/06  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: 1.2

Type: Improvement Priority: Blocker
Reporter: vladperl Assignee: javaserverfowner
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 195

 Description   

By default JSF alert any developer defined id using parent id as prefix.
Only the way to prevent that is defined "false" value for attribute "prependId"
on the "Form" component.
I believe that in case if author page setup value of "id" JSF must honor that
setting because this value could be used in javascript, css and so on.
JSF components using id mostly to recognize what component fired the action.
I'm talking about decoding method.

Typical decoding method:

public void decode(FacesContext context, UIComponent component)

{ String clientId = component.getClientId(context); Map requestParameterMap = context.getExternalContext().getRequestParameterMap(); String value = (String) requestParameterMap.get(clientId); if (value == null || value.equals("") || !clientId.equals(value)) return; ActionEvent actionEvent = new ActionEvent(component); component.queueEvent(actionEvent); }

As you can see decoding method using value from getClientId method and compare
it with corresponding parameter value.
Rendered hidden fields provide mechanism to supply values to parameters map.
And usual practice now that to render hidden fields with name that equal to id
of the corresponding component. That kind of functionality implemented inside
encoding methods of component.

Typical encoding method:

public void encodeBegin(FacesContext context, UIComponent component) throws
IOException {
ResponseWriter writer = context.getResponseWriter();
String clientId = component.getClientId(context);
UIForm uiform = Util.getParentForm(component);
String formClientId = uiform.getClientId(context);
Map requestMap = context.getExternalContext().getRequestMap();
String key = Util.ADD_PARAM_METHOD_NAME + "_" + formClientId;
if (requestMap.get(key) == null)

{ Util.renderAddParamToFormJavaScript(writer, formClientId); requestMap.put(key, Boolean.TRUE); }

writer.startElement("a", component);
Util.writeIdAttributeIfNecessary(context, writer, component);
StringBuffer sb = new StringBuffer();
sb.append("document.forms['");
sb.append(formClientId);
sb.append("']." + Util.ADD_PARAM_METHOD_NAME + "('");
sb.append(clientId);
sb.append("','");
sb.append(clientId);
sb.append("');");
sb.append(" document.forms['");
sb.append(formClientId);
sb.append("'].submit(); void(0)");
writer.writeAttribute("href", "javascript:" + sb.toString(), "href");
...
...
}

Probably it's make sense to use JSF defined id only for rendering hidden fields
not for rendering client id of component.

First scenario:

Client id is not defined for component:
In this situation not allow rendering id attribute for component.
Use id attribute only for encoding hidden fileds and corresponding decoding.

Second scenario:
Client id is defined for component:
In this situation render id attribute without any changes to it value.
In most cases name of encoded hidden field could use value of user defined id.
But there are some situations when it could be problematic.

For example take a look on this issue:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=365

But if we will combine some prefix with user defined id that will fix it.

In case the suggestion will be accepted attribute "prependId" have to be deprecated.

I understand there is a need to discuss this suggestion in great details.
If it's necessary I can prepare some working examples to prove the concept.
If I'm wrong somehow please correct my point.



 Comments   
Comment by Ed Burns [ 31/Jul/06 ]

Hello Vlad, thanks for your feedback. If I am understanding you correctly, the
use case you describe is exactly what the "prependId=false" scenario is trying
to solve. Why do you feel prependId=false is insufficient for your needs?

Ed

Comment by vladperl [ 01/Aug/06 ]

Hi Ed,
Sorry for late response.

> If I am understanding you correctly, the use case you describe is exactly
> what the "prependId=false" scenario is trying to solve.
Yes, that is correct conclusion.

> Why do you feel prependId=false is insufficient for your needs?

I just think that JSF have to render only user defined id.
I don't see cases when JSF have to render jsf specified ids.
If I'm correct and JSF don't have to render jsf based id why we have to bother
with attribute "prependId" at all?
If in some cases JSF still have to render not user defined component ids I'd
like to have possibility to switch value of this attribute at least on the
application level.
I'm strongly opposite to the idea that JSF have possibilities to alert user
defined ids. As you know many web developers very often using css and java
script with html. Many developers when working with css used only classes or
tag names as contextual selectors to define style for corresponding elements.
But exists important difference between IDs and classes.
Id has higher priority in CSS comparing with class and in cases when you need
define specific style to specific piece of page's markup that definitily better
to do with id selector. Regarding importance for scripting user defined id I
could say that getElementById function is very popular for scripters.

Also what about developer who deside to swith to modern framework and widely
used html with plenty of elements that has defined id value.
Should he go to some framework as "Tapestry" or go to JSF in case he need
strong support for html and related technologies?
Alerting ids by jsf probably the last reason why people could choose other
framework instead of JSF.
Fix it and JSF will be winner!

Comment by Ed Burns [ 20/Aug/08 ]

Per 20080820 EG meeting, I am taking action on these issues.

Comment by Ed Burns [ 20/Aug/08 ]

Per 20080820 EG meeting, marking these as WONTFIX. In some cases, this means the issue was fixed
already, under another issue. In other cases, this means the issue is too vague to fix. In still other cases,
this means the EG deemed that the issue isn't appropriate for fixing.

If you strongly disagree with this resolution, please contact jsr-314-comments@jcp.org.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-173] DataTable var attribute incorrect in TLD Created: 12/May/06  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: 1.2

Type: Bug Priority: Blocker
Reporter: ssilvert Assignee: javaserverfowner
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 173

 Description   

I believe I have discovered a bug in <h:dataTable>. When the TLD is generated,
the var attribute looks like this:

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

Because it is a deferred-value, the JSP generated source will not match the
setter which looks like this:

// PROPERTY: var
private java.lang.String _var;
public void setVar(java.lang.String _var)

{ this._var = _var; }

I assume that the setter is correct and the TLD is not.



 Comments   
Comment by ssilvert [ 12/May/06 ]

I just realized that I reported this in the wrong place. Sorry.

Stan

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "implementation" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-134] Major Backwards Compatability Problems for JSF 1.2 Created: 18/Jan/06  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.1
Fix Version/s: 1.2

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

Operating System: All
Platform: Macintosh


Attachments: GZip Archive jsf-api-134.tar.gz     Text File message.txt     Text File message.txt     Text File message.txt     Text File message.txt    
Issuezilla Id: 134

 Description   

This method was introduced in JSF 1.2, but hasn't been marked with an @since
tag. Also, if you have a JSF 1.1 ResponseStateManager you'll get an
AbstractMethodError because JSF 1.1 doesn't have that method.



 Comments   
Comment by Ed Burns [ 18/Jan/06 ]

reassign

Comment by Ed Burns [ 18/Jan/06 ]

accept

Comment by Ed Burns [ 18/Jan/06 ]

I'm about to attach a fix for the first batch of problems: some
AbstractMethodErrors in ResponseStateManager and UIComponent. While those are
easy to fix, this next one, I'm not so sure about:

ava.lang.IllegalStateException: RenderingContext has already been created!
oracle.adfinternal.view.faces.uinode.FacesRenderingContext.createRenderingContext(FacesRenderingContext.java:79)
oracle.adfinternal.view.faces.renderkit.CoreRenderKit.createResponseWriter(CoreRenderKit.java:332)
com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175)
oracle.adfinternal.view.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:157)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:108)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:262)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:157)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:219)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:262)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.Subject.doAsPrivileged(Subject.java:517)

Comment by Ed Burns [ 18/Jan/06 ]

Created an attachment (id=73)
in progress fix

Comment by Ed Burns [ 19/Jan/06 ]

Ok, after doing some more analysis I have determined that the RenderKit
provided in ADF Faces does not like having createResponseWriter( )
called more than once per request.

The javadocs for RenderKit.createResponseWriter( ), included below, do
not state that it is forbidden to call this method more than once per
request. Therefore, I assert this is a problem with the ADF Faces
RenderKit.

To test this, I have modified ViewHandlerImpl.renderView( ) to place an
extra call into createResponseWriter( ), like so:

if (null != oldWriter)

{ newWriter = oldWriter.cloneWithWriter(strWriter); }

else

{ newWriter = renderKit.createResponseWriter(strWriter, null, request.getCharacterEncoding()); newWriter = renderKit.createResponseWriter(strWriter, null, request.getCharacterEncoding()); }

The second call causes this exception to be thrown:

java.lang.IllegalStateException: RenderingContext has already been created!
oracle.adfinternal.view.faces.uinode.FacesRenderingContext.createRenderingContext(FacesRenderingContext.java:79)
oracle.adfinternal.view.faces.renderkit.CoreRenderKit.createResponseWriter(CoreRenderKit.java:332)
com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:162)
oracle.adfinternal.view.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:157)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:108)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:264)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:159)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:219)

For your information, the reason why we need to call
createResponseWriter( ) twice is that the first ResponseWriter is
created around a StringWriter, then we replace the state saving markers
in the StringWriter, then we create the "real" ResponseWriter around the
ServletResponse's Writer and write out the response to it.

I'm going to try a different implementation approach and see if I can
make it work, but in the meantime, I want to pose the question to the EG
if it is legal to create more than one ResponseWriter intsances
per-request.

Comment by Ed Burns [ 19/Jan/06 ]

I tried closing the first ResponseWriter before creating another one but that
didn't work either.

Comment by Ed Burns [ 19/Jan/06 ]

Switching to use cloneWithWriter( ) for the second ResponseWriter fixed this
problem, but now I'm running into some JavaScript problems.

Investigating further.

Comment by Ed Burns [ 19/Jan/06 ]

I have found that the javaScript file can't be loaded.

Trying to load http://localhost:8080/adf-faces-demo/adf/jsLibs/Commonea19.js yields:

ava.security.AccessControlException: access denied (java.net.NetPermission
specifyStreamHandler)
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
java.security.AccessController.checkPermission(AccessController.java:427)
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
java.net.URL.checkSpecifyHandler(URL.java:629)
java.net.URL.(URL.java:354)
oracle.adf.view.faces.resource.AggregatingResourceLoader.getURL(AggregatingResourceLoader.java:106)
oracle.adf.view.faces.resource.DynamicResourceLoader.findResource(DynamicResourceLoader.java:60)
oracle.adf.view.faces.resource.ResourceLoader.getResource(ResourceLoader.java:43)
oracle.adf.view.faces.resource.RegexResourceLoader.findResource(RegexResourceLoader.java:45)
oracle.adf.view.faces.resource.ResourceLoader.getResource(ResourceLoader.java:43)
oracle.adf.view.faces.resource.CachingResourceLoader.findResource(CachingResourceLoader.java:59)
oracle.adf.view.faces.resource.ResourceLoader.getResource(ResourceLoader.java:43)
oracle.adf.view.faces.webapp.ResourceServlet.getLastModified(ResourceServlet.java:212)
javax.servlet.http.HttpServlet.service(HttpServlet.java:705)
javax.servlet.http.HttpServlet.service(HttpServlet.java:822)
oracle.adf.view.faces.webapp.ResourceServlet.service(ResourceServlet.java:136)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

With a server 500 error.

This causes the navigation links to fail.

Error: _defaultTZ is not defined
Source File: http://localhost:8080/adf-faces-demo/faces/index.jspx
Line: 7

among others.

Comment by Ed Burns [ 19/Jan/06 ]

Created an attachment (id=74)
full stack trace

Comment by Ed Burns [ 19/Jan/06 ]

For now, I've worked around the NetPermission exception by putting all the
adf*.jar files in glassfish/lib. Still not working, but some style is showing up.

Comment by Ed Burns [ 19/Jan/06 ]

The JSP portion of this is being covered in glassfish issue 173

https://glassfish.dev.java.net/issues/show_bug.cgi?id=173

Comment by Ed Burns [ 19/Jan/06 ]

Change Summary.

Comment by Ed Burns [ 20/Jan/06 ]

Created an attachment (id=75)
Fix for this issue, version 1

Comment by rogerk [ 23/Jan/06 ]

r=rogerk

Comment by Ed Burns [ 23/Jan/06 ]

Fix checxed in, but waiting for EG approval before closing.

Comment by Ed Burns [ 23/Jan/06 ]

As noted earlier, the fix for the JSF side of this issue has been checked in and
we're awaiting EG approval.

I have workarounds for the two glassfish issues:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=173

Remove jsf-*.jar from WEB-INF/lib.
Remove jsf_core.tld from WEB-INF.
Remove html_basic.tld from WEB-INF.
Remove the taglib decl for http://java.sun.com/jsf/core from web.xml.
Remove the taglib decl for http://java.sun.com/jsf/core from web.xml.

https://glassfish.dev.java.net/issues/show_bug.cgi?id=185

Move all adf*.jar files from WEB-INF/lib to the container's lib directory.

With these changes, and the fix for this bug, ADF Faces EA 19 works with Glassfish.

Comment by Ed Burns [ 26/Jan/06 ]

Fix verified with latest JSF nightly and glassfish nightly.

Comment by Ed Burns [ 31/Jan/06 ]

When building the Shale trunk against the JSF 1.2 trunk today, I found some more
simple backwards incompatibility issues. A change-bundle is forthcoming.

Comment by Ed Burns [ 31/Jan/06 ]

Created an attachment (id=77)
Fix for the second part of this issue, version 1

Comment by rogerk [ 31/Jan/06 ]

r=rogerk

Comment by Ed Burns [ 06/Feb/06 ]

Created an attachment (id=79)
Fix for the third part of this issue, version 1

Comment by Ed Burns [ 08/Feb/06 ]

As far as binary compatibility, we have these fixed. The remainder of the ones
from ADF Faces are the result of
http://sfjsf.blogspot.com/2006/02/adf-faces-and-jsf-12.html

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "implementation" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-97] Increase Dynamism (Real Time Development) Created: 28/Jul/05  Updated: 01/Aug/14  Resolved: 24/Nov/09

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 2.0

Type: Improvement Priority: Blocker
Reporter: jhook Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 97
Status Whiteboard:

EGTop5 effort_moderate


 Description   

To increase the live-development-ability of JSF, implementations can check for
changes in faces-configs for additional navigation handlers, components, and
other entities.

This is to allow real time development of JSF applications.

The implementation of this shouldn't be difficult as entities within JSF are all
keyed, so populating keyed data shouldn't cause race-condition issues.



 Comments   
Comment by jhook [ 28/Jul/05 ]

changing type

Comment by Ed Burns [ 08/Feb/06 ]

2

Comment by Ed Burns [ 09/Sep/08 ]

EGTop5

Comment by Ed Burns [ 12/Sep/08 ]

effort_moderate

Comment by Ed Burns [ 28/Jul/09 ]

take ownership

Comment by Ed Burns [ 28/Jul/09 ]

I'm widening this to include what we do with composite components.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "implementation" subcomponent.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-77] Synchronization in UIComponentBase Constructor Created: 29/Apr/05  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: 1.2

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

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Zip Archive changebundle.zip    
Issuezilla Id: 77

 Description   

We need to remove the synchronization block on the static variable
"descriptors". Under the current implementation, any component created, the
current classloader (application wide) has to be synchronized with every other
component. This is not acceptable.

Since loading PropertyDescriptors is not required to be synchronous, it is
acceptable to have more than one constructor actually populate the static map in
a non-blocking manner.

Code changes would require simply removing the synchronization block in the
constructor. Also, the static WeakHashMap should probably be indexed not by
Class, but by ClassName. With all of the oddball Classloaders and byte weavers
developers are using, I wouldn't trust Class.hashCode().



 Comments   
Comment by rogerk [ 28/Jul/05 ]

Created an attachment (id=48)
change bundle

Comment by rogerk [ 29/Jul/05 ]

Created an attachment (id=50)
changes - part 2

Comment by Ed Burns [ 03/Mar/06 ]

reassign to Roger.

Comment by rogerk [ 03/Mar/06 ]

Ed, can you take alook at this one please?

Comment by Ed Burns [ 07/Mar/06 ]

This is an implementation issue. Moving to
<https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=255>.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-585] Specify behavior of h:outputText and h:inputText Created: 08/Jul/09  Updated: 01/Aug/14  Resolved: 09/Jun/11

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

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

Operating System: All
Platform: All


Attachments: Text File diffs.txt    
Issuezilla Id: 585
Status Whiteboard:

cat1 renderkitdoc size_small importance_medium


 Description   

The behavior of h:outputText and h:inputText for rendering children is currently
unspecified.

The RI behavior for outputText is odd - it renders the children first, then the
value of the tag.

After extensive discussion in the EG, there was a rough consensus that children
for outputText not be rendered. During the process of implementing the fix, I
discovered that inputText had a similar undesired behavior, and also changed
that to not be rendered.

I've marked this P1, since this is slated for inclusion in the very next MR of
JSF, and the RI has already changed behavior to not render children.



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 05/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

rk

Comment by Ed Burns [ 15/Mar/10 ]

2.0 rev a

Comment by rogerk [ 13/May/10 ]

The RI has added a configuration option to enable the rendering of children.
See: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1154
And, by default, the rendering of children should not be done.
Currently, the renderkit docs for text rendering say:

"This component is responsible for rendering its children."

I suppose we could add a clarification like:

"Implementations may choose to disable the rendering of children by default."

Comment by rogerk [ 14/May/10 ]

Ownership

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 17/May/10 ]
  • move to 2.1. When you do fix it, you can use this as the log message
    text.
  • modify javax.faces. {Output,Input}

    javax.faces.Text renderer to not
    render children by default, but do allow the possibility of a config
    option to control rendering.

About to attach patch.

Comment by Ed Burns [ 17/May/10 ]

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

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 09/Jun/11 ]

Committed to trunk.

Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-api/doc/standard-html-renderkit.xml
Sending jsf-api/src/main/java/javax/faces/context/ExternalContextWrapper.java
Sending jsf-api/src/main/java/javax/faces/webapp/FacesServlet.java
Sending jsf-api/src/main/resources/overview.html
Sending jsf-tools/src/main/resources/com/sun/faces/generate/facesdoc/stylesheet.css
Transmitting file data ......
Committed revision 9144.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-570] Add description property to javascript event payload Created: 10/Jun/09  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 1.2

Type: Improvement Priority: Blocker
Reporter: driscoll Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 570

 Description   

We need to add a description property to the javascript event payload.

Without it, it will difficult to provide debugging hints in a compatible manner,
since the information contained in the default error names is extremely limited.



 Comments   
Comment by rogerk [ 25/Jun/09 ]

started / ownership

Comment by rogerk [ 26/Jun/09 ]

Fixed;
Spec pdf updated.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-567] Clarify f:ajax execute/render id behavior Created: 25/May/09  Updated: 01/Aug/14  Resolved: 21/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

Type: Bug Priority: Blocker
Reporter: aschwart Assignee: javaserverfowner
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 567
Status Whiteboard:

cat1 frame changelog


 Description   

The spec (section 10.4.1.1) states that f:ajax execute/render ids are resolved
as follows:

"The String value for identifiers specified for execute and render may be
specified as a search expression as outlined in the JavaDocs for
UIComponent.findComponent. The implementation must resolve these identifiers as
specified for UIComponent.findComponent."

However:

1. There is no mention of this in the pdldocs for f:ajax.
2. An small sample illustrating this behavior would be extremely helpful.

Logging this issue to request that we address both #1 and #2 as spec clarifications.



 Comments   
Comment by driscoll [ 26/May/09 ]

Change priority, milestone.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 05/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

frame

Comment by Ed Burns [ 15/Mar/10 ]

2.0 rev a

Comment by Ed Burns [ 27/Apr/10 ]

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=540
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=590
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=629

  • typo

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=567

  • Add pdldocs for f:ajax documenting UIComponent.findComponent behavior
Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by rogerk [ 21/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-549] Keep server-side state ID for AJAX requests. Created: 29/Apr/09  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 1.2

Type: Bug Priority: Blocker
Reporter: alexsmirnov Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File jsf-ri.patch    
Issuezilla Id: 549

 Description   

In the case of server-side state saving, implementation of ResponseStateManager
saves a new state for an every request,even for a same viewId as previous was,
and generates a new value for "javax.faces.ViewState" hidden field. That feature
allows JSF to restore proper view state then user returns to previous page by
browser "back" button and submit some form from that page again.
But that behaviour is incorrect for AJAX requests because in this case browser
does not save page in history ( Even if "back" button support for AJAX will be
implemented, it could be done by special 'iframe' object only, and does not save
page in history anyway ), and old values is only going to garbage. As a result,
small view states cache ( which default size is 16 ) could be refilled by values
from AJAX requests soon, and browser "back" button support will be broken.



 Comments   
Comment by alexsmirnov [ 29/Apr/09 ]

Created an attachment (id=223)
patch to keep server-side view state ID during ajax requests.

Comment by driscoll [ 29/Apr/09 ]

Changing priority to P1 - this can cause a view expired exception that a user
could trip across fairly easily in basic coding.

Comment by driscoll [ 29/Apr/09 ]

Also, I would class this as a spec defect, for the same reason.

Comment by rogerk [ 29/Apr/09 ]

Take ownership

Comment by rogerk [ 30/Apr/09 ]

Take ownership

Comment by rogerk [ 30/Apr/09 ]

I've added the following to javax.faces.render.ResponseStateManager.writeState :

+ * <p>If the state saving method for this application is

{@link + * javax.faces.application.StateManager#STATE_SAVING_METHOD_SERVER}

,
+ * and the current request is an <code>Ajax</code> request
+ * (@link javax.faces.context.PartialViewContext.isAjaxRequest} returns
+ * <code>true</code>), use the current view state identifier if it is
+ * available (do not generate a new identifier).</p>

Comment by rogerk [ 30/Apr/09 ]

change target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "implementation" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-498] Upgrade Standard HTML RenderKit to XHTML Created: 18/Oct/08  Updated: 01/Aug/14  Resolved: 08/Jun/10

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

Type: Improvement Priority: Blocker
Reporter: cdoremus Assignee: javaserverfowner
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 498
Status Whiteboard:

cat2 renderkit


 Description   

Although JSF 2.0 will support facelets it is suprising that the current draft of
the spec still specifies the Standard HTML RenderKit to use HTML 4.01. I suggest
that the RenderKit specification be upgraded to XHTML compliance since the
facelets UI is done in XHTML. This will also allow JSF to support the WAP 2
standard since it specifies a subset of XHTML.



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

Comment by Ed Burns [ 04/Mar/10 ]

We've talked about this issue on the EG. Dan was more in favor of dropping the claim of XHTML
support instead of just saying XML. I'm not sure yet. This also ties in with HTML5 issues.

Comment by Ed Burns [ 22/Mar/10 ]

renderkit

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

Fold into 697

      • This issue has been marked as a duplicate of 697 ***
Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-14] Spec should require ValueBinding and MethodBinding to implement equals() and has Created: 27/Aug/04  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: 1.2

Type: New Feature Priority: Blocker
Reporter: Ed Burns Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 14

 Description   

The specification is silent on whether ValueBinding and MethodBinding should
implement equals() and hashCode() or not, and the current RI implementation does
not implement them, defaulting to the underlying logic in java.lang.Object. It
would be very useful for equals() to return true if the reference expressions
for two instances are the same (and hashCode() would have to be implemented as
well to maintain the contracts defined in java.lang.Object). These methods
could be implemented in the API classes (javax.faces.el.

{Method,Value}

Binding)
quite easily, so that all implementations could benefit from them.



 Comments   
Comment by Ed Burns [ 27/Aug/04 ]

Tools need to know whether a new value binding or method binding instance
represents a different value (and should therefore trigger property change
events inside the tool) or not. Sophisticated applications that generate and
use such bindings would also benefit.
ed.burns@sun.com 7/23/04 15:18 GMT

Comment by Ed Burns [ 30/Aug/04 ]

p1 feature

Comment by Ed Burns [ 06/Oct/04 ]

Roger, please remember to bring this up during the ValueBinding discussion on
webtier-alignment.

Comment by jhook [ 11/Nov/04 ]

In the JSF 1.2 check in on head, the new EL implementation does implement the
equals/hashCode and toString() methods for both ValueBinding and MethodBinding.

Comment by Ed Burns [ 18/Jan/05 ]

This has been addressed in the JSF 1.2 and JSP 2.1 EDR.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-15] Enhanced Decorator support Created: 27/Aug/04  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: 1.2

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

Operating System: All
Platform: Sun


Attachments: Zip Archive wrapper-src.zip    
Issuezilla Id: 15

 Description   

>>>>> On Thu, 08 Apr 2004 16:49:03 -0700, Adam Winer <adam.winer@ORACLE.COM> said:

AW> The faces-config.xml support for the decorator pattern is
AW> one of my favorite features in JSF, and I like pushing
AW> it at users whenever I get a chance. But it is a pain
AW> using it, especially on objects with large APIs (like ViewHandler).

AW> I'd recommend we follow the lead of the Servlet API and
AW> provide convenience classes for implementing the Decorator
AW> pattern. (They were a bit more than convenience classes
AW> for the Servlet API, but anyway...)

AW> This would make implementing the Decorator pattern much,
AW> much simpler. It also makes it much more robust - as things
AW> stand now, every time we add a method to any of these
AW> decoratable APIs in a new version of JSF, all existing
AW> Decorators will break!

AW> This would involve, as an extreme, adding the following ten
AW> classes to JSF:
AW> ApplicationFactoryWrapper
AW> NavigationHandlerWrapper
AW> ViewHandlerWrapper
AW> StateManagerWrapper
AW> FacesContextFactoryWrapper
AW> ResponseWriterWrapper
AW> PropertyResolverWrapper
AW> VariableResolverWrapper
AW> LifecycleFactoryWrapper
AW> RenderKitFactoryWrapper

AW> But of that long list, only four are especially useful:
AW> ViewHandlerWrapper
AW> StateManagerWrapper
AW> ResponseWriterWrapper
AW> PropertyResolverWrapper

AW> The rest are either rather esoteric, or are wrappers for
AW> single method APIs (where using a canned wrapper would
AW> be even harder than writing the wrapper from scratch).

AW> BTW, I'm aware this nothing built-in about decorator support
AW> for ResponseWriters. But we've found over the last few
AW> years of using an analogous concept that decorating ResponseWriters
AW> is very, very useful for things like:

AW> - Optimizing page content
AW> - Catching common HTML errors
AW> - Adding whitespace (the current RI pushes this task to each
AW> renderer)
AW> - Sliding in design-time hooks
AW> - Adding comments to the page output (e.g., this content
AW> was built by a UICommand with id='foo')

AW> ... all of which don't require bloating the base response writer
AW> or adding any performance or output size overhead for users not
AW> using the decorator. And we don't really need anything special
AW> to support decorating ResponseWriters - that can be done in the
AW> JSP page with some easy tags sliding inside of <f:view>.

AW> This would be a very nice improvement in JSF 1.1, and I
AW> don't think it's a huge amount of work, but I could
AW> understand punting it to JSF 1.2.



 Comments   
Comment by Ed Burns [ 30/Aug/04 ]

up to p1 feature.

Comment by Ed Burns [ 06/Oct/04 ]

I have asked Ryan Lubke of the Sun team to produce a proposal for this, based on
Adam's content in this message.

Comment by Ed Burns [ 08/Oct/04 ]

Created an attachment (id=2)
source for proposal

Comment by Ed Burns [ 08/Oct/04 ]

From Ryan Lubke:

Motivation
-----------------------------------

AW> The faces-config.xml support for the decorator pattern is
AW> one of my favorite features in JSF, and I like pushing
AW> it at users whenever I get a chance. But it is a pain
AW> using it, especially on objects with large APIs (like ViewHandler).

AW> I'd recommend we follow the lead of the Servlet API and
AW> provide convenience classes for implementing the Decorator
AW> pattern. (They were a bit more than convenience classes
AW> for the Servlet API, but anyway...)

AW> This would make implementing the Decorator pattern much,
AW> much simpler. It also makes it much more robust - as things
AW> stand now, every time we add a method to any of these
AW> decoratable APIs in a new version of JSF, all existing
AW> Decorators will break!

Proposal
--------------------------
Create wrapper classes for the following:

  • ViewHandlerWrapper
  • StateManagerWrapper
  • ResponseWriterWrapper
  • PropertyResolverWrapper
  • VariableResolverWrapper (this one was added more for balance)
  • These classes have a single constructor which takes an instance
    of the class they are designed to wrap.
  • The default behavior for the methods of each implementation call through
    to the wrapped instance
Comment by Ed Burns [ 11/Oct/04 ]

take ownership

Comment by Ed Burns [ 18/Oct/04 ]

I've resolved ViewHandler, StateManager, and ResponseWriter and left the EL bits
until we have the EL alignment done.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-2] Security issues with client side state saving Created: 18/Aug/04  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 1.2

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

Operating System: All
Platform: All


Issuezilla Id: 2

 Description   

The current spec says nothing about security when doing client side state
saving. We need to say that the state should be encoded using some minimal
level of security.



 Comments   
Comment by Ed Burns [ 07/Oct/04 ]

take ownership

Comment by Ed Burns [ 11/Jan/05 ]

The EG has decided to modify the contract for ResponseStateManager.writeState()
to say that the state may be encrypted and note that the Sun RI does encrypt it.

Comment by Ed Burns [ 11/Jan/05 ]

The impl is being covered in
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=84

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1166] Make it so proper license is included and linked from Javadocs Created: 19/Feb/13  Updated: 19/Feb/13  Resolved: 19/Feb/13

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

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


 Description   

See http://aseng-wiki.us.oracle.com/asengwiki/display/JavaEE/JavadocsSpecLicense






[JAVASERVERFACES_SPEC_PUBLIC-1165] Leverage the default "value" attribute of an annotation to be the flow id of a @FlowScoped bean Created: 18/Feb/13  Updated: 22/Feb/13  Resolved: 22/Feb/13

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

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

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-730 Make flows reusable Closed

 Description   

Hello Experts,

This came in on the users list.

>>>>> On Mon, 11 Feb 2013 07:01:07 -0800, Edward Burns said:

>>>>> On Thu, 24 Jan 2013 17:49:23 +0000 (GMT), said:
AG> I was wondering if any discussions have happened around changing
AG> @FlowScoped(id="...") to @FlowScoped(value="..."). This will make my
AG> bean declaration cleaner.

AG> @FlowScoped("foo")
AG> public class MyBean implements Serializable

{ AG> }

AG> instead of

AG> @FlowScoped(id="foo")
AG> public class MyBean implements Serializable {AG> }

AG> Comments ?

EB> Yes, I like that idea.

EB> I'll do it that way instead.

Any objections?

Ed






[JAVASERVERFACES_SPEC_PUBLIC-1167] <f:selectItems> itemLabelEscaped: if not specified, behave as if true. Created: 22/Feb/13  Updated: 22/Feb/13  Resolved: 22/Feb/13

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

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 22 minutes
Time Spent: 8 minutes
Original Estimate: 30 minutes

Issue Links:
Dependency
blocks JAVASERVERFACES-2747 XSS hole: GenericObjectSelectItem inc... Closed

 Description   

See http://java.net/jira/browse/JAVASERVERFACES-2747






[JAVASERVERFACES_SPEC_PUBLIC-1169] Convert namespace URIs to use new hostname: xmlns.jcp.org instead of java.sun.com. Created: 04/Feb/13  Updated: 26/Jun/13  Resolved: 26/Jun/13

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

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 days, 23 hours
Time Spent: 1 hour
Original Estimate: 3 days

Issue Links:
Dependency
blocks JAVASERVERFACES-2764 Apply java.sun.com -> xmlns.jcp.org c... Closed

 Description   

Per Bill Shannon, all newly created XML namespaced artifacts in JSF 2.2 must use the new xmlns.jcp.org hostname instead of java.sun.com. For example, the faces-config.xml schema will be <http://xmlns.jcp.org/xml/ns/javaee> instead of <http://java.sun.com/xml/ns/javaee>.



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

EB> Pass Through Attributes
EB>
EB> http://java.sun.com/jsf/passthrough
EB>
EB> becomes

http://xmlns.jcp.org/xml/ns/jsf/passthrough

EB> Pass Through Elements
EB>
EB> http://java.sun.com/jsf
EB>
EB> becomes

http://xmlns.jcp.org/xml/ns/jsf

Comment by Ed Burns [ 06/Feb/13 ]

EB> * Looking at overview-summary in JSF 2.2 you can see that there are three new XSD files in JSF
EB> 2.2. They are all increments of anologous files in JSF 2.1. All of
EB> these will use the new XML ns.





[JAVASERVERFACES_SPEC_PUBLIC-900] Images resources in css with relative path Created: 24/Oct/10  Updated: 01/Aug/14  Resolved: 29/Feb/12

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

Type: Bug Priority: Critical
Reporter: michael_kurz Assignee: Ed Burns
Resolution: Duplicate Votes: 0
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-884 Support library prefix in resource URLs Reopened
duplicates JAVASERVERFACES_SPEC_PUBLIC-947 Relative Resources Open
Issuezilla Id: 900
Status Whiteboard:

size_large importance_large


 Description   

JSF resource handling does not allow the usage of images with relative paths in
css like this:

url('img01.jpg')
url('../img/img02.jpg')

This is caused by the way resources are loaded in JSF. For a css this would for
instance be:

http://www.example.com:8080/javax.faces.resource/style.css.jsf?ln=css

The browser would then try to load the images above with the following urls:

http://www.example.com:8080/javax.faces.resource/img01.jpg
http://www.example.com:8080/img/img02.jpg

None of them would resolve to an image. In the first case the library is missing
and in the second one the prefix.

The problem could be avoided by using #

{resource['...']}

in the css. The
drawbacks of this approach are that it is not "designer friendly" and that it
creates a performance bottleneck (value expressions have to be evaluated again
and again). Furthermore, resources could also be referenced in other files that
currently don't support value expressions.

A solution would be to have a "real" path for resources including the library
name. On resolving the library name could be retrieved as the part of the path
between the prefix and the first slash (slashes are not allowed in lib names
anyway). This will apparently only work for prefix mapping but the current
solution is not working at all.

Another possibility would be to register "/javax.faces.resource/*" as a servlet
mapping for resources (with Servlet 3 this could be done automatically).



 Comments   
Comment by ramiromagalhaes [ 14/Apr/11 ]

I think this duplicates JAVASERVERFACES_SPEC_PUBLIC-884.

Comment by Jakob Korherr [ 15/Apr/11 ]

adding duplication link

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-880] Add default attribute discovery capability to composite component metadata specification Created: 30/Aug/10  Updated: 01/Aug/14  Resolved: 30/Aug/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 880

 Description   

EB> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1782
EB> The proposed solution is to enhance the composite component metadata
EB> specification to include information about the list of composite
EB> component attributes for which default attribute values have been
EB> declared.

EB> This information is used in the Facelets tag layer in the code that
EB> installs the ValueExpression for any child attributes in the using page.
EB> In this case, the MetadataHandler manually removes the attribute from
EB> the attributes map if there is a ValueExpression for an attribute for
EB> which there also is a composite component attribute.

EB> SECTION: Modified Files
EB> ----------------------------
EB> M Spec section 3.6.2.1 Composite Component Metadata

EB> Add a new paragraph at the end of the section, which would fall under
EB> the bullet that describes the runtime representation of the
EB> <cc:attribute> element.

EB> The composite component BeanDescriptior must return a
EB> Collection<String> when its getValue() method is called with an
EB> argument equal to the value of the symbolic constant
EB> UIComponent.ATTRS_WITH_DECLARED_DEFAULT_VALUES. The
EB> Collection<String> must contain the names of any <cc:attribute>
EB> elements for which the default attribute was specified, or null, if
EB> none of the attributes have been given a default value.



 Comments   
Comment by Ed Burns [ 30/Aug/10 ]

accept

Comment by Ed Burns [ 30/Aug/10 ]

Checking in userInterfaceComponentModel.fm;
/cvs/javaserverfaces-spec-eg/spec/frame/userInterfaceComponentModel.fm,v <--
userInterfaceComponentModel.fm
new revision: 1.158; previous revision: 1.157
done

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-862] Remove class jsf-api/src/main/java/javax/faces/event/PostAddToViewNonPDLEvent Created: 01/Jul/10  Updated: 01/Aug/14  Resolved: 20/Sep/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.1

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

Operating System: All
Platform: All


Issuezilla Id: 862
Status Whiteboard:

size_small importance_small

Tags: changelog_2_1

 Description   

r7762 | edburns | 2009-08-25 16:12:01 -0400 (Tue, 25 Aug 2009) | 7 lines

SECTION: Deleted files

jsf-api/src/javax/faces/event/PostAddToViewNonPDLEvent.java

This file should not be in the final API. It is not used and should
have been deleted a long time ago.



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

Take this over. Triage.

Comment by Ed Burns [ 02/Jul/10 ]

Fix checked in

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-805] PostAddToViewEvent delivery specification needs clarification Created: 20/May/10  Updated: 01/Aug/14  Resolved: 22/Jun/10

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 805
Status Whiteboard:

changelog


 Description   

UIComponent.getChildren() says the following about PostAddToViewEvent delivery:

"After the child component has been added to the view, if the following condition is not met:

FacesContext.isPostback() returns true and FacesContext.getCurrentPhaseId() returns
PhaseId.RESTORE_VIEW

Application.publishEvent(javax.faces.context.FacesContext, java.lang.Class, java.lang.Object) must be
called, passing PostAddToViewEvent.class as the first argument and the newly added component as the
second argument."

However:

1. We do actually deliver PostAddToViewEvents during restore view when partial state saving is
enabled.
2. We don't actually want to deliver PostAddToViewEvents during render response when Facelets
temporarily removes/re-adds existing components from the tree.
3. These requirements are not specified in UIComponent.setParent(), which also discusses
PostAddToViewEvent delivery:

"This method will cause an PostAddToViewEvent to be published and if parent.isInView() returns true an
PostAddToViewEvent will be published as well."

The getChildren()/setParent() documentation should either be consistent, or we should remove the doc
from one of these locations.



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

p2

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

Fix checked in.

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-802] Ajax fileupload capabilities Created: 17/May/10  Updated: 23/Dec/13  Resolved: 30/Apr/13

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

Type: Improvement Priority: Critical
Reporter: werpu12 Assignee: Ed Burns
Resolution: Fixed Votes: 10
Labels: None
Remaining Estimate: 6 days, 8 hours, 3 minutes
Time Spent: 15 hours, 57 minutes
Original Estimate: 1 week
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File 20110613-i_spec_802_mods.txt     Text File 20111208-i_spec_802-mods.patch     File 20121102-werpu-AjaxFileupload.odt    
Issue Links:
Dependency
depends on GLASSFISH-16740 Unable to get "multipart/form-data" r... Resolved
depends on JAVASERVERFACES_SPEC_PUBLIC-149 Provide way to discover the JSF spec ... Closed
blocks JAVASERVERFACES-2573 Implement "ajax" file upload Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1197 Support multiple attribute on h:input... Open
is related to JAVASERVERFACES-3122 Migrate test for spec issue #802 to t... Closed
Issuezilla Id: 802
Status Whiteboard:

size_medium importance_large draft

Tags: adf

 Description   

The main issue with the current implementation is, that fileupload the ajax way
is not working properly.

The problem simply is, that fileupload component and multipart form requests
both are a second class citizen in the JEE world and html generally.
There is no way to submit a fileupload via ajax currently, however there is an
iframe based method to do it.

But for that an iframe transport layer is missing, since the current spec only
talks abut queued asynchronous xhr requests.

see http://www.openjs.com/articles/ajax/ajax_file_upload/

for more information....



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

New features, 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 08/Jun/10 ]

Comments from issue 647 Note that from a spec perspective, I believe that the main issue is that
jsf.ajax.response() expects a XHR
object, which it uses to grab the responseXML. However, XHR cannot be used in the multi-part form case
(requires iframe-based postback), and as such no XHR object is available to pass off to jsf.ajax.response().

Comment by Ed Burns [ 08/Jun/10 ]
      • Issue 647 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 08/Jun/10 ]

adf keyword

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 30/Jun/10 ]

triage - Folks have been asking for this.

Comment by ganeshpuri [ 30/Jun/10 ]

would be great to be able to do AJAX uploads with 2.1

Comment by werpu12 [ 09/Jul/10 ]

Ok I am doing some prototyping on this issue within the realms of myfaces (since
I am not allowed to do that for Mojarra)
So far I have something preliminary up and running which has yet to be committed
which pushes the current lifecycle over iframes insteas of xhr. However I found
something in the spec which is some sort of a blocker. The spec requires for a
valid ajax request that Faces-Request:partial/ajax is set in the request header.
I do not think you can tamper on form level (which in fact the iframe solution
is) with that. The result of leaving it out is that the impl thinks this is not
an ajax request and then renders the full page instead of the response xml.

I am going to investigate further if setting the request header is possible on
the iframe solution. Otherwise we have to revamp the spec here a little bit.

Comment by werpu12 [ 14/Jul/10 ]

Ok the issue with the current specification in the ajax dection and triggering
of the partial mechanisms is following. I was able to patch the
PartialViewHandler up so that the entire lifecycle works with the iframe transport.

The problem really is we currently have two mechanisms, one identifying that it
is a partial request, the other one, that it is an Ajax request.
Both work over request headers, for the iframe case we have to weaken the spec
here a little bit to allow the same over
request parameters, since there seems to be no way to submit a new header param
via a normal form submit.

The idea is following, introduce a third type, iframe request, and allow both
ajax request, iframe request and partial request also be submitted over simple
request parameters instead of header params (so both type of values can trigger
a valid partial lifecycle a request header parameter or a normal request parameter)
Once a valid iframe request can trigger the partial lifecycle everything else
behaves just as it would in the xhr case (for the server both usecases are just
post requests)

As for the proposed mechanism. My personal idea is to enqueue an iframe request
just like we would a normal xhr post request in our asynchronous queue and just
treat it from outside like we we an xhr request. I have this running for most
browsers already I just have a sync issue for heavy load on IE6, which I will
investigate later into, but the pattern looks good to me that it might be
implementable.

(see the preliminary snapshot code here http://www.pastebin.org/396667 and
http://www.pastebin.org/396646 from my myfaces based prototype)
The reason for this is synchronisation issues which the queue eliminates.

As how and when we trigger the mechanism is a little bit unclear to me still, my
personal guess is that an auto switch between xhr and iframe in case of an
embedded executed fileupload might make the most sense to keep the api simple),
I will try to find out more once my prototype can finally do the fileupload.

Comment by Ed Burns [ 28/Jul/10 ]

Please make sure to look at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?
id=690

Comment by Ed Burns [ 28/Jul/10 ]

Also make sure to look at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=861

Comment by Ed Burns [ 29/Jul/10 ]

Werner suggests the attribute set for t:inputFileUpload as a guide

http://www.jsftoolbox.com/documentation/tomahawk/09-TagReference/tomahawk-inputFileUpload.html

Comment by Ed Burns [ 02/Sep/10 ]

Even though Werner has done most of the preparatory work on this issue, I still have to move it to JSF
2.2.

Comment by markcolletteice [ 14/Apr/11 ]

In ICEfaces ACE, the fileEntry component uses the [hidden] iframe technique. We have to fake out the partial/ajax request, as well as extract the uploaded file(s) and translate the multi-part request to not be multi-part, so that JSF will run. And then in the browser, when handling the response, we have to fake out the XHR response object, using what we get from the iframe response, so that page updates will be handled.

It would be nice to collaborate on moving parts of this into JSF, so that everyone's different file upload components could be built on a common infrastructure.

One critical issue to us is that we don't follow the pattern of simply sticking the file contents into a temporary byte[] or file, like the other component frameworks do. We allow for either directly writing the file to the end file-system destination that the application specified, or using a callback interface for chunking the file data, without buffering the whole file, to the application, so that it can virus scan the file contents, or re-transmit it to another server via a socket, or write it to a database. So, we'd like the file processing to be custom for the component framework, that way we're not limited by a lowest common denominator handling of file data.

http://wiki.icefaces.org/display/ICE/FileEntry
http://www.icefaces.org/docs/v2_latest/ace/tld/ace/fileEntry.html
http://wiki.icefaces.org/display/ICE/Incremental+Upload+Processing+Using+FileEntryCallback

Comment by Neil Griffin [ 19/Apr/11 ]

I'm very happy to see that Ajax-based file upload is being discussed. But for the sake of completeness, I think that the old Web 1.0 multipart/form-data technique should be supported, as was discussed in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-690

In my comments there,mentioned that I implemented a solution in the PortletFaces Bridge. It's working quite nicely – no need for Servlet 3.0, no need for a filter. Everything works great. Making this work in a Servlet-based JSF like Mojarra should be a piece of cake.

Comment by tedgoddard [ 21/Apr/11 ]

The approach to resolving this should be to provide additional APIs that make it possible to plug different transports into the JSF request/response cycle:

  • allow a partial response to be requested without a custom HTTP header
  • support new HTML5/XMLHttpRequest features that include file parts
  • expose JSF form serialization to String as JavaScript API
  • ensure that jsf.ajax.response can easily be called by external code (context and jsfResponse do not seem to be entirely public parameters)
Comment by werpu12 [ 21/Apr/11 ]

Actually that is how we prototyped it for myfaces. We dont have an official api, but we have configuration options which allow to choose a certain transport type.

So you can define jsf.ajax.request with additional myfaces:

{transportType: "iframeRequest"}

etc.. options to force the system into an iframe request.

We also allow an auto transport option where the system changes from the default xhr level1 into iframe if a multipart file upload situation is detected.

The problem with xhr level3 simply is or was the last time I looked at it that most browsers issued multipart requests without length attributes which rendered most fileupload libraries useless (and broke one of the two related specs in that area)
so an auto fallback to xhr level3 is definitely given the state of affairs a no go.

But as I see it xhr level3 is a good option if you can support it properly because it also allows some kind of progress notification so if this issue is started we also should opt for xhr level3 optionally.

The http header issue was another one. Currently the jsf ajax cycle is determined over custom http header, which is a no go in an iframe scenario because you only can send parameters, this needs to be fixed (and I did an internal fallback in myfaces to fix this but this is currently an implementation detail.

the jsf.ajax.response is another issue relatively unrelated, in myfaces we have some internal params which fix some internal issues, like how do you fix the issue of having an update and your original element is detached as well as its parent form. Those kind issues simply have to be taken care of in the official spec then I guess the jsf.ajax.response is really public.
I guess mojarra has 1-2 of those extra bugfix params as well.
But actually in case of myfaces I just got this bugreport in and it indeed is a bug in our impl because the call to the jsf.ajax.response should work without any extra params.

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 08/Dec/11 ]

Neil committed his version of the work to https://svn.java.net/svn/mojarra~svn/branches/FILE_UPLOAD

These are the files that differ from the state of the tree when he created that branch.

These files were committed in r9162.

Index: common/ant/dependencies.xml
Index: jsf-api/doc/file-props.xml
Index: jsf-api/doc/standard-html-renderkit-base.xml
Index: jsf-api/doc/standard-html-renderkit.xml
Index: jsf-api/src/main/java/javax/faces/component/UploadedFile.java
Index: jsf-ri/conf/share/html_basic.taglib.xml
Index: jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapMultiPartImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterMapFactory.java
Index: jsf-ri/src/main/java/com/sun/faces/context/RequestParameterValuesMapMultiPartImpl.java
Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlDecorator.java
Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/html/HtmlLibrary.java
Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/FileRenderer.java
Index: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/TextRenderer.java
Index: jsf-ri/src/main/java/com/sun/faces/component/UploadedFileImpl.java
Index: jsf-ri/src/main/resources/com/sun/faces/standard-html-renderkit-impl.xml

Comment by Ed Burns [ 08/Dec/11 ]

Notes from merging in Neil's work.

Comment by Ed Burns [ 08/Dec/11 ]

In progress patch.

Comment by Ed Burns [ 09/Dec/11 ]

muellermi
@edburns Will JSF's AJAX file upload offer functions to display progress? Or suport multi-file uploads?

Comment by werpu12 [ 09/Dec/11 ]

Progress is not possible with existing html means, XHR Level 2 in the long run will support it. Not sure if the spec can specifiy a progress event which if supported can be fired and if not does nothing except to go from 0 to 100, it would make sense. Same I think goes for multiple file uploads.
(Cannot remember if the existing iframe method supports multiple file uploads)

Comment by Ed Burns [ 16/Dec/11 ]

Move to Sprint 10, but at leas we have the non-Ajax portion committed.

Comment by Ed Burns [ 03/Feb/12 ]

Move to sprint 11

Comment by robweaver [ 13/Apr/12 ]

Just updated to 3.1.2 (Build 23) and the FileUpload on PrimeFaces broke (I think due to this issue).

Upload widget acts as if the upload is working, but never hits the back end event handler.

Reverting to 3.1 with no changes to WAR and the file upload works again.

Would be glad to help diagnose this issue.

Any target date for the fix, and is there a workaround ?

Comment by Ed Burns [ 13/Apr/12 ]

Hello robweaver,

Can I ask you please to file this in the GLASSFISH JIRA? I know some multipart upload changes were done in GlassFish 3.1.2 and t's quite possible this has nothing to do with Mojarra JSF implementation. At any rate, it certainly doesn't have anything to do with the spec.

http://java.net/jira/browse/GLASSFISH

Thanks,
Ed

Comment by robweaver [ 15/Apr/12 ]

Thanks, I thought I was entering it on the GlassFish issue, sorry see http://java.net/jira/browse/GLASSFISH-18444 which appears to be my issue.

Apologies for the incorrect entry.

Comment by rogerk [ 23/May/12 ]

There currently is a bug in the implementation - see: http://java.net/jira/browse/JAVASERVERFACES-2420. However, if the page author specifies a "value" attribute it should be rendered.

Comment by Ed Burns [ 15/Oct/12 ]

Werner prepared this document prior to a 60 minute Google+ hangout we had today. We edited the document during the meeting.

Comment by Ed Burns [ 16/Oct/12 ]

See < http://tim-vm9.us.oracle.com:7070/hudson/job/trunk-test-glassfish-4_0/442/ >.

Comment by Ed Burns [ 06/Nov/12 ]

Werner had some additional feedback.

Comment by arjan tijms [ 30/Apr/13 ]

As JSF 2.2 went final, shouldn't this issue be closed?

Comment by rogerk [ 30/Apr/13 ]

Fixed for 2.2

Comment by jid1 [ 03/Jun/13 ]

Did the "multiple" attribute make it into the spec?

Comment by Ed Burns [ 10/Jun/13 ]

Well, yes and no. I just tested it.

Here's the yes part.

You can say this:

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

and it renders correctly:

        <p><input id="file" type="file" name="file" multiple="multiple" />

but the no part is that each of the files in the multiple list is overwritten when the next one is processed.

Comment by Ed Burns [ 10/Jun/13 ]

I have filed < https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1197 > to cover this. We'll get to it in 2.3.





[JAVASERVERFACES_SPEC_PUBLIC-800] UIViewRoot.getComponentResources() generated id rules Created: 13/May/10  Updated: 01/Aug/14  Resolved: 20/Sep/10

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

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

Operating System: All
Platform: All


Attachments: File image.tiff    
Issuezilla Id: 800
Status Whiteboard:

changelog

Tags: changelog_2_1

 Description   

Comments from: [jsr-314-open] UIViewRoot.getComponentResources() documentation
does not match with the implementation

Doing some tests I notice the implementation in mojarra of
UIViewRoot.getComponentResources() does not match with the spec javadoc. This
javadoc says this:

"...Return an unmodifiable List of UIComponents for the provided target
agrument. Each component in the List is assumed to represent a resource instance.

The default implementation must use an algorithm equivalent to the the following.

  • Locate the facet for the component by calling getFacet() using target as
    the argument.
  • If the facet is not found, create the facet by calling
    context.getApplication().createComponent() using javax.faces.Panel as the argument
    o Set the id of the facet to be target
    o Add the facet to the facets Map using target as the key
  • return the children of the facet...."

The javadoc says cleary that the returning facet is created using
javax.faces.Panel as argument. But mojarra uses
"javax.faces.ComponentResourceContainer" as argument. The effect can be seen
when you try to use myfaces on glassfish v3 and you set the classloader delegate
to true (I know that configuration is wrong, but the exception caught my attention).

Looking on google I saw this issue:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1427

I also saw that the line:

"Set the id of the facet to be target"

is to respected too. Tomahawk has an example
(myfaces-example-simple20/calendar.jsf) that has this code

<h:panelGroup id="body">

It works with mojarra (2.0.3-SNAPSHOT) but do not with myfaces. The reason is
myfaces is doing what spec says, but mojarra set the id to
"javax_faces_location_body". That's not fair. On JSF 2.0 Rev A Change Log there
is no issue related to this one.

I have to say it, my personal opinion is that spec changes should not be done
without document them on javadoc or add them to JSF 2.0 Rev A Change Log. Do
things like that, only makes things more difficult to track, even worst,
important details that needs to be on the spec just will be missing.

Could anyone include this detail on:

http://wiki.jcp.org/wiki/index.php?page=JSF+2.0+Rev+A+Change+Log

and correct the spec javadoc? Thanks !



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

P2.

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 24/May/10 ]

Fix checked in.

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by lu4242 [ 03/Aug/10 ]

Checking this change I notice that it was let this line:

"...Set the id of the facet to be target..."

But the current behavior is

  • If target=head then the id is javax_faces_location_HEAD
  • If target=body then the id is javax_faces_location_BODY
  • If target=form then the id is javax_faces_location_FORM

Could anyone confirm if that line is correct or if it is a bug on the javadoc?

Comment by Ed Burns [ 04/Aug/10 ]

Created an attachment (id=263)
rendered javadoc with this fix.

Comment by Ed Burns [ 04/Aug/10 ]

Fix checked in r8539.

Comment by Ed Burns [ 13/Sep/10 ]

changelog

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 13/Sep/10 ]

Update status for JCP ChangeLog.

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-798] UIComponent.broadcast only propagate events on ClientBehavior instances Created: 13/May/10  Updated: 01/Aug/14  Resolved: 22/Jun/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 798
Status Whiteboard:

changelog


 Description   

Comments from: [jsr-314-open] UIComponent.broadcast only propagate events on
ClientBehavior instances

Checking the new Behavior api (for implement cc:clientBehavior), I note that the
javadoc of UIComponent.broadcast says this:

"....Broadcast the specified FacesEvent to all registered event listeners who
have expressed an interest in events of this type. Listeners are called in the
order in which they were added.

If the event is an instance of BehaviorEvent and the current component is the
source of the event call BehaviorEvent.getBehavior() to get the Behavior for the
event. If the behavior implements ClientBehavior, call
Behavior.broadcast(javax.faces.event.BehaviorEvent)}....."

The wrong line is:

".....If the behavior implements ClientBehavior, call Behavior.broadcast....."

So, if a user try to create a custom Behavior, the method broadcast() will be
useless, and custom behaviors will not catch events. I think it is a bug on the
javadoc, so I'll correct it on myfaces.

Martin Marinschek says:

just so that I get you right: you are saying that broadcast should be
called in any case, not only if the behaviour is a ClientBehavior?

Leonardo Uribe says:

Yes, the Behavior interface has only one method: broadcast(). It does not have
sense to put a method on a base class that only will be called for an specific
child class (in this case ClientBehavior). I think the intention of the
programmer here is call it always.



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

move to p2.

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 24/May/10 ]

Fix checked in.

Comment by Ed Burns [ 24/May/10 ]

Forgot to mark FIXED.

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-787] Restore ViewScope before templates are processed with buildView Created: 23/Apr/10  Updated: 10/Dec/12  Resolved: 16/Aug/11

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

Type: Improvement Priority: Critical
Reporter: Hanspeter Duennenberger Assignee: Hanspeter Duennenberger
Resolution: Fixed Votes: 2
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle-787-workaround.txt     Text File changebundle.txt     Text File changebundle.txt     Text File JAVASERVERFACES_SPEC_PUBLIC-787-restore-ViewScope-before-buildView.patch     Zip Archive JAVASERVERFACES_SPEC_PUBLIC-787.zip    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1032 UIForm.createUniqueId() does not crea... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1034 disentangle ViewScope state handling ... Open
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-1034 disentangle ViewScope state handling ... Sub-task Open  
Issuezilla Id: 787
Status Whiteboard:

size_medium importance_large draft


 Description   

Restoring the view with partial state saving enabled, the state is attached to
the component tree after the view-definition is processed (aka the tree is built
from the template). But sometimes the application of the view-definition might
depend on state from the previous request. An example: we have a dialog system
which remembers across requests which dialog is active.

So, to be backwards compatible with JSF 1.2, we need a way to store this state
across requests - it can not be part of the component state, cause the component
state is applied too late.

Our solution - and also recommendation for the next version of the spec - is
that the ViewScope (or the complete state of the ViewRoot component, but
ViewScope is sufficient) is restored before buildView() is called. That would
allow components with dynamic behavior to keep state in the ViewScope.

best regards,

Martin and Hanspeter

=====================

Here what we do currently: we decorated ViewDeclarationLanguage.buildView like
this (ok, for simplification we restored complete ViewRoot state):

public void buildView(FacesContext context, UIViewRoot root) throws
IOException {

if(context.getCurrentPhaseId()== PhaseId.RESTORE_VIEW)

{ //restore the view-scope (part of the UIViewRoot state-saving process) //_before_ we run the templates RenderKit renderKit = context.getRenderKit(); ResponseStateManager rsm = renderKit.getResponseStateManager(); Object[] rawState = (Object[]) rsm.getState(context, root.getViewId()); //noinspection unchecked final Map<String, Object> state = (Map<String,Object>) rawState[1]; Object viewRootState = state.get(root.getClientId()); root.restoreState(context, viewRootState); }

delegate.buildView(context, root);
}



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

I talked to Martin and Hanspeter about this. I agree with restoring the ViewMap first, but I don't know
if it will be possible in practice. Marking as P2 to make sure we get to it.

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

Behavior change, move to 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Hanspeter Duennenberger [ 14/Nov/10 ]

Created an attachment (id=337)
Proposed patch to restore viewScpe before buildView

Comment by Hanspeter Duennenberger [ 14/Nov/10 ]

Hi Ed.

Finally I found some time to develop a patch for this. It works fine with CS JSF.
Please have a look at it (I hope you find some time for that .

regards
Hanspeter

Comment by Hanspeter Duennenberger [ 26/May/11 ]

taking ownership to develop patch for review and commit.

Comment by Hanspeter Duennenberger [ 07/Jun/11 ]

Hello.

This is a reworked patch to restore ViewScope before the templates are processed in buildView().

Until now the full state including ViewScope is restored in UIViewRoot.restoreState(). But this method must only be called after the templates have been processed. To allow restore of ViewScope before processing the templates, I introduced a new method called UIViewRoot.restoreViewScopeState(FacesContext fc, Object state) to restore ViewScope only. In UIViewRoot.restoreState(..) viewScope will only be restored if not done before.

I am aware that it seems weird that ViewScope is state saved in the normal UIViewRoot.saveState(..) method and restored with restoreViewScopeState(..). But for saving the state there was no need to change the behaviour unless we want to redesign this in more depth which would involve a pair of method to save/restore ViewScope.

We use this solution in CS JSF since about 1/2 year and it worked with partial- and full state saving.

regards
Hanspeter

Comment by Ed Burns [ 08/Jun/11 ]

This is a nice and simple patch. Naturally, I wonder if there is a root problem (no pun intended) not specific to just the UIViewRoot, where a component needs to have some state restored to it after the tree has been built from the template, but before the partial state restoration traversal. If the UIViewRoot has this problem, then perhaps other components may have it as well?

Do we need to generalize this or is it sufficient to handle the view scope alone?

Arguments in favor of accepting the special case approach directly from
Hanspeter's 20110607 patch.

1. The manner in which the pre-restoration-traversal state is obtained
is specific to the implementation of the component. Therefore, we
must own the implementation of the component. In the case of
UIViewRoot, we do. If we wanted to generalize it, we would need
additional API and the state management API is already too complex.

2. An other use-case for pre-restoration-traversal state is dynamic
components. However, these are handled specifically elsewhere in the
implementation.

3. The UIViewRoot is unique among all other components in that you don't
need a template to obtain a reference to it. This uniqueness
warrants special case API.

Arguments in favor of denying Hanspeter's 20110607 patch in favor of a
request for a more general solution.

1. The additional API required would not be that large. Here is a sketch.
Introduce a new ComponentSystemEvent: PreRestoreStateEvent. Modify
the contract of the existing UIComponent.processEvent() to handle
this event. Override it in the case of UIViewRoot to do the action
currently impleneted in Hanspeter's 20110607 patch.

Hanspeter, can you please cook up a version of the patch that uses the
PreRestoreStateEvent approach?

Comment by Ed Burns [ 08/Jun/11 ]

For what it's worth, all 2160 automated tests passed with this patch applied.

Comment by Hanspeter Duennenberger [ 08/Jun/11 ]

Hi Ed.

Interesting considerations and I really like more generalized solutions, but I think UIViewRoot is unique for this matter:

1. UIViewRoot is not created from templates and there is also no possibility to do special work in a UIViewRootTagHandler.

2. The state in question is the ViewScope - all other components don't have theyr own scope to restore.

3. PreRestoreStateEvent on the component would be about the same time as PostAddToViewEvent on the component. It's after component was constructed and added to the view but before restore state is processed - restore state is processed after the full component tree was built.

4. In my opinion there is no way to restore some component state before the component is created - and during component creation TagHandler may be used for such action or directly after component construction PostAddToView component event may be used.

5. PreRestoreStateEvent processing would probably cause another tree walk, which some of the EG members will not like.

Ed, I don't see the need for that elaboration.

Regards
Hanspeter

Comment by Ed Burns [ 08/Jun/11 ]

Ok, thanks for considering the alternate idea.

I'm r=edburns for adding this to the trunk.

Comment by Hanspeter Duennenberger [ 08/Jun/11 ]

final changebundle before commit

Comment by Ed Burns [ 09/Jun/11 ]

r=edburns. Please add the output from svn commit, including all the "Sending..." lines and the line containing the svn revision number to this issue.

Ed

Comment by Hanspeter Duennenberger [ 09/Jun/11 ]

Committed to trunk.

Sending jsf-api/src/main/java/javax/faces/component/UIViewRoot.java

Sending jsf-api/src/test/java/javax/faces/component/UIViewRootTestCase.java

Sending jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java

Transmitting file data ......

Committed revision 9139.

(had to reproduce this manually - next time I know)

Comment by Ed Burns [ 10/Jun/11 ]

Additional attribution and spec language

Comment by Ed Burns [ 10/Jun/11 ]

Sending jsf-api/src/main/java/javax/faces/component/UIViewRoot.java
Sending jsf-api/src/main/java/javax/faces/view/StateManagementStrategy.java
Sending jsf-api/src/main/java/javax/faces/view/package.html
Transmitting file data ...
Committed revision 9149.

Comment by Rinner23 [ 14/Jul/11 ]

Before I try a merge do you think this would be safe to work into 2.0.4b9? This would be a great feature for us as it would allow viewscope to be used instead of Session in some of our nasty dynamic components

Cheers!

Matt

Comment by Hanspeter Duennenberger [ 14/Jul/11 ]

Hi Matt,

we used that on our custom built JSF RI 2.0 before 2.0.4 without any problem. So you should be save doing the same.

regards
Hanspeter

Comment by Rinner23 [ 18/Jul/11 ]

Actually, this change does appear to have a problem on 2.0.4b9. After applying the patch, we do have the viewscope at the correct time, but for some reason we are seeing two PostAddToViewEvents being fired during RENDER_RESPONSE but only during the very first time the page is requested.

The second PostAddToViewEvent has the component in a bad state, with no children.

If I refresh the page, everything works as normal. The only way to cause the problem again is to bounce the server, and again on the first page refresh the additional PostAddToViewEvent is fired.

Matt

Comment by Rinner23 [ 26/Jul/11 ]

Any thoughts on this? I've tried looking through the source code, but I'm currently really too ignorant of the details of the system to figure out why this might happen...

I think it must be related to how the system deals with the templates for the first time, like when it compiles/caches(correct?) them or something its throwing that additional PostAddToViewEvent. I've confirmed that if I remove the code, the additional event goes away as expected.

To work around this, I'm serializing my object graph into a hidden input field and restoring on the decode() of my custom composite component (manually grabbing the value from request).

This seems to work, and allows us to then dynamically create our component tree during PostAddToView based on the data serialized in that field from request to request (which can change).

Thanks for any input on this!

Regards,

Matt

Comment by Hanspeter Duennenberger [ 26/Jul/11 ]

Hi Matt,
sorry, I did not have time to look into that.

The changes from this issue only affect restoreState in UIViewRoot and restoreView in StateManagementStrategyImpl - so I can hardly believe it affects the first time a page is rendered. I assume the double delivered PostAddToViewEvent is due to something else.

Debug into your PostAddToViewEvent handling will show where the event comes from. Make sure the second one is not from a resource request - which would explain why the component delivered by the event does not have any children or parent.

regards
Hanspeter

Comment by Rinner23 [ 26/Jul/11 ]

I did check this, and there are no resources being requested.. It is simply a custom composite component in an otherwise empty page. Now, I am registering for the PostAddToViewEvent inside my components constructor, not in any page backing bean.

It is strange, that when I revert the changes and re-compile the extra event goes away with the exact same page.

As noted above I'm still very new to this technology having come across from ASP.NET, but it does have some similarities and I am working hard to get a better understanding.

Thanks,

Matt

Comment by rogerk [ 27/Jul/11 ]

This patch breaks a fundamental dynamic components test. Here it is (and the exception):

Test Case: Simple View

<h:form prependId="false" id="dynamicForm">

<h:panelGroup id="group">
<h:commandButton value="Add Component" action="#

{testManagedBean.addComponent}

"/>
</h:panelGroup>

</h:form>

The action in the managed bean dynamically created an HTMLOutputText component and adds it as a child to the panelGroup ("group"):

public void addComponent()

{ FacesContext ctx = FacesContext.getCurrentInstance(); UIComponent group = ctx.getViewRoot().findComponent("dynamicForm" + UINamingContainer.getSeparatorChar(ctx) + "group"); HtmlOutputText output = new HtmlOutputText(); output.setValue("OUTPUT"); group.getChildren().add(output); }

The first button click adds it fine (after the button). The next button click produces the following exception:

java.lang.ClassCastException: com.sun.faces.application.view.StateHolderSaver cannot be cast to [Ljava.lang.Object;
at javax.faces.component.UIViewRoot.restoreViewScopeState(UIViewRoot.java:1693)
at com.sun.faces.application.view.StateManagementStrategyImpl.restoreView(StateManagementStrategyImpl.java:240)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:211)
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:452)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:148)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:635)

Comment by rogerk [ 27/Jul/11 ]

The problem is that dynamic components are saved as StateHolderSaver objects.
You can see that logic in StateManagementStrategyImpl class (saveView method).
And in UIViewRoot.restoreViewScopeState (line 1693) we are blindly casting that to Object[]..
So, in this case, the first button press creates the dynamic component and it is saved as
a StateHolderSaver.

Comment by rogerk [ 27/Jul/11 ]

Reopening as this has issues with dynamic components.

Comment by rogerk [ 27/Jul/11 ]

Changes for workaround.

Comment by rogerk [ 27/Jul/11 ]

I've committed the workaround to the trunk:
Sending jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java
Transmitting file data .
Committed revision 9226.

Comment by Hanspeter Duennenberger [ 28/Jul/11 ]

Hi Roger,

thanks for that update - but I think the workaround is really just a workaround. I wonder why the dynamically added component changes the state structure. In UIViewRoot.saveState() - the saved state is an Object array with size 2 - element 0 is assigned with super.saveState() and element 1 is storing the viewScope as attachedState. But in case of the dynamically added component that seems no longer true - so that would mean the dynamically added component corrupts the state structure on UIViewRoot level.

I'll try to reproduce that problem and analyse it - hope I find time for it.

regards
Hanspeter

Comment by rogerk [ 28/Jul/11 ]

I spoke incorrectly when I said dynamic components were saved as StateHolderSaver objects - obviously that is not true. StateHolderSaver is a helper class in Mojarra. During saveView, dynamic components are added to the state map as StateHolderSaver objects. You can see this in StateManagementStrategyImpl.saveView.
So StateHolderSaver is used to save/restore state for dynamic components.
In restoreView, dynamic components are handled after non-dynamic components. The state map will also contain StateHolderSaver objects (used for the restoration of dynamic components). So, at the time you call:
viewRoot.restoreViewScopeState(context, stateObj);
you cannot assume stateObj will always be the state object itself.

Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

Hi Ed and Roger.

I tried to reproduce the error with the example Roger has given - but was not able to reproduce the exact same problem. But I have realized that h:form prependId="false" may lead to duplicate id's - see http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1032.

Looking at what tree visitor does in StateManagementStrategyImpl.saveView I somewhat understood the problem - in case a certain component was added dynamically, it's state is packed into a StateHolderSaver. But to cause the problem that Roger has pointed out it would be necessary to dynamically add UIViewRoot - is that possible at all or are we hunting a phantom problem?

I think the problem Roger ran into was based on the problem that UIForm with prependId="false" generated an id for the dynamically added component that was the same as the UIViewRoot's id. Then of course the saveView() treeVisitor assumes UIViewRoot was added dynamically and wraps it's state within a StateHolderSaver - and voila - we have the problem. However, I was not able to reproduce that.

Big question: is it possible to have UIViewRoot as a dynamically added component?

I was not able to reproduce the problem - if Roger can reproduce it, please provide me exact information of how to reproduce.

Unfortunatley on my windows machine I cannot run test.with.container.refresh anymore ...

Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

Testcase I tried to reproduce the problem - no success so far.

Comment by Hanspeter Duennenberger [ 12/Aug/11 ]

Finally with some help from Roger I was abler to reproduce the problem - but only after removing the patch for http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1032 UIForm.createUiqueId() which may produce non-unique clientId's in case prependId is false.

The dynamically added component is actually added to a panelGroup - and get's the clientId "j_id1" - which is the same as teh UIViewRoot's clientId. Now StateManagementStrategyImpl gets confused and handles UIViewRoot as a dynamically added component - and wraps it's state into a StateSaveHolder. And then next restoreState fails.

Comment by rogerk [ 15/Aug/11 ]

Tests ran successfully on my hosted machine.

r=rogerk

Comment by Hanspeter Duennenberger [ 16/Aug/11 ]

resolved as of JAVASERVERFACES_SPEC_PUBLIC-1032 - see there

Comment by Ed Burns [ 19/Oct/11 ]

Marking closed per most recent comments.

Comment by Ed Burns [ 06/Apr/12 ]

Sending jsf-api/src/main/java/javax/faces/component/UIViewParameter.java
Sending jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/config/processor/FaceletTaglibConfigProcessor.java
Transmitting file data ...
Committed revision 9814.

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1063 http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-787 http://java.net/jira/browse/JAVASERVERFACES-2369

SECTION: Modified Files
----------------------------
M jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java

  • in restoreView(), note that the state map will never be null due to
    the assignment statement at the top of the method. Therefore, we
    shouldn't test for null to determine the presence or absence of a
    pre-existing state map.

M jsf-ri/src/main/java/com/sun/faces/config/processor/FaceletTaglibConfigProcessor.java

  • in createMethod(), replace one or more whitespace with a single whitespace.

M jsf-api/src/main/java/javax/faces/component/UIViewParameter.java

  • in getSubmittedValue(), remove unnecessary cast to String.
Comment by fabmars [ 24/Nov/12 ]

UIViewRoot#restoreViewScopeState isn't called from anywhere anymore.

Probably this has to do with the big rework/split of StateManagementStrategyImpl in http://java.net/jira/browse/JAVASERVERFACES-2373

Comment by Hanspeter Duennenberger [ 10/Dec/12 ]

After looking at the code on trunk I think UIViewRoot#restoreViewScopeState is no longer needed since ViewScope is now kept on session and only the viewScopeId becomes part of the View's state.
This last change came from http://java.net/jira/browse/JAVASERVERFACES-2561 and completely makes sense - only think remaining - the UIViewRoot#restoreViewScopeState method could be removed or at least made deprecated.

Comment by lu4242 [ 10/Dec/12 ]

I think UIViewRoot#restoreViewScopeState still has a lot of sense, and should not be marked as deprecated or removed, because it enforces the condition of restore the view scope state before restore the view state. If a side effect of ViewScope implementation is make this method not necessary, does not means that the method is not valid for other alternate implementations of ViewScope. In other words, it is not a good idea to rely on a implementation detail for something that should be enforced by spec.

Comment by Hanspeter Duennenberger [ 10/Dec/12 ]

Hi Leonardo,
you are right about the spec aspect. On the other hand there is no counterpart like saveViewScopeState() to complete the state handling for ViewScope. Also with support for CDI or other Scope Managers these methods might not really fit.
Currently it seems this restoreViewScopeState() method is a relict because it's never ever called in JSF RI.
That is what needs to be resolved - I don't mind if this method is no longer used as long as the handling of ViewScope is clearly specified - at least the fact that ViewScope must be present before buidView() is called. I just don't know now if that is still specified.
Best regards
Hanspeter

Comment by lu4242 [ 10/Dec/12 ]

Hi Hanspeter

Ok, I see. It is clear restoreViewScopeState() is necessary for jsf 2.0 view scope, because in this case, JSF stores the view scope with the view state, but the question is how is really handle scopes in CDI, or in other words, how CDI recognize a specific "context". For example, how CDI knows that a view scope is for an specific bean. Does it uses the viewId? a combination of the windowId/viewId? a generated identifier stored in UIViewRoot?. In my understanding, MyFaces CODI/Openwebbeans uses a combination of the windowId/viewId.

In my opinion, the flaw in the spec and the reason of the discussion over restoreViewScopeState() is more related to how JSF defines a "view context" and expose that information to the external context like CDI-JSF integration module or any other bean container. In the current design, CDI is responsible to handle the beans and all issues related to them (injection, serialization, ...), so JSF should not do operation to save / restore bean stated directly, and instead let CDI to do its magic under curtains.

So, what has sense here is enforce that any view scope or the "view context" should be defined before restore the view state, which means in PSS context, call vdl.buildView and apply the state to the created component tree.

In theory restoreViewScopeState() is not implemented directly by UIViewRoot, but it has sense to override UIViewRoot and implement it cases like portlets or even with plain CDI, because this method gives the chance to initialize the context properly, no matter which trick is used to define the "view context".

Note I don't know the details behind CDI-JSF integration, but with the current spec, I suppose/guess the intention is do something like that.

best regards,
Leonardo





[JAVASERVERFACES_SPEC_PUBLIC-782] Fix PostAddToViewEvent and PreRemoveFromViewEvent publishing conditions Created: 31/Mar/10  Updated: 01/Aug/14  Resolved: 01/Nov/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 782
Status Whiteboard:

size_small importance_large

Tags: adf

 Description   

There is a discussion unde the topic:

[jsr-314-open] PostAddToViewEvent publishing conditions

Here the first email describing it:

Actually the event publishing conditions of
PostAddToViewEvent/PreRemoveFromViewEvent are not very clear. These conditions
depends if partial state saving is used or not and if facelets updates the view
or not. The problem is this fact is not very intuitive, so for write code
correctly the user needs to be aware of that, in other words this should be
documented somewhere. Also, there are some technical questions that could be of
interest on this mailing list and myfaces dev list too.

In theory, PostAddToViewEvent is used in this cases:

  • h:outputScript and h:outputStylesheet renderers uses it to relocate component
    resources to UIViewRoot facet "head" or "body" target (h:outputStylesheet by
    default to "head"). Note "head" and "body" facets are transient.
  • cc:insertChildren and cc:insertFacet, to relocate components to some place
    inside cc:implementation. The reason why we do that through a listener attached
    to PostAddToViewEvent is we need to take into account the case of nested
    composite components using cc:insertFacet/cc:insertChildren. Note when the
    component tree is built the first time, PostAddToViewEvent is propagated from
    root to nodes.
  • When Partial State Saving is enabled, it is necessary to attach a listener to
    PostAddToViewEvent/PreRemoveFromViewEvent, so if some user add/remove a
    component, we can keep track of those changes and save/restore the component
    tree properly, in other words, support component addition or removal
    programatically.

Now, the instants of time where PostAddToViewEvent is published are:

  • With Partial State Saving enabled
  • When the view is build at first time.
  • In a postback when the view is build but before the state of the component
    is restored.
  • With Partial State Saving disabled
  • When the view is build at first time.
  • In a postback when the view is "refreshed", because all component nodes are
    detached and attached to the tree. In other words, on render response phase,
    vdl.buildView is called and in this case facelets algorithm add all transient
    components (usually all html markup not saved), and to do that, it detach and
    attach all components to be in right order. This also has some other
    implications, like c:if tag depends on this to work correctly.

A developer that is not aware of this fact could think that PostAddToViewEvent
is called when the view is build.

This is true with PSS is enabled, but is not true when PSS is disabled. On this
topic:

[jsr-314-open] add component resources depending on the owner component state

It was described why PostAddToViewEvent cannot be used in that case. But let's
change a litte bit the problem. We have a custom component that creates some
other on PostAddToViewEvent and add it as a children. It should work but in fact
it only works when PSS is enabled, with PSS disabled that code will cause a
duplicate id exception. Of course, the developer can solve it with some effort
but the point is we are not consider the element of least surprise.

But this fact this is only the tip of the iceberg. In mojarra (this was already
fixed on myfaces), components relocated by cc:insertChildren or cc:insertFacet
does not have state when PSS is disabled, because when the view is "refreshed"
the components are created again, but facelets algorithm remove all components
with no bound to a facelet tag handler, and then the listeners attached to
PostAddToViewEvent relocates the new ones, so this effect is not notice at first
view.

Do you remember PostAddToViewEvent propagation ordering is important by
cc:insertChildren/cc:insertFacet? well, with PSS disabled, the ordering now is
from nodes to root, because all nodes are detached and attached from nodes to
root, so in myfaces we did something like this (I removed some non relevant code
to be more clear):

try
{
if (refreshTransientBuild)

{ context.setProcessingEvents(false); }

// populate UIViewRoot
_getFacelet(renderedViewId).apply(context, view);
}
finally
{
if (refreshTransientBuild)

{ context.setProcessingEvents(true); // When the facelet is applied, all components are removed and added from view, // but the difference resides in the ordering. Since the view is // being refreshed, if we don't do this manually, some tags like // cc:insertChildren or cc:insertFacet will not work correctly, because // we expect PostAddToViewEvent will be propagated from parent to child, and // facelets refreshing algorithm do the opposite. FaceletViewDeclarationLanguage._publishPreRemoveFromViewEvent(context, view); FaceletViewDeclarationLanguage._publishPostAddToViewEvent(context, view); }

}

In few words, disable event processing, and fire PostAddToViewEvent and
PreRemoveFromViewEvent in the expected order to build the tree correctly. If we
don't do this, h:outputScript and h:outputStylesheet will not work correctly
(remember that UIViewRoot "head" and "body" facets are transient, so if these
components are relocated, are in fact transient too). Also, care must be taken
to prevent the listener of programatic component addition/removal register
components on this time.

The conclusion based on this reasoning, it is clear the need of new event that
be specific for relocate components (keep it simple for christ sake!). This
event should be propagated for all components in the tree after the view is
build from root to nodes. It could be good to have some clearification about the
real intention of PostAddToViewEvent/PreRemoveFromViewEvent. Really, better
names for those events are
PostAddToComponentTreeEvent/PreRemoveFromComponentTreeEvent.

On this link:

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

attachment: MYFACES-2638-3.patch

I attached a proposal to fix this issue, based on myfaces code. The idea is
create a event called javax.faces.event.PostBuildRefreshViewEvent. This event
is quite different from the one proposed in:

[jsr-314-open] add component resources depending on the owner component state

because there is one case this one is not published: when partial state saving
is enabled and there is no call to vdl.buildView for refresh. I also notice that
there is no "inheritance" between events, that means, if I have two events and
one extends from the other and there is a listener attached to the parent, when
the child event is raised the listener is not notified.

h:outputScript, h:outputStylesheet, cc:insertChildren, cc:insertFacet needs to
attach its listeners to that event too, to give the chance to relocate their
related components correctly. The listener that track changes on the component
tree and mark them to be saved/restored fully does not need to listen this event.

PostAddToViewEvent/PreRemoveFromViewEvent should continue working as always,
the important here is disable event processing while we are refreshing the view.
The side effect is components added to the component tree when view is refreshed
(c:if case) will not receive that event.

If we want to avoid that side effect, the proposal is change
PostBuildRefreshViewEvent to PostBuildViewEvent, this one will be an event
specific for relocation and that one should be published after the view is
build, in other words, in the same place as we are doing
PostBuildRefreshViewEvent but for all cases, but that one requires remove
the register of the listeners to PostAddToViewEvent on h:outputScript and
related. Also, it is necessary to indicate in some way when publish
PostAddToViewEvent/PreRemoveFromViewEvent by facelets algorithm for
build/refresh view, because it is there where we have the knowledge about when
propagate it or not.

I think at this point it is clear the problem and the possible direction to
solve it.



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

P2 for 2.0 Rev a.

Comment by Ed Burns [ 24/May/10 ]

New behavior. Move to 2.1

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 01/Nov/10 ]

Fixed

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-768] Missing ID attributes Created: 15/Mar/10  Updated: 01/Aug/14  Resolved: 22/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

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

Operating System: All
Platform: All


Issuezilla Id: 768
Status Whiteboard:

changelog


 Description   

According to the final spec, the following JSF elements do not have ID
attributes, yet their older peers do. For consisentcy sakes, I believe that
they should also.

faces-config-orderingType
faces-config-absoluteOrderingType
faces-config-behaviorType
faces-config-client-behavior-rendererType



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

Important to fix.

Comment by Ed Burns [ 24/May/10 ]

move to Sheetal.

Comment by Ed Burns [ 07/Jun/10 ]

Take these back.

Comment by Ed Burns [ 11/Jun/10 ]

Asked Douglas Donahue about potential TCK impact.

Comment by Ed Burns [ 11/Jun/10 ]
  • add the id type="xsd:ID" attribute to the following complexType declarations

faces-config-orderingType
faces-config-ordering-orderingType
faces-config-absoluteOrderingType
faces-config-default-valueType
faces-config-from-view-idType
faces-config-client-behavior-rendererType
faces-config-behaviorType
faces-config-value-classType
faces-config-rendererType

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-762] Only short-circuit a non-faces request to render response if view metadata has no children Created: 06/Mar/10  Updated: 01/Aug/14  Resolved: 08/Jun/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Bug Priority: Critical
Reporter: mojavelinux Assignee: Ed Burns
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 22 hours, 11 minutes
Time Spent: 1 hour, 49 minutes
Original Estimate: 1 day
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Zip Archive JAVASERVERFACES_SPEC_PUBLIC-762.zip    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-758 Support view actions that execute bef... Closed
Related
is related to JAVASERVERFACES-3118 Migrate test for spec issue 762 to te... Closed
Issuezilla Id: 762
Status Whiteboard:

size_medium importance_medium


 Description   

Currently, on an non-faces request, the Restore View short-circuits to the
Render Response if the view metadata contains no UIViewParameter children. The
exclusive check in this logic breaks the whole extensibility of the view
metadata feature.

Consider that a component author creates a custom component to be used in the
view metadata. Now, the page author has to add add least one (perhaps arbitrary)
UIViewParameter in the view metadata in order for view metadata to go through
the full JSF lifecycle, and the custom component activated, on an initial
request.

Here is the correct logic for the Restore View phase:

viewRoot = metadata.createMetadataView(facesContext);
// Only skip to render response if there are no child components
UIComponent metadataFacet = viewRoot.getFacet(UIViewRoot.METADATA_FACET_NAME);
if (metadataFacet.getChildCount() == 0) {
facesContext.renderResponse();
}

As a workaround, a component author could decorate the createMetadataView call
and add a artificial UIViewParameter if other children are present (though
setting it up would require a lot of work).



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

Move to 2.1

Comment by Ed Burns [ 22/Jun/10 ]

sheetalv

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 08/Jun/11 ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/lifecycle/RestoreViewPhase.java
Sending jsf-ri/systest/build-tests.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces/regression/i_spec_762
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces/regression/i_spec_762/Issue762PhaseListener.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/java/com/sun/faces/regression/i_spec_762/UserBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-762/i_spec_762_war/src/main/webapp/main.xhtml
Sending jsf-test/build.xml
Transmitting file data ..........
Committed revision 9143.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-750] <f:ajax> onevent attribute calls javascript function 3 times Created: 19/Feb/10  Updated: 01/Aug/14  Resolved: 15/May/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

Type: Bug Priority: Critical
Reporter: adriaaaaan Assignee: javaserverfowner
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 750
Status Whiteboard:

cat1


 Description   

Using this simple test case using latest Mojarra

<h:form>
<h:commandButton type="button">
<f:ajax onevent="toggleWorkflow"/>
</h:commandButton>
<script type="text/javascript">
function toggleWorkflow()

{ alert("nooooooo"); }

;
</script>
</h:form>

toggleWorkflow is called 3 times, producing 3 javascript alerts. I have tried
every combination of command button params, all produce the same effect



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat1. This may be an impl issue.

Comment by Ed Burns [ 16/Mar/10 ]

Filed under

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1585

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-745] Type of #{cc.attrs.test} cannot be obtained if test resolves to null Created: 15/Feb/10  Updated: 01/Aug/14  Resolved: 10/Aug/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: EL
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Critical
Reporter: Jakob Korherr Assignee: Ed Burns
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: 1 day, 19 hours
Time Spent: 5 hours
Original Estimate: 2 days
Environment:

Operating System: All
Platform: All


Attachments: Text File 20110720_i_spec_745.patch     Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt    
Issuezilla Id: 745
Status Whiteboard:

cat1 frame size_small importance_medium


 Description   

On a facelets composite component the type of a ValueExpression like
#

{cc.attrs.test}

cannot be obtained if the property test resolves to null,
because #

{cc.attrs} resolves to a Map and thus the MapELResolver is used to
determine the type. However this resolver can only determine the type if the
value is not null.

This can lead to problems with composite components with EditableValueHolders on
the first request (when the property in the managed bean is null).

You can test this with the mojarra sample "switchlistComponent.xhtml" by setting
the properties list1 and list2 in the managed bean SwitchlistBean from String[]
to List<String>. This sample currently only works because mojarra uses a
String[] as the value type of a h:selectManyMenu if the type of the
ValueExpression resolves to null. When you change the property type to
List<String> you will get a ClassCastException.

You won't see this problem if you're using the code from the composite component
implementation directly in your view, because then you will get the right type
from the ValueExpression even though it resolves to null and so everything will
work fine. Therefore this issue is problematic, because it is not easy to track
down.

However the solution to it is very simple. Just change the method getType() from
CompositeComponentELResolver to be aware of the base which is the wrapper for
the composite's attributes (#{cc.attrs}

) and use getExpression((String)
property).getType() to determine the right type in that case.

Please take a look at the related MyFaces issue MYFACES-2552. I already provided
a very simple patch to solve this problem.



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 18/May/10 ]

Move to P2

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

I looked at MYFACES 2552 and it looks like a decent fix, however, it's a behavior change, so we need to
move it to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 20/Jul/11 ]

Here is the stacktrace Jakob mentions.

javax.faces.component.UpdateModelException: java.lang.IllegalArgumentException: Cannot convert [Ljava.lang.String;@7096f3 of type class [Ljava.lang.String; to interface java.util.List
at javax.faces.component.UIInput.updateModel(UIInput.java:853)
at javax.faces.component.UIInput.processUpdates(UIInput.java:735)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1242)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1242)
at javax.faces.component.UIForm.processUpdates(UIForm.java:281)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1242)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1242)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:1228)
at com.sun.faces.lifecycle.UpdateModelValuesPhase.execute(UpdateModelValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:635)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.IllegalArgumentException: Cannot convert [Ljava.lang.String;@7096f3 of type class [Ljava.lang.String; to interface java.util.List
at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:397)
at com.sun.el.parser.AstValue.setValue(AstValue.java:194)
at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:286)
at com.sun.faces.facelets.el.TagValueExpression.setValue(TagValueExpression.java:131)
at com.sun.faces.el.CompositeComponentAttributesELResolver$ExpressionEvalMap.put(CompositeComponentAttributesELResolver.java:365)
at com.sun.faces.el.CompositeComponentAttributesELResolver$ExpressionEvalMap.put(CompositeComponentAttributesELResolver.java:287)
at javax.el.MapELResolver.setValue(MapELResolver.java:262)
at com.sun.faces.el.DemuxCompositeELResolver._setValue(DemuxCompositeELResolver.java:255)
at com.sun.faces.el.DemuxCompositeELResolver.setValue(DemuxCompositeELResolver.java:281)
at com.sun.el.parser.AstValue.setValue(AstValue.java:197)
at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:286)
at com.sun.faces.facelets.el.ContextualCompositeValueExpression.setValue(ContextualCompositeValueExpression.java:170)
at com.sun.faces.facelets.el.TagValueExpression.setValue(TagValueExpression.java:131)
at javax.faces.component.UIInput.updateModel(UIInput.java:818)

Comment by Ed Burns [ 20/Jul/11 ]

This patch has extra code in it that tries to inspect the collection or array to determine the type of the inner object. This is not necessary, but I wanted to save it here for reference.

Comment by Ed Burns [ 20/Jul/11 ]

Ready for review

Comment by Ed Burns [ 20/Jul/11 ]

Spec frame document changes.

Sending preface.fm
Sending valueReferences.fm
Transmitting file data ..
Committed revision 1022.

Comment by lu4242 [ 20/Jul/11 ]

I think a better solution could be use the information on javax.faces.component.BEANINFO_KEY. In this way, the value declared in cc:attribute "type" property could be used instead try to evaluate the ValueExpression to derive the final type. Note the change proposed here requires change the spec, in the part that describe the Composite Component EL Resolver.

Comment by Ed Burns [ 20/Jul/11 ]

Thanks for the suggestion, but I would like a solution that works even when the <cc:interface> is empty or non-existent. You do bring up a good point, though. We have duplicate sources of metadata: 1. <cc:interface> and 2. the Java language type of the EL Expression itself.

Comment by Ed Burns [ 20/Jul/11 ]

changebundle with test

Comment by Ed Burns [ 20/Jul/11 ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/el/CompositeComponentAttributesELResolver.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/JavaTopLevelComponent.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/UserBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc.xhtml
Sending jsf-test/build.xml
Transmitting file data .........
Committed revision 9210.

Comment by lu4242 [ 20/Jul/11 ]

Ok. I was thinking on "... if 'type' was declared on cc:attribute return this value, otherwise ...". It is just add the check for cc:attribute type throught javax.faces.component.BEANINFO_KEY and if no type set, try the code you proposed. It has sense, because the definition of cc:interface has precedence over the metadata in the EL Expression.

Comment by Matt Benson [ 20/Jul/11 ]

Confirm that this commit fixes the breakages I've seen with myfaces-extval bean validation attempting to validate strings instead of converted types for values of UIInput cc children with e.g. value="#

{cc.attrs.value}

". Leo's suggestion would also seem to have merit, though I might consult the EL first in case it yields a more specific type than that configured on the cc attribute declaration.

Comment by lu4242 [ 21/Jul/11 ]

Yes, but note the javadoc of ValueExpression says this about getType() :

"... Evaluates the expression relative to the provided context, and returns the most general type that is acceptable for an object to be passed as the value parameter in a future call to the setValue(javax.el.ELContext, java.lang.Object) method.

This is not always the same as getValue().getClass(). For example, in the case of an expression that references an array element, the getType method will return the element type of the array, which might be a superclass of the type of the actual element that is currently in the specified array element. ..."

Following Unified EL spec, the value declared on 'type' property should be used. It is more, if the property is defined on the component class, the code should check the associated PropertyDescriptor and return the type based on that.

Comment by Ed Burns [ 21/Jul/11 ]

Ahh, I see what you are suggesting now, Leonardo. I am re-opening this to add in your additional suggestion. It is a good performance boost.

Comment by Matt Benson [ 21/Jul/11 ]

I am no longer sure where the discussion rests. The current implementation (and hence, the proposed specification) merely looks for a valueExpression associated with a given attribute, and if it finds it, defers to valueExpression.getType(). It is then the responsibility of the available EL implementation to do the right thing by that valueExpression. If there is no such valueExpression, it would seem proper to attempt to return the declared type of the composite:attribute. This way e.g. a component that required that attribute 'foo' resolve to an instance of Foo could be used with 'foo' set to a valueExpression e.g. #

{fooOwner.fooSubclassInstance}

. The subclass type should then be read from the bean metadata of FooOwner by the base EL implementation and returned from the composite component attributes ELResolver. In practice it would seem that this would be the path oftenest taken; if a component's value is set to something other than a direct child of the attributes map, it follows that it is most likely e.g. #

{cc.attrs.someObject.someProperty}

in which case getValue(), rather than getType(), would be invoked against the composite component attributes ELResolver, and would have no bearing on this discussion. Can we all agree here?

Comment by lu4242 [ 21/Jul/11 ]

I think that if there is a declared type on cc:attribute, it has precedence, because it always will be the "most general" type and comply with the javadoc of getType. If it is not declared, and there is another ValueExpression, delegate.

This change on the spec implies ExpressionEvalMap should be resolved by CompositeComponentELResolver, instead MapELResolver (just like with flash scope).

In theory #

{cc.attrs.test}

and #

{cc.attrs.someObject.someProperty}

are different cases. CompositeComponentELResolver should provide proper code to deal with this, but anyway cc metadata has precedence over VE delegation.

Comment by Matt Benson [ 21/Jul/11 ]

Okay, so we are indeed, as I feared, in precise disagreement. My position: I presume that the EL has a better chance of returning a more specific type and thus when ELResolver.getType() is used e.g. in converter selection, preferring the EL-deduced type has a better chance of converting to a value that can actually be assigned to the appropriate place in the object graph. Note that pulling from the final type of a "redirected" ValueExpression can also be interpreted as being the "most general" type (that can be assigned to the position represented by the given ValueExpression). My aim in this conversation is to yield the specification that requires the least amount of configuration to do the right thing, and I believe that preferring the result of valueExpression.getType to composite:attribute @type is the best way to accomplish this.

Comment by lu4242 [ 21/Jul/11 ]

Ok, now I understand you intention. The problem is see is the EL expression becomes dependant of the value it holds.

Usually expressions using cc.attrs are inside <cc:implementation>, and the attribute expressions are on the location where the composite component is used, right?. In theory the one who evaluates the expression is a "detail" inside <cc:implementation> or the composite component class itself. Let's put it in code:

On the page:

<xx:myCC property1="#

{some.expression}">

On the composite component (xx:myCC)
<cc:interface>
<cc:attribute name="property1" type="java.lang.Collection"/>
</cc:interface>
<cc:implementation>
<jj:doSomething with="#{cc.attrs.property1}"/>
</cc:implementation>

Now suppose property1 #{some.expression}

is bound to a List (I don't know if generics works in this case). if getType() is called for #

{cc.attrs.property1}, what should it return? what should we expect? The composite component developer expect java.lang.Collection, but if we delegate before consider cc:attribute "type", the is not warrant about which type will be returned.

The component that has the reference to #{cc.attrs.property1}

should handle by default java.lang.Collection, because is the "most general" type. If the component do something for java.util.List, it should always call getValue() first. Look this fragment from MyFaces code (it is used by h:selectManyXXX components):

org.apache.myfaces.shared.renderkit.RendererUtils

public static Converter findUISelectManyConverter(FacesContext facesContext,
UISelectMany component, boolean considerValueType)

// .... some code here .... //

// Try to get the type from the actual value or,
// if value == null, obtain the type from the ValueExpression
Class<?> valueType = null;
Object value = ve.getValue(facesContext.getELContext());
valueType = (value != null)
? value.getClass()
: ve.getType(facesContext.getELContext());

This is the use case I'm considering. So, in practice ve.getType() will not be called unless ve.getValue is null.

From other point of view, what happens if setValue is called for "cc.attr" expression? This is an extract from tomahawk:

_SerializableDataModel dm = (_SerializableDataModel) qdm;
Class type = (getValueType() == null) ?
vb.getType(context.getELContext()) :
ClassUtils.simpleClassForName(getValueType());
Class dmType = dm.getClass();
if (DataModel.class.isAssignableFrom(type))

{ vb.setValue(context.getELContext(), dm); }

here getType is called to find the "most general" type, to call later vb.setValue correctly. This is another valid usage, but here we can see the inconsistency if we call delegate first, because a "less general" type will be returned and that could cause an exception.

Comment by lu4242 [ 21/Jul/11 ]

On behalf of Hanspeter Dünnenberger:

I kind of support your view: if we compare the cc:interface section with a Java Interface declaration then we clearly define the expected type on parameters of methods defined in the interface. If we allow any type on a parameter in a Java interface, it must be of type Object - that would be the same as if we would not specify the type in a cc:attribute definition, because then the expected type only depends on the currently passed in expression/value.

What I mean, if expected type is defined as in
<cc:attribute name="property1" type="java.util.Collection" />,
then from the view of an interface definition I can assume that the expected type of that parameter indeed must be java.util.Collection.

Comment by Matt Benson [ 21/Jul/11 ]

Answers inline:

Ok, now I understand you intention. The problem is see is the EL expression becomes dependant of the value it holds.

Usually expressions using cc.attrs are inside <cc:implementation>, and the attribute expressions are on the location where the composite component is used, right?. In theory the one who evaluates the expression is a "detail" inside <cc:implementation> or the composite component class itself. Let's put it in code:

On the page:

<xx:myCC property1="#

Unknown macro: {some.expression}

">

On the composite component (xx:myCC)
<cc:interface>
<cc:attribute name="property1" type="java.lang.Collection"/>
</cc:interface>
<cc:implementation>
<jj:doSomething with="#

Unknown macro: {cc.attrs.property1}

"/>
</cc:implementation>

Now suppose property1 #

is bound to a List (I don't know if generics works in this case).

I doubt it. I wish that were not the case, and I suspect a determined EL implementation could handle this to whatever degree possible, but that's another discussion.

if getType() is called for #

Unknown macro: {cc.attrs.property1}

, what should it return? what should we expect? The composite component developer expect java.lang.Collection, but if we delegate before consider cc:attribute "type", the is not warrant about which type will be returned.

I would rather assert that this is a separate check that should be done; presumably one of the main purposes the @type can be specified on a cc's attribute is so that ELs used in its implementation can confidently refer to properties/methods per the API of type. The use case for calling ValueExpression.getType() with which I am concerned relates to getting the correct converter for a UIInput component, if at all possible without the facelets view author having to set it explicitly; I don't know offhand what other situations might require one to search for the type.

The component that has the reference to #

Unknown macro: {cc.attrs.property1}

should handle by default java.lang.Collection, because is the "most general" type. If the component do something for java.util.List, it should always call getValue() first. Look this fragment from MyFaces code (it is used by h:selectManyXXX components):

org.apache.myfaces.shared.renderkit.RendererUtils

public static Converter findUISelectManyConverter(FacesContext facesContext,
UISelectMany component, boolean considerValueType)

// .... some code here .... //

// Try to get the type from the actual value or,
// if value == null, obtain the type from the ValueExpression
Class<?> valueType = null;
Object value = ve.getValue(facesContext.getELContext());
valueType = (value != null)
? value.getClass()
: ve.getType(facesContext.getELContext());

This is the use case I'm considering. So, in practice ve.getType() will not be called unless ve.getValue is null.

In fact MyFaces cannot handle the equivalent case on e.g. an HtmlInputText instance whose value is e.g. {{#

{cc.attrs.value}

}} precisely because the cc attributes ELResolver doesn't defer to the valueExpression. The fact that something special has to be done for UISelectMany+ only proves that something is missing at a more basic level. I would argue that the EL spec provides mechanisms for resolving type for the express purpose of avoiding consultations of actual values wherever possible. I could contrive an example using subclasses and explicitly registered converters for both superclass and subclasses to show how relying on the current value of some expression is suboptimal, but as I said it would be a contrived example.

From other point of view, what happens if setValue is called for "cc.attr" expression? This is an extract from tomahawk:

_SerializableDataModel dm = (_SerializableDataModel) qdm;
Class type = (getValueType() == null) ?
vb.getType(context.getELContext()) :
ClassUtils.simpleClassForName(getValueType());
Class dmType = dm.getClass();
if (DataModel.class.isAssignableFrom(type))

Unknown macro: { vb.setValue(context.getELContext(), dm); }

here getType is called to find the "most general" type, to call later vb.setValue correctly. This is another valid usage, but here we can see the inconsistency if we call delegate first, because a "less general" type will be returned and that could cause an exception.

Maybe I'm not seeing enough code here. How could returning a narrower type cause an exception in this case? It is being used as an argument to Class.isAssignableFrom(). A narrower class should be just as assignable as any of its ancestor types.

On behalf of Hanspeter Dünnenberger:

I kind of support your view: if we compare the cc:interface section with a Java Interface declaration then we clearly define the expected type on parameters of methods defined in the interface. If we allow any type on a parameter in a Java interface, it must be of type Object - that would be the same as if we would not specify the type in a cc:attribute definition, because then the expected type only depends on the currently passed in expression/value.

What I mean, if expected type is defined as in
<cc:attribute name="property1" type="java.util.Collection" />,
then from the view of an interface definition I can assume that the expected type of that parameter indeed must be java.util.Collection.

True, but what if the using page has {{<xx:myCC property1="#

{someBean.someList}

" />}}, we have converters registered for both Collection and List, and Collection defaults to creating a Set? The collections hierarchy isn't necessarily the example I'd have used, but it seems evident to me that the attribute @type will always be as-wide-as-or-wider-than the type of the valueExpression, if present.

Comment by Ed Burns [ 21/Jul/11 ]

Another iteration. This one takes Matt Benson's advice and only consults the composite component metadata if a value cannot be determined from the EL.

Unless Leonardo and Hanspeter can provide an example where this approach is harmful, I'd like to resolve it this way.

Thanks for your help.

Comment by Ed Burns [ 21/Jul/11 ]

Committed to trunk:

Sending jsf-ri/src/main/java/com/sun/faces/el/CompositeComponentAttributesELResolver.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/build.xml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/JavaTopLevelComponent.java
Deleting jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_1.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_2.xhtml
Deleting jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_1.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_2.xhtml
Transmitting file data .......
Committed revision 9211.

Committed to trunk:

Sending valueReferences.fm
Transmitting file data .
Committed revision 1024.

Comment by lu4242 [ 22/Jul/11 ]

After review the discussion, I agree that it is clear the examples known where getType() is called does not suppose a problem or cause side effects, even if it does not follow the EL javadoc related to the method or could suppose theorically a transgression to some object oriented principle. So in conclusion, is more convenient to delegate always and fallback to composite component metadata when it cannot be resolved. Thanks to you for dedicate time to fix this issue.

Comment by Ed Burns [ 22/Jul/11 ]

Latest and hopefully final iteration.

Comment by Ed Burns [ 22/Jul/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/el/CompositeComponentAttributesELResolver.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/composite/AttributeHandler.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/build.xml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/JavaTopLevelComponent.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/UserBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_3.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_4.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_3.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_4.xhtml
Transmitting file data ..........
Committed revision 9212.

Comment by Ed Burns [ 22/Jul/11 ]

Sending preface.fm
Sending userInterfaceComponentModel.fm
Sending valueReferences.fm
Transmitting file data ...
Committed revision 1025.

Comment by Ed Burns [ 22/Jul/11 ]

r9212 broke automated tests.

Reverting until they are fixed.

Comment by Ed Burns [ 22/Jul/11 ]

Reverted 9212.

Sending jsf-ri/src/main/java/com/sun/faces/el/CompositeComponentAttributesELResolver.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/composite/AttributeHandler.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/build.xml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/JavaTopLevelComponent.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/UserBean.java
Deleting jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_3.xhtml
Deleting jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_4.xhtml
Deleting jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_3.xhtml
Deleting jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_4.xhtml
Transmitting file data ......
Committed revision 9213.

Comment by Matt Benson [ 22/Jul/11 ]

From my analysis the major final effect of r9212 was to use RT value class for values actually stored in the map, which I didn't think was necessary at this level. AFAICT the only situation not covered by the code as it now stands is when a ValueExpression points to a position in the graph whose type is wider than any configured attribute @type. This will hopefully be a rare enough situation that pointing users to valueHolder/editableValueHolder will be sufficient (i.e. purposely require a strongly-typed graph for best type, and thereby converter, resolution). If this turns out to be absolutely unacceptable, the idea of comparing assignability of @type vs. type-of-valueExpression could be revisited (at a recognized runtime cost). This could be done as a configurable implementation-specific option, even.

Comment by Ed Burns [ 25/Jul/11 ]

Second resolution attempt.

Sending jsf-ri/src/main/java/com/sun/faces/el/CompositeComponentAttributesELResolver.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/composite/AttributeHandler.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/composite/PropertyHandlerManager.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/CompositeComponentTagHandler.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/build.xml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/JavaTopLevelComponent.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/UserBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_3.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_4.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_3.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_4.xhtml
Transmitting file data .......
Committed revision 9218.

Comment by Ed Burns [ 28/Jul/11 ]

Test help.
Sending common/ant/common.xml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/pom.xml
Sending lib/jsf-extensions-test-time.jar
Transmitting file data ...
Committed revision 9236.

Comment by Matt Benson [ 29/Jul/11 ]

After further discussion, making a case that the actual value assigned to an attribute of a composite component should never be taken into account, as this may precipitate conflicts with the stated purpose of ELResolver.getType() to return the "most general type" that is acceptable as the value argument to ELResolver.setValue(). For example, if an attribute is declared as being of type Animal but currently holds an instance of Dog, this does not mean that an instance of Cat would not be an equally valid setValue() value argument. This results in a greatly simplified specification for the getType() method of the Composite Component Attributes ELResolver, so much so that the following enhancement is included in this changebundle:

When a value expression of a given attribute points to a position whose type is assignable from the type declared on the composite component attribute's metadata, the metadata-declared type is therefore narrower and should be respected. This has the unfortunate drawback of requiring that the metadata be consulted in all cases including those in which a value expression can be found attached to a given attribute, but as the overall solution remains less complex than the HEAD of svn trunk, it is provided here anyway.

Comment by Matt Benson [ 29/Jul/11 ]

Also, I neglected to mention that my attempt at a revision of the related spec is included in the provided changebundle, under the "New Files" section at the end of the document. However, in this wording I realize that I forgot to mention explicitly that ELContext.setPropertyResolved(true) should be called prior to returning a metadata-derived type.

Comment by Matt Benson [ 04/Aug/11 ]

update to tests: rename *string attributes *literal and exercise typedXliteral using type="java.lang.Integer" per suggestion of Imre Oßwald

Comment by Ed Burns [ 09/Aug/11 ]

New patch from Matt and Imre.

Comment by Ed Burns [ 10/Aug/11 ]

Sending jsf-ri/src/main/java/com/sun/faces/el/CompositeComponentAttributesELResolver.java
Sending jsf-ri/test/com/sun/faces/application/resource/TestResourceHandlerImpl.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/GetTestType.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/JavaTopLevelComponent.java
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/java/com/sun/faces/regression/i_spec_745_war/UserBean.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_1.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_2.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_3.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/i_spec_745_4.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_1.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_2.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_3.xhtml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-745/i_spec_745_war/src/main/webapp/resources/ezcomp/i_spec_745_cc_4.xhtml
Transmitting file data ................
Committed revision 9246.
committed to trunk.

Comment by Ed Burns [ 10/Aug/11 ]

Sending preface.fm
Sending valueReferences.fm
Transmitting file data ..
Committed revision 1026.

Rhombus:frame edburns$ cat changebundle.txt
Further tweaks and optimizations http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745

SECTION: Modified Files
----------------------------
M valueReferences.fm

  • New spec for getType().

If the base argument to getType() is not an instance of the composite
component attributes map or the property argument to getType() is not
an instance of java.lang.String, return null. Otherwise, check the
top level component's ValueExpression collection for an expression
under the name given by the property argument to getType(). If the
expression exists, call getType() on the expression. If the property
argument to getType() is not empty, search the composite component's
metadata for a declared type on a <composite:attribute> whose name
matches the property argument to getType(). If the expression and the
metadata both yield results, the metadata takes precedence ONLY if it
provides a narrower result than does the expression, i.e. expression
type is assignable from metadata type. If the metadata result does
take precedence, call ELContext.setPropertyResolved(true). Otherwise,
return whichever result was available, or null.

M preface.fm

  • point to new changes.
Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-712] f:event TagDoc does not match what the Spec (PDF) says Created: 31/Dec/09  Updated: 01/Aug/14  Resolved: 22/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

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

Operating System: All
Platform: All


Issuezilla Id: 712
Status Whiteboard:

cat1 frame vdldoc changelog


 Description   

Check this:
http://java.sun.com/javaee/javaserverfaces/2.0/docs/pdldocs/facelets/f/event.html

it talks about "name" attribute, but the spec talks about type (so do the most
blogs). Section 3.4.3.4:

Declarative Listener Registration
Page authors can subscribe to events using the <f:event/> tag. This tag will
allow the application developer to specify the
method to be called when the specifed event fires for the component of which the
tag is a child. The tag usage is as
follows:
The type attribute specifies the type of event, and can be any of the
specification-defined events or one of any userdefined
events, but must be a ComponentSystemEvent, using either the short-hand name for
the event or the fullyqualified
class name (e.g., com.foo.app.event.CustomEvent). If the event can not be found, a
FacesException listing the offending event type will be thrown. Please see the
tlddocs for the <f:event /> tag
for the normative specification of the declarative event feature.
The method signature for the MethodExpression pointed to by the listener
attribute must match the signature of
javax.faces.event.ComponentSystemEventListener.processEvent().



 Comments   
Comment by mwessendorf [ 31/Dec/09 ]

Also, I wonder where in the spec these "short-cuts" are specified:

-preRenderComponent
-PostAddToView
-preValidate
-postValidate

the spec "only" says this about it =>
<quote>
using either the short-hand name for the event or the fullyqualified
class name (e.g., com.foo.app.event.CustomEvent).
</quote>

Not sure why the TAG_DOC only contains four short-hand names. There are more
events, like "PreRenderViewEvent" ...

Also, the list of the short-cuts is inconsistent. Most start with a low
character, but PostAddToView starts with a capital one....

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

vdl

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 ]

Move to P2.

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

Fix checked in.

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-683] Form serialization should happen at the last possible second Created: 02/Dec/09  Updated: 01/Aug/14  Resolved: 20/Sep/10

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

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

Operating System: All
Platform: All


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

size_medium importance_large

Tags: changelog_2_1

 Description   

Form serialization should happen at the last possible second - just before the
begin event happens.

There was wide agreement within the Ajax EG on this, and it probably only
requires a spec clarification. Hence, the P2 Priority.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by Ed Burns [ 24/Feb/10 ]

Jim targeted this at 2.1, so I prefer to leave it that way. Also, it fails the Bill test.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 13/Sep/10 ]

target MS6

Comment by rogerk [ 20/Sep/10 ]

Ok - for this I've specified in the jsdocs:

"Form serialization should occur just before the request is sent to minimize
the amount of time between the creation of the serialized form data and the
sending of the serialized form data (in the case of long requests in the queue)."

Comment by rogerk [ 20/Sep/10 ]

Created an attachment (id=287)
Changes

Comment by rogerk [ 20/Sep/10 ]

Checked in.

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-657] New API for JSF environment Created: 27/Oct/09  Updated: 01/Aug/14  Resolved: 15/May/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 2.1

Type: Improvement Priority: Critical
Reporter: Jan-Kees van Andel Assignee: javaserverfowner
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 657
Status Whiteboard:

cat2


 Description   

It might be useful to define a class/interface in the API to determine if
certain "features" are available in the current JSF environment (the JVM).

When developing Bean Validation support in MyFaces 2.0, I needed to check if
Bean Validation and Unified EL are available, so I created an utility for this
(for performance, I only perform the check @startup).

But the issue with my implementation is that the checks are used in multiple
packages (currently "component" and "validate"), making a package-private class
impossible. Public is also impossible because of TCK issues.

A generic, standardized API might be useful here. For example:
public interface FacesEnvironment {
public boolean isBeanValidationAvailable();
public boolean isUnifiedELAvailable();
public boolean isWebBeansAvailable();
// public boolean isSomethingElseAvailable();
}

This would eliminate the need for code duplication. And it might even be a
useful API for 3th party vendors to interact with.

And (just thinking out of the box), it might even make testing easier because
you can turn certain features off by providing a mock implementation of this
interface.

See this link for the original discussion on the subject:
http://www.mail-archive.com/dev@myfaces.apache.org/msg41153.html

/Jan-Kees



 Comments   
Comment by mwessendorf [ 27/Oct/09 ]

maybe just some (simple) utility class would be good?

i personally feel that this would be great. For all:
-(jsf) implementors
-3rd party / extension vendors
-application developers

suggested package => javax.faces.application

Comment by Jan-Kees van Andel [ 28/Oct/09 ]

+1 on the package

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

cat2

      • This issue has been marked as a duplicate of 669 ***
Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-656] tlddocs for f:viewParam missing name attribute Created: 22/Oct/09  Updated: 01/Aug/14  Resolved: 22/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.0 Rev a

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

Operating System: All
Platform: Macintosh


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

cat1 vdldoc changelog


 Description   

See <http://www.netbeans.org/issues/show_bug.cgi?id=174945>.



 Comments   
Comment by Ed Burns [ 22/Oct/09 ]

There are actually two errors here.

1. JSP should not have f:viewParam.

2. the Facelet taglibrary docs should have a name attribute for f:viewParam

Comment by Ed Burns [ 22/Oct/09 ]

Issue: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=656

SECTION: Modified Files
----------------------------
M jsf-ri/conf/share/facelets_jsf_core.tld

  • add required name attribute to f:viewParam

M jsf-ri/conf/share/jsf_core.tld

  • remove f:viewParam. Not relevant for JSP

SECTION: Diffs
----------------------------
Index: jsf-ri/conf/share/facelets_jsf_core.tld
===============================================================
====
— jsf-ri/conf/share/facelets_jsf_core.tld (revision 8095)
+++ jsf-ri/conf/share/facelets_jsf_core.tld (working copy)
@@ -1147,6 +1147,18 @@
</attribute>
<attribute>
<description>
+ Name of the parameter to be created.
+ </description>
+ <name>name</name>
+ <required>
+ true
+ </required>
+ <deferred-value>
+ <type>java.lang.String</type>
+ </deferred-value>
+ </attribute>
+ <attribute>
+ <description>
<![CDATA[<p>

MethodExpression representing a value change listener method
Index: jsf-ri/conf/share/jsf_core.tld
===============================================================
====
— jsf-ri/conf/share/jsf_core.tld (revision 8095)
+++ jsf-ri/conf/share/jsf_core.tld (working copy)
@@ -575,228 +575,6 @@

</tag>

  • <tag>
  • <description><![CDATA[
    -
  • <p class="changed_added_2_0">Used inside of the metada facet
  • of a view, this tag causes a <a target="_"
  • href="../../../javadocs/javax/faces/component/UIViewParameter.html">UIViewParameter</a>
  • to be attached as metadata for the current view. Because
  • <code>UIViewParameter</code> extends <code>UIInput</code>
  • all of the attributes and nested child content for any
  • <code>UIInput</code> tags are valid on this tag as well.</p>
    -
  • ]]></description>
  • <name>viewParam</name>
  • <tag-class>com.sun.faces.taglib.jsf_core.ParameterTag</tag-class>
  • <body-content>JSP</body-content>
    -
  • <attribute>
  • <description>
  • <![CDATA[Converter instance registered with this component.]]>
  • </description>
  • <name>
  • converter
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-value>
  • <type>
  • javax.faces.convert.Converter
  • </type>
  • </deferred-value>
  • </attribute>
  • <attribute>
  • <description>
  • <![CDATA[A ValueExpression enabled attribute that, if present, will be
  • used as the text of the converter message, replacing any message
  • that comes from the converter.]]>
  • </description>
  • <name>
  • converterMessage
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-value>
  • <type>
  • java.lang.String
  • </type>
  • </deferred-value>
  • </attribute>
  • <attribute>
  • <description>
  • <![CDATA[The component identifier for this component. This value must be
  • unique within the closest parent component that is a naming
  • container.]]>
  • </description>
  • <name>
  • id
  • </name>
  • <required>
  • false
  • </required>
  • <rtexprvalue>
  • true
  • </rtexprvalue>
  • </attribute>
  • <attribute>
  • <description>
  • <![CDATA[Flag indicating that the user is required to provide a submitted
  • value for this input component.]]>
  • </description>
  • <name>
  • required
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-value>
  • <type>
  • boolean
  • </type>
  • </deferred-value>
  • </attribute>
  • <attribute>
  • <description>
  • <![CDATA[A ValueExpression enabled attribute that, if present, will be
  • used as the text of the validation message for the "required"
  • facility, if the "required" facility is used.]]>
  • </description>
  • <name>
  • requiredMessage
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-value>
  • <type>
  • java.lang.String
  • </type>
  • </deferred-value>
  • </attribute>
  • <attribute>
  • <description>
  • <![CDATA[MethodExpression representing a validator method that will be called
  • during Process Validations to perform correctness checks on the
  • value of this component. The expression must evaluate to a public
  • method that takes FacesContext, UIComponent, and Object parameters,
  • with a return type of void.]]>
  • </description>
  • <name>
  • validator
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-method>
  • <method-signature>
  • void validate(javax.faces.context.FacesContext, javax.faces.component.UIComponent,
    java.lang.Object)
  • </method-signature>
  • </deferred-method>
  • </attribute>
  • <attribute>
  • <description>
  • <![CDATA[A ValueExpression enabled attribute that, if present, will be
  • used as the text of the validator message, replacing any
  • message that comes from the validator.]]>
  • </description>
  • <name>
  • validatorMessage
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-value>
  • <type>
  • java.lang.String
  • </type>
  • </deferred-value>
  • </attribute>
  • <attribute>
  • <description>
  • <![CDATA[The current value of this component.]]>
  • </description>
  • <name>
  • value
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-value>
  • <type>
  • java.lang.Object
  • </type>
  • </deferred-value>
  • </attribute>
  • <attribute>
  • <description>
  • <![CDATA[<p>
  • MethodExpression representing a value change listener method
  • that will be notified when a new value has been set for this
  • input component. The expression must evaluate to a public
  • method that takes a <code>ValueChangeEvent</code> parameter,
  • with a return type of void, <span class="changed_added_2_0">or
  • to a public method that takes no arguments with a return type
  • of void. In the latter case, the method has no way of easily
  • knowing what the new value is, but this can be useful in cases
  • where a notification is needed that "this value
  • changed".</span>
  • </p>]]>
  • </description>
  • <name>
  • valueChangeListener
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-method>
  • <method-signature>
  • void valueChange(javax.faces.event.ValueChangeEvent)
  • </method-signature>
  • </deferred-method>
  • </attribute>
    -
  • <attribute>
  • <description>
  • <![CDATA[The maximum number of characters that may
  • be entered in this field.]]>
  • </description>
  • <name>
  • maxlength
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-value>
  • <type>
  • int
  • </type>
  • </deferred-value>
  • </attribute>
    -
  • <attribute>
  • <description>
  • The ValueExpression linking this component to a property in a backing bean
  • </description>
  • <name>
  • binding
  • </name>
  • <required>
  • false
  • </required>
  • <deferred-value>
  • <type>
  • javax.faces.component.UIComponent
  • </type>
  • </deferred-value>
  • </attribute>
    -
  • </tag>
    -
    <tag>

<description>

Comment by Ed Burns [ 22/Oct/09 ]

Fix checked in.

Comment by Ed Burns [ 23/Oct/09 ]

I had to revert the jsp portion of this change, which was to simply remove f:viewParam from the JSP
jsf_core.tld. Even though removing it is the correct thing to do, the TCK signature tests fail without that
tag. I have re-added it and will make a note in the MR changelog.

Comment by Ed Burns [ 28/Oct/09 ]

I'm going to re-open this to accomodate additional omissions.

Comment by Ed Burns [ 28/Oct/09 ]

Created an attachment (id=230)
Fix for 20091028 reopening.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 ]

Move to P2

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 28/May/10 ]

Fixed.

Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-344] The javadocs for UIData.invokeOnComponent() need to be clarified with respect to UIData-level facets Created: 24/Mar/08  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: 1.2

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

Operating System: All
Platform: All


Issuezilla Id: 344

 Description   

Please see Mojarra issue 718
(https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=718)



 Comments   
Comment by Ed Burns [ 24/Mar/08 ]

Index: UIData.java
===============================================================
====
RCS file: /cvs/javaserverfaces-sources/jsf-api/src/javax/faces/component/UIData.java,v
retrieving revision 1.82
retrieving revision 1.83
diff -u -r1.82 -r1.83
— UIData.java 26 Nov 2007 22:17:06 -0000 1.82
+++ UIData.java 24 Mar 2008 15:58:22 -0000 1.83
@@ -764,19 +764,28 @@
}

/**

  • * <p>Override behavior from {@link UIComponentBase#invokeOnComponent}

    to

  • * provide special care for positioning the data properly before finding the
  • * component and invoking the callback on it. If the argument
  • * <code>clientId</code> is equal to <code>this.getClientId()</code> simply
  • * invoke the <code>contextCallback</code>, passing the <code>context</code>
  • * argument and <b>this</b> as arguments, and return <code>true.</code>
  • * Otherwise, attempt to extract a rowIndex from the <code>clientId</code>.
  • * For example, if the argument <code>clientId</code> was
  • * <code>form:data:3:customerHeader</code> the rowIndex would be
  • * <code>3</code>. Let this value be called <code>newIndex</code>. The
  • * current rowIndex of this instance must be saved aside and restored before
  • * returning in all cases, regardless of the outcome of the search or if any
  • * exceptions are thrown in the process.</p>
    + * <p>Override behavior from {@link + * UIComponentBase#invokeOnComponent}

    to provide special care for
    + * positioning the data properly before finding the component and
    + * invoking the callback on it. If the argument
    + * <code>clientId</code> is equal to <code>this.getClientId()</code>
    + * simply invoke the <code>contextCallback</code>, passing the
    + * <code>context</code> argument and <b>this</b> as arguments, and
    + * return <code>true.</code> If the argument <code>clientId</code>
    + * is not equal to <code>this.getClientId()</code>, inspect each of
    + * the facet children of this <code>UIData</code> instance and for
    + * each one, compare its <code>clientId</code> with the argument
    + * <code>clientId</code>. If there is a match, invoke the
    + * <code>contextCallback</code>, passing the <code>context</code>
    + * argument and <b>this</b> as arguments, and return
    + * <code>true</code>. Otherwise, attempt to extract a rowIndex from
    + * the <code>clientId</code>. For example, if the argument
    + * <code>clientId</code> was <code>form:data:3:customerHeader</code>
    + * the rowIndex would be <code>3</code>. Let this value be called
    + * <code>newIndex</code>. The current rowIndex of this instance must
    + * be saved aside and restored before returning in all cases,
    + * regardless of the outcome of the search or if any exceptions are
    + * thrown in the process.</p>

  • <p>The implementation of this method must never return <code>true</code>
  • if setting the rowIndex of this instance to be equal to
Comment by Ed Burns [ 09/Apr/08 ]

Javadoc fix checked in. Re-assigning to Ryan Lubke for impl and verification.

Comment by Ryan Lubke [ 09/Apr/08 ]

Impl changes were added prior to the logging of this issue.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-327] UIInput.resetValue() is wrong Created: 18/Jan/08  Updated: 01/Aug/14  Resolved: 24/Nov/09

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 2.0

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

Operating System: All
Platform: All


Issuezilla Id: 327
Status Whiteboard:

EGTop5 effort_moderate


 Description   

the resetValue() method was added directly to UIInput, instead to a
proper interface (EditableValueHolder).
I guess this was done, to not break impls of that interface.

It should have been added to the interface to start with as it simplifies many
loops used for reseting EditableValueHolder of the whole tree. You cannot use
instanceof UIInput for those as Trinidad input components, for example, does not
extends UIInput, but does implement EditableValueHolder

IMO this is wrong and should (at least in JSF2) be part of the
EditableValueHolder interface.

Since JSF2 will bring much more new bits, such an "enhancement" on the
interface might be valueable.



 Comments   
Comment by mwessendorf [ 21/Aug/08 ]

please don't add a EditableValueHolder2

Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by mwessendorf [ 30/Aug/08 ]

question: shouldn't validate() be on the EditableValueHolder interface as well ?

Comment by Ed Burns [ 02/Sep/08 ]

Matthias, I'm really sorry, but the only way I will allow this is by creating EditableValueHolder2. Don't
blame me for the lack of a practical solution to the fragile base class problem in Java.

Comment by Ed Burns [ 02/Sep/08 ]

Changing to EGTop5. Certainly not "easy".

Comment by Ed Burns [ 12/Sep/08 ]

effort_moderate

Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 29/Sep/08 ]

Fix checked in.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-270] StandardRenderKitAdditions Created: 01/Aug/07  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 1.2

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

Operating System: All
Platform: All


Issuezilla Id: 270

 Description   

Consider adding a small number of additional components to the standard renderkit.



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

>> 1) Date input
>> 2) Pagination control
>> 3) File upload
>> 4) Tab panel
>> 5) Tree
>> 6) Menu
>> 7) Repeater
>>

Comment by Ed Burns [ 01/Aug/07 ]

>>>>> On Tue, 24 Jul 2007 11:21:19 -0500, Gavin King <gavin@HIBERNATE.ORG> said:

>>
>> 1) Date input

GK> extremely complex!

GK> 2) Pagination control

GK> extremely complex!

GK> 3) File upload

GK> pretty complex to "do right"

GK> we could do something shitty if we wanted to stay simple

GK> 4) Tab panel

GK> complex

GK> 5) Tree

GK> very complex, but perhaps justifiable

GK> 6) Menu

GK> complex

GK> 7) Repeater

GK> simple

GK> I consider them essential to JSF.

GK> Of course they are essential to JSF. They are not, however, essential in the
GK> JSF spec.

Comment by Ed Burns [ 01/Aug/07 ]

>>>>> On Sat, 21 Jul 2007 08:56:40 +0200, Martin Marinschek
<mmarinschek@APACHE.ORG> said:

MM> 2) Pagination control

MM> It's easy to do this in whatever component library available, every
MM> component library has one - I don't think we need to bother. It would be

MM> 3) File upload

MM> Major pain in the neck with interoperability between libraries. Should be
MM> added to the spec because of this.

MM> 4) Tab panel

MM> Only server-side - simple to do. A general issue you have in

MM> 5) Tree

MM> I hate the 7+ different TreeModels out there. I'd love a standardized
MM> version of this (eventually with a standardized layout - but we'd come very
MM> far just specifying the model). But please: simple to use and easy to
MM> understand.

MM> 6) Menu

MM> A menu-model with a list-based standard layout: ok. A fancy drop-down menu
MM> with a lot of JavaScript: again no.

MM> 7) Repeater

MM> Simple to do, and a must. Something like t:dataList or ui:repeat needs to be
MM> in the spec.

Comment by Ed Burns [ 01/Aug/07 ]

>>>>> On Tue, 24 Jul 2007 10:23:16 -0700, Igor Shabalov <ishabalov@EXADEL.COM> said:

IS>
IS> Ajax-ified pagination itself is trivial. The real problem is missing
IS> TableDataModel, that supports row range (pagination), visitor pattern,
IS> primary keys, selection and sorting metadata. This must be the focus of
IS> our effort for new Repeat/DataTable.

Comment by driscoll [ 20/Aug/08 ]

Be decision of the EG, there will be no additional components done for JSF 2.0.

Any additional components could be done as a new, separate JSR, much like JSTL
for JSP. Or, there may be an opportunity to add components in a future
version of JSF.

Comment by Ed Burns [ 20/Aug/08 ]

Per 20080820 EG meeting, I am taking action on these issues.

Comment by Ed Burns [ 20/Aug/08 ]

Per 20080820 EG meeting, marking these as WONTFIX. In some cases, this means the issue was fixed
already, under another issue. In other cases, this means the issue is too vague to fix. In still other cases,
this means the EG deemed that the issue isn't appropriate for fixing.

If you strongly disagree with this resolution, please contact jsr-314-comments@jcp.org.

Comment by driscoll [ 21/Aug/08 ]

It's not that we won't fix it (which is the current status), it's that we're
probably going to fix it later - I'm changing the status to reflect that.

Comment by driscoll [ 21/Aug/08 ]

It's not that we won't fix it (which is the current status), it's that we're
probably going to fix it later - I'm changing the status to reflect that.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-266] h:message "for" attribute is mis-specified Created: 29/Jun/07  Updated: 01/Aug/14  Resolved: 21/Jun/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 1.2
Fix Version/s: 2.0 Rev a

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 266
Status Whiteboard:

EGEasy5 cat1 vdldoc changelog


 Description   

The Javadoc for UIMessage and TLDDOC for h:message describes it as one that takes a clientId. This was
never the intent - this should always have been a relative ID, exactly as in h:outputLabel. As specified,
h:message is incredibly difficult to use. IMO, this is an errata, not a spec change, though for backwards
compatibility I'd recommend continuing to look for messages in addition as if "for" were for clientIds.

FYI, the MyFaces implementation matches the original intent and user expectation.



 Comments   
Comment by Ed Burns [ 20/Aug/08 ]
      • Issue 292 has been marked as a duplicate of this issue. ***
Comment by rogerk [ 25/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 23/Sep/08 ]

target 2.0

Comment by Ed Burns [ 28/Jul/09 ]

Still not fixed. Sorry.

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 mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.0 Rev a and specify subcomponent

Comment by Ed Burns [ 03/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

vdldoc

Comment by Ed Burns [ 02/May/10 ]

Fixed

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by rogerk [ 21/Jun/10 ]

changelog

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-261] FactoryFinder may not work as expected in certain configurations Created: 21/May/07  Updated: 01/Aug/14  Resolved: 24/Nov/09

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: 2.0

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

Operating System: All
Platform: All


Issuezilla Id: 261
Status Whiteboard:

EGEasy5


 Description   

The JSF’s FactoryFinder is described in section 10.2.6.1 of the JSF 1.2
Specification.

In this section we can read:

….

Once the name of the factory implementation class is located, the web
application class

loader for the calling application is requested to load this class, and a
corresponding instance

of the class will be created. A side effect of this rule is that each web
application will receive

its own instance of each factory class, whether the JavaServer Faces
implementation is

included within the web application or is made visible through the container's
facilities for

shared libraries.

public static Object getFactory(String factoryName);

Create (if necessary) and return a per-web-application instance of the appropriate

implementation class for the specified JavaServer Faces factory class, based on
the discovery

algorithm described above.

…..

The problem with this is that FactoryFinder relays on the fact that each web
module bundled in a JEE Application will posses its own class loader. This class
loader is later used as index of the web module factories. Neither javaee-5.0
specification nor servlet-2.5 specification states that each web module MUST
have separate class loader. For instance consider the text in SRV.9.7.2 Web
Application Class Loader from the servlet-2.5 specification.

See JSF RI issue 359 [1]

[1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=359



 Comments   
Comment by rogerk [ 25/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 23/Sep/08 ]

target 2.0

Comment by Ed Burns [ 22/Jan/09 ]

PROBLEM STATEMENT
=================

Consider a container with two webapps, appA and appB. appA bundles a
FacesContextFactory into WEB-INF/lib. appB does not. The problem is,
due to the lack of a strict requrirement that each webapp must have its
own classloader (the fact that it delegates to the system classloader is
irrelevent here), does cause the following behavior in SAP's container.
appB will see appA's FacesContextFactory, and furthermore, appA can
"release" that factory, messing up appB, or vice-versa.

REASON FOR PROBLEM
==================

Our FactoryFinder impl uses the ClassLoader obtained by the following
code.

private static ClassLoader getClassLoader() throws FacesException {

ClassLoader cl = Thread.currentThread().getContextClassLoader();
if (cl == null)

{ throw new FacesException("getContextClassLoader"); }

return (cl);

}

Our FactoryFinder impl makes the assumption that calling the above
getClassLoader() will return a different instance in every webapp
running in a container. We need to make this assumption because our
FactoryFinder uses this ClassLoader in two ways:

1. "the normal way" to cause a class to be loaded and instantiated.

clazz = Class.forName(implName, false, getClassLoader());
getCtorArg = new Class[1];
getCtorArg[0] = factoryClass;
ctor = clazz.getConstructor(getCtorArg);
newInstanceArgs[0] = previousImpl;
result = ctor.newInstance(newInstanceArgs);

2. as a key in a VM-wide (that is, static final variable) data structure
where the value is a FactoryManager instance. The FactoryManager
actually stores the name->factory instance mappings.

factories = applicationMap.putIfAbsent(getClassLoader(),
new FactoryManager());

If appA and appB share the same physical ClassLoader instance (as in
SAP's container) you get the problem.

Comment by Ed Burns [ 22/Jan/09 ]

I suggest we add text similar to the following to Servlet 3.0 section 10.7.2. At the end of the
paragraph, add

"The implementation must guarantee that every web application deployed in a container makes it so a
call to Thread.currentThread().getContextClassLoader() returns a ClassLoader instance that implements
the contract specified in this section. Furthermore, the ClassLoader instance must be a separate
instance for each deployed web application."

If it's not possible to add this text, then adding a method to ServletContext would work:

public static ServletContext getCurrentInstancte();

This would use ThreadLocal storage to return the current ServletContext instance. It must be valid to
call this instance from the very beginning of the web application's lifetime. JSF would then use this
instance as the key in its map (from the previous comment) instead of the context ClassLoader.

Comment by Ed Burns [ 28/Jul/09 ]

Verified this is in Servlet 3.0 PFD section 10.7.2.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-243] ScopedAttributeELResolver.getValue() behavior, as spec'd, is incorrrect. Created: 13/Feb/07  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 1.2
Fix Version/s: 1.2

Type: Bug Priority: Critical
Reporter: Ryan Lubke Assignee: javaserverfowner
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 243

 Description   

Section 5.6.2.7 for getValue() states that setPropertyResolved() should only be
set to true if an attribute was found in one of the scopes. It should be set to
true even if it wasn't found as technically, this ELResolver handles 'property',
it just happened to resolve to null.

See https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=506



 Comments   
Comment by Ed Burns [ 15/Oct/08 ]

fixed

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

Move all to 1.2

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-234] BP issue 4968985 called for spec edits that were never made Created: 08/Jan/07  Updated: 01/Aug/14  Resolved: 04/Mar/10

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 1.2

Type: Bug Priority: Critical
Reporter: Ryan Lubke Assignee: javaserverfowner
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: