<< Back to previous view

[MAVEN2_REPOSITORY-17] Mojarra (JSF) Created: 03/Mar/11  Updated: 11/May/11

Status: Open
Project: maven2-repository
Component/s: migration-cleanup
Affects Version/s: None
Fix Version/s: None

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

File Attachments: XML File jsf-api-pom-template.xml     XML File jsf-impl-pom-template.xml    
Issue Links:
Dependency
depends on MAVEN2_REPOSITORY-13 JSP maven artifacts cleanup and migra... Open
depends on MAVEN2_REPOSITORY-14 EL maven artifacts cleanup and migration Open
depends on MAVEN2_REPOSITORY-15 JSTL maven artifacts cleanup and migr... Open
Tags:
Participants: Ed Burns, janey, juven and rogerk

 Description   

================
JSF 2.0.x
================
Group Id: com.sun.faces
Artifact Id: { jsf-api jsf-impl }

Version: 2.0.x

================
JSF 2.1.x
================
Group Id: com.sun.faces
Artifact Id: { jsf-api jsf-impl }
}

Version: 2.1.x



 Comments   
Comment by rogerk [ 03/Mar/11 01:26 PM ]

Pom templates we use.

Comment by rogerk [ 03/Mar/11 01:27 PM ]

Project URL: http://java.net/projects/mojarra

Comment by Ed Burns [ 04/Mar/11 09:17 AM ]

Looks great. Thanks for taking the initiative on this, Roger.

Comment by juven [ 15/Mar/11 12:13 AM ]

it depends on javax.servlet.jsp:jsp-api

Comment by juven [ 15/Mar/11 12:14 AM ]

it depends on javax.el:el-api

Comment by juven [ 15/Mar/11 12:15 AM ]

it depends on JSTL

Comment by juven [ 15/Mar/11 12:17 AM ]

missing javadoc.jar

Comment by janey [ 10/May/11 10:48 AM ]

Please provide me access to deploy to the new java.net Maven repository. My java.net id is janey.

Comment by juven [ 11/May/11 02:18 AM ]

Configuration has been prepared, now you can:

would you please help follow the doc [1] and try deployment a SNAPSHOT, I want to know if the credential mapping w/ project id works.

[1] http://java.net/projects/maven2-repository/pages/MigrationAndCleanupRelatedDocumentation#Publish_Snapshots





[JSP-18] Add setExpressionFactory method to JspApplicationContextImpl Class Created: 10/Jan/11  Updated: 10/Jan/11  Resolved: 10/Jan/11

Status: Resolved
Project: jsp
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Tags: 3_1-review
Participants: kchung and rogerk

 Description   

Add setExpressionFactory method to JspApplicationContextImpl



 Comments   
Comment by kchung [ 10/Jan/11 10:03 AM ]

1. How bad is its impact? (Severity)

This change is needed to pass the weld tck tests.

2. How often does it happen? Will many users see this problem? (Frequency)

Without this change, an important functionality in weld will not work. All users will be affected.

3. How much effort is required to fix it? (Cost)

The effort is minimal: only need to add a new method to an implementation class.

misto:runtime%svn diff
Index: JspApplicationContextImpl.java
===================================================================
— JspApplicationContextImpl.java (revision 1347)
+++ JspApplicationContextImpl.java (working copy)
@@ -110,6 +110,10 @@
return expressionFactory;
}

+ public void setExpressionFactory(ExpressionFactory expressionFactory) { + this.expressionFactory = expressionFactory; + }
+
public void addELContextListener(ELContextListener listener) { listeners.add(listener); }

4. What is the risk of fixing it and how will the risk be mitigated? (Risk)

Risk is also minimal. Adding a new method would not affect existing running codes.

Comment by kchung [ 10/Jan/11 05:22 PM ]

Fixed in jsp in revision 1348.
Integrated into glassfish 3.1 in revision 44380.





[JSF_EXTENSIONS-90] Ensure scripts in replacement markup are evaluated prior to postReplace, when appropriate Created: 26/Mar/08  Updated: 29/May/13  Resolved: 29/May/13

Status: Closed
Project: jsf-extensions
Component/s: runtime
Affects Version/s: current
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: autozoom Assignee: Ed Burns
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 90
Tags:
Participants: autozoom, Ed Burns, mattbohm and rogerk

 Description   

if you set the postreplace attribute of an Ajax transaction, the function
receives incorrect call parameters:

<?xml version="1.0" encoding="UTF-8"?>
<!--
Document : Page1
Created on : 26-mar-2008, 15.56.38
Author : mauro
-->
<jsp:root version="2.1" xmlns:df="http://java.sun.com/jsf/dynamicfaces"
xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html"
xmlns:jsp="http://java.sun.com/JSP/Page"
xmlns:webuijsf="http://www.sun.com/webui/webuijsf">
<jsp:directive.page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"/>
<f:view>
<webuijsf:page binding="#{Page1.page1}" id="page1">
<webuijsf:html binding="#{Page1.html1}" id="html1">
<webuijsf:head id="head1">
<webuijsf:link binding="#{Page1.link1}" id="link1"
url="/resources/stylesheet.css"/>
<df:ajaxTransaction binding="#{Page1.tx1}" id="tx1"
inputs="page1:html1:body1:form1:button1" postReplace="pr"
render="page1:html1:body1:form1:staticText1"/>
<webuijsf:script id="script1">
function pr(a,b,c) { alert(a + " " + b + " " + c); }
</webuijsf:script>
</webuijsf:head>
<webuijsf:body id="body1" style="-rave-layout: grid">
<webuijsf:form id="form1">
<webuijsf:staticText binding="#{Page1.staticText1}"
id="staticText1" style="position: absolute; left: 444px; top: 108px"
text="provaaaaaaaaa"/>
<webuijsf:button
actionExpression="#{Page1.button1_action}" id="button1"
onClick="DynaFaces.Tx.fire('tx1');return false;"
style="height: 36px; left: 72px; top: 108px;
position: absolute; width: 107px" text="Button"/>
</webuijsf:form>
</webuijsf:body>
</webuijsf:html>
</webuijsf:page>
</f:view>
</jsp:root>

whatever the button action handler does, the javascript function named pr()
receives the 1st and 3rd parameters as null or undefined, making it impossible
to use it



 Comments   
Comment by rogerk [ 26/Mar/08 12:00 PM ]

Taking ownership

Comment by rogerk [ 26/Mar/08 01:17 PM ]

I'm not familiar with how thw Woodstock components encapsulate the underlying
Dynamic Faces javascript apis and..
I haven't used the postReplace function myself but the documentation states:

postReplace

The name of a globally scoped function that conforms to the following signature.

function postReplace(ajaxZone, innerHTML, [closure], [xjson]);

This function is called after the markup replacement for each component that
needs to be re-rendered with data from this ajax response. The optional argument
closure is whatever was passed as the closure option to the
DynaFaces.fireAjaxTransaction or DynaFaces.installDeferredAjaxTransaction that
initiated the ajax request for this response. The optional argument xjson is
whatever was passed as the xjson option to the DynaFaces.fireAjaxTransaction or
DynaFaces.installDeferredAjaxTransaction that initiated the ajax request for
this response. The xjson agrument is passed to the server and may have been
modified by the server.
----------------------------

An example usage of this in dynamic faces is the jmaki integration.
Take a look under:
jsf-extensions/trunk/code/run-time/samples/jmaki/src/main/webapp
Take a look at:
mainColumn.jsp
devtime.js

devtime.js has a postReplace function:

function postReplace(ajaxZone, innerHTML) {
var isJmaki;
if ((isJmaki = (-1 != ajaxZone.id.indexOf("form:table")))) { jmaki.clearWidgets(); }
innerHTML.evalScripts();
if (isJmaki) { window.onload(); }
}

Seems like the args to your function should be "ajaxZone" and "innerHTML"

Comment by autozoom [ 27/Mar/08 01:49 AM ]

I read the documentation and it's pretty clear how it's supposed to work, but
it's not working with woodstock components, and woodstock team points me to JSF
extension website

Comment by rogerk [ 27/Mar/08 06:34 AM ]

Reassinging to Matt at his request.

Comment by mattbohm [ 27/Mar/08 03:22 PM ]

Because woodstock is heavily based on JavaScript, currently you must go a little
further in your application to ensure that the scripts of woodstock components
are evaluated prior to the invocation of your custom postReplace function.

I was able to resolve this by doing two things:

1. Manually replace the jsf-extensions-dynamic-faces-0.1.jar and
jsf-extensions-common-0.1.jar inside the dynamicfaces.complib (0.2) with the
versions of those jars used in woodstock. (If you are building netbeans from
sources, you can find those jars inside
visualweb.woodstock.webui.jsf/external/woodstock-components-4.2.zip.)

2. Specify a custom replace function, as shown below, calling markup.evalScripts
after DynaFaces.replace:

<?xml version="1.0" encoding="UTF-8"?>
<jsp:root version="2.1" xmlns:df="http://java.sun.com/jsf/dynamicfaces"
xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html"
xmlns:jsp="http://java.sun.com/JSP/Page"
xmlns:webuijsf="http://www.sun.com/webui/webuijsf">
<jsp:directive.page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"/>
<f:view>
<webuijsf:page id="page1">
<webuijsf:html id="html1">
<webuijsf:head debug="true" id="head1">
<webuijsf:link id="link1" url="/resources/stylesheet.css"/>
<df:ajaxTransaction id="tx1"
inputs="page1:html1:body1:form1:button1" postReplace="customPostReplace"
render="page1:html1:body1:form1:staticText1"
replaceElement="customReplace"/>
<webuijsf:script id="script1"><![CDATA[
function customPostReplace(element, markup, closure) {
alert(element + "|||" + markup + "|||" + closure);
}
function customReplace(id, markup) {
DynaFaces.replace(id, markup);
markup.evalScripts();
}
]]></webuijsf:script>
</webuijsf:head>
<webuijsf:body id="body1" style="-rave-layout: grid">
<webuijsf:form id="form1">
<webuijsf:staticText binding="#{Page1.staticText1}"
id="staticText1" style="position: absolute; left: 120px; top: 48px"/>
<webuijsf:button
actionExpression="#{Page1.button1_action}" id="button1"
onClick="DynaFaces.Tx.fire('tx1');return false;"
style="position: absolute; left: 120px; top: 96px"
text="Button"/>
<webuijsf:messageGroup id="messageGroup1"
style="position: absolute; left: 336px; top: 144px"/>
</webuijsf:form>
</webuijsf:body>
</webuijsf:html>
</webuijsf:page>
</f:view>
</jsp:root>

Now the element parameter passed in to customPostReplace is non-null.

The closure parameter passed in to customPostReplace is still unpopulated,
because we are not passing any closure to the DynaFaces.fireAjaxTransaction call
(see
https://jsf-extensions.dev.java.net/nonav/mvn/reference-ajax.html#DynaFaces.fireAjaxTransaction).
If you do want to use a closure, as, for instance, the Currency Trader sample
application does (it does so conditionally), you can specify a closure as
follows. The following appears in the poll function in currencytrader.js:

DynaFaces.Tx.config.pollTx.closure = ...;
...
DynaFaces.Tx.fire('pollTx');

You could emulate this technique, replacing occurrences of pollTx with the name
of your AjaxTransaction (for example, tx1). By doing so, the logic in
DynaFaces.Tx.fire will pass your closure in when it calls
DynaFaces.fireAjaxTransaction.

Marking as enhancement, to devise a cleaner way to ensure scripts embedded in
the replacement markup are evaluated prior to postReplace, but only when
appropriate.

Comment by autozoom [ 28/Mar/08 02:44 AM ]

Yes this way it works thanks, I think the trick is that we cannot use a custom
postreplace without using a custom replace at the same time.
This is the kind of samples and docs we need to effectively use the libraries.
thanks

Comment by Ed Burns [ 29/May/13 03:24 PM ]

I am no longer tracking progress of these projects on java.net.





[JSF_EXTENSIONS-88] ENCODING Problem -> javax.faces.request.charset Created: 14/Feb/08  Updated: 19/Feb/08  Resolved: 19/Feb/08

Status: Resolved
Project: jsf-extensions
Component/s: runtime
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: rogerk Assignee: jsf-extensions-issues
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


File Attachments: Text File a.txt    
Issuezilla Id: 88
Tags:
Participants: Ed Burns, jsf-extensions-issues and rogerk

 Description   

From the poster:

Date: Tue, 12 Jun 2007 08:35:15 +0200
From: Matthias Unverzagt <matthias.unverzagt@enpasos.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Subject: ENCODING Problem -> javax.faces.request.charset

I have a typical foreigner problem: It's about encoding.
I wrote a little VWP test application (on latest NB6, Glassfish V2): One
page, one textfield
and static text following Hong's simple ajax-zone example
(http://blogs.sun.com/honglu/entry/walking_through_creating_a_simple).
The idea is: You enter a character in the textfield, onkeydown you get
an ajax request that is responsible for putting the entered character on
the static text. However, I can not get the encoding work.

Switching on the NetBeans HTTP monitor I get

FIRST REQUEST OF THE PAGE
before the request:
javax.faces.request.charset = UTF-8
after the request:
javax.faces.request.charset = UTF-8

FIRST AJAX BASED REQUEST
before the request:
javax.faces.request.charset = UTF-8
after the request:
javax.faces.request.charset = ISO-8859-1

SUBSEQUENT AJAX REQUESTs
before the request:
javax.faces.request.charset = ISO-8859-1
after the request:
javax.faces.request.charset = ISO-8859-1

Any help, especially short-term workarounds are very much appreciated.

Thank you,

Matthias



 Comments   
Comment by rogerk [ 14/Feb/08 09:24 AM ]

It appears that this problem only occurs in JSP.
In Facelets, the problem does not occur.

Comment by rogerk [ 15/Feb/08 03:10 PM ]

The problem appears to be in AsyncResponse class.
Specifically in AsyncResponse.createAjaxResponseWriter method...

We use reflection to get the writer from the response object,
but the character encoding has not been set. So it defaults
to ISO-8859-1

Possible Fix:

1. get the last stored character encoding from the session
(identified by the key: ViewHandler.CHARACTER_ENCODING_KEY)
2. set that character encoding in the response using reflection.

So now the character encoding will be set on the response object before
we get the writer from it.

This fix appears to work.

Comment by rogerk [ 15/Feb/08 03:13 PM ]

Created an attachment (id=23)
Patch

Comment by Ed Burns [ 19/Feb/08 06:14 AM ]

r=edburns, looks great!

Comment by rogerk [ 19/Feb/08 10:53 AM ]

Checked in. Thanks for the second set of eyes on this one - Ryan.





[JSF_EXTENSIONS-82] fireAjaxTransaction for input text with null value problem Created: 17/Oct/07  Updated: 25/Nov/10

Status: Open
Project: jsf-extensions
Component/s: runtime
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: PC


Issue Links:
Dependency
blocks JSF_EXTENSIONS-84 fireAjaxTransaction for input type ch... Open
Issuezilla Id: 82
Tags:
Participants: rogerk and sjoglesby

 Description   

I have an input text component which is ajaxified using fireAjaxTransaction
wired into the onchange event. This works OK when a value is entered in the
input field. However, if I then try to blank out the value then it posts the
value as being 'x' (I can see this using Firebug). I would expect it to send an
empty string or nothing.



 Comments   
Comment by rogerk [ 17/Oct/07 08:57 AM ]

Can you please specify exactly what your fireAjaxTransaction command looks like
(cut and paste it)?

Comment by sjoglesby [ 18/Oct/07 03:30 AM ]

Here is the input that is doing the fireAjaxTransaction.

<input id="bodySubView:CreateSPS:outerPanel:j_id38:nominalInput" type="text"
name="bodySubView:CreateSPS:outerPanel:j_id38:nominalInput" value="x" cols="0"
onchange="DynaFaces.fireAjaxTransaction(this,
{execute: 'bodySubView:CreateSPS:outerPanel:j_id38:nominalInput', render: 'bodySubView:CreateSPS:outerPanel:j_id38:nominalInput,bodySubView:Create SPS:outerPanel:j_id38:nominalInputMessage', inputs: 'bodySubView:CreateSPS:outerPanel:j_id38:nominalInput,_uccId'});return
false;" rows="0"/>

I have managed to do some debugging and found that line 710 of
com_sun_faces_ajax.js is setting the value to x if it is an empty string and
the fireAjaxTransaction was invoked by that input. The line reads:

709 if (action && action.form) { 710 this[action.name] = action.value || 'x'; 711 }

I guess this sets it to a value for command buttons in order that you can tell
who fired the event?

Comment by sjoglesby [ 18/Oct/07 04:04 AM ]

Hi,
Just to be clear. If the current value is '500' and I then blank it out then it
gets posted as 'x'. It just happens that the current value is x because I have
been debugging and it keeps setting it to x.





[JSF_EXTENSIONS-81] DynaFaces.ViewState initialize function - collect Form Data Check Created: 26/Sep/07  Updated: 27/Sep/07  Resolved: 27/Sep/07

Status: Resolved
Project: jsf-extensions
Component/s: runtime
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


Issuezilla Id: 81
Tags:
Participants: Ed Burns and rogerk

 Description   

In com_sun_facesw_ajax.js:

DynaFaces.ViewState

initialize: function ....
...
if (('void' != collectPostDataType && 'undefined' != collectPostDataType) ||
('void' != inputsType && 'undefined' != collectPostDataType)) {
// Just get the state data.
...

I believe should be:

if (('void' != collectPostDataType && 'undefined' != collectPostDataType) ||
('void' != inputsType && 'undefined' != inputsType)) {
// Just get the state data.
...



 Comments   
Comment by Ed Burns [ 27/Sep/07 04:51 AM ]

Thanks for catching this. r=edburns. Please fix it on the HEAD.

Comment by rogerk [ 27/Sep/07 11:30 AM ]

Checked in mods:

Index: com_sun_faces_ajax-max.js
===================================================================
— com_sun_faces_ajax-max.js (revision 468)
+++ com_sun_faces_ajax-max.js (working copy)
@@ -505,7 +505,7 @@
var collectPostDataType = typeof this.options.collectPostData;
var inputsType = typeof this.options.inputs;
if (('void' != collectPostDataType && 'undefined' != collectPostDataType) ||

  • ('void' != inputsType && 'undefined' != collectPostDataType)) {
    + ('void' != inputsType && 'undefined' != inputsType)) {
    // Just get the state data.
    var viewState = DynaFaces.$(DynaFaces.gViewState);
    t = viewState.tagName.toLowerCase();
    @@ -661,7 +661,7 @@
    var collectPostDataType = typeof this.options.collectPostData;
    var inputsType = typeof this.options.inputs;
    if (('void' != collectPostDataType && 'undefined' != collectPostDataType) ||
  • ('void' != inputsType && 'undefined' != collectPostDataType)) {
    + ('void' != inputsType && 'undefined' != inputsType)) {
    // Just get the state data.
    var viewState = DynaFaces.$(DynaFaces.gViewState);
    t = viewState.tagName.toLowerCase();




[JSF_EXTENSIONS-75] NPE in AsyncResponse Created: 04/May/07  Updated: 05/May/07

Status: Open
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kenpaulsen Assignee: jsf-extensions-issues
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 75
Tags:
Participants: jsf-extensions-issues, kenpaulsen and rogerk

 Description   

A GlassFish user reported the exception below. It appears the response has been
completed and the FacesContext is no longer available. However, a finally block
after the request is trying to clean stuff up and throwing a NPE when attempting
to use a null FacesContext. See below the following exception for my proposed
solution (null check). If you'd like me to commit this change, assign the bug
to me and I'll check it in.

Thanks,

Ken

jsf.lifecycle.phase.exception
SEVERE
[javax.enterprise.resource.webcontainer.jsf.lifecycle]

.

StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet
FacesServlet threw

exception

java.lang.NullPointerException

at
com.sun.faces.extensions.avatar.lifecycle.AsyncResponse.getPartialTraversalViewRoot(AsyncResponse.java:831)

at
com.sun.faces.extensions.avatar.lifecycle.PartialTraversalLifecycle.execute(PartialTraversalLifecycle.java:83)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)

at
com.sun.enterprise.tools.admingui.servlet.DelayedInitFacesServlet.service(DelayedInitFacesServlet.java:66)

at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185)

at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:240)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:217)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185)

at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)

at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:258)

at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:189)

at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:611)

at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:564)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:81)

at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:193)

at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:611)

at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:564)

at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:558)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1067)

at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)

at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:611)

at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:564)

at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:558)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1067)

at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:255)

at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:618)

at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:549)

at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:790)

at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326)

at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:248)

at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:199)

at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)

at
com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103)

SEVERE [javax.enterprise.system.container.web]

Here's the proposed solution:

/**

  • Getter for property partialTraversalViewRoot.
  • @return Value of property partialTraversalViewRoot.
    */
    public PartialTraversalViewRoot getPartialTraversalViewRoot() {
    PartialTraversalViewRoot result = this.partialTraversalViewRoot;
    if (null == result) {
    FacesContext ctx = FacesContext.getCurrentInstance();
    if (ctx != null)
    Unknown macro: { UIViewRoot root = ctx.getViewRoot(); if (root instanceof PartialTraversalViewRoot) { result = (PartialTraversalViewRoot) root; } }

    }
    return result;
    }


 Comments   
Comment by rogerk [ 05/May/07 08:50 AM ]

r=rogerk





[JSF_EXTENSIONS-64] ajaxZone prevents form input Created: 21/Feb/07  Updated: 25/Nov/10

Status: Open
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


File Attachments: File sandbox.war    
Issue Links:
Dependency
blocks JSF_EXTENSIONS-63 nested CDATA sections in response Resolved
Issuezilla Id: 64
Tags:
Participants: iamnoah and rogerk

 Description   

Cannot type in input field (.war to be attached)

Backing Bean:

package sandbox;

public class TestBean {

private String name = "no name entered";

private String hello = "Hi!";

public String getName() { return name; }

public void setName(String name) { this.name = name; }

public String sayHello() { setHello("Hi " + name + "!"); return null; }

public String getHello() { return hello; }

private void setHello(String hello) { this.hello = hello; }

}



 Comments   
Comment by rogerk [ 21/Feb/07 05:49 PM ]

taking ownership

Comment by rogerk [ 21/Feb/07 05:51 PM ]

can you attach the war?

Comment by iamnoah [ 21/Feb/07 05:53 PM ]

Created an attachment (id=15)
WAR Demonstrating the problem

Comment by iamnoah [ 24/Feb/07 09:07 AM ]

Only seems to occur on Tomcat, possibly related to the jars being used. (see
issue 63)

Comment by iamnoah [ 27/Feb/07 08:52 AM ]

Update: Tabbing to the field works (instead of clicking), and first selecting
text also works. I'm guessing there is something attached to the onclick event
on the text field that is stealing the focus when it submits.

Oh, and I was mistaken in my last comment. Glassfish also seems to be affected
in the same way.

Stack:
rc2
JSF 1.2_03-b-09
Firefox 2.0.0.1
Kubuntu Linux 6.10





[JSF_EXTENSIONS-59] jsf-tictactoe doesn't operate via ajax Created: 09/Feb/07  Updated: 21/Feb/07  Resolved: 21/Feb/07

Status: Resolved
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: Sun


Issuezilla Id: 59
Tags:
Participants: Ed Burns, Rajiv Mordani and rogerk

 Description   
  • The transactions do not happen via Ajax.


 Comments   
Comment by rogerk [ 09/Feb/07 11:11 AM ]

Can you elaborate? I just ran it with a clean and up to date workspace with
firefox, and I don not see any "non ajax" transactions..
What browser are you seeing this behavior in?

Comment by Rajiv Mordani [ 21/Feb/07 04:40 PM ]

It works for me so I am marking this bug as fixed.

  • Rajiv




[JSF_EXTENSIONS-57] jsf-fire-ajax-transaction sample doesn't work with IE 7 Created: 08/Feb/07  Updated: 22/Feb/07  Resolved: 22/Feb/07

Status: Resolved
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: aditya_dada Assignee: jsf-extensions-issues
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 57
Tags:
Participants: aditya_dada, jsf-extensions-issues and rogerk

 Description   

Sample: jsf-fire-ajax-transaction
Issue: Sample doesn't work properly on IE 7
Error from console:
=================
Line: 207
Char: 2
Error: Could not set the innerHTML property. Invalid target element for this
operation.
Code: 0
URL: http://localhost:8080/jsf-fire-ajax-transaction/home.jsf
=================
I'm using promoted SDK b06 on windows xp.



 Comments   
Comment by rogerk [ 22/Feb/07 05:50 AM ]

This has been fixed. Please checkout the latest.





[JSF_EXTENSIONS-48] tictactoe sample not working properly Created: 12/Jan/07  Updated: 24/Jan/07  Resolved: 24/Jan/07

Status: Resolved
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: aditya_dada Assignee: jsf-extensions-issues
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 48
Tags:
Participants: aditya_dada, Ed Burns, jsf-extensions-issues and rogerk

 Description   

I'm using 12 Jan 07 nightly build for swdp on windows xp, and am trying to run
the tictactoe sample.

the deployment of the sample went fine on glassfish v2 milestone 3 build 28,
except the following warnings were echoed in the server log file.

After the deployment, I was able to access the url:
http://localhost:8080/jsf-tictactoe/home.jsf

However, I didn't see any change when I clicked the buttons.
Opening the firebug shows following errors:

=======[FireBug Console]====================
mismatched tag. Expected: </markup>. home.jsf (line 85)
</script></div>]]></markup></render></components><state><![CDATA[j_id1:j_id64]]></state></partial-response>
--^
anonymous com_sun_faces_aja... (line 634)
anonymous com_sun_faces_aja... (line 607)
anonymous prototype.js.jsf (line 68)
anonymous prototype.js.jsf (line 815)
anonymous prototype.js.jsf (line 774)
anonymous prototype.js.jsf (line 68)
anonymous firebug.js (line 951)
anonymous firebug.js (line 2049)


components has no properties com_sun_faces_aja... (line 634)


components has no properties com_sun_faces_aja... (line 634)

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

=====[ Server log warnings ] ====
[#|2007-01-12T12:38:20.119-0500|WARNING|sun-appserver-ee9.1|javax.enterprise.sys
tem.core|_ThreadID=12;_ThreadName=Timer-4;C:/sun/glassfish/domains/domain1\gener
ated\xml\j2ee-modules\WSTXServices;C:/sun/glassfish/lib/install/applications/wst
x-services;_RequestID=b31ff8ac-66df-422e-83ac-8c675576452a;|Failed to load deplo
yment descriptor files from directory: C:/sun/glassfish/domains/domain1\generate
d\xml\j2ee-modules\WSTXServices. Load them from directory : C:/sun/glassfish/lib
/install/applications/wstx-services instead.|#]

[#|2007-01-12T12:38:21.056-0500|INFO|sun-appserver-ee9.1|javax.enterprise.resour
ce.webcontainer.jsf.config|_ThreadID=12;_ThreadName=Timer-4;/adminconsole;|Initi
alizing Sun's JavaServer Faces implementation (1.2_03-b06-FCS) for context '/adm
inconsole'|#]

[#|2007-01-12T12:38:22.775-0500|INFO|sun-appserver-ee9.1|javax.enterprise.resour
ce.webcontainer.jsf.config|_ThreadID=12;_ThreadName=Timer-4;;|Initializing Sun's
JavaServer Faces implementation (1.2_03-b06-FCS) for context ''|#]

[#|2007-01-12T12:38:24.697-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@1c9ca1 doesn't support class com.sun.xml.ws.api.server.Module|#]

[#|2007-01-12T12:38:24.759-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@d5e4c7 doesn't support class com.sun.xml.ws.api.server.Module|#]

[#|2007-01-12T12:38:24.790-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@773f4b doesn't support class com.sun.xml.ws.api.server.Module|#]

[#|2007-01-12T12:38:24.915-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@527386 doesn't support class com.sun.xml.ws.api.server.Module|#]

[#|2007-01-12T12:38:24.962-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@149d226 doesn't support class com.sun.xml.ws.api.server.Module|#]

[#|2007-01-12T12:38:24.994-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@126c06b doesn't support class com.sun.xml.ws.api.server.Module|#]

[#|2007-01-12T12:38:25.040-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@225f0 doesn't support class com.sun.xml.ws.api.server.Module|#]

[#|2007-01-12T12:38:25.087-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@184747e doesn't support class com.sun.xml.ws.api.server.Module|#]

[#|2007-01-12T12:38:25.119-0500|WARNING|sun-appserver-ee9.1|com.sun.xml.ws.trans
port.http.servlet.ServletAdapter|_ThreadID=12;_ThreadName=Timer-4;_RequestID=b31
ff8ac-66df-422e-83ac-8c675576452a;|Container com.sun.enterprise.webservice.JAXWS
Container@c0e18b doesn't support class com.sun.xml.ws.api.server.Module|#]

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



 Comments   
Comment by rogerk [ 12/Jan/07 10:17 AM ]

try it oj glassfish v1.

Comment by Ed Burns [ 24/Jan/07 08:09 AM ]

Fixed. Author: rogerk





[JSF_EXTENSIONS-45] Change behavior of execute and render options Created: 11/Jan/07  Updated: 18/Jan/07

Status: Open
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: jsf-extensions-issues
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 45
Status Whiteboard:

target_r2

Tags:
Participants: Ed Burns, jsf-extensions-issues, mattbohm and rogerk

 Description   

The current specification for the "execute" and "render" options to
fireAjaxTrainsaction() is:

execute

Comma separated string containing a list of client ids against which
the execute portion of the request processing lifecycle must be
run. This is known as a "partial traversal". If the value of the
option is the single string "none" without the quotes, the execute
portion of the lifecycle will be effectively skipped. If this option
is not specified at all, the value of the render parameter is used
as the value of the option. If that is not specified, the entire
view is traversed during the execute portion of the request
proecssing lifecycle.

render

Comma separated string containing a list of client ids against which
the render portion of the request processing lifecycle must be
run. If not specified, the entire view is rendered. If the value of
the option is the single string "none" without the quotes, the
render portion of the lifecycle will be effectively skipped.

I propose we change the above specification as follows:

execute

Comma separated string containing a list of client ids. Each client
id in the list identifies a node in the server side View for the
current page. For each node in the list, the execute portion of the
request processing lifecycle will visit that node and its children
in the same traversal order as the usual non-Ajax lifecycle. If
this option is not specified the entire view is traversed.

execute

Comma separated string containing a list of client ids. Each client
id in the list identifies a node in the server side View for the
current page. For each node in the list, the render portion of the
request processing lifecycle will visit that node and its children
in the same traversal order as the usual non-Ajax lifecycle. If
this option is not specified the entire view is traversed.



 Comments   
Comment by rogerk [ 11/Jan/07 11:19 AM ]

+1

Make sure to update the sample apps (if needed).

Comment by mattbohm [ 16/Jan/07 01:53 PM ]

I believe the default for execute should not be the entire view but rather the
value of the inputs parameter. I have observed in my Currency Trader sample app
that executing over nodes whose input has not been submitted can cause problems.

I think we should make explicit in these descriptions that we are supporting the
"all" and "none" keywords.

Therefore I propose the following revision. (Note I've opted for the...is it
British?...comma-outside-the-quotes punctuation technique.)

inputs

Comma separated string containing a list of client ids of input
elements whose values are to be submitted to the server.
If the value of this option is the string "none", no input elements
are submitted.
If the value of this option is the string "all" or if this option
is not specified, the values of all input elements in the current form are
submitted.

execute

Comma separated string containing a list of client ids. Each client
id in the list identifies a node in the server side View for the
current page. For each node in the list, the execute portion of the
request processing lifecycle will visit that node and its children
in the same traversal order as the usual non-Ajax lifecycle.
If the value of this option is the string "none", the execute
portion of the lifecycle is effectively skipped.
If the value of this option is the string "all", the entire view is traversed.
If this option is not specified, the value of the inputs option is used.
If neither this option nor the inputs option is specified, the entire view
is traversed.

render

Comma separated string containing a list of client ids. Each client
id in the list identifies a node in the server side View for the
current page. For each node in the list, the render portion of the
request processing lifecycle will visit that node and its children
in the same traversal order as the usual non-Ajax lifecycle.
If the value of this option is the string "none", the render
portion of the lifecycle is effectively skipped.
If the value of this option is the string "all" or if this option
is not specified, the entire view is traversed.

Comment by Ed Burns [ 18/Jan/07 12:32 PM ]

target_r2





[JSF_EXTENSIONS-34] AjaxZone eventType Option Doesn't Work Created: 07/Dec/06  Updated: 07/Dec/06  Resolved: 07/Dec/06

Status: Resolved
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


File Attachments: Text File com_sun_faces_ajax_zone.js    
Issuezilla Id: 34
Tags:
Participants: Ed Burns and rogerk

 Description   

If I have a very simple page:

<jsfExt:ajaxZone id="zone1" eventType="onmouseover" action="..." >
<h:inputText id="text"/>
</jsfExt:ajaxZone>

The ajax request does not occur when the input text field is moused over...



 Comments   
Comment by rogerk [ 07/Dec/06 09:40 AM ]

Here is the fix:

Index: com_sun_faces_ajax_zone.js
===================================================================
— com_sun_faces_ajax_zone.js (revision 314)
+++ com_sun_faces_ajax_zone.js (working copy)
@@ -58,7 +58,7 @@
function moveAsideEventType(ajaxZone, element, options, getCallbackData) {
if (null != options.eventType) {
if('on' == options.eventType.substring(0,2)) { - options.eventType = eventType.substring(2); + options.eventType = options.eventType.substring(2); }
}
else {

Comment by rogerk [ 07/Dec/06 09:41 AM ]

Created an attachment (id=9)
attachment

Comment by Ed Burns [ 07/Dec/06 10:30 AM ]

r=edburns

Comment by rogerk [ 07/Dec/06 12:00 PM ]

Fix Committed.





[JSF_EXTENSIONS-33] Rename installDeferredAjaxTransaction Created: 07/Dec/06  Updated: 07/Dec/06

Status: Open
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: rogerk Assignee: jsf-extensions-issues
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 33
Tags:
Participants: jsf-extensions-issues and rogerk

 Description   

Please rename installDeferredAjaxTransaction to
deferredAjaxTransaction.
The name is too long as it is, and there is no need
for the 'install' portion. 'deferredAjaxTransaction'
is sufficient to describe the behavior of this method.






[JSF_EXTENSIONS-29] fireAjaxTransaction Problems Created: 02/Dec/06  Updated: 04/Dec/06  Resolved: 04/Dec/06

Status: Resolved
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


Issuezilla Id: 29
Tags:
Participants: agoria, Ed Burns and rogerk

 Description   

I've got a very simple page (and bean):

<h:form id="form">

<h1>DynaFaces.fireAjaxTransaction</h1>

<h:commandButton value="fire"
actionListener="#{bean.fire}"
onclick="DynaFaces.fireAjaxTransaction(this);"/>

<h:outputText value="Result:"/>
<h:outputText id="result" value="#{bean.result}"/>

</h:form>

Expectation is that whole view is refreshed via Ajax.
However, looks like Ajax transaction is not happening - looks like
form submit is happening.

Specifying the id of the output component as in:

fireAjaxTransaction(this), {render:result}...

makes no difference.



 Comments   
Comment by rogerk [ 02/Dec/06 07:49 PM ]

I've discovered that I was missing the return false;

So, the following works:

onclick="DynaFaces.fireAjaxTransaction(this);
return false;"/>

However, the following still does not appear to work:

<h:form id="form">

<h1>DynaFaces.fireAjaxTransaction</h1>

<h:outputText value="Result:"/>
<h:outputText id="result" value="#{bean.result}"/>

<h:commandButton value="fire"
actionListener="#{bean.fire}"
onclick="DynaFaces.fireAjaxTransaction(this,
{render:'result'}); return false;"/>

</h:form>

I can see the params being sent:

Content-Type: application/x-www-form-urlencoded
com.sun.faces.avatar.Partial: true
com.sun.faces.avatar.Render: result

But I don;t see the incremented value in the outputText.

Comment by agoria [ 03/Dec/06 09:13 AM ]

rogerk, I think you should provide the execute property:

render:'result', execute:'<button id>'.

In https://jsf-extensions.dev.java.net/issues/show_bug.cgi?id=23 I have already
pointed out that the execute property is not so natural and easy to remeber.
IMHO default execute value should be changed...

Comment by rogerk [ 03/Dec/06 09:35 AM ]

I was under the assumption that not specifying "execute" (just specifying
"render" in fireAjaxTransaction) would also do the "execute" portion of the
lifecycle.
So, the event hander was not getting called.
I'll get better clarification on this.

Comment by rogerk [ 03/Dec/06 11:12 AM ]

Actually, I'm finding that:

render:'result', execute:'<button id>' does not work.

However, qualifying with the parent (form id) works:

render:'form:result', execute:'<button id>'

Why do I have to qualify with the parent form id?

Comment by agoria [ 04/Dec/06 02:18 AM ]

Are you sure you was passing the right client id?

Usually I set prependId="false" on the form to avoid the long client id.





[JSF_EXTENSIONS-27] ajaxZone With commandButton Created: 30/Nov/06  Updated: 30/Nov/06  Resolved: 30/Nov/06

Status: Resolved
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


Issuezilla Id: 27
Tags:
Participants: Ed Burns and rogerk

 Description   

Including ajaxZone tags immediately around a commandButton does not send
proper "partial render" params. For example:

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib prefix="jsfExt" uri="http://java.sun.com/jsf/extensions/dynafaces" %>

<f:view>
<h:form id="form">
<jsfExt:ajaxZone id="zone2">
<h:commandButton id="_0" value="press me"
actionListener="#{game.select}"/>
</jsfExt:ajaxZone>
</h:form>
</f:view>

Does not send the proper partial render params.



 Comments   
Comment by Ed Burns [ 30/Nov/06 08:31 AM ]

edward-burns-powerbook-g4-15:~/Projects/J2EE/workareas/jsf-extensions-
trunk/code edburns$ svn diff run-time/avatar/src/main/java/com/sun/faces/
extensions/avatar/renderkit/AjaxZoneRenderer.java
Index: run-time/avatar/src/main/java/com/sun/faces/extensions/avatar/
renderkit/AjaxZoneRenderer.java
===================================================================
— run-time/avatar/src/main/java/com/sun/faces/extensions/avatar/
renderkit/AjaxZoneRenderer.java (revision 294)
+++ run-time/avatar/src/main/java/com/sun/faces/extensions/avatar/
renderkit/AjaxZoneRenderer.java (working copy)
@@ -39,6 +39,7 @@
import javax.el.MethodExpression;
import javax.el.ValueExpression;
import javax.faces.FacesException;
+import javax.faces.component.ActionSource;
import javax.faces.component.EditableValueHolder;

import javax.faces.component.UIComponent;
@@ -291,7 +292,8 @@
new Util.TreeTraversalCallback() {
public boolean takeActionOnNode(FacesContext context,
UIComponent curNode) throws FacesException {
boolean keepGoing = true;

  • if (curNode instanceof EditableValueHolder) {
    + if (curNode instanceof EditableValueHolder ||
    + curNode instanceof ActionSource) { keepGoing = false; }
    return keepGoing;
    edward-burns-powerbook-g4-15:~/Projects/J2EE/workareas/jsf-extensions-
    trunk/code edburns$
Comment by Ed Burns [ 30/Nov/06 08:31 AM ]

fix checked in.





[JSF_EXTENSIONS-24] AjaxZone With SelectOne Created: 24/Nov/06  Updated: 28/Nov/06  Resolved: 28/Nov/06

Status: Resolved
Project: jsf-extensions
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

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

Operating System: All
Platform: All


File Attachments: Text File cvslog.txt     GZip Archive rogerk-24.tar.gz    
Issuezilla Id: 24
Tags:
Participants: Ed Burns and rogerk

 Description   

I have a very simple jsp page:

<jsfExt:ajaxZone id="zone1">
<h:selectOneMenu id="menu" value="#{zoneBean.color}">
<f:selectItem itemValue="red" itemLabel="Red" />
<f:selectItem itemValue="blue" itemLabel="Blue" />
<f:selectItem itemValue="yellow" itemLabel="Yellow" />
</h:selectOneMenu>
</jsfExt:ajaxZone>

<jsfExt:ajaxZone id="zone2">
<h:outputText value="#{zoneBean.color}" />
</jsfExt:ajaxZone>

The managed bean sets a default color of "blue".

When the selectone component displays I see "blue"
displayed rom the outputText component.

However, when I select another color from the selectOne list,
say, "Red", the outputText still says "blue".

Subsequent selections appear to work - so it appears
to not work just on the selection.



 Comments   
Comment by Ed Burns [ 27/Nov/06 07:56 AM ]

Roger, thanks for reporting this. I'll look at it.

Comment by rogerk [ 28/Nov/06 07:04 AM ]

More Information:

This only seems to happen after a page refresh.
After a page refresh (either from the page displaying for the first time, or,
after a buttn press that redisplays the same page), it seems that only the first
ajaxZone is being sent as can be seen from this:

http://localhost:8080/ajaxzone1/home.jsf;jsessionid=2f15617856d005f1c5767a2fb88

POST /ajaxzone1/home.jsf;jsessionid=2f15617856d005f1c5767a2fb88 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20
061025 Firefox/1.5.0.8
Accept: text/javascript, text/html, application/xml, text/xml, /
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: close
X-Requested-With: XMLHttpRequest
X-Prototype-Version: 1.5.0_rc1
Content-Type: application/x-www-form-urlencoded
com.sun.faces.avatar.Partial: true
com.sun.faces.avatar.Render: form:zone1
Content-Length: 82
Cookie: JSESSIONID=2f15617856d005f1c5767a2fb88
Pragma: no-cache
Cache-Control: no-cache
options=%5Bobject%20Object%5D&javax.faces.ViewState=j_id1%3Aj_id2&form:menu=yell
ow
HTTP/1.x 200 OK
X-Powered-By: Servlet/2.5, JSF/1.2, JSP/2.1
Cache-Control: no-cache
Content-Type: text/xml;charset=ISO-8859-1
Content-Language: en-US
Date: Tue, 28 Nov 2006 15:01:34 GMT
Server: Sun Java System Application Server Platform Edition 9.0_01
Connection: close
----------------------------------------------------------

After subsequent choices from the selectOneMenu component, both zones are sent
correctly:

http://localhost:8080/ajaxzone1/home.jsf;jsessionid=2f15617856d005f1c5767a2fb88

POST /ajaxzone1/home.jsf;jsessionid=2f15617856d005f1c5767a2fb88 HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20
061025 Firefox/1.5.0.8
Accept: text/javascript, text/html, application/xml, text/xml, /
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: close
X-Requested-With: XMLHttpRequest
X-Prototype-Version: 1.5.0_rc1
Content-Type: application/x-www-form-urlencoded
com.sun.faces.avatar.Partial: true
com.sun.faces.avatar.Render: form:zone1,form:zone2
Content-Length: 79
Cookie: JSESSIONID=2f15617856d005f1c5767a2fb88
Pragma: no-cache
Cache-Control: no-cache
options=%5Bobject%20Object%5D&javax.faces.ViewState=j_id1%3Aj_id3&form:menu=red
HTTP/1.x 200 OK
X-Powered-By: Servlet/2.5, JSF/1.2, JSP/2.1
Cache-Control: no-cache
Content-Type: text/xml;charset=ISO-8859-1
Content-Language: en-US
Date: Tue, 28 Nov 2006 15:03:39 GMT
Server: Sun Java System Application Server Platform Edition 9.0_01
Connection: close
----------------------------------------------------------

Comment by Ed Burns [ 28/Nov/06 08:39 AM ]

Thanks for sharing the HTTP output.

Comment by Ed Burns [ 28/Nov/06 09:34 AM ]

Created an attachment (id=7)
Sample ware source

Comment by Ed Burns [ 28/Nov/06 09:34 AM ]

I can reproduce this. I have attached my sample war.

Comment by Ed Burns [ 28/Nov/06 09:42 AM ]

I have discovered the cause of the problem. It's a bug in com_sun_faces_ajaxZone.js. If you place zone2
before zone1 in the page, it works. This is because the zoneList isn't populated until it is encountered.

I'm working on a fix now.

Comment by Ed Burns [ 28/Nov/06 12:02 PM ]

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

Comment by rogerk [ 28/Nov/06 12:14 PM ]

r=rogerk

Comment by Ed Burns [ 28/Nov/06 12:15 PM ]

Fix checked in.





[JSFTEMPLATING-45] view handler throws NPE in createView method when viewId is null. Created: 10/Apr/11  Updated: 11/Apr/11  Resolved: 11/Apr/11

Status: Closed
Project: jsftemplating
Component/s: LayoutElements
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Bhavanishankar Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any


File Attachments: File jsftest.war     Text File server.log    
Issue Links:
Dependency
blocks GLASSFISH-16336 NPE in Embedded GlassFish while runni... Resolved
Tags:
Participants: Bhavanishankar and rogerk

 Description   

As per the API documentation of ViewHandler (http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/application/ViewHandler.html), createView method is NOT supposed throw NPE when viewId is null.

But the jsftemplating does not seem to be compliant with the specification. It throws NPE when createView(facesContext, null) is called.

The other view handler implementation in com.sun.faces:jsf-impl works fine with null viewId. So, it is evident that jsftemplating should also follow the specification.

I have attached a simple application for reproducing the issue. The application bundles jsftemplating.jar and has a Servlet that invokes viewHandler.createView(context, null); When the application is deployed and servlet is accessed, it results in NPE. (You can deploy to GlassFish and access http://localhost:8080/hellojsf/JSFTestServlet).

I have also attached the exception stack trace.



 Comments   
Comment by Bhavanishankar [ 10/Apr/11 11:16 PM ]

Test case and exception stack trace.

Comment by rogerk [ 11/Apr/11 10:01 AM ]

Thanks for the attachments - I'll take a look.

Comment by rogerk [ 11/Apr/11 10:56 AM ]

Hello. This is not a GlassFish bug. In addition, there is no one here that is supporting jsftemplating project. Your best bet is to file an issue in the jsftemplating project: http://java.net/jira/browse/JSFTEMPLATING
I am happy to hear that your application works in mojarra.





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

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

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

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

 Description   

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



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

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

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

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

Contribution From IceSoft





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

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

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

Tags:
Participants: rogerk

 Description   

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






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

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

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

Tags:
Participants: Ed Burns and rogerk

 Description   

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



 Comments   
Comment by Ed Burns [ 02/Oct/13 07:34 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1182] Implement new requirements for ViewState multi-form case in Ajax Created: 08/Nov/12  Updated: 17/Apr/13

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

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

Tags:
Participants: Ed Burns and rogerk

 Description   

Please contact Werner Punz if you need more explanations on how to test this.

>>>>> On Wed, 31 Oct 2012 09:35:34 -0700, Edward Burns <edward.burns@oracle.com> said:

EB> I added this sentence:

EB> * In
EB> * addition to the submitting form, all forms created by JSF
EB> * under the view root identified by
EB> * <code>VIEW_ROOT_CONTAINER_CLIENT_ID</code> must be
EB> * updated similarly.

This is in jsf.js.



 Comments   
Comment by Ed Burns [ 30/Jan/13 07:38 PM ]

Move to m10.

Comment by rogerk [ 13/Mar/13 04:05 PM ]

After talking with Werner Punz (EG member) we agreed that there were some unanswered issues that could not be addressed in time for 2.2.





[JAVASERVERFACES_SPEC_PUBLIC-1168] Make web-partialresponse_2_2.xsd w/r/t "Insert" Element Match Jsdocs. Created: 23/Feb/13  Updated: 27/Feb/13  Resolved: 27/Feb/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 40 minutes
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and rogerk

 Description   

Currently the web-partialresponse_2_2.xsd schema w/r/t insert element processing does not match the jsdocs for the implementation. This was a feature requested by ICESoft for 2.0, and based on their response we should change the schema to match the jsdocs.



 Comments   
Comment by Ed Burns [ 27/Feb/13 02:30 PM ]

Task order

1. Roger confirms the existing impl is correct with respect to design intent, and makes any necessary changes.

2. Ed updates the XSD to match the impl.

3. Roger updates the JSDoc to match the XSD and impl.

Comment by rogerk [ 27/Feb/13 05:11 PM ]

The schema must match this response format:

<partial-response id="j_id1"><changes><insert><before id="alpha"><![CDATA[This is before text]]></before></insert></changes></partial-response>

and for insert after:

<partial-response id="j_id1"><changes><insert><after id="alpha"><![CDATA[This is after text]]></after></insert></changes></partial-response>

The jsdocs will be updated as:

  • <p><i>Insert Element Processing</i></p>
  • <li>If an <code><insert></code> element is found in
  • the response with a nested <code><before></code>
  • element:
  • <pre><code><insert>
  • <before id="before id">
  • <![CDATA[...]]>
  • </before>
  • </insert></code></pre>
  • <ul>
  • <li>Extract this <code><before></code> element's <code>CDATA</code> contents
  • from the response.</li>
  • <li>Find the DOM element whose identifier matches <code>before id</code> and insert
  • the <code><before></code> element's <code>CDATA</code> content before
  • the DOM element in the document.</li>
  • </ul>
  • </li>
  • <li>If an <code><insert></code> element is found in
  • the response with a nested <code><after></code>
  • element:
  • <pre><code><insert>
  • <after id="after id">
  • <![CDATA[...]]>
  • </after>
  • </insert></code></pre>
  • <ul>
  • <li>Extract this <code><after></code> element's <code>CDATA</code> contents
  • from the response.</li>
  • <li>Find the DOM element whose identifier matches <code>after id</code> and insert
  • the <code><after></code> element's <code>CDATA</code> content after
  • the DOM element in the document.</li>
  • </ul>
  • </li>

The jsdocs update is part of http://java.net/jira/browse/JAVASERVERFACES-2752

Comment by Ed Burns [ 27/Feb/13 06:27 PM ]

The JSDocs look good.





[JAVASERVERFACES_SPEC_PUBLIC-1161] CSRF protection cannot be used "out of the box" without create a custom component or override forcefully ExternalContext Created: 05/Feb/13  Updated: 05/Feb/13  Resolved: 05/Feb/13

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

Type: Improvement Priority: Major
Reporter: lu4242 Assignee: rogerk
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns, lu4242 and rogerk

 Description   

In JAVASERVERFACES_SPEC_PUBLIC-869 it was specified CSRF view protection for GET request but there is no way to use this improvement "out of the box".

For example, for use ClientWindow API there is an attribute called disableClientWindow for h:link and h:button.

A param in h:link / h:button like enableViewProtection or something like that could be helpful.

There are only two ways to use it?

1. override ExternalContext methods and include the param in encodeBookmarkableURL / encodeRedirectURL

or

2. create a custom link or button component, do the same stuff h:button or h:link renderer does but append the CSRF query param, and use it in every place.

One way or another, this looks bad.

The suggested way to fix it is apply the same pattern used for ClientWindow:

public static void enableViewProtection(FacesContext context)
public static void disableViewProtection(FacesContext context)
public static boolean isViewProtectionEnabled(FacesContext context)

And add a param in h:link / h:button like enableViewProtection .

The change is pretty straighforward.

My concern about this issue is that without this improvement, the CSRF solution looks broken for users (a feature that can't be used without write the same boilerplate over and over), and without it portlet compatibility looks broken too.



 Comments   
Comment by Ed Burns [ 05/Feb/13 03:20 PM ]

The CSRF protection feature was desgined to be similar to how view
protection works in Servlet. Specifically, the designation of which
views are protected is done in a central place rather than in any
specific views, or in specific UI components within views.

Leonardo, why do you feel it is necessary to pollute the view with this
information? Looking at the latest spec [1], look at the generated HTML
for the "faces-config XML Schema Documentation" link. Within there look
at the spec for faces-config-protected-viewsType. It says.

Any view that matches any of the url-patterns in this element may only
be reached from another JSF view in the same web application. Because
the runtime is aware of which views are protected, any navigation from
an unprotected view to a protected view is automatically subject to
protection.

I really don't see why this has to be a per-component decision. I'm
going to close this as "works as designed" but if after reading this
response you and someone else on this list disagree, please re-open
it. At this point, I welcome all challenges, but I have a high bar if I
think it's already designed correctly.

Remember, as we discussed yesterday, getting the view loading story
right with respect to composite components, templates and regular views
within resource libraries, contracts, and flows, is my most pressing
concern, spec wise. Anything else takes away time from that vital
concern.

Ed

[1] http://jsf-spec.java.net/SNAPSHOT/javadoc/





[JAVASERVERFACES_SPEC_PUBLIC-1157] javax.faces.Token must be transported by Ajax if present Created: 22/Jan/13  Updated: 22/Jan/13  Resolved: 22/Jan/13

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

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

Tags:
Participants: lu4242 and rogerk

 Description   

Checking the spec, I notice that the CSRF token
is passed under javax.faces.Token request parameter, but the javascript
documentation should "relay" the token like it does with
javax.faces.ViewState or javax.faces.ClientWindow if and only if
the token is present.

The solution is just update javascript documentation of

jsf.ajax.request(source, event, options)

to reflect this condition.



 Comments   
Comment by rogerk [ 22/Jan/13 07:02 PM ]

Closing per reporter's comments.





[JAVASERVERFACES_SPEC_PUBLIC-1151] Cannot Attach Ajax Behavior To Html5 Elements Created: 07/Dec/12  Updated: 12/Dec/12  Resolved: 12/Dec/12

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 39 minutes
Original Estimate: Not Specified

Tags:
Participants: Ed Burns, Frank Caputo and rogerk

 Description   

HTML5 passthrough elements such as <fieldset> are created as UIPanel components. This prevents a page author fromn attahcing Ajax behavior. For example, currently, this cannot be done:

<fieldset jsf:id="fieldset3">
<legend jsf:id="legend3">
FieldSet2
</legend>
<f:ajax event="click" onevent="statusUpdate"/>
</fieldset>

The component that must be created is HtmlPanelGrid.



 Comments   
Comment by rogerk [ 07/Dec/12 02:28 PM ]

The implement issue for this is: http://java.net/jira/browse/JAVASERVERFACES-2629

Comment by Frank Caputo [ 09/Dec/12 07:21 PM ]

Hi Roger,

the user would not expect any tr and td elements in the rendered output. The prototype created h:panelGroup instead of jsf:element. I think this should work fine with the fix of http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1145.

Frank

Comment by rogerk [ 12/Dec/12 06:12 PM ]

Hi Frank -

Using the current JSF trunk source, I attempted to nest an f:ajax in a <fieldset>.
I got an exception because <fieldset jsf:id="foo"... created a UIPanel component in the view.
If your intention is to create a panel group component, then it must be an HTMLPanelGroup
since that implements the ClientBehaviorHolder interface that is required for attaching Ajax
behavior.

Comment by Ed Burns [ 12/Dec/12 08:47 PM ]

The spec change for this issue will be to modify the spec for

jsf:element

to require that the underlying component implements ClientBehaviorHolder and that the default event is "click". The choice of click is supported due to section 6.1.6.2 of the HTML5 draft spec.





[JAVASERVERFACES_SPEC_PUBLIC-1145] HtmlPanelGroup Does Not Implement ClientBehaviorHolder Created: 16/Nov/12  Updated: 30/Nov/12  Resolved: 30/Nov/12

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

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

Tags:
Participants: rogerk

 Description   

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

The spec 2.1 lists in section 8.7 all concrete HTML component classes and states that all these classes implement BehaviorHolder. This list includes HtmlPanelGroup but it does not implements ClientBehaviorHolder like HtmlPanelGrid.



 Comments   
Comment by rogerk [ 30/Nov/12 12:41 PM ]

See JAVASERVERFACES-1957





[JAVASERVERFACES_SPEC_PUBLIC-1136] ExternalContext.dispatch Javadocs Should Match Implementation Created: 12/Oct/12  Updated: 12/Oct/12  Resolved: 12/Oct/12

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

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

File Attachments: Text File changebundle-sp-1136.txt    
Tags:
Participants: rogerk

 Description   

Currently the Javadocs for ExternalContext.dispatch method say:

@throws IllegalArgumentException if no request dispatcher

  • can be created for the specified path
    @throws NullPointerException if <code>path</code>
  • is <code>null</code>

However the implementation does this:

RequestDispatcher requestDispatcher = request.getRequestDispatcher(
requestURI);
if (requestDispatcher == null) { ((HttpServletResponse) response). sendError(HttpServletResponse.SC_NOT_FOUND); return; }

The servlet specification indicates that a null RequestDispatcher will be returned if one cannot be created (for example by passing in a null argument to request.getRequestDispatcher). The JavaDocs for ExternalContextDispatcher should be changed as follows:

1. remove throws IllegalArgumentException, NullpointerException verbage.
2. add "If the call to <code>getRequestDisatcher(path)</code> returns null, send a<code>ServletResponse SC_NOT_FOUND</code> error code.



 Comments   
Comment by rogerk [ 12/Oct/12 02:44 PM ]

Changes.

Comment by rogerk [ 12/Oct/12 02:47 PM ]

Committed to trunk:
Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java
Transmitting file data .
Committed revision 10834.





[JAVASERVERFACES_SPEC_PUBLIC-1128] All form controls sent as request params when @none specified for execute. Created: 01/Aug/12  Updated: 08/Nov/13

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

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

Tags:
Participants: jasonzhang2002gmailcom, kithouna and rogerk

 Description   

A clarification is needed to state that no form controls should be sent if the 'execute' option is @none.
Currently, all form controls are encoded and sent regardless.



 Comments   
Comment by rogerk [ 01/Aug/12 02:32 PM ]

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

Comment by jasonzhang2002gmailcom [ 01/Aug/12 07:41 PM ]

In ajax call, all render parameters (@this, ids, @none) should be respected. The current implementation sends the whole form. All input controlls are evaluated(validated, and model are updated).

Comment by kithouna [ 07/Mar/13 09:55 AM ]

Isn't this perhaps a special case of JAVASERVERFACES_SPEC_PUBLIC-1098?





[JAVASERVERFACES_SPEC_PUBLIC-1118] Provide a switch case sort of thing to render one out of multiple possibilities Created: 03/Jul/12  Updated: 04/Dec/12  Resolved: 04/Dec/12

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

Type: New Feature Priority: Major
Reporter: Ertio lew Assignee: rogerk
Resolution: Duplicate Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-730 Make flows reusable Closed
Tags:
Participants: Asil Klin, Ed Burns, Ertio lew and rogerk

 Description   

There should be a switch case sort of thing that allows to render one out of multiple possibilities based on some condition. This would help saving a lot of condition checks in rendered attribute, when you want to show only one out of several possibilities.



 Comments   
Comment by Ertio lew [ 01/Sep/12 12:52 PM ]

Perhaps this should provide something similar to JSTL's <c:choose> with c:if & c:otherwise taghandlers but it can be used without problems(as with JSTL) inside iterating components like <h:dataTable>, <ui:repeat>, etc, or when deciding condition depend on results of JSF events like preRenderView.

Comment by Asil Klin [ 04/Dec/12 07:42 AM ]

Strongly in support of this. It'll be a much useful thing to have.

Comment by Ed Burns [ 04/Dec/12 02:10 PM ]

Faces Flows implements this. See linked issues.





[JAVASERVERFACES_SPEC_PUBLIC-1109] Add RendererWrapper Created: 30/May/12  Updated: 30/Nov/12  Resolved: 30/Nov/12

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

Type: New Feature Priority: Major
Reporter: Neil Griffin Assignee: rogerk
Resolution: Fixed Votes: 1
Remaining Estimate: 0 minutes
Time Spent: 30 minutes
Original Estimate: Not Specified

File Attachments: Java Source File RendererWrapper.java    
Tags:
Participants: Neil Griffin and rogerk

 Description   

During the development of Liferay Faces Bridge, I found it necessary to wrap renderers provided by various component suites. To this end, I hereby request that a RendererWrapper be added to the JSF API. The code is attached.






[JAVASERVERFACES_SPEC_PUBLIC-1098] f:ajax exeucte always sends all the fields of the wrapping form Created: 08/May/12  Updated: 08/Nov/13

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

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

Tags:
Participants: arjan tijms, Darious3, kithouna and rogerk

 Description   

f:ajax doesn't obey the 'execute' attribute but always sends all the fields in a form. Mojarra does, however, only process the listed fields as supposed. However, excess fields shouldn't be sent because it increases request size.

Recplicate with:

<h:form id="form1">
<h:commandButton>
<h:inputText id="field1" />
<h:inputText id="field1x" />
<f:ajax execute="field1" />
</h:commandButton>
</h:form>

On button click, both fields are sent (but only field1 would be processed).

See for further info: http://stackoverflow.com/questions/3889894/jsf-2-0-why-does-fajax-send-all-the-form-fields-and-not-only-those-marked-with

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



 Comments   
Comment by Darious3 [ 18/Aug/12 03:02 PM ]

PrimeFaces has recently implemented this, would be great to have this in the spec.

Comment by kithouna [ 28/Jan/13 09:27 AM ]

Must have feature for JSF 2.3. This really shouldn't be that hard, should it?

Comment by arjan tijms [ 31/Jan/13 02:30 PM ]

An implementation duplicate: JAVASERVERFACES-1841





[JAVASERVERFACES_SPEC_PUBLIC-1097] Include Missing Id Attribute For h:body In VDL Docs Created: 07/May/12  Updated: 19/Nov/12  Resolved: 14/May/12

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 10 minutes
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and rogerk

 Description   

It appears that the "id" attribute is not in the VDL docs for h:body. Refer to
http://java.net/jira/browse/JAVASERVERFACES-2409






[JAVASERVERFACES_SPEC_PUBLIC-1090] HTML5 Support Created: 18/Apr/12  Updated: 25/Jul/13  Resolved: 25/Jul/13

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: rogerk
Resolution: Fixed Votes: 1
Σ Remaining Estimate: 4 weeks, 5 days, 6 hours, 12 minutes Remaining Estimate: Not Specified
Σ Time Spent: 2 days, 17 hours, 48 minutes Time Spent: Not Specified
Σ Original Estimate: 5 weeks, 1 day Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES-2512 Implement HTML5 support Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-990 HTML5 Forms Support Sub-task Resolved Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-991 Support for new/changed features in H... Sub-task Closed  
JAVASERVERFACES_SPEC_PUBLIC-1075 HTML5 Metadata Content Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-1076 HTML5 Sectioning and Heading Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-1077 HTML5 Form Associated Elements Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-1089 Support for HTML5 passthru attributes... Sub-task Resolved Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-1111 Generic Passthru Elements Sub-task Closed Ed Burns  
Tags:
Participants: Ed Burns and rogerk

 Description   

Umbrella issue for HTML 5 support in JSF 2.2



 Comments   
Comment by Ed Burns [ 25/Jul/13 07:20 PM ]

The HTML5 Friendly Markup feature is the extent of HTML5 support in JSF 2.2.





[JAVASERVERFACES_SPEC_PUBLIC-1084] FaceletTaglibConfigProcessor.java fails to interpret el-function method signature when XML formatting the taglib.xml caused newline within the method signature Created: 29/Mar/12  Updated: 29/Mar/12  Resolved: 29/Mar/12

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

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

Tags:
Participants: rogerk

 Description   

as summary says. Formatting taglib.xml might lead to newlines within method signature like this:

<function>
<function-name>resolveCodeVariant</function-name>
<function-class>com.csg.jsf.el.Functions</function-class>
<function-signature>java.lang.String
resolveCodeVariant(java.lang.String, java.lang.String, java.lang.String)</function-signature>
</function>

Currently FaceletTaglibConfigProcessor will only use the first line to lookup the method and of course fail.

Proposed change is to replace any whitespace with space char - see attached changebundle.

Originally filed as spec issue: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1083
It's an impl issue not a spec issue.



 Comments   
Comment by rogerk [ 29/Mar/12 05:11 PM ]

impl issue not spec issue.





[JAVASERVERFACES_SPEC_PUBLIC-1083] FaceletTaglibConfigProcessor.java fails to interpret el-function method signature when XML formatting the taglib.xml caused newline within the method signature Created: 27/Mar/12  Updated: 29/Mar/12  Resolved: 29/Mar/12

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping
Affects Version/s: 2.2 Sprint 10
Fix Version/s: 2.2 Sprint 11 B

Type: Bug Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: rogerk
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle.txt    
Tags:
Participants: Hanspeter Duennenberger and rogerk

 Description   

as summary says. Formatting taglib.xml might lead to newlines within method signature like this:

<function>
<function-name>resolveCodeVariant</function-name>
<function-class>com.csg.jsf.el.Functions</function-class>
<function-signature>java.lang.String
resolveCodeVariant(java.lang.String, java.lang.String, java.lang.String)</function-signature>
</function>

Currently FaceletTaglibConfigProcessor will only use the first line to lookup the method and of course fail.

Proposed change is to replace any whitespace with space char - see attached changebundle.



 Comments   
Comment by Hanspeter Duennenberger [ 27/Mar/12 04:01 PM ]

sorry, this issue should be on impl, not spec-issue. Yan this issue be moved over?

Comment by rogerk [ 29/Mar/12 05:13 PM ]

This is an impl issue. Filed as: http://java.net/jira/browse/JAVASERVERFACES-2369





[JAVASERVERFACES_SPEC_PUBLIC-1068] Partial Processing Requirements for InvokeApplication and RenderResponse phases unspecified Created: 09/Feb/12  Updated: 16/Apr/12  Resolved: 16/Apr/12

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

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

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-220 Prevent "id" attribute name-collision... Resolved
Tags:
Participants: Ed Burns and rogerk

 Description   

I could be missing this, but I can't find where in the spec the partial processing requirements for the InvokeApplication and RenderResponse lifecycle phases are listed.

I encountered this problem when writing up the changebundle for JAVASERVERFACES_SPEC_PUBLIC-220, when I needed to update the bit of the spec that dealt with the <update> element pertaining to the ViewState.

This happens in the RenderResponse phase, but I found no such text in the spec.



 Comments   
Comment by rogerk [ 10/Feb/12 02:06 PM ]

Section 13.4.2 of the spec talks aboput Praitl View Processing. In summary, the "execute" portion of the lifecycle w/r/t ajax request processing is the “Apply Request Values Phase”, “Update Model Values Phase” and “Process Validations Phase”. In other words, you can dictate that a component gets processed through these lifecycle phases (over ajax).
Likewise, Section 13.4.3 talks about Partial View Rendering which is ajax request processing through the Render Response Phase.

Section 13.4.4 talks about the requirements for writing the partial response.
More of the detail is also found in the javadocs.

Comment by Ed Burns [ 10/Feb/12 08:41 PM ]

Thanks for pointing me to those sections, but I still don't see where we require that we render an <update> region for the ViewState. This is implemented in our PartialViewContextImpl.renderState() private method, which gets called during the RENDER_RESPONSE portion of the processPartial() method, but I don't see that requirement anywhere in the spec.

Am I missing something?

Comment by rogerk [ 10/Feb/12 09:18 PM ]

It's in the jsdocs for the response function.

Comment by Ed Burns [ 10/Feb/12 09:21 PM ]

I need to update the text in the jsf.js file that covers the jsf.ajax.response() function.

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

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

locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response. Locate and update the javax.faces.ViewState value for all forms specified in the render target list.

Comment by Ed Burns [ 27/Feb/12 09:17 PM ]

Added to spec per Roger's suggestion.

Comment by Ed Burns [ 14/Mar/12 03:44 PM ]

I'm not satisfied with the resolution. I think we need a sub-section in 2.2.6 for partial rendering that corresponds to 2.2.3.1 Partial Validations Partial Processing and 2.2.4.1 Update Model Values partial processing.

In that section, I'll describe the need for the windowId <update> element, as well as the existing requirements for partial view rendering.

Comment by Ed Burns [ 16/Apr/12 07:28 PM ]

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

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

  • refer to new section 2.2.6.1.

M requestProcessingLifecycle.fm

  • new section 2.2.6.1: describe partial render requirements, including
    the windowId for partial rendering.

Sending preface.fm
Sending requestProcessingLifecycle.fm
Transmitting file data ..
Committed revision 1057.





[JAVASERVERFACES_SPEC_PUBLIC-1059] f:selectItem escapeItem attribute should be itemEscaped Created: 05/Dec/11  Updated: 08/Nov/13

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

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

Tags:
Participants: rogerk

 Description   

The vdl docs are in error w/r/t f:selectItem escapeItem - it should be itemEscaped.
The implementation is correct here.






[JAVASERVERFACES_SPEC_PUBLIC-1058] VDL Docs Need Correction/Clarification For ui:repeat size Attribute Created: 01/Dec/11  Updated: 19/Nov/12  Resolved: 19/Nov/12

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

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

File Attachments: Text File changebundle-1058.txt     Text File changebundle-1058.txt    
Tags:
Participants: rogerk

 Description   

Currently, the VDL docs say this for ui:repeat "size" attribute:

"Read-write property setting the size of the collection to iterate. If this value is less than the actual size of the collection, a FacesException must be thrown."

However, the purpose of the size attribute is to specify the number of elements or items to iterate over in the overall collection. So, for example:

  • overall collection size = 10
  • u:repeat size="5"
    should iterate over the first 5 items of the collection.


 Comments   
Comment by rogerk [ 01/Dec/11 08:52 PM ]

Changes.

Comment by rogerk [ 01/Dec/11 08:59 PM ]

Revised Change.

Comment by rogerk [ 01/Dec/11 09:01 PM ]

Committed to trunk:
Sending jsf-ri/conf/share/ui.tld
Transmitting file data .
Committed revision 9484.

Comment by rogerk [ 01/Dec/11 09:01 PM ]

checked in.





[JAVASERVERFACES_SPEC_PUBLIC-1057] VDL Docs Need Correction/Clarification Created: 01/Dec/11  Updated: 08/Nov/13

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

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

Tags:
Participants: rogerk




[JAVASERVERFACES_SPEC_PUBLIC-1053] VDL Docs Need Clarification for f:view afterPhase Attribute Created: 23/Nov/11  Updated: 08/Nov/13

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

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

Tags:
Participants: rogerk

 Description   

The VDL docs state this for f:view afterPhase :

"MethodBinding pointing to a method that takes a javax.faces.event.PhaseEvent and returns void. This method will be called after every phase except for restore view."

This should be clarified to:

"MethodBinding pointing to a method that takes a javax.faces.event.PhaseEvent and returns void. This method will be called after every phase except for restore view on an initial request."



 Comments   
Comment by rogerk [ 23/Nov/11 05:00 PM ]

Fix Version





[JAVASERVERFACES_SPEC_PUBLIC-1032] UIForm.createUniqueId() does not create unique id's in case prependId="false" is specified. Created: 12/Aug/11  Updated: 16/Aug/11  Resolved: 16/Aug/11

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

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

File Attachments: Text File changebundle.txt     Text File JAVASERVERFACES_SPEC_PUBLIC-1032-UIForm.createUniqueId.patch    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-787 Restore ViewScope before templates ar... Closed
Tags:
Participants: Hanspeter Duennenberger and rogerk

 Description   

In case prependId="false" is given, UIForm must delegate createUniqueId to it's parent UniqueIdVendor.

Stumbled across that while testing for JAVASERVERFACES_SPEC_PUBLIC-787 - where in a simple view outputText components where added dynamically from a managed bean action. Because the form had prependeId="false" it happened that the dynamically added outputText got the same j_idt3 as the UIOutput for the jsf.js resource already had - jsf.js got the id from UIViewRoot, the dynamically added component got the id from the form with prependId="false".

There might be other NamingContainer/UniqueIdVendor that also support prependId="false" - they need to be checked against that too.

This issue might also be related to JAVASERVERFACES_SPEC_PUBLIC-539 - please verify.

If this is solved with 2.2, consider back-porting it to 2.1/2.0 also.

There is a simple workaround - do not use prependId="false"!

regards
Hanspeter



 Comments   
Comment by Hanspeter Duennenberger [ 12/Aug/11 10:52 AM ]

Patch to let UIForm.createUniqueId() delegate next ancestor UniqueIdVendor, or ViewRoot if ancestor UniqueIdvendor cannot be found.

Comment by Hanspeter Duennenberger [ 12/Aug/11 08:10 PM ]

1032 fix solves the problem that has lead to add a workaround on the 787 changes in StateManagementStrategyImpl before calling UIViewRoot.restoreViewScopeState().

The 787 workaround must be removed at the same time as 1032 fix is commited.

Comment by rogerk [ 12/Aug/11 08:14 PM ]

<p class="changed_modified_2_2">Generate an identifier for a component. The identifier
will be prefixed with UNIQUE_ID_PREFIX, and will be unique
within this component container. Optionally, a unique seed value can
be supplied by component creators which should be
included in the generated unique id.</p>
<p class="changed_added_2_2">
If the <code>prependId</code> property has the value <code>false</code>,
this method must call <code>createUniqueId</code> on the next ancestor
<code>UniqueIdVendor</code>.
</p>

Comment by Hanspeter Duennenberger [ 12/Aug/11 09:01 PM ]

added changebundle for proposed changes.

Comment by rogerk [ 15/Aug/11 03:31 PM ]

Tests on my hosted machine ran successfully.
r=rogerk

Provided you've considered cases where component frameworks have their own custom Forms.

Comment by Hanspeter Duennenberger [ 16/Aug/11 10:16 PM ]

UIForm.createUniqueId() does not create unique id's in case prependId="false" is specified. http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1032

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

  • delegate createUniqueId() to ancestor UniqueIdVendor if prependId is set to false
  • removed workaround in StateManagementStrategyImpl that was added because UIViewRoot was false identified as dynamically added because of above bug

Sending /Users/hampi/Projects/ws-helios/Mojarra/jsf-api/src/main/java/javax/faces/component/UIForm.java
Sending /Users/hampi/Projects/ws-helios/Mojarra/jsf-ri/src/main/java/com/sun/faces/application/view/StateManagementStrategyImpl.java
Transmitting file data ...
Committed revision 9268.

Is that UIForm fix also needed on 2.1/2.0 branches?





[JAVASERVERFACES_SPEC_PUBLIC-1030] Message / Messages Component ToolTip Attribute To Use Detail Message Created: 04/Aug/11  Updated: 10/Aug/11  Resolved: 10/Aug/11

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

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

Tags:
Participants: rogerk

 Description   

Currently, the "tooltip" attribute description for message and messages renderer says:

"Flag indicating whether the detail portion of the message should be displayed as a tooltip."

However, the rendering details and the implementation always use the summary.

PROPOSAL:
Use the detail message for the tooltip (if it is set). If no detail message is set, use the summary.

This relates to http://java.net/jira/browse/JAVASERVERFACES-2160



 Comments   
Comment by rogerk [ 10/Aug/11 04:32 PM ]

Fixed. See: http://java.net/jira/browse/JAVASERVERFACES-2160





[JAVASERVERFACES_SPEC_PUBLIC-1026] tlddoc says f:ajax event - type="javax.el.ValueExpression (must evaluate to java.lang.String)", but in theory that is invalid Created: 23/Jul/11  Updated: 25/Jul/11  Resolved: 24/Jul/11

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

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

File Attachments: Text File changebundle-spec-1026.txt    
Tags:
Participants: 120430, lu4242, Martin Kočí and rogerk

 Description   

JSF 2.0 spec facelets tlddoc says on f:ajax "event" property that it can be assigned to a ValueExpression, but in theory that is not possible. The documentation of vld.retargetAttachedObjects call getEvent() without pass FacesContext, so I suppose this is a bug on the documentation. Related issue on MyFaces is MYFACES-3233



 Comments   
Comment by Martin Kočí [ 24/Jul/11 09:05 AM ]

it would be nice to have support for event=ValueExpression

<h:inputText>
<f:ajax event="#{user.preferredEvent}" >

-> user can select if he/she want keyup or change for example. This is useful is use case like "perform validation during typing" and "perform validation after cursor leaves the field"

Currently wen need two same f:ajax element with different event names and disable one with disabled="#{}"

Comment by rogerk [ 24/Jul/11 05:34 PM ]

Changes

Comment by rogerk [ 24/Jul/11 05:42 PM ]

Committed to trunk:
Sending jsf-ri/conf/share/facelets_jsf_core.tld
Transmitting file data .
Committed revision 9214.

Committed to MOJARRA_2_1X_ROLLING:
Sending jsf-ri/conf/share/facelets_jsf_core.tld
Transmitting file data .
Committed revision 9215.

Comment by 120430 [ 25/Jul/11 09:49 AM ]

I would agree Martin. Why ValueExpression should not supported?

Comment by rogerk [ 25/Jul/11 10:45 AM ]

It should be supported. There is an open issue for it.

Comment by lu4242 [ 25/Jul/11 04:17 PM ]

Do you know the issue? which number is it? just for reference purposes? will this be handled in JSF 2.2?





[JAVASERVERFACES_SPEC_PUBLIC-1011] ResourceELResolver does not encode the URL with ExternalContext.encodeResourceURL() Created: 26/May/11  Updated: 17/Dec/13

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

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

File Attachments: Text File SPEC-1011-ResourceELResolver.patch    
Tags:
Participants: Hanspeter Duennenberger and rogerk

 Description   

The getValue() method says:

  • If one of the above steps resulted in the creation of a {@link Resource}
  • instance, call <code>ELContext.setPropertyResolved(true)</code> and return
  • the result of {@link javax.faces.application.Resource#getRequestPath()}

Taken from: http://java.net/jira/browse/JAVASERVERFACES-1878



 Comments   
Comment by Hanspeter Duennenberger [ 15/Jun/11 02:27 AM ]

Hi Ed.

Here an updated patch for this ResourceELResolver issue.

Actually I opened this issue as a mojarra impl bug, but Roger has closed JAVASERVERFACES-1878 and created this one instead.

I'm not sure if that is right - I mean, if ResourceELResolver is affecting the spec, why is it then not in package javax.faces.el? Or is resource handling subject to bigger change for JSF 2.2?

Anyway, the attached patch contains the changes to fix this issue and a little correction in javadoc.

regards
Hanspeter





[JAVASERVERFACES_SPEC_PUBLIC-1009] Make it so ExternalContext.getRealPath() is callable at startup time Created: 24/May/11  Updated: 26/May/11  Resolved: 24/May/11

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

Type: Improvement Priority: Trivial
Reporter: lamine_ba Assignee: rogerk
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-821 ExternalContext.getRealPath() on star... Open
Tags:
Participants: Ed Burns, Jakob Korherr, lamine_ba and rogerk

 Description   

for the moment, JSF don't give you the ability to get the real path at startup. getRealPath is not listed as valid for calling at startup time.



 Comments   
Comment by Jakob Korherr [ 24/May/11 01:28 PM ]

this issue already exists. closing this one as duplicate.

Comment by Ed Burns [ 25/May/11 02:54 PM ]

Thank you so much. Lamine, please make sure next time you file an issue you check for its existence first.

Comment by lamine_ba [ 26/May/11 07:00 AM ]

Already read that on your "Vote for your 5 issues" blog post and that is the process I used to use. But when I'm in automatic mode, tired and full of troubles, my other process is to rely on the Assignees and the Reporters who monitor the tracker to check the existence of the issue against their memories.





[JAVASERVERFACES_SPEC_PUBLIC-1004] Specify Reasonable Default For javax.faces.FACELETS_BUFFER_SIZE Created: 19/May/11  Updated: 19/Nov/12  Resolved: 19/May/11

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

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

Tags:
Participants: Ed Burns and rogerk

 Description   

In 11.1.3 Application Configuration Parameters of JSF 2.0 specification, there is a description about javax.faces.FACELETS_BUFFER_SIZE.

----->
By default the value is -1, which will not assign a buffer size
<-----

=======

This puts an unnecessary burden on applications to override this -1 value with a context init param in web.xml. A reasonable default such as "1024" should be specified.



 Comments   
Comment by Ed Burns [ 19/May/11 11:38 AM ]

Sending usingFacesInWebapps.fm
Transmitting file data .
Committed revision 1015.





[JAVASERVERFACES_SPEC_PUBLIC-999] ui:decorate ui:composition "template" Attribute Created: 10/May/11  Updated: 10/May/11  Resolved: 10/May/11

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

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

Tags:
Participants: Ed Burns and rogerk

 Description   

The following issues/inconsistencies exist today w/r/t the "template" attribute for
ui:decorate and ui:composition tags.

1. vdl docs say that ui:composition / ui:decorate "template" attribute is not required.
The Mojarra implementation implements ui:decoreate as required but does nothing for
ui:composition if "template" attribute is not specified.
http://java.net/jira/browse/JAVASERVERFACES-2023

Does it make sense to use these tags without a "template" attribute?
If not we should specify it as required for both tags.

2. What should be the behavior if a page author specifies this:
ui:decorate template="" or ui:composition template=""

Does it make sense to use these tags without a value for "template" attribute?
If not we should specify a TagAttributeException.



 Comments   
Comment by rogerk [ 10/May/11 08:18 AM ]

Actually it does not make sense to make "template" attribute required for
ui:composition, as it is perfectly feasible to author something like this:

<ui:composition>
....
</ui:composition>

But the vdldocs should specify "template" as required attribute for ui:decorate

Comment by Ed Burns [ 10/May/11 08:49 AM ]

Sending jsf-ri/conf/share/tlddoc-resources/stylesheet.css
Sending jsf-ri/conf/share/ui.tld
Transmitting file data ..
Committed revision 9024.





[JAVASERVERFACES_SPEC_PUBLIC-997] UIComponent event-listening APIs are inconsistent Created: 29/Apr/11  Updated: 01/Feb/12  Resolved: 01/Feb/12

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

Type: Improvement Priority: Minor
Reporter: Matt Benson Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File 20120201-1427-i_spec_997.patch     Text File changebundle.txt    
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: dougd, Ed Burns, Matt Benson and rogerk

 Description   

UIComponent defines the pair of:

void subscribeToEvent(Class<? extends SystemEvent>, ComponentSystemEventListener)
void unsubscribeFromEvent(Class<? extends SystemEvent>, ComponentSystemEventListener)

The rationale given for ComponentSystemEventListener is that, being installed on a specific component, there is no need for an instance to implement the full-blown SystemEventListener interface. It was not desired that ComponentSystemEventListener be an abstract class itself implementing SystemEventListener presumably because (a) that would force a listener into a particular inheritance hierarchy and (b) in order to narrow the argument accepted for .processEvent(), would most likely have necessitated the introduction of generics into the SystemEventListener taxonomy. The point at which the inconsistency arises is when UIComponent defines:

List<SystemEventListener> getListenersForEventClass(Class<? extends SystemEvent>)

Ignoring the contrived possibility that all ComponentSystemEventListeners installed on a given UIComponent also implement SystemEventListener, the getListeners... method is meaningless and cannot return the objects registered via subscribeToEvent().



 Comments   
Comment by rogerk [ 02/May/11 01:59 PM ]

triage

Comment by Ed Burns [ 12/May/11 11:31 AM ]

Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Sending jsf-api/src/main/java/javax/faces/event/ComponentSystemEvent.java
Sending jsf-api/src/main/java/javax/faces/event/SystemEvent.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun/faces/regression/i_spec_997
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/java/com/sun/faces/regression/i_spec_997/Issue997TestCase.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_htmlunit/src/main/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun/faces/i_spec_997
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun/faces/i_spec_997/ListenerForComponent.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/java/com/sun/faces/i_spec_997/ListenersForComponent.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/resources
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/resources/META-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/resources/META-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_jar/src/main/resources/META-INF/i_jsf_1948.taglib.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-997/i_spec_997_war/src/main/webapp/main.xhtml
Sending jsf-test/build.xml
Transmitting file data ...............
Committed revision 9035.

Comment by dougd [ 09/Jan/12 07:39 PM ]

I am hitting a ClassCastException when calling to ComponentSystemEvent.processListener(ComponentSystemEventListener).

This is due to the fact that we call SystemEvent.processListener() from ComponentSystemEvent.processListenerwhich is now trying to cast to a SystemEventListener(). The issue is that ComponentSystemEventLIstener and SystemEventListener are peers. This is unlike ComponentSystemEvent which is a SystemEvent in the hierarchy.

Comment by Ed Burns [ 01/Feb/12 08:30 PM ]

Sending jsf-api/src/main/java/javax/faces/event/ComponentSystemEvent.java
Transmitting file data .
Committed revision 9630.





[JAVASERVERFACES_SPEC_PUBLIC-994] Facelet classes should be in faces-config instead of web.xml Created: 29/Apr/11  Updated: 08/Nov/13

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

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

Status Whiteboard:

size_medium importance_small

Tags:
Participants: kito75 and rogerk

 Description   

Some configuration from the original version of Facelets, like TagDecorator and ResourceResolver, should be defined in faces-config.xml instead of web.xml. Configuration with web.xml is more error-prone to use because there's no schema.



 Comments   
Comment by rogerk [ 02/May/11 02:00 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-942] Allow JSF application artifacts to be delivered as OSGi bundles Created: 31/Jan/11  Updated: 17/Dec/13

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

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

File Attachments: Text File message.txt    
Status Whiteboard:

size_large importance_large

Tags:
Participants: rogerk

 Description   

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

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

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






[JAVASERVERFACES_SPEC_PUBLIC-941] reduce number of times rendered attribute value expression is evaluated Created: 31/Jan/11  Updated: 08/Nov/13

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

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

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

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



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

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





[JAVASERVERFACES_SPEC_PUBLIC-940] Custom scope cyclic detection needs to be added. Created: 31/Jan/11  Updated: 17/Dec/13  Resolved: 17/Dec/13

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

Need to handle cyclic detection with custom scoped beans.



 Comments   
Comment by Ed Burns [ 17/Dec/13 03:26 PM ]

With JSF getting out of the business of managed beans, this problem now becomes the domain of CDI.





[JAVASERVERFACES_SPEC_PUBLIC-939] behavior issues with "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" setting Created: 31/Jan/11  Updated: 24/Dec/13

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

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

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-3098 Regression in UIComponentBase#saveAtt... Closed
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: balusc, dennishoersch, rogerk and vabp

 Description   

currently - where INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is FALSE - we
have the following behavior:

Imaging two elements, bound to some managed bean (e.g in sessionScope)

<inputText id="one" />
<inputText id="two" required="true" />

Enter this:
one => FOO
two => BAR
HIT_ENTER (e.g submit the form)

now remove all the values
one =>
two =>
HIT_ENTER (e.g submit the form)

the rendered result is that BOTH fields are empty and there is an error-msg
for the required one.

Now when "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" is set to TRUE, we
have the following behavior
(same components used):

Enter this:
one => FOO
two => BAR
HIT_ENTER (e.g submit the form)

now remove all the values
one =>
two =>
HIT_ENTER (e.g submit the form)

the rendered result is that ONLY the required field is empty (and it has a
warning msg).
The other one - b/c submitted value is NULL is getting the real value, which has
been pushed into the bean before (=>FOO)

=> Is this really the intention ?

Do we really want to show the "original" data ? Today we don't, we just provided
the entered stuff/wrong_value (e.g nothing in this particular case)

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

ah, ok.

basically the fix is this:

public Object getValue()
{
FacesContext fc = getFacesContext();
if (fc != null && fc.isValidationFailed())

{ return getStateHelper().get(PropertyKeys.value); }

else

{ return getStateHelper().eval(PropertyKeys.value); }

}

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

IMO you shouldn't return something different from getValue because validation
failed!

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

It's returning the local value that would have been pushed to the model if
validation hadn't failed. That behavior seems correct based on the problem report.

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

let's say validation doesn't fail, but for some reason the developer calls
renderResponse in a valueChangeListener. Shouldn't the local value still get
shown when you rerender?
[ Show » ]
gabfest added a comment - 02/Dec/09 11:16 AM let's say validation doesn't fail, but for some reason the developer calls renderResponse in a valueChangeListener. Shouldn't the local value still get shown when you rerender?

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

Fair point.



 Comments   
Comment by vabp [ 15/May/12 08:55 PM ]

Can this please be addressed? It is significantly impact our in-production system.

Comment by balusc [ 11/Oct/12 02:51 PM ]

Issue 2262 is related http://java.net/jira/browse/JAVASERVERFACES-2262

Comment by dennishoersch [ 14/Jan/13 07:48 PM ]

Is there any decision made?

We're using the 'interpretion' of a submitted value as null, but the redisplay of the old value is a problem for us too.





[JAVASERVERFACES_SPEC_PUBLIC-938] PartialViewContextWrapper is missing setPartialRequest Created: 31/Jan/11  Updated: 07/Jun/11  Resolved: 19/May/11

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.1, 2.2

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

File Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-917 add a JUnit test to make sure that cl... Resolved
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Hanspeter Duennenberger and rogerk

 Description   

PartialViewContextWrapper is supposed to only require getWrapped to be implemented by subclasses.

ADDITIONAL COMMENTS:

http://java.net/jira/secure/ViewProfile.jspa?name=ioss added attachment.



 Comments   
Comment by Hanspeter Duennenberger [ 19/May/11 02:21 PM ]

This issue was resolved by JAVASERVERFACES_SPEC_PUBLIC-917





[JAVASERVERFACES_SPEC_PUBLIC-937] Disable implicit navigation for JSF 1.x applications Created: 31/Jan/11  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk

 Description   

Currently, implicit navigation seems to be enabled for all applications that
are deployed on a container with Mojarra 2.0, even when they have a JSF 1.x
configuration. Because some of the action methods in our 1.x applications can
return an outcome that isn't defined in the navigation rules in faces-
new view (one that possibly doesn't even exist) instead of doing nothing, like
Mojarra 1.2 did.

It would be great for maintaining compatibility with 1.x applications if
implicit navigation is disabled when a 1.x configuration is found. Adding a
context initialization parameter to explicitly disable implicit navigation
could also be useful.
Description
Currently, implicit navigation seems to be enabled for all applications that are deployed on a container with Mojarra 2.0, even when they have a JSF 1.x configuration. Because some of the action methods in our 1.x applications can return an outcome that isn't defined in the navigation rules in faces- new view (one that possibly doesn't even exist) instead of doing nothing, like Mojarra 1.2 did. It would be great for maintaining compatibility with 1.x applications if implicit navigation is disabled when a 1.x configuration is found. Adding a context initialization parameter to explicitly disable implicit navigation could also be useful.



 Comments   
Comment by rogerk [ 31/Jan/11 08:27 AM ]

Additional comments from http://java.net/jira/secure/ViewProfile.jspa?name=omolenkamp

Ok, Bugzilla / some javascript / my browser somehow strips a line starting at
config dot xml. Last attempt:

"Because some of the action methods in our 1.x applications can
return an outcome that isn't defined in the navigation rules in faces dash
config dot xml, Mojarra 2.0 will in such a case redirect to a new view (one
that possibly doesn't even exist) instead of doing nothing, like
Mojarra 1.2 did."





[JAVASERVERFACES_SPEC_PUBLIC-936] Set FACELETS_REFRESH_PERIOD to -1 if project stage is Production Created: 31/Jan/11  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_small importance_small

Tags:
Participants: rogerk

 Description   

In most common cases there not need to reload Facelet from .xhtml in production
environment. Currently FACELETS_REFRESH_PERIOD has value 2 (if it is not set
explicitly) even in production - for simplification of configuration managenent
it should be set to -1 like:

if (refreshParam == null && stage == production)
refreshPeriod = -1
else
refreshPeriod = refreshParam






[JAVASERVERFACES_SPEC_PUBLIC-935] UIData needs review on a couple of fronts Created: 31/Jan/11  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 4
Σ Remaining Estimate: 3 days, 23 hours, 30 minutes Remaining Estimate: Not Specified
Σ Time Spent: 1 hour, 16 minutes Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-322 Add interfaces to javax.faces.compone... Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-479 UIData should support the collection ... Sub-task Resolved Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-963 Alignment/extending of iterating ui c... Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-965 Provide a component for iterating ove... Sub-task Open  
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: lu4242 and rogerk

 Description   

Note that the following will most likely apply to 1.2 as well

From Martin Marinschek:
-----------------------------

a) if invokeOnComponent returns successfully for any of the facets,
invokeOnComponent should return with true - currently it doesn't (maybe there is
a reason for this I fail to see?)

b) I think that the NumberConversionException thrown from the current version of
this method is dangerous in the sense that if the client-id is not actually
valid (the component is not yet anymore in the table) but was a sub-component of
a naming-container in a facet (client-id
tableClientId:namContainerId:subCompId), the long client-id will trigger the
code to check if the component is in one of the rows and you will suddenly get a
number conversion exception popping up from the table. This is not the case with
other components and invokeOnComponent, and so should be done differently.
Instead, this NumberConversion exception has to be silently ignored - or a
better solution for this algorithm has to be found (I didn't find one in a
decent time-frame, however, and just ignored the NumberConversion exception in
my version).

As a side-note: could it be that you guys keep track of the state of children of
transient nodes? I seem to be running into this from time to time. Leonardo
mentioned this as an implementation difference to MyFaces to me, so maybe you
could check if this is the case (I don't think this would make sense - a
transient component would certainly mean every sub-component has to be transient
as well).



 Comments   
Comment by lu4242 [ 18/Apr/11 09:05 AM ]

The most important problem I see with UIData current implementation is the clientId append the rowIndex and it could be better if we can just create some property called rowKey or a converter or whatever that allow us to generate this part of the id in a clean way. Right now, there is a solution for this one committed on tomahawk code if you want to take a look. I'm willing to write the solution for mojarra too.





[JAVASERVERFACES_SPEC_PUBLIC-934] JSF 2 Compatibility and JSR-303 Created: 31/Jan/11  Updated: 08/Nov/13

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

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

File Attachments: Zip Archive beanvalidatortest.zip    
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk

 Description   

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

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

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

ADDITIONAL COMMENTS (edburns):

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

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

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

ADDITIONAL COMMENTS (jpleed3)

You have my attention.

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

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

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

ADDITIONAL COMMENTS (edburns):

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

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

NOTE: Attachment is from jpleed3 illustrating issue.






[JAVASERVERFACES_SPEC_PUBLIC-933] Support for zero-arg action/valueChangeListener does not work with EL VariableMapper Created: 31/Jan/11  Updated: 08/Nov/13

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk

 Description   

Template client:
<h:body >
<ui:decorate template="template.xhtml">
<ui:param name="bean" value="#{beanA}" />
</ui:decorate>
</h:body>

Template:
<f:subview xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:form >
<h:inputText value="value" valueChangeListener="#{bean.processValueChange}" />
<h:commandButton value="Click" actionListener="#{bean.processAction}" />
</h:form>
</f:subview>

if processValueChange/processAction are methods without event param, a exception
"javax.el.PropertyNotFoundException: Target Unreachable, identifier 'bean'
resolved to null" is thrown.
Description
Template client:
<h:body >
<ui:decorate template="template.xhtml">
<ui:param name="bean" value="#{beanA}" />
</ui:decorate>
</h:body>
Template:

<f:subview xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html">
<h:form >
<h:inputText value="value" valueChangeListener="#{bean.processValueChange}" />
<h:commandButton value="Click" actionListener="#{bean.processAction}" />
</h:form>
</f:subview>

if processValueChange/processAction are methods without event param, a exception "javax.el.PropertyNotFoundException: Target Unreachable, identifier 'bean' resolved to null" is thrown.
Show »

ADDITIONAL COMMENTS:

Problem can be solved in
com.sun.faces.facelets.tag.jsf.ActionSourceRule.ActionListenerMapper2.applyMetadata:
MethodExpression methodExpressionOneArg = this.attr.getMethodExpression(ctx,
null,ActionSourceRule.ACTION_LISTENER_SIG);
MethodExpression methodExpressionZeroArg = this.attr.getMethodExpression(ctx,
null,ActionSourceRule.ACTION_SIG);

.. new MethodExpressionActionListener(methodExpressionOneArg,
methodExpressionZeroArg)

and probably similarly in Rule for ValueChangeListener.






[JAVASERVERFACES_SPEC_PUBLIC-932] PreValidate/PostValidate events are not published properly Created: 31/Jan/11  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk

 Description   

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

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

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

super.processValidators(context);
if (!isImmediate()) { executeValidate(context); }

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






[JAVASERVERFACES_SPEC_PUBLIC-931] Messages component has inconsistent root tag Created: 31/Jan/11  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk

 Description   

When the messages component is rendered initially with no messages, it renders as a <div
id="messages">, but when messages are required, a <ul id="messages"> is rendered instead.

This makes it difficult to perform an ajax update of messages.

The preferred output would retain the outer <div> tag and optionally render the <ul> within it.

(There may be similar output with the message component.)






[JAVASERVERFACES_SPEC_PUBLIC-930] f:ajax not working when response contains CDATA / ui:debug Created: 31/Jan/11  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk and werpu12

 Description   

when calling an action-method that returns a string (viewId), f:ajax tries to
update the whole page with the new view.

This fails, when the source of the new view contains an xml-comment (CDATA) like
the one that gets automatically inserted through ui:debug.

when trying to update a page this way, an alert-box is shown, saying that update
failed.
Description
when calling an action-method that returns a string (viewId), f:ajax tries to update the whole page with the new view. This fails, when the source of the new view contains an xml-comment (CDATA) like the one that gets automatically inserted through ui:debug. when trying to update a page this way, an alert-box is shown, saying that update failed.
Show »

Sort Order: Ascending order - Click to sort in descending order



 Comments   
Comment by werpu12 [ 06/Mar/12 03:05 PM ]

I dont see this as a spec bug, the problem there probably is that the CDATA is not escaped correctly on the server by the partial response writer.
In MyFaces we do double buffering just for this issue, to avoid unescaped CDATAs in the ajax response.





[JAVASERVERFACES_SPEC_PUBLIC-929] @ViewScoped fails when an UIComponent is bound to bean Created: 31/Jan/11  Updated: 01/Jul/13  Resolved: 01/Jul/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 9
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: arjan tijms, Darious3, Ed Burns and rogerk

 Description   

A @ViewScoped bean will behave like a @RequestScoped bean when at least an
UIComponent is bound to the bean using binding attribute in the view. I.e. it
will be recreated on every request.

I can't find any line in the JSF specification if this is intentional or not.

A side effect is that UIData#getRowData() of the bound h:dataTable returns only
the 1st item everytime. When the bean is @RequestScoped, the UIData#getRowData()
returns the expected item.



 Comments   
Comment by arjan tijms [ 17/Apr/11 08:41 AM ]

See http://java.net/jira/browse/JAVASERVERFACES-1658 for additional details.

Comment by Darious3 [ 20/Dec/12 10:38 AM ]

Wasn't this fixed already by the way the view scope is handled now in JSF 2.2? (restoring the view scope first)

Comment by arjan tijms [ 19/May/13 12:37 PM ]

It looks like this has been fixed indeed.

I tested on GlassFish 4.0 b88 with the following Facelet:

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
>
    <h:body>
        <h:form id="form">
            <p>
                <h:outputText id="test" value="test component" binding="#{viewScopedBean.component}" />
            </p>
            
            <p>
                Output from bean:
                <h:outputText value="#{viewScopedBean.value}" />
            </p>
        
            <h:commandButton value="Submit form" action="#{viewScopedBean.doAction}" />
        </h:form>
    </h:body>
</html>

and the following bean:

@ViewScoped
@ManagedBean
public class ViewScopedBean {

    private Date date = new Date();
    private UIComponent component;
    private int postbackCount;
    
    private String value;

    public String doAction() {
        value = String.format("Postback: '%d' -- Bean created at: '%s' -- Component id: '%s'  -- Bean class id: '%s'",
            ++postbackCount,
            date,
            component.getClientId(),
            this
        );
                
        return null;
    }

    public UIComponent getComponent() {
        return component;
    }

    public void setComponent(UIComponent component) {
        this.component = component;
    }
    
    public String getValue() {
        return value;
    }
    
}

After the first postback I got:

test component

Output from bean: Postback: '1' -- Bean created at: 'Sun May 19 14:32:55 CEST 2013' -- Component id: 'form:test' -- Bean class id: 'beans.ViewScopedBean@552f82fe'

After the second:

test component

Output from bean: Postback: '2' -- Bean created at: 'Sun May 19 14:32:55 CEST 2013' -- Component id: 'form:test' -- Bean class id: 'beans.ViewScopedBean@552f82fe'

etc.

I also tried with the new JSF 2.2 CDI view scope and an @Named bean and there it also worked; after every postback the bean instance remains the same one and the counter correctly increases.





[JAVASERVERFACES_SPEC_PUBLIC-928] @ViewScoped fails when JSTL c:forEach or c:if is used in view Created: 31/Jan/11  Updated: 01/Jul/13  Resolved: 01/Jul/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 7
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: dwightd, Ed Burns, Hanspeter Duennenberger and rogerk

 Description   

A @ViewScoped bean will behave like a @RequestScoped bean when JSTL c:forEach or
c:if tag is been used in the view. I.e. it will be recreated on every request.

I can't find any line in the JSF specification if this is intentional or not.



 Comments   
Comment by Hanspeter Duennenberger [ 18/Apr/11 10:10 AM ]

I think http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-787 would solve this too.

Comment by dwightd [ 22/Feb/13 01:59 AM ]

This problem appears to be fixed in 2.1.18, at least in my environment (with ICEfaces 3.2). It was still broken in 2.1.17. Looking over the fixes in 2.1.18, it might be that http://java.net/jira/browse/JAVASERVERFACES-2688 fixed it, although I'm guessing somewhat. (I have a limited understanding of the cause and possible fixes!)

This also seems related to http://java.net/jira/browse/JAVASERVERFACES-1492





[JAVASERVERFACES_SPEC_PUBLIC-926] UIInput change Created: 31/Jan/11  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk

 Description   

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

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

private static boolean isEmpty(Object value) {

if (value == null) { return (true); } else if ((value instanceof String) &&
(((String) value).trim().length() < 1)) { return (true); } } else if (value.getClass().isArray()) {
if (0 == java.lang.reflect.Array.getLength(value)) { return (true); }
} else if (value instanceof List) {
if (((List) value).isEmpty()) { return (true); } }
}
return (false);
}

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

Thanks.
Description
We had an issue with UIInput type components regarding validation. If the user entered a lot of spaces in the Input field, the UIInput validator accepted the value as "filled out". We suggest to change the isEmpty function in the javax.faces.component.UIInput class to:
private static boolean isEmpty(Object value) {
if (value == null) { return (true); } else if ((value instanceof String) &&
(((String) value).trim().length() < 1)) { return (true); } } else if (value.getClass().isArray()) {
if (0 == java.lang.reflect.Array.getLength(value)) { return (true); }
} else if (value instanceof List) {
if (((List) value).isEmpty()) { return (true); } }
}
return (false);
}
Where we trim the value before examining the length of it: (((String) value).trim().length(), so a lot of space will not be a valid value. Thanks.
Show »






[JAVASERVERFACES_SPEC_PUBLIC-914] add ResourceWrapper#getContentType() or define resource behaviour for null values Created: 30/Nov/10  Updated: 07/Jun/11  Resolved: 19/May/11

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

Type: Improvement Priority: Major
Reporter: Mark Struberg Assignee: Hanspeter Duennenberger
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-917 add a JUnit test to make sure that cl... Resolved
Status Whiteboard:

size_medium importance_medium

Tags: 3_1-exclude
Participants: Ed Burns, Hanspeter Duennenberger, Mark Struberg and rogerk

 Description   

Component libraries which use the ResouceWrapper but do not explicitely override Resource#getContentType() will cause an undefined content Type (aka null).

So we either also provide delegation for this method in ResourceWrapper() or we define that the resource handler implementation must use the external context to determine the default contentType to use as fallback.



 Comments   
Comment by rogerk [ 30/Nov/10 11:28 AM ]

I would prefer to go the route of providing delegation in ResourceWrapper - see: http://java.net/jira/browse/JAVASERVERFACES-1879
However, this may be classified as a spec change and therefore we may not be able to get it into 2.1 (but let's see). To speed things up, can you provide a patch for the implementation workaround option?

Comment by rogerk [ 01/Dec/10 12:23 PM ]

Assign

Comment by rogerk [ 01/Dec/10 12:25 PM ]

Need to defer to 2.2 since this is a spec change.

Comment by Hanspeter Duennenberger [ 07/Dec/10 12:59 AM ]

The patch is attached to http://java.net/jira/browse/JAVASERVERFACES-1879

Comment by Ed Burns [ 08/Dec/10 11:28 AM ]

This should be done for 2.2

Comment by rogerk [ 18/Jan/11 11:26 AM ]

triage

Comment by Hanspeter Duennenberger [ 19/May/11 02:39 PM ]

This issue was resolved by JAVASERVERFACES_SPEC_PUBLIC-917





[JAVASERVERFACES_SPEC_PUBLIC-913] Unlabeled Navigation in HTML_BASIC RenderKit Docs Created: 30/Nov/10  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_small importance_small

Tags:
Participants: rogerk

 Description   

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






[JAVASERVERFACES_SPEC_PUBLIC-910] Can't render a multiline <selectone_radio/> or <selectmany_c.b.l/> Created: 15/Nov/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 910
Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns and rogerk

 Description   

Name: gm110360 Date: 03/17/2004

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

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

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

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

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

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

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

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

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

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



 Comments   
Comment by rogerk [ 16/Nov/10 08:05 AM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-908] StylesheetRenderer RenderKit Docs Request Path Rendering Created: 05/Nov/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 908
Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk

 Description   

The renderkit docs specify StykesheetRenderer directly renders the request path
gotten from Resource.getRequestPath(), when it should pass through
ExternalContext.encodeResourceURL() taking into account portlets.
the change has been done in implemetation (Mojarra) see:

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



 Comments   
Comment by rogerk [ 05/Nov/10 11:57 AM ]

triage

Comment by rogerk [ 16/Nov/10 01:04 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-907] Improve Ajax Http.Get support to (re)render parts of the page Created: 04/Nov/10  Updated: 17/Dec/13

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

Type: Improvement Priority: Critical
Reporter: mwessendorf Assignee: Unassigned
Resolution: Unresolved Votes: 5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 907
Status Whiteboard:

size_medium importance_large

Tags:
Participants: mwessendorf, rogerk and werpu

 Description   

The current JavaScript Ajax API should be improved to have a simplified version
that allows to "just" render (several) components, via GET.

A use case would be:
-You have a client side callback that get's invoked (e.g. when a
Bayeux/WebSocket notification arrives). Inside the callback you are simply only
interested in (re)rendering some components.

Today it would look like:

webSocket.onmessage = function(evt)
{
// work with evt.data.....
jsf.ajax.request('jsfForm:dummyBtn',null,{render:'listComp'});
};



 Comments   
Comment by mwessendorf [ 04/Nov/10 01:06 AM ]

Perhaps we could have something like:

/**

  • Issues an Http.GET request to render a set of components.
  • @param varargs that specify a list of components to re-render
    */
    jsf.ajax.renderRequest(varargs);
Comment by werpu [ 04/Nov/10 01:26 AM ]

I think this falls into a similar category like the ajaxed fileuploads, you have
to have a mechanism which allows a switchable transport layer.

We have the basics in myfaces already implemented, due to prototyping the ajax
fileupload for jsf 2.2, but a GET is missing on our side as well, but can be
easily added without too much effort.

Comment by mwessendorf [ 04/Nov/10 02:35 AM ]

For cases like this, another limitation is not only the POST. Also the fact that
'source' is needed..

jsf.ajax.request(source,null,{render.... });

the event can be NULL, but source (currently) not.

Therefore we may need a new function, e.g. renderRequest() - as said before

Comment by rogerk [ 04/Nov/10 06:33 AM ]

triage

Comment by rogerk [ 16/Nov/10 01:03 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-903] ResponseWriter markup enhancements Created: 29/Oct/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 903
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, kellerapps and rogerk

 Description   

Make the ResponseWriter responsible for ensuring the proper xmlns declarations are sent to the user
agent.



 Comments   
Comment by Ed Burns [ 29/Oct/10 09:31 AM ]

2.2

Comment by rogerk [ 16/Nov/10 08:05 AM ]

triage

Comment by kellerapps [ 18/Apr/11 12:56 PM ]

JSF components should support safe HTML. gwt recently added this. Should this be a separate issue?





[JAVASERVERFACES_SPEC_PUBLIC-899] cc:renderFacet renders wrapper component Created: 24/Oct/10  Updated: 07/Jun/11  Resolved: 27/Oct/10

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

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

Operating System: All
Platform: All


File Attachments: Zip Archive issue899-test.zip    
Issuezilla Id: 899
Status Whiteboard:

size_medium importance_large

Tags:
Participants: Ed Burns, michael_kurz and rogerk

 Description   

Every time cc:renderFacet is used in the implementation part of a composite
component, the contnet of the facet is wrapped in a parent component. This
behaviour is specified in the cc:renderFacet tag documentation:

"The implementation of this tag handler must insert a component with component-
type javax.faces.Output and renderer-type javax.faces.CompositeFacet as a child
at this point in the component tree."

This leads to problems with h:panelGrid and similiar components that work with
"direct" children. The followinf example shows the implementation part of a
composite component.

<h:panelGrid columns="2">
<cc:renderFacet name="header"/>
<cc:insertChildren/>
</h:panelGrid>

If this component is used like below the rendered table is broken. This is
caused by the fact, that the facet is handled as one child by h:panelGrid.

<jl:panelGrid>
<f:facet name="header">
<h:outputText value="Header 1"/>
<h:outputText value="Header 2"/>
</f:facet>
<h:outputText value="1.1"/>
<h:outputText value="1.2"/>
</jl:panelGrid>



 Comments   
Comment by michael_kurz [ 24/Oct/10 01:20 AM ]

Created an attachment (id=316)
I added a Maven-based test web application with a simple page and a composite component to demonstrate the problem. The app can be started with: mvn jetty:run-exploded -Pmojarra

Comment by Ed Burns [ 27/Oct/10 08:25 AM ]

triage

Comment by Ed Burns [ 27/Oct/10 09:37 AM ]

I really hate to do this, because you guys, Michel, Martin, and Hanspeter, are the most advanced JSF users I
know. But I have to ask, it seems that this case is precisely why we invented <cc:insertFacet>. In fact,
when I change the composite component declaration do be <cc:insertFacet> the page lays out as
expected.

I'm marking this as INVALID, but please re-open if I'm misunderstanding something.





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

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

Tags:
Participants: angelcervera, Ed Burns and rogerk

 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 02:43 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:03 PM ]

triage

Comment by Ed Burns [ 31/Jan/11 08:38 AM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-897] New getSessionId() for ExternalContext Created: 15/Oct/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 897
Status Whiteboard:

size_small importance_small

Tags:
Participants: Ed Burns, nick_belaevski and rogerk

 Description   

Please add getSessionId() method for ExternalContext. It's useful to provide
session handling for Flash-based components.



 Comments   
Comment by rogerk [ 27/Oct/10 02:42 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-892] ui:repeat requires document "begin" and "end" properties Created: 12/Oct/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 892
Status Whiteboard:

size_small importance_medium

Tags:
Participants: lu4242 and rogerk

 Description   

It was notice that ui:repeat implementation has "begin" and "end" properties,
but there are not mentioned in the javadoc.

After talk with Martin Marinschek, the conclusion was this is an undocumented
feature, but it is provided by Mojarra.



 Comments   
Comment by rogerk [ 27/Oct/10 02:39 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-891] converter and validator attributes TLD doc misleading Created: 07/Oct/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 891
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Hanspeter Duennenberger and rogerk

 Description   

UIOutput converter attribute allows assigning a literal to specify the
converterId of the converter to be used or a ValueExpression evaluating to an
instance of Converter.
TLD doc only mentions the ValueExpression as allowed type and also the
Description does not mention the possibility to pass the converterId.

The same is missing for validator attributes on input components - TLD doc only
mentions teh MethodExpression but says nothing about the literal validatorId
that can be used too.



 Comments   
Comment by rogerk [ 27/Oct/10 02:39 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-890] Give the ability to change the scope of <f:loadBundle> to ease its use in composites. Created: 26/Sep/10  Updated: 17/Dec/13  Resolved: 17/Dec/13

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

Type: Improvement Priority: Major
Reporter: grunt2000 Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 890
Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns, grunt2000 and rogerk

 Description   

When you have a page using these composites:
<myTools:a/>
<myTools:b/>
<myTools:c/>

and that these composites use a resource bundle by the mean of <f:loadBundle>
for their own work, you have to take care of using a unique variable for each of
them.

If you attempt to ease your coding by using the same variable each time in all
your composites, such as here (using x):
<html xmlns="http://www.w3.org/1999/xhtml" [...]>
</cc:interface/>

<cc:implementation>
<f:loadBundle basename="myWork_a" var="x" />
...

Then <myTools:a/>, <myTools:b/>, and <myTools:c/> will use the same bundle,
whatever their own basename is saying. (I don't remember if only the basename of
the myWork_a bundle will be used or only myWork_c).

Then, we have to find unique variables one to ensure our composite won't have
bundle variables that could collide. Like:
<f:loadBundle basename="myWork_a" var="xa" /> for component a,
<f:loadBundle basename="myWork_b" var="xb" /> for component b,
<f:loadBundle basename="myWork_c" var="xc" /> for component c.

and of course, it's a bit boring. The problem comes from <f:loadBundle> that has
a request scope, I think. Can something be done to allow it having only the
strict composite scope (= no scope at all?).

Regards,

Grunt.



 Comments   
Comment by rogerk [ 27/Oct/10 02:38 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:03 PM ]

triage

Comment by Ed Burns [ 17/Dec/13 03:39 PM ]

<f:loadBundle> is not the recommended way to perform I18N in JSF. Instead, use application level config in the faces-config.xml.





[JAVASERVERFACES_SPEC_PUBLIC-889] <ui:repeat> inner variable can't be transmitted to a composite. Created: 26/Sep/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 889
Status Whiteboard:

size_medium importance_small

Tags:
Participants: grunt2000 and rogerk

 Description   

This source code based on a <c:forEach> loop is able to work:

<c:forEach var="adresse" items="#{assoCtrl.association.adresses}">
<territoire:adresse adresse="#{adresse}" />
</c:forEach>


But this one, based on an <ui:repeat> loop, fails:

<ui:repeat var="adresse" value="#{assoCtrl.association.adresses}">
<territoire:adresse adresse="#{adresse}" />
</ui:repeat>

This message is received:
"<territoire:adresse> The following attribute(s) are required, but no values
have been supplied for them: adresse. "


As a test, I changed the content of my loop that way:
<ui:repeat var="adresse" value="#{assoCtrl.association.adresses}">
<!-- The address content is: #{adresse} -->
</ui:repeat>

And found that the HTML page is displayed, no Exception thrown by JSF 2.0.3
then. (I see that content on the HTML page that is created: <!-- The address
content is: Adresse [nom: , complément de nom: null, complément de voie: null,
voie: , code postal: 00000, ville: , pays: France, commentaire: null, types
adresse: []] -->).

Therefore, I think that the transmission of the var parameter of <ui:repeat> is
faulty when an inner composite is targeted. I made some tries by promoting the
value part of <ui:repeat> to various scopes, but without success.

Regards,
Grunt.



 Comments   
Comment by rogerk [ 27/Oct/10 02:38 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:02 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-888] UIInput.submittedValue returns Object, but Converter suggest only String is allowed Created: 23/Sep/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 888
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, lu4242 and rogerk

 Description   

The current conversion model is not good enough on some cases when it
is required the submitted value be something different than String, or on
more complex components that requires to send information from multiple html
"input" components.
This issue has been discussed earlier on myfaces list, as you can
see on the comments at the end of this mail:

To understand what's missing, I'll resume how the current conversion model
works. This could be redundant, but the intention is expose the reasons about
why it is wanted to extend the current model in a understandable way.

Every component that is used as a input has at least one "value binding" to a
bean. In UIInput, the user just set "value" property with an EL expression to
indicate that the value sent should be assigned to that expression.

Now suppose a form with this component that is submitted. The input component
should first create the "submittedValue" from the information available on
request parameter map. This is done on UIComponent or Renderer decode() method.
Then, this value is converted to the type required by the "value binding",
through Converter interface and later, if conversion fails by some reason, the
information stored on "submittedValue" will be used to render the component later.

Therefore, "submittedValue" must satisfy three conditions:

1. It should contain all info sent by the component through request parameter
map, otherwise the renderer will not be able to render the component correctly.
2. It should be on a way that can be converted to the type indicated by "value
binding", that means the submittedValue type should be a public class, so the
renderer can instantiate it and conversion model can process it.
3. The component should be responsible to define the type used by submitted
value, according to its needs.

Now, let's take a look at the current Converter interface:

public interface Converter

{ /** * used to map the submittedValue to the "value binding". */ Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException; /** * used to convert the "value binding" into a String to be used * on the renderer. */ String getAsString(FacesContext context, UIComponent component, Object value) throws ConverterException; }

Note that JSF provide some converters for the most common types, so the user can
specify which converter use or let JSF decide which one fits best, using
the converters registered with "forClass" mapping. Yes, that's ok, but only for
components with only one "<input>". In that case, assume String as submitted
value type looks better and keep things simple.

Things start to get confusing when you see the signature of
UIInput.getSubmittedValue():

public Object getSubmittedValue()

Does the conversion model did not make the assumption that String is the only
type to be used by submittedValue?

But this assumption fails when a more complex component is required. The typical
example is a component that handles date/time values. In that case, the
date/time value can be decomposed into its elements (year, month, day, hour,
minutes ....). In this case, a component developer could want to send all that
info into multiple "<input>" parameters through request parameter map. So, to
use the model proposed, all that information should be used to encode a String,
just to later decode it on the converter used to construct the "value binding"
required, but later it will be decoded/encoded by the renderer again to render
the component.

The proposal to put into consideration is do the following modifications on jsf:

  • Add a class called BusinessConverter (maybe you can find other name but for
    now let it as is) :

public interface BusinessConverter

{ public Object getBusinessValue(FacesContext context, UIComponent component, Object submittedValue); public Object getAsSubmittedValue(FacesContext context, UIComponent component, Object value); }

Really is similar to Converter interface but does not force submittedValue to be
String, instead it lets it open.

  • Add the following methods to Application class :

public abstract void addBusinessConverter(Class<?> submittedClass,
Class<?> targetClass,
String converterClass);

public abstract void addBusinessConverter(String businessConverterId,
String businessConverterClass);

public abstract Converter createBusinessConverter(Class<?> submittedClass,
Class<?> targetClass);

public abstract Converter createBusinessConverter(String businessConverterId);

public abstract Iterator<String> getBusinessConverterIds();

public abstract Iterator<Class<?>> getBusinessConverterTypes(Class<?>
submittedClass);

Again, it is similar to converter methods on Application class, but in this case
it takes into consideration the submittedClass. Therefore, a component that
define as submittedClass java.util.Date, could retrieve the converters that can
handle this conversion. From some point of view, the current Converter interface
is a particular case when submittedClass is java.lang.String.

  • Add the following methods to UIOutput class :

public BusinessConverter getBusinessConverter();

public void setBusinessConverter(BusinessConverter converter);

/**

  • Return the value type the submitted value will take on
  • decode() method. In my opinion, allow just one submittedValueType is
  • enough.
    */
    public Class<?> getSubmittedValueClass();

The idea is provide a way to configure business converter, just like Converter.
Note this implies change some stuff on UIInput too.

  • Add an annotation @FacesBusinessConverter.
  • Add a component f:businessConverter in the same way as f:converter.

I would like to put into consideration this idea. My personal opinion is this
should be included at the spec level for two reasons:

  • It is clear there is a contradiction between UIInput.getSubmittedValue() and
    Converter interface.
  • It could be good to have a common repository for business converters, and use
    JSF annotations to register it.

I have some code I'm working but it is better to know if you think it is worth
or not before continue. If it is necessary I can help with the implementation.

Suggestions are welcome

best regards,

Leonardo Uribe

Note: As an historical comment, currently, Trinidad has a workaround for handle
handle "oracle types", from the binding layer, using an interfaces called
TypedConverter as you can see below:

package org.apache.myfaces.trinidadinternal.convert;

public interface TypeConverter

{ /** * converts the given Object into an instance of the * targetType. * @return an instance of the targetType. */ Object convert(Object source, Class<?> targetType); }

The idea behind this interface is provide a way that trinidad can "understand"
specific types and include them when are resolved, but note this class is not
part of trinidad api. The reason is this is just an internal workaround.

COMMENTS FROM OTHER PEOPLE SUPPORTING THIS ISSUE:

Martin Koci

MK>> maybe this is a stupid question but:
MK>>
MK>> >From UIInput javadoc:
MK>>
MK>> ... decoded value of this component, usually but >>>not necessarily a
MK>> String<<<, must be stored - but not yet converted - using
MK>> setSubmittedValue() ....
MK>>
MK>> from UIInput.getConvertedValue:
MK>>
MK>> ... and the submitted value is a >>>String<<<, locate a Converter as
MK>> follows
MK>>
MK>> Question: why is Converter tied only to String? Whole specification
MK>> speaks about submitted value as of "raw representation of value from
MK>> client" but not necessarily String. And 3.3 Conversion Model: "This
MK>> section describes the facilities provided by JavaServer Faces to support
MK>> type conversion between server-side Java objects and their (typically
MK>> String-based) representation in presentation markup."
MK>> But Converter.getAsObject expects only String as this "raw
MK>> representation" and "typically String-based" formulation from spec now
MK>> means "always String-based".
MK>> It seems to me that Converter introduces unnecessary dependency on
MK>> String-based representation - even ResponseWriter.write* accepts
MK>> java.lang.Object as value ....
MK>>
MK>> What I try to do is JSF-based server view with custom NOT-string based
MK>> protocol where "raw representations from client" can be java object like
MK>> Integer or more complex. Creating of:
MK>>
MK>> interface Converter2 { MK>> Object getAsObject(FacesContext,UIComponent,Object) MK>> Object getAsRepresentation(FacesContext,UIComponent,Object) MK>> }
MK>>
MK>> solves my problem but I must reprogram significant part of JSF api.

Martin Marinschek

MM>> MK>> So on JSF level conversion String <-> Object is unable to solve this
MM>> MK>> problem - I simply need Object <-> Object conversion which is not
MM>> MK>> supported yet.
MM>>
MM>> Yes, this is true - this is obviously a spec problem.
MM>>
MM>> If the submitted value is an object, it should also be allowed to
MM>> convert it. A converter is more than just a string to object (and
MM>> back) converter, it is an artefact which transforms information from
MM>> its representation for output (and this output could be anything, and
MM>> certainly doesn't have to be string based) to its representation which
MM>> the business model (or also an artefact within JSF, like a validator)
MM>> understands.
MM>>
MM>> So I agree. This hasn't come up so far cause nobody uses non string
MM>> based output models for JSF.
MM>>
MM>> Note that my notion of a business converter (discussed on this mailing
MM>> list a while ago) for converting between a business model
MM>> representation and a representation in a JSF artefact like the
MM>> renderer (e.g. you use joda.Date in the business model, but the JSF
MM>> date picker renderer only understands the normal java date) is also
MM>> hinting in the direction that such an additional converter API would
MM>> be necessary. I discussed this with the EG (and also Ed privately),
MM>> and there wasn't much interest for adding this.



 Comments   
Comment by Ed Burns [ 19/Oct/10 01:15 PM ]

Target for 2.2.

Comment by rogerk [ 27/Oct/10 02:47 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:02 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-887] Allow locale fallback with resource loading Created: 17/Sep/10  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 887
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: cayhorstmann, Ed Burns and rogerk

 Description   

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=548
describes that the current attempt at providing localizable resources is
irretrievably broken.

In addition to the issues noted in issue 548, note that the proposed scheme
doesn't play nicely with versioning. If someone versions a library, that
particular library version may have support for different locales. That is, the
library version should be resolved first, then the locale.

Here is a proposed enhancement (which depends on the implementation of
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=885).

In 2.6.1.3, allow resource identifiers of the form

[libraryName/][libraryVersion/][locale/]resourceName[/resourceVersion]

where locale is a regex of the form [A-Za-z]{2}(_[A-Za-z]{2}(_[A-Za-z]+)?)?

In 2.6.1.4 function deriveResourceId, require inspection of the directories

libraryName/language_locale_variant
libraryName/language_locale
libraryName/language
libraryName

for locating a resource, in the case that localePrefix is null.

This behavior is what people would expect from a Java SE ResourceBundle.

Note that this is a compatible change. Anyone who wants the old behavior simply
adds a ResourceHandler.LOCALE_PREFIX to the application's message bundle. Anyone
who wants the new behavior doesn't do that but instead adds locale directories.
If someone does neither, there is no change in behavior.



 Comments   
Comment by Ed Burns [ 26/Oct/10 09:44 AM ]

2.2

Comment by rogerk [ 27/Oct/10 02:47 PM ]

triage

Comment by Ed Burns [ 19/Dec/13 10:39 PM ]

We've done all we plan to do on this issue in 2.2.





[JAVASERVERFACES_SPEC_PUBLIC-886] Allow hierarchical resource library names Created: 17/Sep/10  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

Type: Improvement Priority: Major
Reporter: cayhorstmann Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 886
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: cayhorstmann, Ed Burns and rogerk

 Description   

The spec is a bit unclear about this, but it appears that hierarchical resource
library names are not supported. It is desirable to support them for two reasons.

1) It allows developers greater flexibility in structuring their resources and
composite components
2) It allows for longer package names with backing components for composite
components.

(NB. Mojarra will load hierarchical names such as components/util.)

Two changes are required.

1) In section 2.6.1.3, add a bullet that a libraryName is a /-separated sequence
of libraryDirname. If
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=884 is
adopted, specify that each libraryDirname must not match the regexes for
versions or locales.

2) In
https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Application.html#createComponent(javax.faces.context.FacesContext,%20javax.faces.application.Resource),
change

let fqcn be library-name + "." + resource-name

to

let fqcn be library-name.replace("/", ".") + "." + resource-name



 Comments   
Comment by cayhorstmann [ 17/Sep/10 09:05 PM ]

Changed to Enhancement

Comment by cayhorstmann [ 17/Sep/10 09:09 PM ]

That's
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=885, not
884 in part 1).

Comment by Ed Burns [ 26/Oct/10 09:44 AM ]

2.2

Comment by rogerk [ 27/Oct/10 02:46 PM ]

triage





Relative Resources (JAVASERVERFACES_SPEC_PUBLIC-947)

[JAVASERVERFACES_SPEC_PUBLIC-884] Support library prefix in resource URLs Created: 17/Sep/10  Updated: 08/Nov/13

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

Type: Sub-task Priority: Major
Reporter: cayhorstmann Assignee: Unassigned
Resolution: Unresolved Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


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

size_small importance_medium

Tags:
Participants: cayhorstmann, Ed Burns, Jakob Korherr, lamine_ba, ramiromagalhaes and rogerk

 Description   

Consider a stylesheet

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

Resources are loaded with URLs such as

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

(when prefix mapping is used).

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

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

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

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

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

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

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

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

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

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

javax.faces.RESOURCE_URL_MAPPING with options prefix and param

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

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


 Comments   
Comment by Ed Burns [ 26/Oct/10 09:45 AM ]

2.2

Comment by rogerk [ 27/Oct/10 02:45 PM ]

triage

Comment by ramiromagalhaes [ 14/Apr/11 10:35 AM ]

This is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900.

Comment by lamine_ba [ 14/Apr/11 02:10 PM ]

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

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

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

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

If would be nice if we could come back to this

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

Comment by Jakob Korherr [ 15/Apr/11 03:19 AM ]

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

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





[JAVASERVERFACES_SPEC_PUBLIC-882] Specification talks about non existing APIs Created: 09/Sep/10  Updated: 19/Dec/13

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

Type: Bug Priority: Critical
Reporter: mwessendorf Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 882
Status Whiteboard:

size_small importance_medium

Tags:
Participants: mwessendorf and rogerk

 Description   

I opened this version of the spec:

Version: 2.0 Rev A
Status: Final Release
Release: 9 July 2010

It talks about FacesContext.isPartialRequest() - Note this method does not
exist. A similar is available on PartialViewContext.

Also it talks about FacesContext.isAjaxRequest() AND
PartialViewContext.isAjaxRequest() - Note: the first one does not exist as well



 Comments   
Comment by mwessendorf [ 09/Sep/10 05:50 AM ]

Also from reading the PartialViewContext JAvaDoc it is not clear (to me) what
the main difference is between the two.

Comment by rogerk [ 27/Oct/10 02:37 PM ]

triage - partially fixed





[JAVASERVERFACES_SPEC_PUBLIC-879] Decoder that act as separate functionality Created: 29/Aug/10  Updated: 19/Dec/13

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

Type: Improvement Priority: Critical
Reporter: vladperl Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 879
Status Whiteboard:

size_large importance_large draft

Tags:
Participants: rogerk and vladperl

 Description   

I suggest to introduce concept of decoders as functionality that works
independently from rendering functionality. JSF already has dedicated Renderer
class. So it makes sense to do the same thing for decoding functionality.
The first benefit from this approach would be possibility to send data from
client directly to decoder, skipping on the way to it necessity to use JSF
components and JSF life cycle. JSF developers will be able to create more
stateless JSF applications and use Javascript libraries in more flexible than
now manner.

The first usage of decoder would be the following kind of scenario:

client side:
jsf.ajax.post({data:{'dataHolder.value': value1}, render: 'input1');

server side:
if (isDataRequest(context.getExternalContext().getRequestHeaderMap())) { Decoder.handleDataRequest(context); context.responseComplete(); }

...
ValueExpression ve = getValueExpression(context, key);
ve.setValue(context.getELContext(), o.get(key));
...

Note: The first argument of the method "post" would be optional and called "url".
In case if developer need to customize handling of data from client we will use
this argument as way to identify decoder that will handle the data.

Complete signature of the Javascript method could be defined something like this:
jsf.ajax.post([url], [data], [handleAs], [render], [onSuccess(data)],
onError(data)]);



 Comments   
Comment by vladperl [ 29/Aug/10 08:38 PM ]

The following link seems could be used as supporting point:
http://forums.java.net/jive/thread.jspa?messageID=481227

Comment by rogerk [ 27/Oct/10 02:35 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:02 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-878] FacesContext.setUIViewRoot Spec Inconsistent With Implementation Created: 27/Aug/10  Updated: 07/Dec/12  Resolved: 21/Oct/10

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

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

Operating System: All
Platform: Macintosh


File Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES-1792 FacesContext.setUIViewRoot Should Onl... Closed
Issuezilla Id: 878
Status Whiteboard:

size_small importance_medium

Tags: changelog_2_1
Participants: Ed Burns and rogerk

 Description   

Currently, the Javadocs for FacesContext.setViewRoot say:

"This method can only be called by the application handler (or a class that the
handler calls), and only during the Invoke Application phase of the request
processing lifecycle."

However, FacesContext.setViewRoot is also called during the RestoreViewPhase,
especially when a new ViewRoot is created.



 Comments   
Comment by rogerk [ 27/Aug/10 07:25 AM ]

Target.

Comment by rogerk [ 27/Aug/10 07:57 AM ]

started

Comment by rogerk [ 27/Aug/10 08:00 AM ]

Created an attachment (id=275)
Changes

Comment by rogerk [ 27/Aug/10 08:04 AM ]

The modified language will be:

+ * <p class="changed_modified_2_1">This method can
+ * be called by the application handler (or a class that the
+ * handler calls), during the <em>Invoke Application</em>
+ * phase of the request processing lifecycle and during the
+ * <em>Restore View</em> phase of the request processing
+ * lifecycle (especially when a new root component is
+ * created).</p>

Comment by rogerk [ 27/Aug/10 08:08 AM ]

Checked in.

Comment by Ed Burns [ 21/Oct/10 09:18 AM ]

Add changelog_2_1 keyword





[JAVASERVERFACES_SPEC_PUBLIC-877] allow declarative configuration of ELContextListener in faces-config Created: 19/Aug/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 877
Status Whiteboard:

size_small importance_small

Tags:
Participants: manuelbernhardt and rogerk

 Description   

Currently the only way of registering an ELContextListener seems to be programmatically via
Application#addELContextListener().

It would be interesting to allow declarative configuration via a key (e.g. el-context-resolver) in the
<application> section of the faces-config schema.



 Comments   
Comment by rogerk [ 27/Oct/10 02:34 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:02 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-876] ViewChangedEvent Created: 13/Aug/10  Updated: 08/Nov/13

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 876
Status Whiteboard:

size_small importance_small

Tags:
Participants: Darious3, Ed Burns, Hanspeter Duennenberger and rogerk

 Description   

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

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



 Comments   
Comment by rogerk [ 27/Oct/10 02:33 PM ]

triage

Comment by Hanspeter Duennenberger [ 06/Jun/11 09:24 AM ]

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

Comment by Ed Burns [ 06/Jun/11 09:40 AM ]

##jsf freenode IRC discussion

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

  • rogerk1 (~Adium@pool-96-237-170-36.bstnma.fios.verizon.net) has joined ##jsf
    <edburns> hpdueni: When you say "reset all component bindings" do you mean that funny little traversal we do of the tree before really getting started with the lifecycle?
    <hpdueni> or what we already have in CS JSF is a Bindings bean that should be used for all component bindings - and that one is cleared whenever ViewRoot changes
    <ioss> hpdueni: if your binding would always return null, wouldn't that solve the problem? not sure I got your issue right?
    <hpdueni> with reset component binding when viewroot changes I mean, the backing bean which holds the bound component must release that component which is from the previous view
    <ioss> or why would you want to hold the component for longer then a request?
    <hpdueni> for simplicity we used e.g. h:panelGroup bindgin="#{facesContext.attributes['someid']} " and then ass that el into another CC to pass on teh dynamic clientId
    <hpdueni> ioss: that problem already happens within one request - as required, we never hold bindings longer than a request.
    <hpdueni> ioss: but as it tunred out, request scope is already too long in case when viewroot changes -
    <edburns> hpdueni: Yes, I know requestscope is too long when the viewroot changes, but I'm still trying to understand your quandry.
    <hpdueni> edburns: exactly, since the component that was created in restore phase is bound to something in request scope, the component is still there after viewRoot changed and therfore Application.createComponent() will not be invoked and none of teh resource dependencies are detected
    <ioss> Hanspeter: how about always returning null?
    <ioss> then your component binding should get reset on the render-phase
    <ioss> you should possibly get a call on restore-view and another one after the view changes
    <edburns> ak: I see. Actually, there were no changes in the XSD for facelet taglibs in 2.1, so you can just use the 2.0 one.
    <hpdueni> ioss: if teh binding always returns null I can't use it anymore to pass component references to some other component ...
    <ioss> hpdueni: sure, name the binding in another way
    <ioss>
    <edburns> In fact, I just had to make the first change in the facelet taglib xsd since 2.0 a few weeks ago.
    <ioss> getTemplateComponent => null, setTemplateComponent => normal setter + getComponent => returns the one that was set by setTemplateComponent
    <hpdueni> ioss: would mean to have one attribute name with only a set method to pass teh component and another read-only name to retrieve it ...
    <ioss> right
    <hpdueni> ioss: that could work, would that be your general recommendation for component binding ?
    <ioss> hpdueni: not the nicest approach I agree, but still not horrible I would say
    <ioss> hpdueni: for components that you will never provide yourself (you can not return null there) I guess it is a possible approach
    <ioss> hpdueni: I nearly never use componentbinding
    <ioss> hpdueni: I am more a "lookup"-guy
    <hpdueni> ioss: yea, it has its pitfalls
  • mbenson_ (~mbenson@apache/committer/mbenson) has joined ##jsf
    <ioss> also there is a myfaces codi extension to bind components to longer scopes, that works that way (I think it is still in development)
    <edburns> ak: Can you please file an issue in the docmentation sub-component on this JIRA: http://java.net/jira/browse/JAVASERVERFACES
    <hpdueni> ioss: now we are close to what we do - we actually need to pass the id of one component to some CC - but as the component's clientId is unknown at development time we pass the component using this binding .
    <ioss> hpdueni: so the template author does not know the id?
    <hpdueni> ioss: not the full clientId - that may change depending on if you are running as a web app or as a Portlet - both is possible from the same web app instance
    <ioss> hpdueni: If it is different templates (inclusion/etc) it is probably cleaner to bind the component in question
    <ioss> ok
    <ioss> so this is really some sort of fire-and-(partially)-forget
    <ioss> i guess a readonly property describes exactly your "contract", as that component is never meant to be set directly
    <ioss> directly=by java code
    <ioss> by java code=non jsf implementation java code
    <hpdueni> ioss: kind of, but still I need a writable property to get hold on the component which I want to read-only from somewhere else
    <hpdueni> I just think some of the new features interfere with component binding and we need a general approach for that
    <ioss> hpdueni: if you like to go creazy you could add an ELResolver, that will set even a private property
    <ioss> or one that will return null always when el is used
    <ioss> that's actually not to bad
    <ioss> if you can come up with a naming convention, or annotations
    <ioss> or a "fake" scope
    <ioss> #{componentwriteonlybinding.mybean.property}
    <ioss> so setter and getter would work normally, but el will always return null
    <ioss> hpdueni: but i think the viewchangedevent is not a bad one, you'll just have to find a good place to "bind" them too
    <hpdueni> ioss: sounds somehow weird - actually, thinking on that kind of use my binding should work as readonly only while component tree is built - (buildView) - to prevent passing the component to the new view and allow Application.createComponent() doing it's work
    <hpdueni> ioss: I wouldn't like another ELResolver for that as there are already so many ELResolvers involved - and writing to private method would involve reflection and is somehow dirty
    <hpdueni> ioss: talking about face scope - a custom scope could hanlde that
    <ioss> hpdueni: right
    <hpdueni> ioss: on the other hand, I'd like a solution for all JSF users, not only the ones that are aware of that potential problem
    <ioss> hpdueni: couldn't you use a prerender event?
    <ioss> hpdueni: it guess it does not matter for you, if the view changed or not, you just have to get rid of that component before rendering
    <hpdueni> ioss: sure - to always get a fresh or updated component in buildView all such bindings could be thrown away in before render phase
    <ioss> hpdueni: I think a scope is the easiest way to cope with that for now. either clean the scope, or let the scope have a "special" getter, while the normal getter will return null always
    <hpdueni> ioss: but now, where does that lead us - would that mean standard bindings usage should behave always like this? Then we could really use a BindingsScope to support that
    <ioss> hpdueni: well i wouldn't call it bindingscope, but there might be use for a scope that has a "half-request" lifetime
    <hpdueni> ioss: such a bindings scope would survive during the execute phases and be a separate instance for the render phase
    <ioss> right
    <hpdueni> ioss: whatever it's called - it would have separate lifetime for execute phases and render phase
    <hpdueni> ioss: that is pretty close to the two Portlet phases
    <ioss> you could probably even use it for some fancy persistence stuff, like make the "execute" phase transactional and write enabled, while the request-phase would have an long-running em to cope with lazy-load, but also would not allow to persist anything
    <ioss> Reminds me, that I have to read about portlets!
    <hpdueni> ioss: guess we close the discussion for now - was anybody else listening on that? Any other positions on that?
    <edburns> hpdueni: Ok, so ioss proposed a workaround involving an extra javabeans property, and then the discussion went to having a scope for this use-case.
    <hpdueni> edburns: yes, some special ELResolver was also in discussion
    <edburns> hpdueni: But really, this is closelely related to <http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876>.
    <edburns> Let me capture this discussion to the comment thread on the issue.
    <hpdueni> edburns: what would be a solution for everybody - or should binding be considered as advanced usage where one has to know the bindings might need to be cleared in certain cases even in the middle of the request?
Comment by Darious3 [ 07/Oct/12 10:42 AM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-875] Add Facelets attribute to limit EL scope to explicitly declared parameters Created: 13/Aug/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 875
Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns and rogerk

 Description   

>>>>> On Mon, 09 Aug 2010 21:08:00 -0400, Ryan de Laplante said:

R> It would be nice have a new attribute on ui:composition and ui:decorate
R> that tells it to NOT allow the template have access to the global EL
R> context. Instead, only the ui:insert and ui:param values within the
R> ui:composition or ui:decorate would be accessible to the template.
R> This I would enable me to allow my customers to input their own facelet
R> templates from the web UI of the SaaS application.



 Comments   
Comment by rogerk [ 13/Aug/10 11:40 AM ]

eval

Comment by rogerk [ 27/Oct/10 02:33 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:01 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-874] Clarify Executing Element Id In Ajax Request Created: 05/Aug/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 874
Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk and werpu12

 Description   

On 8/3/10 10:45 AM, Werner Punz wrote:
> Hello while doing another round of testing and optimisations I noticed a
slight difference in the implementations of the request of mojarra and myfaces
which opened an area where the spec probably is unclear:
>
> Following case:
>
> <h:panelGroup id="bla">
>
> <h:inputText id="inputbla" value="#{myBean2.searchTerm}" />
>
> <h:commandLink value="Press me for more action"
action="#{myBean2.doSearch}">
> <f:ajax execute="bla" render="content"/>
> </h:commandLink>
> </h:panelGroup>
>
> now results in following post data:
>
> Mojarra:
>
> form2 form2
> form2:inputbla
> javax.faces.ViewState 6697453697014869722:-1090088301633916042
> javax.faces.behavior.even... action
> javax.faces.partial.ajax true
> javax.faces.partial.event click
> javax.faces.partial.execu... form2:j_idt8 form2:bla
> javax.faces.partial.rende... form2:content
> javax.faces.source form2:j_idt8
>
>
> in myfaces
> form2:inputbla
> form2_SUBMIT 1
> javax.faces.ViewState
EmWJgKYkJoTEWDCzpUwZQR3Ek94rGnxK1V6NEZgO6yDgPANeOc1wplJjDYezu2cx9aQ7ZSKNPyGY
L8P9y5DwH2codFvGPjklD04wuxG4XXTPutNww3pdzIsMkw0=
> javax.faces.behavior.even... action
> javax.faces.partial.ajax true
> javax.faces.partial.event click
> javax.faces.partial.execu... form2:bla
> javax.faces.partial.rende... form2:content
> javax.faces.source form2:j_id1980473354_760ba132
>
>
>
> While most of the differeing data is mostly implementation specific and
therefor it is not that interesting following is:
> javax.faces.partial.execu... form2:j_idt8 form2:bla
>
> compared to
>
> javax.faces.partial.execu... form2:bla
>
> Now the difference is that Mojarra adds the executing element as it seems
> while MyFaces does not.
> The second interesting fact is following definition from the spec:
>
> * Determine additional arguments (if any) from the options argument. If
options.execute exists:
> o If the keyword @none is present, do not create and send the post
data argument javax.faces.partial.execute.
> o If the keyword @all is present, create the post data argument with
the name javax.faces.partial.execute and the value @all.
> o Otherwise, there are specific identifiers that need to be sent.
Create the post data argument with the name javax.faces.partial.execute and the
value as a space delimited string of client identifiers.
> * If options.execute does not exist, create the post data argument with
the name javax.faces.partial.execute and the value as the identifier of the
element that caused this request.
>
>
> Which means exactly, that I am not sure which behavior is correct and which
not. My personal guess is that both implementations are
> correct because the spec clearly leaves it open if the issuing element also
can be added to the exec list unless no exec list is given at all.
> But that is merely an assumption on my side here.
> Any ideas on this.
>
> Werner

On 8/4/10 3:31 AM, Martin Marinschek wrote:
> Hi Werner,
>
> I think some clarification would certainly be good there (especially
> as the language doesn't really say what client identifiers should be
> present, plus once talks about client identifiers, and once about
> identifiers only). My POV: for now, Mojarra and MyFaces should behave
> the same. The sentence following the one that you highlighted in bold:
>
> "...with the name javax.faces.partial.execute and the value as the
> identifier of the element that caused this request..."
>
> indicates to me that the triggering client id should be there.
>
> best regards,
>
> Martin

On 8/4/10 5:08 AM, Werner Punz wrote:
> Hi,
> I just did some further digging around in the code specially since I am
currently doing some optimisation stuff in that area in myfaces. And I came to
the conclusion that Mojarras behavior breaks the spec.
>
> The reason. The spec itself leaves it open, but we have an implicit @this
parameter which can be set both in execute and in render
> and if this @this parameter is set then the issuing client id has to be set in
the list where it is set.
> So the spec clearly states here that @this is a placeholder for the executing
element. If is allowed in exec, appending automatically the issuing client id is
pointless.
>
> Werner



 Comments   
Comment by rogerk [ 05/Aug/10 08:08 AM ]

Evaluate

Comment by rogerk [ 27/Aug/10 06:13 AM ]

For now re-target for 2.2.
If time permits may revisit for 2.1.

Comment by rogerk [ 16/Nov/10 01:01 PM ]

triage

Comment by werpu12 [ 06/Mar/12 03:15 PM ]

Ok MyFaces has in the meanwhile cloned mojarras behavior in this regard. So we probably can nail down the mojarra status quo into the spec.





[JAVASERVERFACES_SPEC_PUBLIC-873] Add pre and post ajax transaction function callbacks Created: 03/Aug/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 873
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

Use case: say the user wants to use some effect to fade in/out the content to be updated via Ajax. It
would be nice to have a way to install pre-request and post request callback functions. On the post
request, we need to have actually two functions. One when we have the response but have not yet done
the replacement, and another after we have done the replacement.



 Comments   
Comment by rogerk [ 27/Oct/10 02:32 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:00 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-872] The View Metadata tag is not processed unless at least one <f:viewParam> is defined Created: 29/Jul/10  Updated: 19/Dec/13

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

Type: Bug Priority: Critical
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 872
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: arjan tijms, Ed Burns, lincolnbaxter and rogerk

 Description   

Section 2.2.1 of the JSF 2 spec requires that if no view-parameters exist in the
view-metadata, that the render response phase be invoked immediately following
the current phase on a GET request. This prevents custom metadata from being
provided that may require lifecycle processing (view-actions, for example.)

This is a hindrance to creating custom metadata-since even if a tool (such as
prettyfaces) wishes to add custom url-parameter handling (or custom action
invocation), it must also add an empty view-param in order to trigger the
lifecycle. Also, not many people expect this behavior, since it is relatively
counter-intuitive.

I propose defining a new contract that would allow for individual meta-data
components to determine whether or not the full lifecycle should be invoked:

public interface ViewMetadata {
/**

  • If true, the full faces lifecycle will be invoked; if false, the
  • lifecycle will skip directly to render-response, unless another
  • {@link ViewMetadata} object requests that the lifecycle be executed.
    */
    public boolean requiresLifecycle();
    }

This new contract would still honor the behavior of previous implementations,
and should be mostly backwards compatible (because unless the custom tag
requests the lifecycle, it will still be skipped.)

The current spec verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. Call
ViewMetadata.getViewParameters(). If the result is a non-empty Collection, do
not call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."



 Comments   
Comment by lincolnbaxter [ 29/Jul/10 08:26 AM ]

I'd like to revise my proposal; I now oppose my original suggestion of adding a
new interface:

Solution:

It's possible we could just get away with changing the verbiage a little bit in
order to resolve this issue, thereby avoiding changes to any existing, or adding
any new APIs. (Note the **starred** change.) The change is very subtle, and
not very invasive, but perfectly addresses this situation.

The current spec verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. ***Call
ViewMetadata.getViewParameters()***. If the result is a non-empty Collection,
do not call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."

Proposed verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. ***Call
ViewMetadata.getChildren()***. If the result is a non-empty Collection, do not
call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."

Comment by rogerk [ 27/Oct/10 02:32 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

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

Comment by arjan tijms [ 20/Mar/13 03:56 PM ]

I think this is an exact duplicate of JAVASERVERFACES_SPEC_PUBLIC-762.





[JAVASERVERFACES_SPEC_PUBLIC-871] Need events before and after the entire JSF lifecycle processing Created: 26/Jul/10  Updated: 19/Dec/13

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

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

Operating System: Linux
Platform: PC


Issuezilla Id: 871
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, lincolnbaxter and rogerk

 Description   

In order to facilitate custom contexts and other extensions, it would be helpful
if there were events to mark the beginning and end of the JSF lifecycle.

PreExecuteLifecycleEvent
PostExecuteLifecycleEvent

This would enable bean/transaction/security creating/interception at a time that
is independent of phase listeners, which present ordering problems when users
create custom phase listeners, and also cause issues when dealing with exception
handling, since exception handlers are created outside of the faces lifecycle:

https://jira.jboss.org/browse/SEAMFACES-42



 Comments   
Comment by rogerk [ 27/Oct/10 02:29 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-870] Need a PreNavigate system event Created: 26/Jul/10  Updated: 19/Dec/13

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

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

Operating System: Linux
Platform: PC


Issuezilla Id: 870
Status Whiteboard:

size_medium importance_small

Tags:
Participants: lincolnbaxter and rogerk

 Description   

In order to properly intercept and extend navigation, it would be helpful to
have a PreNavigateEvent that included the current target navigation case (as
returned by:

public abstract NavigationCase getNavigationCase(FacesContext context, String
fromAction, String outcome);

public class PreNavigateEvent extends SystemEvent
{
public NavigationCase getNavigationCase() {...}
}



 Comments   
Comment by rogerk [ 27/Oct/10 02:28 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:00 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-869] Specify CSRF Solution Created: 23/Jul/10  Updated: 14/Dec/11  Resolved: 14/Dec/11

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Ed Burns
Resolution: Fixed Votes: 5
Remaining Estimate: 4 days
Time Spent: 1 day
Original Estimate: 5 days
Environment:

Operating System: All
Platform: Macintosh


File Attachments: Text File 20110920-i_spec_869.patch     Text File 869-hidden.txt     Text File 869-hidden.txt     Text File 869-hidden.txt     Text File 869-hidden.txt     Text File 869-url.txt     Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt     Text File i869.patch    
Issue Links:
Dependency
depends on JAVASERVERFACES-2269 Verify implementation of CSRF protection Closed
depends on JAVASERVERFACES-2204 Optimize performance of JAVASERVERFAC... Closed
Issuezilla Id: 869
Status Whiteboard:

size_medium importance_large draft

Tags:
Participants: arjan tijms, dened, Ed Burns, kellerapps and rogerk

 Description   

The specification should specify a solution for preventing CSRF (Cross Site
Request Forgery) for implementations to use. See:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812



 Comments   
Comment by rogerk [ 23/Jul/10 07:27 AM ]

Target

Comment by rogerk [ 13/Aug/10 05:07 AM ]

target

Comment by rogerk [ 25/Aug/10 05:48 AM ]

Kito has described potential solutions as well in:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=559

Comment by rogerk [ 13/Sep/10 08:20 AM ]

target MS6

Comment by rogerk [ 19/Sep/10 05:41 PM ]

The following attachment is for the "hidden field" approach for the CSRF
solution. Essentially a "javax.faces.ViewToken" hidden field is rendered
during Form rendering. This hidden field value is compared to the token
generated from a "secret key" stored in the session during Restore View Phase
processing.

Comment by rogerk [ 19/Sep/10 05:42 PM ]

Created an attachment (id=282)
Changes For The Hidden Field CSRF Approach

Comment by rogerk [ 19/Sep/10 06:16 PM ]

Created an attachment (id=283)
Revised Hidden Field Approach Change Bundle

Comment by rogerk [ 19/Sep/10 07:35 PM ]

Created an attachment (id=284)
Revised Hidden Field Approach Change Bundle

Comment by rogerk [ 20/Sep/10 09:08 AM ]

Created an attachment (id=285)
Latest Revised Hidden Field Approach Change Bundle

Comment by rogerk [ 20/Sep/10 09:09 AM ]

Created an attachment (id=286)
Latest Revised Action URL Approach Change Bundle

Comment by rogerk [ 20/Sep/10 11:29 AM ]

changelog indicator

Comment by Ed Burns [ 20/Sep/10 05:38 PM ]

Ensure changelog_2_1 is in keywords list

Comment by rogerk [ 30/Sep/10 07:07 PM ]

Created an attachment (id=294)
Latest Iteration Of Changes

Comment by rogerk [ 01/Oct/10 12:34 PM ]

Created an attachment (id=297)
Latest Iteration Of Changes

Comment by Ed Burns [ 01/Oct/10 01:30 PM ]

Created an attachment (id=298)
patch with fixes for session use and form id

Comment by rogerk [ 03/Oct/10 08:10 PM ]

Created an attachment (id=299)
Latest Iteration Of Changes

Comment by rogerk [ 03/Oct/10 08:28 PM ]

Checked In.

Comment by rogerk [ 05/Oct/10 10:47 AM ]

Reopening temporarily as the default option for CSRF should be "none".
If we default to something other than "none" we would break backwards
compatibility of existing applications using 2.1 - especially applications
that have not yet implemented new Form Renderer requirements.
Changebundle forthcoming ...

Comment by rogerk [ 05/Oct/10 10:48 AM ]

Created an attachment (id=300)
Latest Iteration Of Changes

Comment by Ed Burns [ 05/Oct/10 10:57 AM ]

Attachment 300 looks fine. Please add the necessary spec language to the formrenderer and whatever
other generated parts of the spec. r=edburns

Comment by rogerk [ 05/Oct/10 11:08 AM ]

Created an attachment (id=301)
Latest Iteration Of Changes - Including Updated Javadoc

Comment by rogerk [ 05/Oct/10 11:29 AM ]

Checked in.

Comment by rogerk [ 12/Oct/10 10:45 AM ]

Created an attachment (id=303)
Revised Changes To Take Into Account Token Verification Exceptions Over Ajax (if responsewriter not available)

Comment by Ed Burns [ 12/Oct/10 10:56 AM ]

Index: jsf-api/src/main/java/javax/faces/application/ViewHandler.java
=================================================================
==

Please put the new content in a <span class="changed_modified_2_1"> element.

Otherwise, looks great.

r=edburns

Comment by rogerk [ 28/Oct/10 08:31 AM ]

Reopening due to late EG feedback. Also
see:https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1850

Comment by rogerk [ 28/Oct/10 08:32 AM ]

Target 2.2 (Unfortunately)

Comment by Ed Burns [ 08/Nov/10 06:45 PM ]

remove changelog_2_1 tag

Comment by kellerapps [ 18/Apr/11 12:58 PM ]

JSF components should support safe HTML.

Comment by Ed Burns [ 08/Jul/11 03:25 AM ]

Please see http://jsf-spec.java.net/nonav/proposals/JAVASERVERFACES_SPEC_PUBLIC-869-CSRF.txt for the latest proposal.

Comment by dened [ 10/Jul/11 11:23 AM ]

I wonder is there any reason for JSF to support the anti-CSRF token in URL in addition to (or instead of) POST parameter? Isn't POST parameter sufficient for the purpose? I think, support for the token in URL just adds unnecessary complications to a implementation and also a little weakens security. Please correct me if I'm wrong.

Comment by Ed Burns [ 13/Sep/11 03:06 PM ]

Adding jsf-api/doc/javaee_6.xsd
Adding jsf-api/doc/javaee_web_services_client_1_3.xsd
Adding jsf-api/doc/web-facesconfig_2_2.xsd
Sending jsf-ri/build.xml
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigManager.java
Sending jsf-ri/src/main/java/com/sun/faces/config/DbfFactory.java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/build.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/pom.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/java
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/java/com
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/java/com/sun
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/java/com/sun/faces
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/java/com/sun/faces/regression
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/java/com/sun/faces/regression/i_spec_869_war
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/WEB-INF
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/WEB-INF/beans.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/WEB-INF/faces-config.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/WEB-INF/web.xml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/i_spec_869_war.xhtml
Adding jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/i_spec_869_war_protected.xhtml
Transmitting file data .............
Committed revision 9377.

Comment by Ed Burns [ 20/Sep/11 08:58 PM ]

snapshot

Comment by Ed Burns [ 21/Sep/11 08:51 PM ]

Committed to trunk.

Adding jsf-api/src/main/java/javax/faces/application/ProtectedViewException.java
Sending jsf-api/src/main/java/javax/faces/application/ViewHandler.java
Sending jsf-api/src/main/java/javax/faces/application/ViewHandlerWrapper.java
Sending jsf-api/src/main/java/javax/faces/component/UIViewAction.java
Sending jsf-api/src/main/java/javax/faces/render/ResponseStateManager.java
Sending jsf-api/src/main/java/javax/faces/render/package.html
Sending jsf-ri/conf/test/web.xml
Sending jsf-ri/src/main/java/com/sun/faces/application/view/MultiViewHandler.java
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigManager.java
Sending jsf-ri/src/main/java/com/sun/faces/config/WebConfiguration.java
Adding jsf-ri/src/main/java/com/sun/faces/config/processor/ProtectedViewsConfigProcessor.java
Sending jsf-ri/src/main/java/com/sun/faces/lifecycle/RestoreViewPhase.java
Sending jsf-ri/src/main/java/com/sun/faces/renderkit/ClientSideStateHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/renderkit/ResponseStateManagerImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/renderkit/StateHelper.java
Sending jsf-ri/src/main/java/com/sun/faces/util/FacesLogger.java
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_de.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_es.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_ja.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_ko.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_pt_BR.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_zh_CN.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_zh_HK.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_zh_TW.properties
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/WEB-INF/faces-config.xml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/WEB-INF/web.xml
Sending jsf-test/JAVASERVERFACES_SPEC_PUBLIC-869/i_spec_869_war/src/main/webapp/i_spec_869_war.xhtml
Transmitting file data .............................
Committed revision 9393.

Comment by Ed Burns [ 21/Sep/11 08:53 PM ]

Committed to trunk.

Sending applicationIntegration.fm
Sending preface.fm
Sending renderingModel.fm
Sending requestProcessingLifecycle.fm
Transmitting file data ....
Committed revision 1032.

Comment by arjan tijms [ 02/Oct/11 09:50 PM ]

Just wondering about one thing, when state is stored on the server and the value of javax.faces.ViewState is sufficiently random, isn't that also a protection against CSRF? If an attacker can not guess this value, then this also functions as a hidden token, doesn't it?

Comment by Ed Burns [ 14/Dec/11 09:49 PM ]

arjan_tijms: yes, it certainly is, and that is why most of the work of this issues is dealing with cases that are not postbacks. In other words, we need a way to protect GET requests within an app from CSRF attacks as well.





[JAVASERVERFACES_SPEC_PUBLIC-865] Ajax inside a DataTable (getClientId append rowIndex) Created: 10/Jul/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 865
Status Whiteboard:

size_medium importance_large draft

Tags:
Participants: cipriandobra, lu4242 and rogerk

 Description   

Comments from [jsr-314-open] Ajax inside a DataTable:

Cagatay Civici

I've faced with an issue in our app I'd like to share when trying to update the
datatable itself from a command element located inside a column. Case is to
select a row, execute logic and update the datatable. Basic code:

<h:dataTable id="cars" var="car" value="#{tableBean.carsSmall}">
<h:column>
<f:facet name="header">
Model
</f:facet>
<h:outputText value="#{car.model}" />
</h:column>

<h:column>
<f:facet name="header">
Action
</f:facet>
<h:commandButton value="Some Action"
actionListener="#{tableBean.handleRowAction(car)}">
<f:ajax render="cars" />
</h:commandButton>
</h:column>
</h:dataTable>

As datatable has a rowIndex >= 0 during rendering of commandButton f:ajax
defines the component id to render as cars:{rowIndex} where I should expect
"cars" only. This is due to UIData.getClientId implementation as UIData
adds rowIndex for unique row ids. This causes an issue with a nested f:ajax case.

Andy Schwartz

Ids specified by <f:ajax> are relative to containing component - in this case,
relative to the <h:commandButton>. This makes is easy to specify
execute/render ids for components within the same NamingContainer (which is by
far the most common case). In the case of iterating components like
<h:dataTable> or <ui:repeat>, this means that execute/render ids refer to
components within the same row.

There is a way out of this... You can specify an absolute id by prefixing the id
with ":". At that point the id starts from the root of the component tree and
you can specify any number of colon-separated segments to descend into each
naming container. (This matches the syntax used by findComponent().)

Of course, specifying absolute paths is at a minimum difficult, and in some
cases, just plain impossible to do (eg. when reusing content across multiple
pages). In Trinidad we use a double-colon prefix ("::") to reference up one
level in the NamingContainer hierarchy - similar to ".." in file system paths.
I suggested exposing this when we were working on the <f:ajax> spec, but this
topic got shelved until 2.1.

Dan has captured some of our thinking here:

http://seamframework.org/Documentation/JSF21#H-ReevaluateComponentReferencingMechanismP2

More here:

http://seamframework.org/Documentation/JSFEnhancementComponentReferencing

Oh, and... for the particular use case that you describe above, I think that it
is very important that the JSF implementations give some warning when a
referenced component is not found, at least when running in development project
stage. Not sure which implementation you are testing, but it might make sense
to log bugs against MyFaces/Mojarra if this is failing silently in development mode.

Martin Marinschek

> Ids specified by <f:ajax> are relative to containing component - in this
> case, relative to the <h:commandButton>. This makes is easy to specify
> execute/render ids for components within the same NamingContainer (which is
> by far the most common case). In the case of iterating components like
> <h:dataTable> or <ui:repeat>, this means that execute/render ids refer to
> components within the same row.

Yes, but what Cagatay totally correctly refers to is that the table is
certainly not in a row - how can the table be in a row of itself? This
is semantical nonsense.

We should never include the row-index in the client-id of the table
itself. For this, we need to revise the client-id generation
algorithm.

Without actually having tried it, I think that it is easy to do so, as
we have a UIComponentBase.getContainerClientId() to create the
client-id of the children - when this method is called, we append the
row-index, if getClientId() itself is called, we don´t. Does this
sound reasonable to you guys?

I think we can regard this as an implementation bug - Catagay, can you
open issues for Mojarra and MyFaces?

Leonardo Uribe

I just want to note a side effect of this change: getContainerClientId() was
introduced
in jsf 1.2, but code written in jsf 1.1 uses getClientId(). If we apply this change,
all libraries for jsf 1.2 needs to be updated. I think we can do this for jsf
2.0 but my
question is if we should apply this change on jsf 1.2 branch. Components written for
jsf 1.1 that extends from UIData will not work correctly with this change.

Martin Marinscheck

> Components
> written for
> jsf 1.1 that extends from UIData will not work correctly with this change.

ah, well - if they override the UIData functionality. Yes, you are
right. Well, not sure how we should handle this properly. Maybe we
should leave this for 2.0.

Andy Schwartz

Yes, but what Cagatay totally correctly refers to is that the table is
certainly not in a row - how can the table be in a row of itself? This
is semantical nonsense.

Ugh, yes, of course. For a moment there it slipped my mind that the UIData
component is indeed found as part of the relative id search. I was thinking
that only the stamped components would be considered valid execute/render
targets when a row index is set. But, since we spec'ed findComponent()
semantics for execute/render, the UIData would indeed be found, and, yes, we
should use the correct client id.

Leonardo Uribe

Added issue on myfaces:

MYFACES-2744 UIData.getClientId() should not append rowIndex, instead use
UIData.getContainerClientId()



 Comments   
Comment by rogerk [ 13/Jul/10 04:01 PM ]

triaged

Comment by rogerk [ 16/Nov/10 01:00 PM ]

triage

Comment by cipriandobra [ 11/Aug/11 05:25 PM ]

A simple workaround is to place the dataTable inside a h:panelGroup and use its id.





[JAVASERVERFACES_SPEC_PUBLIC-864] ExceptionHandler.getRootCause() should use isAssignableFrom() Created: 08/Jul/10  Updated: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: Jakob Korherr Assignee: Unassigned