[jira] [Commented] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
[ https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
+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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/TOBAGO-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/TOBAGO-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/TOBAGO-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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
[ https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
+1 2018-01-04 12:08 GMT+01:00 Dennis Kieselhorst : > +1 >
Re: [VOTE] Release of MyFaces Master POM version 17
+1
[jira] [Comment Edited] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
