[jira] [Commented] (MYFACES-4120) ResourceHandler#markResourceRendered() should be retained during ajax rebuild
[ https://issues.apache.org/jira/browse/MYFACES-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16042163#comment-16042163 ] Leonardo Uribe commented on MYFACES-4120: - I checked the code and how it is handled this case on the javascript side and the whole head tag is replaced, so anyway if we keep track of the resources added in a facesContext map, it will be pointless, because the partial response from the server will be the same. I'll close this issue as not a problem. Please reopen it again if you thing there is something I'm missing in the resolution. Thanks Bauke for the report. > ResourceHandler#markResourceRendered() should be retained during ajax rebuild > - > > Key: MYFACES-4120 > URL: https://issues.apache.org/jira/browse/MYFACES-4120 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0 > Environment: TomEE 7.0.3 with MyFaces 2.3.0-SNAPSHOT >Reporter: Bauke Scholtz > > While running OmniFaces IT suite on today's MyFaces 2.3.0-SNAPSHOT, I noticed > a bug in ResourceHandler#isResourceRendered() during an ajax navigation back > to the same view (more specifically, when FacesContext#setViewRoot() is > invoked with a new UIViewRoot of same viewId during an ajax postback). > During restore view phase, all already-rendered resources are correctly > marked via markResourceRendered(). However, this is in turn stored as a > transient UIViewRoot attribute. As a consequence, when the UIViewRoot gets > changed during the very same ajax request, they are all lost, causing > isResourceRendered() to incorrectly return false. > Basically, the markResourceRendered() of the previous view should be > remembered for the next view when PartialViewContext#isAjaxRequest() returns > true and isRenderAll() returns false. > In MyFaces 2.2 (and possibly earlier) the behavior of markResourceRendered() > and isResourceRendered() was internally correctly implemented via > org.apache.myfaces.RENDERED_SCRIPT_RESOURCES_SET context attribute. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYFACES-4121) Fix javadoc for 2.3 branch and update maven-javadoc-plugin
[ https://issues.apache.org/jira/browse/MYFACES-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-4121. - Resolution: Fixed > Fix javadoc for 2.3 branch and update maven-javadoc-plugin > --- > > Key: MYFACES-4121 > URL: https://issues.apache.org/jira/browse/MYFACES-4121 > Project: MyFaces Core > Issue Type: Task > Components: JSR-372 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe >Priority: Blocker > Fix For: 2.3.0 > > > MyFaces 2.3 branch requires Java 8 and an updated maven-javadoc-plugin. The > problem is the new versions are more strict to generate the javadoc, so we > need to check the javadoc and fix its generation. > This is a blocker issue for beta release, since we cannot generate all > artifacts without fix this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYFACES-4120) ResourceHandler#markResourceRendered() should be retained during ajax rebuild
[ https://issues.apache.org/jira/browse/MYFACES-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041799#comment-16041799 ] Leonardo Uribe commented on MYFACES-4120: - But if isRenderAll() renders the whole view including replace all content inside tag, right? Even if isResourceRendered() return true, the whole view will be replaced. It doesn't sound like a bug to me, or am I missing something? > ResourceHandler#markResourceRendered() should be retained during ajax rebuild > - > > Key: MYFACES-4120 > URL: https://issues.apache.org/jira/browse/MYFACES-4120 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0 > Environment: TomEE 7.0.3 with MyFaces 2.3.0-SNAPSHOT >Reporter: Bauke Scholtz > > While running OmniFaces IT suite on today's MyFaces 2.3.0-SNAPSHOT, I noticed > a bug in ResourceHandler#isResourceRendered() during an ajax navigation back > to the same view (more specifically, when FacesContext#setViewRoot() is > invoked with a new UIViewRoot of same viewId during an ajax postback). > During restore view phase, all already-rendered resources are correctly > marked via markResourceRendered(). However, this is in turn stored as a > transient UIViewRoot attribute. As a consequence, when the UIViewRoot gets > changed during the very same ajax request, they are all lost, causing > isResourceRendered() to incorrectly return false. > Basically, the markResourceRendered() of the previous view should be > remembered for the next view when PartialViewContext#isAjaxRequest() returns > true and isRenderAll() returns false. > In MyFaces 2.2 (and possibly earlier) the behavior of markResourceRendered() > and isResourceRendered() was internally correctly implemented via > org.apache.myfaces.RENDERED_SCRIPT_RESOURCES_SET context attribute. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[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=16041766#comment-16041766
]
Leonardo Uribe commented on MYFACES-3525:
-
No problem from my side, if a custom parameter help, please add it. Just let
the default behavior intact.
> 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
>Reporter: VS
>
> 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.3.15#6346)
[jira] [Commented] (TOBAGO-1628) Security (e.g. @RolesAllowed) should be either "disabled" or "hidden"
[ https://issues.apache.org/jira/browse/TOBAGO-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041098#comment-16041098 ] Hudson commented on TOBAGO-1628: SUCCESS: Integrated in Jenkins build Tobago Trunk #912 (See [https://builds.apache.org/job/Tobago%20Trunk/912/]) TOBAGO-1628: Security (e.g. @RolesAllowed) should be either "disabled" or "hidden" (lofwyr: [http://svn.apache.org/viewvc/?view=rev=1797942]) * (edit) tobago-trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/config/TobagoConfig.java * (edit) tobago-trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUICommandBase.java * (add) tobago-trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/SecurityAnnotation.java * (edit) tobago-trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigFragment.java * (edit) tobago-trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigImpl.java * (edit) tobago-trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigParser.java * (edit) tobago-trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigSorter.java * (edit) tobago-trunk/tobago-core/src/main/resources/org/apache/myfaces/tobago/config/tobago-config-3.1.xsd * (edit) tobago-trunk/tobago-core/src/test/resources/tobago-config-3.1.xml * (edit) tobago-trunk/tobago-example/tobago-example-demo/src/main/webapp/WEB-INF/tobago-config.xml > Security (e.g. @RolesAllowed) should be either "disabled" or "hidden" > - > > Key: TOBAGO-1628 > URL: https://issues.apache.org/jira/browse/TOBAGO-1628 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Minor > Fix For: 4.0.0 > > > These annotations influence the "rendered" and "disabled" attributes of > commands like , etc. > This should be configurable via tobago-config.xml. > The default will be set to "disable" to not confuse developers and user, but > can be set to "hide" or "ignore". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOBAGO-1628) Security (e.g. @RolesAllowed) should be either "disabled" or "hidden"
[ https://issues.apache.org/jira/browse/TOBAGO-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1628. - Resolution: Fixed > Security (e.g. @RolesAllowed) should be either "disabled" or "hidden" > - > > Key: TOBAGO-1628 > URL: https://issues.apache.org/jira/browse/TOBAGO-1628 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Minor > Fix For: 3.1.0 > > > These annotations influence the "rendered" and "disabled" attributes of > commands like , etc. > This should be configurable via tobago-config.xml. > The default will be set to "disable" to not confuse developers and user, but > can be set to "hide" or "ignore". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TOBAGO-1628) Security (e.g. @RolesAllowed) should be either "disabled" or "hidden"
[ https://issues.apache.org/jira/browse/TOBAGO-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041043#comment-16041043 ] Udo Schnurpfeil commented on TOBAGO-1628: - Implementing the simple solution to configure that in the tobago-config.xml > Security (e.g. @RolesAllowed) should be either "disabled" or "hidden" > - > > Key: TOBAGO-1628 > URL: https://issues.apache.org/jira/browse/TOBAGO-1628 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Reporter: Udo Schnurpfeil >Priority: Minor > Fix For: 3.1.0 > > > This might be configurable via a special annotation, or in the > tobago-config.xml. > This is to discuss... -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[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=16040977#comment-16040977
]
Bill Lucy commented on MYFACES-3525:
I realize that this issue is 5+ years old, but it's still causing problems for
users. This wasn't resolved in the 2.1 or 2.2 specifications, so aside from
workarounds there is still no solution.
The patch provided in https://issues.apache.org/jira/browse/MYFACES-2497 seems
to resolve the issue. Since this is an issue with the spec, we could fix this
issue, leave the fix disabled by default, and allow users who need this fix to
enable the non-spec fix via a configuration parameter. For example,
org.apache.myfaces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL_CLEAR_INPUT
with a default value of "false".
Would anyone have an issue with that?
> 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
>Reporter: VS
>
> 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.3.15#6346)
[jira] [Resolved] (TOBAGO-1745) Demo: Fix status code for error pages
[ https://issues.apache.org/jira/browse/TOBAGO-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1745. - Resolution: Fixed Fix Version/s: 3.1.0 > Demo: Fix status code for error pages > - > > Key: TOBAGO-1745 > URL: https://issues.apache.org/jira/browse/TOBAGO-1745 > Project: MyFaces Tobago > Issue Type: Improvement >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil >Priority: Minor > Fix For: 3.1.0 > > > Sometimes the error code is not set correctly, because of forwarding. > Partially same problem like here DELTASPIKE-1043 in comment #5 and #6 > e.g. http://localhost:8080/test.js will be redirected to > /faces/error/404.xhtml?dswid=xy with status code 200 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
