[jira] [Commented] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes

[Paul Nicolucci (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311948#comment-16311948
 ] 

Paul Nicolucci commented on MYFACES-4183:
-

+1 here, without it I think we'll have issues with the TCK tests as well as 
noted in MyFaces-4103.

> Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
> ---
>
> Key: MYFACES-4183
> URL: https://issues.apache.org/jira/browse/MYFACES-4183
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
>Priority: Minor
> Attachments: JSF20FacesConfigAnotherServlet.war, MYFACES-4183.patch
>
>
> There is a difference in behavior between JSF 2.2 and JSF 2.3 when using 
> facelet prefixes.
> I have a sample app that demonstrate this behavior difference. In the app we 
> just define a random servlet and map it to the same prefixes we would 
> normally map to the FacesServlet. We don't map /faces/* to the testServlet 
> but it is automatically added to the FacesServlet, so if you drove a request 
> to something other than .jsf (testServlet) or *.faces (testServlet) the 
> FacesServlet would be invoked for all of the prefix mappings of /faces/*. So 
> that would mean you should see TEST SERVLET printed for the suffix mapping 
> (.jsf and .faces) and then the page1 should be rendered for /faces/*. 
> When you drive a request to: 
> http://localhost:8080/JSF20FacesConfigAnotherServlet/faces/page1.jsf
> On JSF 2.2: You should see an output of "TEST SERVLET". So it ensures that 
> .jsf mapping is invoking the testServlet.
> On JSF 2.3: You get a 404, page1.jsf not found. I think that in the case of 
> JSF 2.3, it is invoking the FacesServlet but can't find the .jsf file because 
> it doesn't actually exist.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes

[Eduardo Breijo (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311943#comment-16311943
 ] 

Eduardo Breijo commented on MYFACES-4183:
-

I found that this doesn't have to do with extensionless mapping views. After 
debugging, I found that on MyFaces 2.3, VDL is returning null in 
ViewHandlerImpl.createView resulting in a 404 error. This is because 
JspViewDeclarationLanguageStrategy.handles changed from MyFaces 2.2 to MyFaces 
2.3. 

Previously we were always returning true, as a result VDL was set to 
JspViewDeclarationLanguage, and when 
JspViewDeclarationLanguageBase.renderView() calls buildView method from 
JSPViewDeclarationLanguage, a dispatch with "/page1.jsf" is made, then we go 
through the servlet container and we end up at the TestServlet since that 
matches the "*.jsf" mapping.

I have tested this same scenario using Mojarra 2.3 and it works fine, the 
behavior is the same as MyFaces 2.0 and MyFaces 2.2.

With the change made in MyFaces 2.3 under 
https://issues.apache.org/jira/browse/MYFACES-4103, the 
JspViewDeclarationLanguageStrategy.handles changed, leading to the regression 
described in this issue.

I have provided a patch, changing JspViewDeclarationLanguageStrategy.handles to 
what we have in JSF 2.0 and JSF 2.2.

> Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
> ---
>
> Key: MYFACES-4183
> URL: https://issues.apache.org/jira/browse/MYFACES-4183
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
>Priority: Minor
> Attachments: JSF20FacesConfigAnotherServlet.war, MYFACES-4183.patch
>
>
> There is a difference in behavior between JSF 2.2 and JSF 2.3 when using 
> facelet prefixes.
> I have a sample app that demonstrate this behavior difference. In the app we 
> just define a random servlet and map it to the same prefixes we would 
> normally map to the FacesServlet. We don't map /faces/* to the testServlet 
> but it is automatically added to the FacesServlet, so if you drove a request 
> to something other than .jsf (testServlet) or *.faces (testServlet) the 
> FacesServlet would be invoked for all of the prefix mappings of /faces/*. So 
> that would mean you should see TEST SERVLET printed for the suffix mapping 
> (.jsf and .faces) and then the page1 should be rendered for /faces/*. 
> When you drive a request to: 
> http://localhost:8080/JSF20FacesConfigAnotherServlet/faces/page1.jsf
> On JSF 2.2: You should see an output of "TEST SERVLET". So it ensures that 
> .jsf mapping is invoking the testServlet.
> On JSF 2.3: You get a 404, page1.jsf not found. I think that in the case of 
> JSF 2.3, it is invoking the FacesServlet but can't find the .jsf file because 
> it doesn't actually exist.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release of MyFaces Master POM version 17

[Paul Nicolucci]

+1




From:   Thomas Andraschko 
To: MyFaces Development 
Date:   01/04/2018 06:51 AM
Subject:Re: [VOTE] Release of MyFaces Master POM version 17



+1

2018-01-04 12:08 GMT+01:00 Dennis Kieselhorst :
  +1

[jira] [Updated] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes

[Eduardo Breijo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eduardo Breijo updated MYFACES-4183:

Status: Patch Available  (was: Open)

> Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
> ---
>
> Key: MYFACES-4183
> URL: https://issues.apache.org/jira/browse/MYFACES-4183
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
>Priority: Minor
> Attachments: JSF20FacesConfigAnotherServlet.war, MYFACES-4183.patch
>
>
> There is a difference in behavior between JSF 2.2 and JSF 2.3 when using 
> facelet prefixes.
> I have a sample app that demonstrate this behavior difference. In the app we 
> just define a random servlet and map it to the same prefixes we would 
> normally map to the FacesServlet. We don't map /faces/* to the testServlet 
> but it is automatically added to the FacesServlet, so if you drove a request 
> to something other than .jsf (testServlet) or *.faces (testServlet) the 
> FacesServlet would be invoked for all of the prefix mappings of /faces/*. So 
> that would mean you should see TEST SERVLET printed for the suffix mapping 
> (.jsf and .faces) and then the page1 should be rendered for /faces/*. 
> When you drive a request to: 
> http://localhost:8080/JSF20FacesConfigAnotherServlet/faces/page1.jsf
> On JSF 2.2: You should see an output of "TEST SERVLET". So it ensures that 
> .jsf mapping is invoking the testServlet.
> On JSF 2.3: You get a 404, page1.jsf not found. I think that in the case of 
> JSF 2.3, it is invoking the FacesServlet but can't find the .jsf file because 
> it doesn't actually exist.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-4180) ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY behavior different between MyFaces and Mojarra

[Paul Nicolucci (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Nicolucci resolved MYFACES-4180.
-
Resolution: Fixed

> ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY behavior different between MyFaces 
> and Mojarra
> ---
>
> Key: MYFACES-4180
> URL: https://issues.apache.org/jira/browse/MYFACES-4180
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Fix For: 2.3.0
>
> Attachments: MYFACES-4180.patch
>
>
> See the following dev discussion: 
> http://mail-archives.apache.org/mod_mbox/myfaces-dev/201711.mbox/%3cof507ae5dc.a54b3314-on002581db.006603e5-852581db.00680...@notes.na.collabserv.com%3e
> We need to determine what updates we want to make here and how best to make 
> them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TOBAGO-1839) Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311677#comment-16311677
 ] 

Hudson commented on TOBAGO-1839:


SUCCESS: Integrated in Jenkins build Tobago Trunk #1232 (See 
[https://builds.apache.org/job/Tobago%20Trunk/1232/])
TOBAGO-1839: Cross-site scripting (XSS) vulnerability in jsoup before (lofwyr: 
rev 34e4410f2cea76c78779627665c73905e2523824)
* (edit) pom.xml


> Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748
> --
>
> Key: TOBAGO-1839
> URL: https://issues.apache.org/jira/browse/TOBAGO-1839
> Project: MyFaces Tobago
>  Issue Type: Task
>  Components: Core
>Affects Versions: 2.1.0, 3.0.6
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.1.1, 4.1.0, 3.0.7
>
>
> Tobago uses jsoup by default. But the dependency can be updated to a newer 
> version in the application which uses Tobago.
> The next releases should reference an updated version of jsoup.
> Current version is 1.11.2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TOBAGO-1839) Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311651#comment-16311651
 ] 

Hudson commented on TOBAGO-1839:


SUCCESS: Integrated in Jenkins build Tobago 2.0.x #1496 (See 
[https://builds.apache.org/job/Tobago%202.0.x/1496/])
TOBAGO-1839: Cross-site scripting (XSS) vulnerability in jsoup before (lofwyr: 
rev 3709a01f640a7e4b6a41ddd0c6493cd0a9d50fcd)
* (edit) pom.xml


> Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748
> --
>
> Key: TOBAGO-1839
> URL: https://issues.apache.org/jira/browse/TOBAGO-1839
> Project: MyFaces Tobago
>  Issue Type: Task
>  Components: Core
>Affects Versions: 2.1.0, 3.0.6
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.1.1, 4.1.0, 3.0.7
>
>
> Tobago uses jsoup by default. But the dependency can be updated to a newer 
> version in the application which uses Tobago.
> The next releases should reference an updated version of jsoup.
> Current version is 1.11.2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TOBAGO-1839) Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311643#comment-16311643
 ] 

Hudson commented on TOBAGO-1839:


SUCCESS: Integrated in Jenkins build Tobago 3.0.x #38 (See 
[https://builds.apache.org/job/Tobago%203.0.x/38/])
TOBAGO-1839: Cross-site scripting (XSS) vulnerability in jsoup before (lofwyr: 
rev 01b94fd5228178b52ac48e7cbd960b872a5662fe)
* (edit) pom.xml


> Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748
> --
>
> Key: TOBAGO-1839
> URL: https://issues.apache.org/jira/browse/TOBAGO-1839
> Project: MyFaces Tobago
>  Issue Type: Task
>  Components: Core
>Affects Versions: 2.1.0, 3.0.6
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.1.1, 4.1.0, 3.0.7
>
>
> Tobago uses jsoup by default. But the dependency can be updated to a newer 
> version in the application which uses Tobago.
> The next releases should reference an updated version of jsoup.
> Current version is 1.11.2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TOBAGO-1839) Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748

[Udo Schnurpfeil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOBAGO-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Udo Schnurpfeil resolved TOBAGO-1839.
-
Resolution: Fixed

> Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748
> --
>
> Key: TOBAGO-1839
> URL: https://issues.apache.org/jira/browse/TOBAGO-1839
> Project: MyFaces Tobago
>  Issue Type: Task
>  Components: Core
>Affects Versions: 2.1.0, 3.0.6
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.1.1, 4.1.0, 3.0.7
>
>
> Tobago uses jsoup by default. But the dependency can be updated to a newer 
> version in the application which uses Tobago.
> The next releases should reference an updated version of jsoup.
> Current version is 1.11.2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TOBAGO-1839) Cross-site scripting (XSS) vulnerability in jsoup before 1.8.3 - CVE-2015-6748

[Udo Schnurpfeil (JIRA)]

Udo Schnurpfeil created TOBAGO-1839:
---

 Summary: Cross-site scripting (XSS) vulnerability in jsoup before 
1.8.3 - CVE-2015-6748
 Key: TOBAGO-1839
 URL: https://issues.apache.org/jira/browse/TOBAGO-1839
 Project: MyFaces Tobago
  Issue Type: Task
  Components: Core
Affects Versions: 3.0.6, 2.1.0
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil


Tobago uses jsoup by default. But the dependency can be updated to a newer 
version in the application which uses Tobago.
The next releases should reference an updated version of jsoup.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309822#comment-16309822
 ] 

Thomas Andraschko edited comment on MYFACES-4175 at 1/4/18 3:38 PM:


[~paul.nicolucci] / [~sartoris] Could you provide a simple unittest (not the 
invalid example in your WAR) that using a template from /resource/ dir fails? I 
think it's valid and has nothing todo with top-level-views AFAICS. A template 
isn't a top-level-vied and should be able to place it inside a /resources dir.

I think it's the best way to fix all those related bugs for now + provide a 
unittests. After that we can fix/enhance the extensionless URLs.


was (Author: tandraschko):
[~paul.nicolucci] / [~sartoris] Could you provide a simple unittest (not the 
invalid example in your WAR) that using a template from /resource/ dir fails? I 
think it's valid and has nothing todo with top-level-views in AFAICS. A 
template isn't a top-level-vied and should be able to place it inside a 
/resources dir.

I think it's the best way to fix all those related bugs for now + provide a 
unittests. After that we can fix/enhance the extensionless URLs.

> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release of MyFaces Master POM version 17

[Thomas Andraschko]

+1

2018-01-04 12:08 GMT+01:00 Dennis Kieselhorst :

> +1
>

Re: [VOTE] Release of MyFaces Master POM version 17

[Dennis Kieselhorst]

+1

[jira] [Comment Edited] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310983#comment-16310983
 ] 

Thomas Andraschko edited comment on MYFACES-3525 at 1/4/18 8:35 AM:


[~wtlucy]
Please see: https://github.com/javaee/javaserverfaces-spec/issues/671
The spec hasn't been changed, as balusc already posted in this ticket, but 
seems like the spec are already correct. I also tested Mojarra 2.3 and they 
changed it. So i'm fine with it to change our behavior in 2.3, so that the 
value is always empty.
If someone really needs it, i'm always fine with introducing the context-param, 
without chancing the default behavior, in 2.0-2.2.


was (Author: tandraschko):
[~wtlucy]
Please see: https://github.com/javaee/javaserverfaces-spec/issues/671
The spec hasn't been changed, as balusc already posted in this ticket, but 
seems like the spec are already correct. I also tested Mojarra 2.3 and they 
changed it. So i'm fine with it to change our behavior in 2.3, so that the 
value is always empty.


> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects 
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525-setsubmittedValueagain.patch, 
> MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true 
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in 
> web.xml
> 2. Create JSF Page:
> 
> 
>  required="true"
> requiredMessage="You must enter a first name"/>
> 
> 
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which 
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed 
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true 
> or false should not result in inconsistent behavior with required fields)
> 
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank 
> out a value for a required field that had previously been populated by the 
> model, submit the form, you will see the OLD data from the model in the 
> field. However, if that field had had a format validation applied to it and 
> the user submits the form with a format validation error, the OLD data is NOT 
> shown in the field (instead, the submitted/invalid data is shown). The same 
> should happen for required field validation errors. The field should show the 
> "blank" data and not the original model data. In order to get the correct 
> behavior, the developer has to currently set 
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not 
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is 
> true or false, the behavior of showing the blank field that the user 
> submitted should be the same.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310983#comment-16310983
 ] 

Thomas Andraschko edited comment on MYFACES-3525 at 1/4/18 8:34 AM:


[~wtlucy]
Please see: https://github.com/javaee/javaserverfaces-spec/issues/671
The spec hasn't been changed, as balusc already posted in this ticket, but 
seems like the spec are already correct. I also tested Mojarra 2.3 and they 
changed it. So i'm fine with it to change our behavior in 2.3, so that the 
value is always empty.



was (Author: tandraschko):
[~wtlucy]
Please see: https://github.com/javaee/javaserverfaces-spec/issues/671
The spec hasn't been changed as balusc already posted in this ticket. I also 
tested Mojarra 2.3 and they changed it. So i'm fine with it to change our 
behavior in 2.3, so that the value is always empty.


> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects 
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525-setsubmittedValueagain.patch, 
> MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true 
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in 
> web.xml
> 2. Create JSF Page:
> 
> 
>  required="true"
> requiredMessage="You must enter a first name"/>
> 
> 
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which 
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed 
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true 
> or false should not result in inconsistent behavior with required fields)
> 
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank 
> out a value for a required field that had previously been populated by the 
> model, submit the form, you will see the OLD data from the model in the 
> field. However, if that field had had a format validation applied to it and 
> the user submits the form with a format validation error, the OLD data is NOT 
> shown in the field (instead, the submitted/invalid data is shown). The same 
> should happen for required field validation errors. The field should show the 
> "blank" data and not the original model data. In order to get the correct 
> behavior, the developer has to currently set 
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not 
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is 
> true or false, the behavior of showing the blank field that the user 
> submitted should be the same.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310983#comment-16310983
 ] 

Thomas Andraschko edited comment on MYFACES-3525 at 1/4/18 8:33 AM:


[~wtlucy]
Please see: https://github.com/javaee/javaserverfaces-spec/issues/671
The spec hasn't been changed as balusc already posted in this ticket. I also 
tested Mojarra 2.3 and they changed it. So i'm fine with it to change our 
behavior in 2.3, so that the value is always empty.



was (Author: tandraschko):
[~wtlucy]
Please see: https://github.com/javaee/javaserverfaces-spec/issues/671
The spec hasn't been changed as balusc already posted in this ticket. I'm fine 
with it to change our behavior in 2.3, so that the value is always empty.

> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects 
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525-setsubmittedValueagain.patch, 
> MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true 
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in 
> web.xml
> 2. Create JSF Page:
> 
> 
>  required="true"
> requiredMessage="You must enter a first name"/>
> 
> 
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which 
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed 
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true 
> or false should not result in inconsistent behavior with required fields)
> 
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank 
> out a value for a required field that had previously been populated by the 
> model, submit the form, you will see the OLD data from the model in the 
> field. However, if that field had had a format validation applied to it and 
> the user submits the form with a format validation error, the OLD data is NOT 
> shown in the field (instead, the submitted/invalid data is shown). The same 
> should happen for required field validation errors. The field should show the 
> "blank" data and not the original model data. In order to get the correct 
> behavior, the developer has to currently set 
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not 
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is 
> true or false, the behavior of showing the blank field that the user 
> submitted should be the same.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310983#comment-16310983
 ] 

Thomas Andraschko commented on MYFACES-3525:


[~wtlucy]
Please see: https://github.com/javaee/javaserverfaces-spec/issues/671
The spec hasn't been changed as balusc already posted in this ticket. I'm fine 
with it to change our behavior in 2.3, so that the value is always empty.

> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects 
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525-setsubmittedValueagain.patch, 
> MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true 
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in 
> web.xml
> 2. Create JSF Page:
> 
> 
>  required="true"
> requiredMessage="You must enter a first name"/>
> 
> 
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which 
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed 
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true 
> or false should not result in inconsistent behavior with required fields)
> 
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank 
> out a value for a required field that had previously been populated by the 
> model, submit the form, you will see the OLD data from the model in the 
> field. However, if that field had had a format validation applied to it and 
> the user submits the form with a format validation error, the OLD data is NOT 
> shown in the field (instead, the submitted/invalid data is shown). The same 
> should happen for required field validation errors. The field should show the 
> "blank" data and not the original model data. In order to get the correct 
> behavior, the developer has to currently set 
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not 
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is 
> true or false, the behavior of showing the blank field that the user 
> submitted should be the same.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4180) ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY behavior different between MyFaces and Mojarra

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310957#comment-16310957
 ] 

Thomas Andraschko commented on MYFACES-4180:


+1. If it works fine, please commit it!

> ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY behavior different between MyFaces 
> and Mojarra
> ---
>
> Key: MYFACES-4180
> URL: https://issues.apache.org/jira/browse/MYFACES-4180
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Fix For: 2.3.0
>
> Attachments: MYFACES-4180.patch
>
>
> See the following dev discussion: 
> http://mail-archives.apache.org/mod_mbox/myfaces-dev/201711.mbox/%3cof507ae5dc.a54b3314-on002581db.006603e5-852581db.00680...@notes.na.collabserv.com%3e
> We need to determine what updates we want to make here and how best to make 
> them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)