[jira] [Updated] (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:all-tabpanel ] Jay Sartoris updated MYFACES-4175: -- Status: Patch Available (was: Open) > 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, JSFTestResourcesBasic.war, > MYFACES-4175-UNITTEST.patch, 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)
[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=16319191#comment-16319191
]
Thomas Andraschko commented on MYFACES-3525:
I'm not sure actually.
We have one user (since many years!) in PrimeFaces which would like to restore
the old value: https://github.com/primefaces/primefaces/issues/2821
But we have actually have 3 cases:
1) reset to empty
2) display old model value
3) display invalid input
Or do i miss something?
> 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, 2.3.0
>
> Attachments: MYFACES-3525-JSF23.patch,
> 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=16319186#comment-16319186
]
Bill Lucy commented on MYFACES-3525:
I think the patch is fine - by default it mirrors Mojarra's behavior, and then
the context param flips the behavior to restore the previous model value.
[~tandraschko] do you think the context param should be removed altogether?
> 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, 2.3.0
>
> Attachments: MYFACES-3525-JSF23.patch,
> 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=16319117#comment-16319117
]
Thomas Andraschko edited comment on MYFACES-3525 at 1/9/18 9:02 PM:
First of all, we should decide what we do...
The JSF (Mojarra 2.3) behavior is that the value is ALWAYS cleared. For this
feature, the patch seems to complicated for me. Should be simple IF-statement?!
If we would like to create a behavior, that the value is displayed from the
model again, then we need a context param, too. But the default should be:
clear always if validation fails.
EDIT: nvm, i never read in the comments here that someone would like to
redisplay the old model value. So the patch is actually ok but i would do a
cleanup, we don't need that overhead in 2.3. with additional methods and
context params.
was (Author: tandraschko):
First of all, we should decide what we do...
The JSF (Mojarra 2.3) behavior is that the value is ALWAYS cleared. For this
feature, the patch seems to complicated for me. Should be simple IF-statement?!
If we would like to create a behavior, that the value is displayed from the
model again, then we need a context param, too. But the default should be:
clear always if validation fails.
> 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, 2.3.0
>
> Attachments: MYFACES-3525-JSF23.patch,
> 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=16319117#comment-16319117
]
Thomas Andraschko commented on MYFACES-3525:
First of all, we should decide what we do...
The JSF (Mojarra 2.3) behavior is that the value is ALWAYS cleared. For this
feature, the patch seems to complicated for me. Should be simple IF-statement?!
If we would like to create a behavior, that the value is displayed from the
model again, then we need a context param, too. But the default should be:
clear always if validation fails.
> 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, 2.3.0
>
> Attachments: MYFACES-3525-JSF23.patch,
> 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=16319107#comment-16319107
]
Eduardo Breijo commented on MYFACES-3525:
-
I have uploaded a patch for JSF 2.3. The patch is a combination of Bernd patch
and the initial patch provided here. It uses the
org.apache.myfaces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL_CLEAR_INPUT
context parameter, but in this case it will be "true" by default. So Bernd fix
will be enabled by default on JSF 2.3. Also, we can port this new patch to JSF
2.0-2.2 but have the context parameter set to "false" by default, meaning that
the fix will not be enabled by default, keeping the old behavior on JSF
2.0-2.2.
If there are no objections, I can commit the patch to JSF 2.3 and port it to
JSF 2.0-2.2.
> 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, 2.3.0
>
> Attachments: MYFACES-3525-JSF23.patch,
> 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] [Updated] (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:all-tabpanel ] Jay Sartoris updated MYFACES-4175: -- Status: Patch Available (was: Open) > 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, JSFTestResourcesBasic.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)
[jira] [Updated] (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:all-tabpanel ] Jay Sartoris updated MYFACES-4175: -- Status: Open (was: Patch Available) > 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, JSFTestResourcesBasic.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)
[jira] [Commented] (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=16318877#comment-16318877 ] Jay Sartoris commented on MYFACES-4175: --- Thanks Thomas. I'm working on the unittest now. > 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, JSFTestResourcesBasic.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)
[jira] [Commented] (MYFACES-4186) Performance concurrency issue in _ComponentAttributesMap
[ https://issues.apache.org/jira/browse/MYFACES-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318492#comment-16318492 ] Bill Lucy commented on MYFACES-4186: Patch attached; if there aren't any comments I'll commit this change to 2.0+ > Performance concurrency issue in _ComponentAttributesMap > > > Key: MYFACES-4186 > URL: https://issues.apache.org/jira/browse/MYFACES-4186 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12, 2.3.0-beta >Reporter: Bill Lucy >Assignee: Bill Lucy > Attachments: MYFACES-4186.patch > > > We've hit a performance issue with the property descriptor map in > _ComponentAttributesMap. Driving a heavy load to an application, we can see > threads spending a lot of time in this area: > ... > (entered lock: java/util/Collections$SynchronizedMap@0x000, entry > count:1) > at > javax/faces/component/_ComponentAttributesMap.getPropertyDescriptor(_ComponentAttributesMap.java:394(Compiled > Code)) > at > javax/faces/component/_ComponentAttributesMap.containsKey(_ComponentAttributesMap.java:165(Compiled > Code)) > at > javax/faces/component/UIComponent.isCompositeComponent(UIComponent.java:239(Compiled > Code)) > ... > In this case, replacing the HashMap used by _propertyDescriptorMap with a > ConcurrentHashMap gives us much better performance. Since we can use a > ConcurrentHashMap here, there shouldn't be any performance hit in the normal > case. > Related: https://issues.apache.org/jira/browse/MYFACES-3216 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4186) Performance concurrency issue in _ComponentAttributesMap
[ https://issues.apache.org/jira/browse/MYFACES-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4186: --- Status: Patch Available (was: Open) > Performance concurrency issue in _ComponentAttributesMap > > > Key: MYFACES-4186 > URL: https://issues.apache.org/jira/browse/MYFACES-4186 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12, 2.3.0-beta >Reporter: Bill Lucy >Assignee: Bill Lucy > > We've hit a performance issue with the property descriptor map in > _ComponentAttributesMap. Driving a heavy load to an application, we can see > threads spending a lot of time in this area: > ... > (entered lock: java/util/Collections$SynchronizedMap@0x000, entry > count:1) > at > javax/faces/component/_ComponentAttributesMap.getPropertyDescriptor(_ComponentAttributesMap.java:394(Compiled > Code)) > at > javax/faces/component/_ComponentAttributesMap.containsKey(_ComponentAttributesMap.java:165(Compiled > Code)) > at > javax/faces/component/UIComponent.isCompositeComponent(UIComponent.java:239(Compiled > Code)) > ... > In this case, replacing the HashMap used by _propertyDescriptorMap with a > ConcurrentHashMap gives us much better performance. Since we can use a > ConcurrentHashMap here, there shouldn't be any performance hit in the normal > case. > Related: https://issues.apache.org/jira/browse/MYFACES-3216 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYFACES-4186) Performance concurrency issue in _ComponentAttributesMap
Bill Lucy created MYFACES-4186: -- Summary: Performance concurrency issue in _ComponentAttributesMap Key: MYFACES-4186 URL: https://issues.apache.org/jira/browse/MYFACES-4186 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3.0-beta, 2.2.12, 2.1.18, 2.0.24 Reporter: Bill Lucy Assignee: Bill Lucy We've hit a performance issue with the property descriptor map in _ComponentAttributesMap. Driving a heavy load to an application, we can see threads spending a lot of time in this area: ... (entered lock: java/util/Collections$SynchronizedMap@0x000, entry count:1) at javax/faces/component/_ComponentAttributesMap.getPropertyDescriptor(_ComponentAttributesMap.java:394(Compiled Code)) at javax/faces/component/_ComponentAttributesMap.containsKey(_ComponentAttributesMap.java:165(Compiled Code)) at javax/faces/component/UIComponent.isCompositeComponent(UIComponent.java:239(Compiled Code)) ... In this case, replacing the HashMap used by _propertyDescriptorMap with a ConcurrentHashMap gives us much better performance. Since we can use a ConcurrentHashMap here, there shouldn't be any performance hit in the normal case. Related: https://issues.apache.org/jira/browse/MYFACES-3216 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
