[jira] [Created] (MYFACES-3919) javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field
Bill Lucy created MYFACES-3919: -- Summary: javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field Key: MYFACES-3919 URL: https://issues.apache.org/jira/browse/MYFACES-3919 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.4, 2.1.15, 2.0.21 Environment: WebSphere 8.5.5 Reporter: Bill Lucy We've come across an issue while trying to modify the javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to break h:commandLink actions. For example, with the separator character set to a hyphen "-", the following navigation does not work (the output link just triggers a refresh): A workaround is to enable the context parameter org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter has been removed in the 2.2 branch. (It's also not a particularly desirable workaround.) The issue here seems to stem from the oamSubmit.js script; in that file there is a call myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId); which explicitly passes uses a colon separator character. In HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have return formInfo.getFormName() + UINamingContainer.getSeparatorChar(FacesContext.getCurrentInstance())+ HIDDEN_COMMANDLINK_FIELD_NAME; which will cause the wrong hidden field name to be searched, and the broken actions seen here. As suggested by Leonardo: We should not use UINamingContainer.getSeparatorChar(...) to render that hidden field and enforce ':' instead. The reason is the intention of use javax.faces.SEPARATOR_CHAR is to avoid the collision with css when you use the ':', but in this case the intention is to create a hidden field, with no real underlying component, so it is better to let ':' on the js file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MYFACES-3919) javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field
[ https://issues.apache.org/jira/browse/MYFACES-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-3919: --- Status: Patch Available (was: Open) > javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field > -- > > Key: MYFACES-3919 > URL: https://issues.apache.org/jira/browse/MYFACES-3919 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.21, 2.1.15, 2.2.4 > Environment: WebSphere 8.5.5 >Reporter: Bill Lucy > > We've come across an issue while trying to modify the > javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to > break h:commandLink actions. For example, with the separator character set > to a hyphen "-", the following navigation does not work (the output link just > triggers a refresh): > > > > > > > > A workaround is to enable the context parameter > org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter > has been removed in the 2.2 branch. (It's also not a particularly desirable > workaround.) The issue here seems to stem from the oamSubmit.js script; in > that file there is a call > > myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId); > > which explicitly passes uses a colon separator character. In > HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have > > return formInfo.getFormName() + > UINamingContainer.getSeparatorChar(FacesContext.getCurrentInstance())+ > HIDDEN_COMMANDLINK_FIELD_NAME; > > which will cause the wrong hidden field name to be searched, and the broken > actions seen here. > As suggested by Leonardo: > We should not use UINamingContainer.getSeparatorChar(...) to > render that hidden field and enforce ':' instead. The reason is the intention > of use javax.faces.SEPARATOR_CHAR is to avoid the collision with css > when you use the ':', but in this case the intention is to create a hidden > field, with no real underlying component, so it is better to let ':' on the js > file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3919) javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field
[ https://issues.apache.org/jira/browse/MYFACES-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14105673#comment-14105673 ] Bill Lucy commented on MYFACES-3919: Patch added (for 2.0.21) which renders/assumes a hidden field character separator of ':'. > javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field > -- > > Key: MYFACES-3919 > URL: https://issues.apache.org/jira/browse/MYFACES-3919 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.21, 2.1.15, 2.2.4 > Environment: WebSphere 8.5.5 >Reporter: Bill Lucy > Attachments: myfaces-3919-2.0.21.patch > > > We've come across an issue while trying to modify the > javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to > break h:commandLink actions. For example, with the separator character set > to a hyphen "-", the following navigation does not work (the output link just > triggers a refresh): > > > > > > > > A workaround is to enable the context parameter > org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter > has been removed in the 2.2 branch. (It's also not a particularly desirable > workaround.) The issue here seems to stem from the oamSubmit.js script; in > that file there is a call > > myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId); > > which explicitly passes uses a colon separator character. In > HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have > > return formInfo.getFormName() + > UINamingContainer.getSeparatorChar(FacesContext.getCurrentInstance())+ > HIDDEN_COMMANDLINK_FIELD_NAME; > > which will cause the wrong hidden field name to be searched, and the broken > actions seen here. > As suggested by Leonardo: > We should not use UINamingContainer.getSeparatorChar(...) to > render that hidden field and enforce ':' instead. The reason is the intention > of use javax.faces.SEPARATOR_CHAR is to avoid the collision with css > when you use the ':', but in this case the intention is to create a hidden > field, with no real underlying component, so it is better to let ':' on the js > file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3982) javax.faces.context.ExternalContext#getInitParameter should throw NPE when name is null
[ https://issues.apache.org/jira/browse/MYFACES-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498082#comment-14498082 ] Bill Lucy commented on MYFACES-3982: I've attached a patch which mirrors what was done on Mojarra via JAVASERVERFACES-2979; it's pretty straightforward. > javax.faces.context.ExternalContext#getInitParameter should throw NPE when > name is null > --- > > Key: MYFACES-3982 > URL: https://issues.apache.org/jira/browse/MYFACES-3982 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup > Attachments: myfaces-3982-2.2.7.patch > > > This issue has been discussed and fixed for Mojarra here > https://java.net/jira/browse/JAVASERVERFACES-2979 > This also needs to be fixed for MyFaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14517114#comment-14517114 ] Bill Lucy commented on MYFACES-3981: Additionally, I've created a spec issue for the topic of static EL resolution in general: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1368 > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Priority: Minor > Attachments: myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4003) Allow the "class" Attribute To Be Set For Custom Tags
Bill Lucy created MYFACES-4003: -- Summary: Allow the "class" Attribute To Be Set For Custom Tags Key: MYFACES-4003 URL: https://issues.apache.org/jira/browse/MYFACES-4003 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.8 Environment: Tomcat 8.0.21, MyFaces 2.2.8 Reporter: Bill Lucy Priority: Minor For native JSF tags, setting the "class" attribute performs as you'd expect; however, in user-defined tags, setting the "class" attribute results in the following exception: java.lang.IllegalArgumentException: Component property class is not writable Which is how we've behaved traditionally. Using the "styleClass" attribute instead does work as expected. Mojarra supports setting the "class" attribute as of 2.2.9. Additionally, the same issue was fixed in MYFACES-3874 for jsf:class. Changing the behavior of MyFaces here - to allow for custom components to accept the "class" attribute without Exceptions - should be fairly trivial, along the lines of MYFACES-3874. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4003) Allow the "class" Attribute To Be Set For Custom Tags
[ https://issues.apache.org/jira/browse/MYFACES-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4003: --- Status: Patch Available (was: Open) > Allow the "class" Attribute To Be Set For Custom Tags > - > > Key: MYFACES-4003 > URL: https://issues.apache.org/jira/browse/MYFACES-4003 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 > Environment: Tomcat 8.0.21, MyFaces 2.2.8 >Reporter: Bill Lucy >Priority: Minor > Attachments: JSFClassTagTest.war, myfaces-4003.patch > > > For native JSF tags, setting the "class" attribute performs as you'd expect; > however, in user-defined tags, setting the "class" attribute results in the > following exception: > java.lang.IllegalArgumentException: Component property class is not writable > Which is how we've behaved traditionally. Using the "styleClass" attribute > instead does work as expected. > Mojarra supports setting the "class" attribute as of 2.2.9. Additionally, > the same issue was fixed in MYFACES-3874 for jsf:class. > Changing the behavior of MyFaces here - to allow for custom components to > accept the "class" attribute without Exceptions - should be fairly trivial, > along the lines of MYFACES-3874. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4009) outputLink URL encoding
Bill Lucy created MYFACES-4009: -- Summary: outputLink URL encoding Key: MYFACES-4009 URL: https://issues.apache.org/jira/browse/MYFACES-4009 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.8 Reporter: Bill Lucy Priority: Minor We have an interesting behaviour when rendering h:outputLink with nested f:param elements: in the param data, the output href string has spaces encoded with a "+" rather than the expected "%20". For example: creates the following: Login page This already seems to have been discussed in https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1019 I'll attach a patch which resolves this - if it is in fact an issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4009) outputLink URL encoding
[ https://issues.apache.org/jira/browse/MYFACES-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4009: --- Status: Patch Available (was: Open) > outputLink URL encoding > > > Key: MYFACES-4009 > URL: https://issues.apache.org/jira/browse/MYFACES-4009 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 >Reporter: Bill Lucy >Priority: Minor > Attachments: myfaces-4009.patch > > > We have an interesting behaviour when rendering h:outputLink with nested > f:param elements: in the param data, the output href string has spaces > encoded with a "+" rather than the expected "%20". For example: > name="username" value="This is a test" /> > creates the following: > Login page > This already seems to have been discussed in > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1019 > I'll attach a patch which resolves this - if it is in fact an issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4010) MyFaces 2.2 throws UnsupportedOperationException with an eager ManagedBean with ManagedProperty
Bill Lucy created MYFACES-4010:
--
Summary: MyFaces 2.2 throws UnsupportedOperationException with an
eager ManagedBean with ManagedProperty
Key: MYFACES-4010
URL: https://issues.apache.org/jira/browse/MYFACES-4010
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.8
Environment: Tomcat, WebShere
Reporter: Bill Lucy
This seems to be a regression from another issue,
https://issues.apache.org/jira/browse/MYFACES-3116, which was resolved in 2.0
and 2.1.
Given a bean similar to the following:
@ManagedBean(eager=true, name="eagerBean")
@ApplicationScoped
public class EagerBean implements Serializable {
private static final long serialVersionUID = 1L;
@ManagedProperty(value="#{message}")
private MessageBean messageBean;
@PostConstruct
public void postConstruct() {
...
}
...
}
The following exception is thrown with MyFaces 2.2.8 on Tomcat 8:
19-Aug-2015 12:48:32.443 SEVERE [localhost-startStop-1]
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces An error occured
while initializing MyFaces: This method is not supported during startup
java.lang.UnsupportedOperationException: This method is not supported during
startup
at
org.apache.myfaces.context.servlet.StartupServletExternalContextImpl.getSession(StartupServletExternalContextImpl.java:187)
at
org.apache.myfaces.view.impl.DefaultViewScopeHandler.generateViewScopeId(DefaultViewScopeHandler.java:128)
at
org.apache.myfaces.view.ViewScopeProxyMap.getWrapped(ViewScopeProxyMap.java:76)
at
org.apache.myfaces.view.ViewScopeProxyMap.get(ViewScopeProxyMap.java:109)
at
org.apache.myfaces.config.ManagedBeanBuilder.getScope(ManagedBeanBuilder.java:560)
at
org.apache.myfaces.config.ManagedBeanBuilder.getNarrowestScope(ManagedBeanBuilder.java:464)
at
org.apache.myfaces.config.ManagedBeanBuilder.isInValidScope(ManagedBeanBuilder.java:435)
at
org.apache.myfaces.config.ManagedBeanBuilder.initializeProperties(ManagedBeanBuilder.java:319)
at
org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:163)
at
org.apache.myfaces.webapp.AbstractFacesInitializer._createEagerBeans(AbstractFacesInitializer.java:303)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:193)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:119)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4727)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5167)
Note, the app does not throw this Exception in MyFaces 2.0. The regression in
2.2 is caused by a spec update to UIViewRoot.getViewMap(boolean): that map is
now backed by the session, which is not available during startup (which was
addressed by MYFACES-3116):
https://javaserverfaces.java.net/docs/2.2/javadocs/javax/faces/component/UIViewRoot.html#getViewMap%28boolean%29
One solution is to make sure we don't call getViewMap(true) during startup;
I'll attach a patch demonstrating that route.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4010) MyFaces 2.2 throws UnsupportedOperationException with an eager ManagedBean with ManagedProperty
[
https://issues.apache.org/jira/browse/MYFACES-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy updated MYFACES-4010:
---
Status: Patch Available (was: Open)
> MyFaces 2.2 throws UnsupportedOperationException with an eager ManagedBean
> with ManagedProperty
> ---
>
> Key: MYFACES-4010
> URL: https://issues.apache.org/jira/browse/MYFACES-4010
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.8
> Environment: Tomcat, WebShere
>Reporter: Bill Lucy
>
> This seems to be a regression from another issue,
> https://issues.apache.org/jira/browse/MYFACES-3116, which was resolved in 2.0
> and 2.1.
> Given a bean similar to the following:
> @ManagedBean(eager=true, name="eagerBean")
> @ApplicationScoped
> public class EagerBean implements Serializable {
> private static final long serialVersionUID = 1L;
>
> @ManagedProperty(value="#{message}")
> private MessageBean messageBean;
> @PostConstruct
> public void postConstruct() {
> ...
> }
> ...
> }
> The following exception is thrown with MyFaces 2.2.8 on Tomcat 8:
> 19-Aug-2015 12:48:32.443 SEVERE [localhost-startStop-1]
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces An error occured
> while initializing MyFaces: This method is not supported during startup
> java.lang.UnsupportedOperationException: This method is not supported during
> startup
> at
> org.apache.myfaces.context.servlet.StartupServletExternalContextImpl.getSession(StartupServletExternalContextImpl.java:187)
> at
> org.apache.myfaces.view.impl.DefaultViewScopeHandler.generateViewScopeId(DefaultViewScopeHandler.java:128)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.getWrapped(ViewScopeProxyMap.java:76)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.get(ViewScopeProxyMap.java:109)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.getScope(ManagedBeanBuilder.java:560)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.getNarrowestScope(ManagedBeanBuilder.java:464)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.isInValidScope(ManagedBeanBuilder.java:435)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.initializeProperties(ManagedBeanBuilder.java:319)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:163)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer._createEagerBeans(AbstractFacesInitializer.java:303)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:193)
> at
> org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:119)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4727)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5167)
> Note, the app does not throw this Exception in MyFaces 2.0. The regression
> in 2.2 is caused by a spec update to UIViewRoot.getViewMap(boolean): that map
> is now backed by the session, which is not available during startup (which
> was addressed by MYFACES-3116):
> https://javaserverfaces.java.net/docs/2.2/javadocs/javax/faces/component/UIViewRoot.html#getViewMap%28boolean%29
> One solution is to make sure we don't call getViewMap(true) during startup;
> I'll attach a patch demonstrating that route.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4010) MyFaces 2.2 throws UnsupportedOperationException with an eager ManagedBean with ManagedProperty
[
https://issues.apache.org/jira/browse/MYFACES-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy updated MYFACES-4010:
---
Resolution: Fixed
Fix Version/s: 2.2.9-SNAPSHOT
Status: Resolved (was: Patch Available)
> MyFaces 2.2 throws UnsupportedOperationException with an eager ManagedBean
> with ManagedProperty
> ---
>
> Key: MYFACES-4010
> URL: https://issues.apache.org/jira/browse/MYFACES-4010
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.8
> Environment: Tomcat, WebShere
>Reporter: Bill Lucy
>Assignee: Bill Lucy
> Fix For: 2.2.9-SNAPSHOT
>
> Attachments: myfaces-4010.patch
>
>
> This seems to be a regression from another issue,
> https://issues.apache.org/jira/browse/MYFACES-3116, which was resolved in 2.0
> and 2.1.
> Given a bean similar to the following:
> @ManagedBean(eager=true, name="eagerBean")
> @ApplicationScoped
> public class EagerBean implements Serializable {
> private static final long serialVersionUID = 1L;
>
> @ManagedProperty(value="#{message}")
> private MessageBean messageBean;
> @PostConstruct
> public void postConstruct() {
> ...
> }
> ...
> }
> The following exception is thrown with MyFaces 2.2.8 on Tomcat 8:
> 19-Aug-2015 12:48:32.443 SEVERE [localhost-startStop-1]
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces An error occured
> while initializing MyFaces: This method is not supported during startup
> java.lang.UnsupportedOperationException: This method is not supported during
> startup
> at
> org.apache.myfaces.context.servlet.StartupServletExternalContextImpl.getSession(StartupServletExternalContextImpl.java:187)
> at
> org.apache.myfaces.view.impl.DefaultViewScopeHandler.generateViewScopeId(DefaultViewScopeHandler.java:128)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.getWrapped(ViewScopeProxyMap.java:76)
> at
> org.apache.myfaces.view.ViewScopeProxyMap.get(ViewScopeProxyMap.java:109)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.getScope(ManagedBeanBuilder.java:560)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.getNarrowestScope(ManagedBeanBuilder.java:464)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.isInValidScope(ManagedBeanBuilder.java:435)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.initializeProperties(ManagedBeanBuilder.java:319)
> at
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:163)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer._createEagerBeans(AbstractFacesInitializer.java:303)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:193)
> at
> org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:119)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4727)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5167)
> Note, the app does not throw this Exception in MyFaces 2.0. The regression
> in 2.2 is caused by a spec update to UIViewRoot.getViewMap(boolean): that map
> is now backed by the session, which is not available during startup (which
> was addressed by MYFACES-3116):
> https://javaserverfaces.java.net/docs/2.2/javadocs/javax/faces/component/UIViewRoot.html#getViewMap%28boolean%29
> One solution is to make sure we don't call getViewMap(true) during startup;
> I'll attach a patch demonstrating that route.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4003) Allow the "class" Attribute To Be Set For Custom Tags
[ https://issues.apache.org/jira/browse/MYFACES-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4003: --- Resolution: Fixed Fix Version/s: 2.2.9-SNAPSHOT Status: Resolved (was: Patch Available) > Allow the "class" Attribute To Be Set For Custom Tags > - > > Key: MYFACES-4003 > URL: https://issues.apache.org/jira/browse/MYFACES-4003 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 > Environment: Tomcat 8.0.21, MyFaces 2.2.8 >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Fix For: 2.2.9-SNAPSHOT > > Attachments: JSFClassTagTest.war, myfaces-4003.patch > > > For native JSF tags, setting the "class" attribute performs as you'd expect; > however, in user-defined tags, setting the "class" attribute results in the > following exception: > java.lang.IllegalArgumentException: Component property class is not writable > Which is how we've behaved traditionally. Using the "styleClass" attribute > instead does work as expected. > Mojarra supports setting the "class" attribute as of 2.2.9. Additionally, > the same issue was fixed in MYFACES-3874 for jsf:class. > Changing the behavior of MyFaces here - to allow for custom components to > accept the "class" attribute without Exceptions - should be fairly trivial, > along the lines of MYFACES-3874. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943975#comment-14943975 ] Bill Lucy edited comment on MYFACES-3981 at 10/5/15 8:36 PM: - You're right, this won't work with an pre-EL-3.0 implementation. We will need to gate the fix with the EL version. A more immediate problem is that this doesn't even compile with the current project setup - it looks like we compile against the EL 2.2 api/impl. was (Author: wtlucy): You're right, this won't work with an pre-EL-3 implementation. We will need to gate the fix with the EL version. A more immediate problem is that this doesn't even compile with the current project setup - it looks like we compile against the EL 2.2 api/impl. > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Priority: Minor > Attachments: myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943975#comment-14943975 ] Bill Lucy commented on MYFACES-3981: You're right, this won't work with an pre-EL-3 implementation. We will need to gate the fix with the EL version. A more immediate problem is that this doesn't even compile with the current project setup - it looks like we compile against the EL 2.2 api/impl. > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Priority: Minor > Attachments: myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943975#comment-14943975 ] Bill Lucy edited comment on MYFACES-3981 at 10/5/15 8:36 PM: - You're right, this won't work with an pre-EL 3.0 implementation. We will need to gate the fix with the EL version. A more immediate problem is that this doesn't even compile with the current project setup - it looks like we compile against the EL 2.2 api/impl. was (Author: wtlucy): You're right, this won't work with an pre-EL-3.0 implementation. We will need to gate the fix with the EL version. A more immediate problem is that this doesn't even compile with the current project setup - it looks like we compile against the EL 2.2 api/impl. > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Priority: Minor > Attachments: myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-3981: --- Status: Patch Available (was: Open) > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Priority: Minor > Attachments: MYFACES-3981.patch, myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14949074#comment-14949074 ] Bill Lucy commented on MYFACES-3981: Thanks for the comments. What you've suggested [~lu4242] makes sense.. I've attached a patch which takes those points into consideration: I added a resolver that just extends our ScopedAttributeResolver, and is placed on the resolver chain just before it. Usage of that new resolver (ImportHandlerResolver) is gated on a custom property, org.apache.myfaces.SUPPORT_EL_3_IMPORT_HANDLER, which is false by default. In that resolver, EL 3.0 functionality is enabled via reflection. Is this an appropriate property name, or do we want something more generic, such as SUPPORT_EL_3, etc.? That could possibly allow us to gate future EL "improvements" more easily. > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Priority: Minor > Attachments: MYFACES-3981.patch, myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-3986) viewScope implicit object not resolved in a JSP page
[ https://issues.apache.org/jira/browse/MYFACES-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-3986: --- Status: Patch Available (was: Open) > viewScope implicit object not resolved in a JSP page > > > Key: MYFACES-3986 > URL: https://issues.apache.org/jira/browse/MYFACES-3986 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.8 >Reporter: Jay Sartoris > > Consider this scenario: > A JSP file has the following contents: > = >"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> > http://www.w3.org/1999/xhtml"; > xmlns:h="http://java.sun.com/jsf/html"; > xmlns:f="http://xmlns.jcp.org/jsf/core"; > xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"; > > > > > > > > > > > > When requested (with the faces mapping), it fails with this exception: > javax.servlet.jsp.JspTagException: > at > org.apache.taglibs.standard.tag.common.core.SetSupport.doEndTag(SetSupport.java:195) > at [internal classes] > The reason for that exception is because the target attribute with a value of > "viewScope" of the c:set tag was resolved to null. > The Problem: > --- > I think the issue here is that the wrong FacesCompositeELResolver is used > while processing the tags. From my debugging, I see that there are two > FacesCompositeELResolvers created in this scenario and also what is mentioned > in the JSF 2.2 spec, section 5.6. One with JSP scope and one with Faces > scope. The ImplicitElResolvers created in each of these scopes is different > as detailed in the spec. > The problem I see is that when processing the tags, the Faces scoped > ELResolvers are created, but not used when processing the c:set tag to > resolve the viewScope implicit map. When processing this tag, it will use > the JSP scoped resolvers and therefore cannot resolve the viewScope and > throws the exception mentioned above because the > org.apache.myfaces.el.unified.resolver.implicitobject.ViewScopeImplicitObject > is never called as it is only associated with a Faces scoped > ImplicitObjectResolver. > Even though this is a JSP file, shouldn't the Faces scoped resolvers be used > when this is a JSF file? > > This same scenario works on Mojarra 2.2.10 with Tomcat 8.0.15, but fails when > using MyFaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3986) viewScope implicit object not resolved in a JSP page
[ https://issues.apache.org/jira/browse/MYFACES-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963416#comment-14963416 ] Bill Lucy commented on MYFACES-3986: I agree with Jay's analysis and fix here; I've provided a patch with his suggested change. If there are no objections by the end of the week I'll go ahead and commit this. > viewScope implicit object not resolved in a JSP page > > > Key: MYFACES-3986 > URL: https://issues.apache.org/jira/browse/MYFACES-3986 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.8 >Reporter: Jay Sartoris > Attachments: MYFACES-3986.patch > > > Consider this scenario: > A JSP file has the following contents: > = >"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> > http://www.w3.org/1999/xhtml"; > xmlns:h="http://java.sun.com/jsf/html"; > xmlns:f="http://xmlns.jcp.org/jsf/core"; > xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"; > > > > > > > > > > > > When requested (with the faces mapping), it fails with this exception: > javax.servlet.jsp.JspTagException: > at > org.apache.taglibs.standard.tag.common.core.SetSupport.doEndTag(SetSupport.java:195) > at [internal classes] > The reason for that exception is because the target attribute with a value of > "viewScope" of the c:set tag was resolved to null. > The Problem: > --- > I think the issue here is that the wrong FacesCompositeELResolver is used > while processing the tags. From my debugging, I see that there are two > FacesCompositeELResolvers created in this scenario and also what is mentioned > in the JSF 2.2 spec, section 5.6. One with JSP scope and one with Faces > scope. The ImplicitElResolvers created in each of these scopes is different > as detailed in the spec. > The problem I see is that when processing the tags, the Faces scoped > ELResolvers are created, but not used when processing the c:set tag to > resolve the viewScope implicit map. When processing this tag, it will use > the JSP scoped resolvers and therefore cannot resolve the viewScope and > throws the exception mentioned above because the > org.apache.myfaces.el.unified.resolver.implicitobject.ViewScopeImplicitObject > is never called as it is only associated with a Faces scoped > ImplicitObjectResolver. > Even though this is a JSP file, shouldn't the Faces scoped resolvers be used > when this is a JSF file? > > This same scenario works on Mojarra 2.2.10 with Tomcat 8.0.15, but fails when > using MyFaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3986) viewScope implicit object not resolved in a JSP page
[ https://issues.apache.org/jira/browse/MYFACES-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963861#comment-14963861 ] Bill Lucy commented on MYFACES-3986: Okay, this makes sense to me, given the context of JSP deprecation. Adding the ViewScopeImplicitObject to the JSP ImplicitObjectResolver like you mention works fine, and is probably a better solution that undoing the MYFACES-3426 change. The spec says in 5.6.1.1 that the JSP implicit resolver should "only resolve(ing) the “facesContext” and “view” implicit objects." However, I think adding the extra resolver here is fine, since we're just adding what's essentially extra functionality. Do you agree with that assessment [~lu4242]? > viewScope implicit object not resolved in a JSP page > > > Key: MYFACES-3986 > URL: https://issues.apache.org/jira/browse/MYFACES-3986 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.8 >Reporter: Jay Sartoris > Attachments: MYFACES-3986.patch > > > Consider this scenario: > A JSP file has the following contents: > = >"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> > http://www.w3.org/1999/xhtml"; > xmlns:h="http://java.sun.com/jsf/html"; > xmlns:f="http://xmlns.jcp.org/jsf/core"; > xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"; > > > > > > > > > > > > When requested (with the faces mapping), it fails with this exception: > javax.servlet.jsp.JspTagException: > at > org.apache.taglibs.standard.tag.common.core.SetSupport.doEndTag(SetSupport.java:195) > at [internal classes] > The reason for that exception is because the target attribute with a value of > "viewScope" of the c:set tag was resolved to null. > The Problem: > --- > I think the issue here is that the wrong FacesCompositeELResolver is used > while processing the tags. From my debugging, I see that there are two > FacesCompositeELResolvers created in this scenario and also what is mentioned > in the JSF 2.2 spec, section 5.6. One with JSP scope and one with Faces > scope. The ImplicitElResolvers created in each of these scopes is different > as detailed in the spec. > The problem I see is that when processing the tags, the Faces scoped > ELResolvers are created, but not used when processing the c:set tag to > resolve the viewScope implicit map. When processing this tag, it will use > the JSP scoped resolvers and therefore cannot resolve the viewScope and > throws the exception mentioned above because the > org.apache.myfaces.el.unified.resolver.implicitobject.ViewScopeImplicitObject > is never called as it is only associated with a Faces scoped > ImplicitObjectResolver. > Even though this is a JSP file, shouldn't the Faces scoped resolvers be used > when this is a JSF file? > > This same scenario works on Mojarra 2.2.10 with Tomcat 8.0.15, but fails when > using MyFaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-3981: --- Resolution: Fixed Assignee: Bill Lucy Fix Version/s: 2.2.9-SNAPSHOT Status: Resolved (was: Patch Available) > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Assignee: Bill Lucy >Priority: Minor > Fix For: 2.2.9-SNAPSHOT > > Attachments: MYFACES-3981.patch, myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-3986) viewScope implicit object not resolved in a JSP page
[ https://issues.apache.org/jira/browse/MYFACES-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-3986: --- Resolution: Fixed Assignee: Bill Lucy Fix Version/s: 2.2.9-SNAPSHOT Status: Resolved (was: Patch Available) > viewScope implicit object not resolved in a JSP page > > > Key: MYFACES-3986 > URL: https://issues.apache.org/jira/browse/MYFACES-3986 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.8 >Reporter: Jay Sartoris >Assignee: Bill Lucy > Fix For: 2.2.9-SNAPSHOT > > Attachments: MYFACES-3986.patch > > > Consider this scenario: > A JSP file has the following contents: > = >"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> > http://www.w3.org/1999/xhtml"; > xmlns:h="http://java.sun.com/jsf/html"; > xmlns:f="http://xmlns.jcp.org/jsf/core"; > xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"; > > > > > > > > > > > > When requested (with the faces mapping), it fails with this exception: > javax.servlet.jsp.JspTagException: > at > org.apache.taglibs.standard.tag.common.core.SetSupport.doEndTag(SetSupport.java:195) > at [internal classes] > The reason for that exception is because the target attribute with a value of > "viewScope" of the c:set tag was resolved to null. > The Problem: > --- > I think the issue here is that the wrong FacesCompositeELResolver is used > while processing the tags. From my debugging, I see that there are two > FacesCompositeELResolvers created in this scenario and also what is mentioned > in the JSF 2.2 spec, section 5.6. One with JSP scope and one with Faces > scope. The ImplicitElResolvers created in each of these scopes is different > as detailed in the spec. > The problem I see is that when processing the tags, the Faces scoped > ELResolvers are created, but not used when processing the c:set tag to > resolve the viewScope implicit map. When processing this tag, it will use > the JSP scoped resolvers and therefore cannot resolve the viewScope and > throws the exception mentioned above because the > org.apache.myfaces.el.unified.resolver.implicitobject.ViewScopeImplicitObject > is never called as it is only associated with a Faces scoped > ImplicitObjectResolver. > Even though this is a JSP file, shouldn't the Faces scoped resolvers be used > when this is a JSF file? > > This same scenario works on Mojarra 2.2.10 with Tomcat 8.0.15, but fails when > using MyFaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4024) Update the NOTICE.txt file in jsf.myfaces
[ https://issues.apache.org/jira/browse/MYFACES-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4024: --- Resolution: Fixed Assignee: Bill Lucy Status: Resolved (was: Patch Available) The patch looks good to me; I went ahead and committed it. I glanced through the other licenses and didn't see anything else that needed removal. > Update the NOTICE.txt file in jsf.myfaces > - > > Key: MYFACES-4024 > URL: https://issues.apache.org/jira/browse/MYFACES-4024 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 >Reporter: Eduardo Breijo >Assignee: Bill Lucy > Fix For: 2.2.10 > > Attachments: MYFACES-4024.patch > > > The NOTICE.txt file under META-INF directory is making reference to two > schemas. These schemas are: javaee_web_services_client_1_2.xsd which doesn't > exist in JSF 2.2 any more and javaee_5.xsd which is not needed since we are > using the open source one. It does not look like the xsd files have CDDL > license. > I have attached a patch for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4025) Incorrect JS content-type
Bill Lucy created MYFACES-4025: -- Summary: Incorrect JS content-type Key: MYFACES-4025 URL: https://issues.apache.org/jira/browse/MYFACES-4025 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.8 Reporter: Bill Lucy Assignee: Bill Lucy Priority: Minor We maintain some HtmlUnit tests, and I noticed that with MyFaces we've been getting these messages: Obsolete content type encountered: 'application/x-javascript'. We certainly don't want to be using 'application/x-javascript', since that's a very outdated type. Convention, and our own code, suggests that we should be using the 'text/javascript' MIME type. This is a fairly trivial change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4025) Incorrect JS content-type
[ https://issues.apache.org/jira/browse/MYFACES-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4025: --- Status: Patch Available (was: Open) > Incorrect JS content-type > - > > Key: MYFACES-4025 > URL: https://issues.apache.org/jira/browse/MYFACES-4025 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Attachments: MYFACES-4025.patch > > > We maintain some HtmlUnit tests, and I noticed that with MyFaces we've been > getting these messages: > Obsolete content type encountered: 'application/x-javascript'. > We certainly don't want to be using 'application/x-javascript', since that's > a very outdated type. Convention, and our own code, suggests that we should > be using the 'text/javascript' MIME type. This is a fairly trivial change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MYFACES-3988) An empty tag in a custom tag-lib causes an Exception
[ https://issues.apache.org/jira/browse/MYFACES-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy reopened MYFACES-3988: Assignee: Bill Lucy (was: Leonardo Uribe) Need to port changes to 2.0 and 2.1 releases > An empty tag in a custom tag-lib causes an Exception > > > Key: MYFACES-3988 > URL: https://issues.apache.org/jira/browse/MYFACES-3988 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.8 >Reporter: Christopher Meyer >Assignee: Bill Lucy >Priority: Minor > Fix For: 2.2.9 > > > While developing a custom tag library we added an empty renderer-type tag > like this: > > myinput > >my.test.MyInput > > > > This causes the following exception: > Caused by: java.lang.Exception: Value Cannot be Empty > at > org.apache.myfaces.view.facelets.compiler.TagLibraryConfigUnmarshallerImpl$LibraryHandler.endElement(TagLibraryConfigUnmarshallerImpl.java:395) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > ... > This appears to be expected based on the code in > TagLibraryConfigUnmarshallerImpl. From what I can see the exception appears > to be thrown on elements which are used in another spot. If any of them are > empty they will throw the above exception. Wildfly/Glassfish does not have > the same behavior, so my assumption is they just ignore it. > Should the MyFaces code be modified to just continue on without the > exception, based on the reference implementation? I can quickly create > something if so, I just wanted to bring this up to the community at large > since I don't know the reasoning behind the difference of the implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3988) An empty tag in a custom tag-lib causes an Exception
[ https://issues.apache.org/jira/browse/MYFACES-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085844#comment-15085844 ] Bill Lucy commented on MYFACES-3988: This affects 2.0.24 and 2.1.18, as well; the 2.2.x fix is applicable to those branches. I'll re-open this issue and port the changes back. > An empty tag in a custom tag-lib causes an Exception > > > Key: MYFACES-3988 > URL: https://issues.apache.org/jira/browse/MYFACES-3988 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.8 >Reporter: Christopher Meyer >Assignee: Leonardo Uribe >Priority: Minor > Fix For: 2.2.9 > > > While developing a custom tag library we added an empty renderer-type tag > like this: > > myinput > >my.test.MyInput > > > > This causes the following exception: > Caused by: java.lang.Exception: Value Cannot be Empty > at > org.apache.myfaces.view.facelets.compiler.TagLibraryConfigUnmarshallerImpl$LibraryHandler.endElement(TagLibraryConfigUnmarshallerImpl.java:395) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > ... > This appears to be expected based on the code in > TagLibraryConfigUnmarshallerImpl. From what I can see the exception appears > to be thrown on elements which are used in another spot. If any of them are > empty they will throw the above exception. Wildfly/Glassfish does not have > the same behavior, so my assumption is they just ignore it. > Should the MyFaces code be modified to just continue on without the > exception, based on the reference implementation? I can quickly create > something if so, I just wanted to bring this up to the community at large > since I don't know the reasoning behind the difference of the implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4025) Incorrect JS content-type
[ https://issues.apache.org/jira/browse/MYFACES-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4025: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Incorrect JS content-type > - > > Key: MYFACES-4025 > URL: https://issues.apache.org/jira/browse/MYFACES-4025 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.23, 2.1.17, 2.2.9 >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Fix For: 2.0.24-SNAPSHOT, 2.1.18-SNAPSHOT, 2.2.10-SNAPSHOT > > Attachments: MYFACES-4025.patch > > > We maintain some HtmlUnit tests, and I noticed that with MyFaces we've been > getting these messages: > Obsolete content type encountered: 'application/x-javascript'. > We certainly don't want to be using 'application/x-javascript', since that's > a very outdated type. Convention, and our own code, suggests that we should > be using the 'text/javascript' MIME type. This is a fairly trivial change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4022) Faces Flows are not discovered when the web application is packaged inside an EAR
[
https://issues.apache.org/jira/browse/MYFACES-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy updated MYFACES-4022:
---
Resolution: Fixed
Assignee: Bill Lucy (was: Leonardo Uribe)
Status: Resolved (was: Patch Available)
> Faces Flows are not discovered when the web application is packaged inside an
> EAR
> -
>
> Key: MYFACES-4022
> URL: https://issues.apache.org/jira/browse/MYFACES-4022
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.8
> Environment: WildFly 10.0.0, MyFaces 2.2.8, Weld 2.3
>Reporter: Hank Ibell
>Assignee: Bill Lucy
>Priority: Minor
> Fix For: 2.2.10
>
> Attachments: FacesFlowTest.ear, myfaces-4022.patch,
> myfaces-4022.patch, myfaces-4022.patch
>
>
> Faces flows built with the FlowBuilder API are not found when the web
> application is packaged inside an EAR. When deploying just the web
> application itself, the application's flows are discoverable however.
> A sample application has been provided to demonstrate the issue. The button
> 'Start Test Flow' should be clicked on the page /FacesFlowTest1/index.xhtml.
> The flow will not be entered and MyFaces will try to navigate to a view with
> the flow id instead:
> {panel:bgColor=#e8e8e8}
> [org.apache.myfaces.application.NavigationHandlerImpl] (default task-2)
> getOutcomeNavigationCase -> viewIdToTest: test-flow-1.xhtml
> [org.apache.myfaces.shared.resource.ResourceHandlerCache] (default task-2)
> Attemping to get resource from cache for test-flow-1.xhtml
> [org.apache.myfaces.application.NavigationHandlerImpl] (default task-2)
> handleNavigation fromAction=test-flow-1 outcome=test-flow-1 no matching
> navigation-case found, staying on current ViewRoot
> {panel}
> Mojarra supports Faces flow applications when they are packaged inside an EAR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4022) Faces Flows are not discovered when the web application is packaged inside an EAR
[
https://issues.apache.org/jira/browse/MYFACES-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094966#comment-15094966
]
Bill Lucy commented on MYFACES-4022:
Thanks for all the work on this, Hank; as discussed on the mailing list, I went
ahead and committed the patch here.
> Faces Flows are not discovered when the web application is packaged inside an
> EAR
> -
>
> Key: MYFACES-4022
> URL: https://issues.apache.org/jira/browse/MYFACES-4022
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.8
> Environment: WildFly 10.0.0, MyFaces 2.2.8, Weld 2.3
>Reporter: Hank Ibell
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.2.10
>
> Attachments: FacesFlowTest.ear, myfaces-4022.patch,
> myfaces-4022.patch, myfaces-4022.patch
>
>
> Faces flows built with the FlowBuilder API are not found when the web
> application is packaged inside an EAR. When deploying just the web
> application itself, the application's flows are discoverable however.
> A sample application has been provided to demonstrate the issue. The button
> 'Start Test Flow' should be clicked on the page /FacesFlowTest1/index.xhtml.
> The flow will not be entered and MyFaces will try to navigate to a view with
> the flow id instead:
> {panel:bgColor=#e8e8e8}
> [org.apache.myfaces.application.NavigationHandlerImpl] (default task-2)
> getOutcomeNavigationCase -> viewIdToTest: test-flow-1.xhtml
> [org.apache.myfaces.shared.resource.ResourceHandlerCache] (default task-2)
> Attemping to get resource from cache for test-flow-1.xhtml
> [org.apache.myfaces.application.NavigationHandlerImpl] (default task-2)
> handleNavigation fromAction=test-flow-1 outcome=test-flow-1 no matching
> navigation-case found, staying on current ViewRoot
> {panel}
> Mojarra supports Faces flow applications when they are packaged inside an EAR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4030) MyFaces CDI support is disabled if non-CDI application is loaded first
[
https://issues.apache.org/jira/browse/MYFACES-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139739#comment-15139739
]
Bill Lucy commented on MYFACES-4030:
The patch here looks good, and given the WebSphere scenario this change makes
sense. If there aren't any objections I think this is a safe change to make.
As far as the logging goes, I agree that's a bit misleading. (Again, just
taking the WebSphere scenario into account.) I'd be fine with making that
change too.
> MyFaces CDI support is disabled if non-CDI application is loaded first
> --
>
> Key: MYFACES-4030
> URL: https://issues.apache.org/jira/browse/MYFACES-4030
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.10-SNAPSHOT
> Environment: WebSphere Liberty 8.5.5.8, Weld 2.3, MyFaces 2.2.8
>Reporter: Hank Ibell
>Priority: Minor
> Attachments: myfaces-4030.patch
>
>
> If MyFaces 2.2 is loaded at the server level, MyFaces CDI support is set once
> per server. This causes CDI-enabled JSF applications to not work properly if
> a non-CDI application is loaded first.
> {panel:title=Steps to reproduce the error on WebSphere
> Liberty|bgColor=#e8e8e8}
> 1. Enable the jsf-2.2 and cdi-1.2 features on the WebSphere Liberty server.
> 2. Deploy two JSF applications: one that uses CDI (e.g. a flow built using
> FlowBuilder) and one that does not use CDI.
> 3. Make a request to the non-CDI application first. The message 'MyFaces CDI
> support disabled' should be written to the logs.
> 4. Make a request to the CDI-enabled application. If testing an application
> with a flow built using FlowBuilder, the flow will not be discovered.
> {panel}
> I've investigated the issue and found that MyFaces has two conditions to
> determine CDI availability:
> 1. CDI must be found on the classpath
> 2. The application map must have a bean manager instance
> (Found inside
> org.apache.myfaces.util.ExternalSpecifications#isCDIAvailable()).
> When MyFaces is shared between different applications, basing CDI
> availability on an application's configuration (condition two) is an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4030) MyFaces CDI support is disabled if non-CDI application is loaded first
[
https://issues.apache.org/jira/browse/MYFACES-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy updated MYFACES-4030:
---
Resolution: Fixed
Fix Version/s: 2.2.10-SNAPSHOT
Status: Resolved (was: Patch Available)
> MyFaces CDI support is disabled if non-CDI application is loaded first
> --
>
> Key: MYFACES-4030
> URL: https://issues.apache.org/jira/browse/MYFACES-4030
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.10-SNAPSHOT
> Environment: WebSphere Liberty 8.5.5.8, Weld 2.3, MyFaces 2.2.8
>Reporter: Hank Ibell
>Assignee: Bill Lucy
>Priority: Minor
> Fix For: 2.2.10-SNAPSHOT
>
> Attachments: myfaces-4030.patch
>
>
> If MyFaces 2.2 is loaded at the server level, MyFaces CDI support is set once
> per server. This causes CDI-enabled JSF applications to not work properly if
> a non-CDI application is loaded first.
> {panel:title=Steps to reproduce the error on WebSphere
> Liberty|bgColor=#e8e8e8}
> 1. Enable the jsf-2.2 and cdi-1.2 features on the WebSphere Liberty server.
> 2. Deploy two JSF applications: one that uses CDI (e.g. a flow built using
> FlowBuilder) and one that does not use CDI.
> 3. Make a request to the non-CDI application first. The message 'MyFaces CDI
> support disabled' should be written to the logs.
> 4. Make a request to the CDI-enabled application. If testing an application
> with a flow built using FlowBuilder, the flow will not be discovered.
> {panel}
> I've investigated the issue and found that MyFaces has two conditions to
> determine CDI availability:
> 1. CDI must be found on the classpath
> 2. The application map must have a bean manager instance
> (Found inside
> org.apache.myfaces.util.ExternalSpecifications#isCDIAvailable()).
> When MyFaces is shared between different applications, basing CDI
> availability on an application's configuration (condition two) is an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4030) MyFaces CDI support is disabled if non-CDI application is loaded first
[
https://issues.apache.org/jira/browse/MYFACES-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145338#comment-15145338
]
Bill Lucy commented on MYFACES-4030:
I've gone ahead and committed the patch - thanks for providing this, Hank. I
didn't change the log message; we can continue to discuss that here, if
necessary.
> MyFaces CDI support is disabled if non-CDI application is loaded first
> --
>
> Key: MYFACES-4030
> URL: https://issues.apache.org/jira/browse/MYFACES-4030
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.10-SNAPSHOT
> Environment: WebSphere Liberty 8.5.5.8, Weld 2.3, MyFaces 2.2.8
>Reporter: Hank Ibell
>Assignee: Bill Lucy
>Priority: Minor
> Fix For: 2.2.10-SNAPSHOT
>
> Attachments: myfaces-4030.patch
>
>
> If MyFaces 2.2 is loaded at the server level, MyFaces CDI support is set once
> per server. This causes CDI-enabled JSF applications to not work properly if
> a non-CDI application is loaded first.
> {panel:title=Steps to reproduce the error on WebSphere
> Liberty|bgColor=#e8e8e8}
> 1. Enable the jsf-2.2 and cdi-1.2 features on the WebSphere Liberty server.
> 2. Deploy two JSF applications: one that uses CDI (e.g. a flow built using
> FlowBuilder) and one that does not use CDI.
> 3. Make a request to the non-CDI application first. The message 'MyFaces CDI
> support disabled' should be written to the logs.
> 4. Make a request to the CDI-enabled application. If testing an application
> with a flow built using FlowBuilder, the flow will not be discovered.
> {panel}
> I've investigated the issue and found that MyFaces has two conditions to
> determine CDI availability:
> 1. CDI must be found on the classpath
> 2. The application map must have a bean manager instance
> (Found inside
> org.apache.myfaces.util.ExternalSpecifications#isCDIAvailable()).
> When MyFaces is shared between different applications, basing CDI
> availability on an application's configuration (condition two) is an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml
Bill Lucy created MYFACES-4042: -- Summary: Improve startup time by skipping classpath jar scan for *.faces-config.xml Key: MYFACES-4042 URL: https://issues.apache.org/jira/browse/MYFACES-4042 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.2.9, 2.1.18 Environment: WebSphere Reporter: Bill Lucy Priority: Minor In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated to scan for faces-config.xml resources in applications JARs during startup, as part of the process to add a FacesConfig in onStartup(). This is a very expensive scan, since we have to iterate over every file in every jar on the app classpath. This scan is not completely necessary: in the spec we have: Section 11.4.2 “Application Startup Behavior” Implementations may check for the presence of a servlet-class definition of class javax.faces.webapp.FacesServlet in the web application deployment descriptor as a means to abort the configuration process and reduce startup time for applications that do not use JavaServer Faces Technology. Which I interpret to mean that skipping checking the app jars at init time - for the purpose of adding a dynamic FacesServlet - is valid. Given the performance hit for the scan, I think adding a context param to disable the scan would be worthwhile. Something like: org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN Would this be worthwhile for others? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4042: --- Status: Patch Available (was: Open) > Improve startup time by skipping classpath jar scan for *.faces-config.xml > -- > > Key: MYFACES-4042 > URL: https://issues.apache.org/jira/browse/MYFACES-4042 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.18, 2.2.9 > Environment: WebSphere >Reporter: Bill Lucy >Priority: Minor > Attachments: MYFACES-4042.patch > > > In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated > to scan for faces-config.xml resources in applications JARs during startup, > as part of the process to add a FacesConfig in onStartup(). This is a very > expensive scan, since we have to iterate over every file in every jar on the > app classpath. > This scan is not completely necessary: in the spec we have: > Section 11.4.2 “Application Startup Behavior” > Implementations may check for the presence of a servlet-class definition of > class javax.faces.webapp.FacesServlet in the web application deployment > descriptor as a means to abort the configuration process and reduce startup > time for applications that do not use JavaServer Faces Technology. > Which I interpret to mean that skipping checking the app jars at init time - > for the purpose of adding a dynamic FacesServlet - is valid. Given the > performance hit for the scan, I think adding a context param to disable the > scan would be worthwhile. Something like: > org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN > Would this be worthwhile for others? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224957#comment-15224957 ] Bill Lucy commented on MYFACES-4042: Based on what the spec says, I think it's valid for us to skip the faces-config.xml scanning if the user doesn't explicitly put the FacesServlet in their web.xml. There are cases of users depending on MyFaces dynamically adding a FacesServlet for the various faces-config.xml possibilities, though. I think that if we do make a change leaving this configurable would be a good idea. > Improve startup time by skipping classpath jar scan for *.faces-config.xml > -- > > Key: MYFACES-4042 > URL: https://issues.apache.org/jira/browse/MYFACES-4042 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.18, 2.2.9 > Environment: WebSphere >Reporter: Bill Lucy >Priority: Minor > Attachments: MYFACES-4042.patch > > > In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated > to scan for faces-config.xml resources in applications JARs during startup, > as part of the process to add a FacesConfig in onStartup(). This is a very > expensive scan, since we have to iterate over every file in every jar on the > app classpath. > This scan is not completely necessary: in the spec we have: > Section 11.4.2 “Application Startup Behavior” > Implementations may check for the presence of a servlet-class definition of > class javax.faces.webapp.FacesServlet in the web application deployment > descriptor as a means to abort the configuration process and reduce startup > time for applications that do not use JavaServer Faces Technology. > Which I interpret to mean that skipping checking the app jars at init time - > for the purpose of adding a dynamic FacesServlet - is valid. Given the > performance hit for the scan, I think adding a context param to disable the > scan would be worthwhile. Something like: > org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN > Would this be worthwhile for others? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15225078#comment-15225078 ] Bill Lucy commented on MYFACES-4042: Right, those mapping rules make sense. My logic here, though, is that 11.4.2 says that we can essentially skip that automatic mapping for performance, so why don't we make it configurable? > Improve startup time by skipping classpath jar scan for *.faces-config.xml > -- > > Key: MYFACES-4042 > URL: https://issues.apache.org/jira/browse/MYFACES-4042 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.18, 2.2.9 > Environment: WebSphere >Reporter: Bill Lucy >Priority: Minor > Attachments: MYFACES-4042.patch > > > In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated > to scan for faces-config.xml resources in applications JARs during startup, > as part of the process to add a FacesConfig in onStartup(). This is a very > expensive scan, since we have to iterate over every file in every jar on the > app classpath. > This scan is not completely necessary: in the spec we have: > Section 11.4.2 “Application Startup Behavior” > Implementations may check for the presence of a servlet-class definition of > class javax.faces.webapp.FacesServlet in the web application deployment > descriptor as a means to abort the configuration process and reduce startup > time for applications that do not use JavaServer Faces Technology. > Which I interpret to mean that skipping checking the app jars at init time - > for the purpose of adding a dynamic FacesServlet - is valid. Given the > performance hit for the scan, I think adding a context param to disable the > scan would be worthwhile. Something like: > org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN > Would this be worthwhile for others? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4044) Flow ID Ambiguity Is Not Handled Well
Bill Lucy created MYFACES-4044:
--
Summary: Flow ID Ambiguity Is Not Handled Well
Key: MYFACES-4044
URL: https://issues.apache.org/jira/browse/MYFACES-4044
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 2.2.9
Reporter: Bill Lucy
If we have multiple flows with the same IDs and definingDocumentIds, we won't
behave as expected: only one flow will actually be used, but no error or
warning to that effect is emitted.
Consider if we have two apps in the same EAR, each defining flows with an ID of
"sample-flow", like this:
final String flowId = "sample-flow";
flowBuilder.id("", flowId);
Per the JSF spec, this creates ambiguity:
11.4.3.1
Defining Flows
Flows are defined using the element. This element must have
an id attribute which uniquely
identifies the flow within the scope of the Application Configuration Resource
file in which the element appears. To
enable multiple flows with the same id to exist in an application, the
element is taken to
be the definingDocumentId of the flow. If no element is specified, the
empty string is taken as the value
for definingDocumentId.
In this case, app1 might define some kind of initializer with the flow, while
app2 doesn't. In that case, app2 might (incorrectly) end up trying to use an
initializer that was intended for app1. A developer might see issues resulting
from the initializer being called from the wrong app, but it wouldn't be clear
that the wrong flow had been entered (due to ambiguity).
Mojarra has something like this:
Caused by: java.lang.IllegalStateException: Flow with id \"sample-flow\" and
definingDocumentId \"\" already exists."}}
I think that MyFaces should emit some kind of similar warning/error in the
given scenario.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4044) Flow ID Ambiguity Is Not Handled Well
[
https://issues.apache.org/jira/browse/MYFACES-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256879#comment-15256879
]
Bill Lucy commented on MYFACES-4044:
I've provided a patch that just throws an IllegalArgumentException if we get to
this scenario. If no one has issues with this - throwing an exception - then
I'll commit this.
> Flow ID Ambiguity Is Not Handled Well
> -
>
> Key: MYFACES-4044
> URL: https://issues.apache.org/jira/browse/MYFACES-4044
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.2.9
>Reporter: Bill Lucy
> Attachments: MYFACES-4044.patch
>
>
> If we have multiple flows with the same IDs and definingDocumentIds, we won't
> behave as expected: only one flow will actually be used, but no error or
> warning to that effect is emitted.
> Consider if we have two apps in the same EAR, each defining flows with an ID
> of "sample-flow", like this:
> final String flowId = "sample-flow";
> flowBuilder.id("", flowId);
> Per the JSF spec, this creates ambiguity:
> 11.4.3.1
> Defining Flows
> Flows are defined using the element. This element must have
> an id attribute which uniquely
> identifies the flow within the scope of the Application Configuration
> Resource file in which the element appears. To
> enable multiple flows with the same id to exist in an application, the
> element is taken to
> be the definingDocumentId of the flow. If no element is specified, the
> empty string is taken as the value
> for definingDocumentId.
> In this case, app1 might define some kind of initializer with the flow, while
> app2 doesn't. In that case, app2 might (incorrectly) end up trying to use an
> initializer that was intended for app1. A developer might see issues
> resulting from the initializer being called from the wrong app, but it
> wouldn't be clear that the wrong flow had been entered (due to ambiguity).
> Mojarra has something like this:
> Caused by: java.lang.IllegalStateException: Flow with id \"sample-flow\" and
> definingDocumentId \"\" already exists."}}
> I think that MyFaces should emit some kind of similar warning/error in the
> given scenario.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4044) Flow ID Ambiguity Is Not Handled Well
[
https://issues.apache.org/jira/browse/MYFACES-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy updated MYFACES-4044:
---
Status: Patch Available (was: Open)
> Flow ID Ambiguity Is Not Handled Well
> -
>
> Key: MYFACES-4044
> URL: https://issues.apache.org/jira/browse/MYFACES-4044
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.2.9
>Reporter: Bill Lucy
> Attachments: MYFACES-4044.patch
>
>
> If we have multiple flows with the same IDs and definingDocumentIds, we won't
> behave as expected: only one flow will actually be used, but no error or
> warning to that effect is emitted.
> Consider if we have two apps in the same EAR, each defining flows with an ID
> of "sample-flow", like this:
> final String flowId = "sample-flow";
> flowBuilder.id("", flowId);
> Per the JSF spec, this creates ambiguity:
> 11.4.3.1
> Defining Flows
> Flows are defined using the element. This element must have
> an id attribute which uniquely
> identifies the flow within the scope of the Application Configuration
> Resource file in which the element appears. To
> enable multiple flows with the same id to exist in an application, the
> element is taken to
> be the definingDocumentId of the flow. If no element is specified, the
> empty string is taken as the value
> for definingDocumentId.
> In this case, app1 might define some kind of initializer with the flow, while
> app2 doesn't. In that case, app2 might (incorrectly) end up trying to use an
> initializer that was intended for app1. A developer might see issues
> resulting from the initializer being called from the wrong app, but it
> wouldn't be clear that the wrong flow had been entered (due to ambiguity).
> Mojarra has something like this:
> Caused by: java.lang.IllegalStateException: Flow with id \"sample-flow\" and
> definingDocumentId \"\" already exists."}}
> I think that MyFaces should emit some kind of similar warning/error in the
> given scenario.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4044) Flow ID Ambiguity Is Not Handled Well
[
https://issues.apache.org/jira/browse/MYFACES-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15257036#comment-15257036
]
Bill Lucy commented on MYFACES-4044:
Thanks for the feedback, Leo.. I'll do that.
> Flow ID Ambiguity Is Not Handled Well
> -
>
> Key: MYFACES-4044
> URL: https://issues.apache.org/jira/browse/MYFACES-4044
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.2.9
>Reporter: Bill Lucy
> Attachments: MYFACES-4044.patch
>
>
> If we have multiple flows with the same IDs and definingDocumentIds, we won't
> behave as expected: only one flow will actually be used, but no error or
> warning to that effect is emitted.
> Consider if we have two apps in the same EAR, each defining flows with an ID
> of "sample-flow", like this:
> final String flowId = "sample-flow";
> flowBuilder.id("", flowId);
> Per the JSF spec, this creates ambiguity:
> 11.4.3.1
> Defining Flows
> Flows are defined using the element. This element must have
> an id attribute which uniquely
> identifies the flow within the scope of the Application Configuration
> Resource file in which the element appears. To
> enable multiple flows with the same id to exist in an application, the
> element is taken to
> be the definingDocumentId of the flow. If no element is specified, the
> empty string is taken as the value
> for definingDocumentId.
> In this case, app1 might define some kind of initializer with the flow, while
> app2 doesn't. In that case, app2 might (incorrectly) end up trying to use an
> initializer that was intended for app1. A developer might see issues
> resulting from the initializer being called from the wrong app, but it
> wouldn't be clear that the wrong flow had been entered (due to ambiguity).
> Mojarra has something like this:
> Caused by: java.lang.IllegalStateException: Flow with id \"sample-flow\" and
> definingDocumentId \"\" already exists."}}
> I think that MyFaces should emit some kind of similar warning/error in the
> given scenario.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4044) Flow ID Ambiguity Is Not Handled Well
[
https://issues.apache.org/jira/browse/MYFACES-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy updated MYFACES-4044:
---
Resolution: Fixed
Assignee: Bill Lucy
Fix Version/s: 2.2.10
Status: Resolved (was: Patch Available)
> Flow ID Ambiguity Is Not Handled Well
> -
>
> Key: MYFACES-4044
> URL: https://issues.apache.org/jira/browse/MYFACES-4044
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.2.9
>Reporter: Bill Lucy
>Assignee: Bill Lucy
> Fix For: 2.2.10
>
> Attachments: MYFACES-4044.patch
>
>
> If we have multiple flows with the same IDs and definingDocumentIds, we won't
> behave as expected: only one flow will actually be used, but no error or
> warning to that effect is emitted.
> Consider if we have two apps in the same EAR, each defining flows with an ID
> of "sample-flow", like this:
> final String flowId = "sample-flow";
> flowBuilder.id("", flowId);
> Per the JSF spec, this creates ambiguity:
> 11.4.3.1
> Defining Flows
> Flows are defined using the element. This element must have
> an id attribute which uniquely
> identifies the flow within the scope of the Application Configuration
> Resource file in which the element appears. To
> enable multiple flows with the same id to exist in an application, the
> element is taken to
> be the definingDocumentId of the flow. If no element is specified, the
> empty string is taken as the value
> for definingDocumentId.
> In this case, app1 might define some kind of initializer with the flow, while
> app2 doesn't. In that case, app2 might (incorrectly) end up trying to use an
> initializer that was intended for app1. A developer might see issues
> resulting from the initializer being called from the wrong app, but it
> wouldn't be clear that the wrong flow had been entered (due to ambiguity).
> Mojarra has something like this:
> Caused by: java.lang.IllegalStateException: Flow with id \"sample-flow\" and
> definingDocumentId \"\" already exists."}}
> I think that MyFaces should emit some kind of similar warning/error in the
> given scenario.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4049) JSF myfaces unsynchronized access to a WeakHashMap
[ https://issues.apache.org/jira/browse/MYFACES-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319048#comment-15319048 ] Bill Lucy commented on MYFACES-4049: I've tested the patch locally, and it looks fine to me; this makes sense. > JSF myfaces unsynchronized access to a WeakHashMap > --- > > Key: MYFACES-4049 > URL: https://issues.apache.org/jira/browse/MYFACES-4049 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.2.10 >Reporter: Eduardo Breijo > Attachments: MYFACES-4049.patch > > > WebContainer threads are hanging due to a thread safety issue in the > underlying JSF 2.0 code. A non thread-safe WeakHashMap is being used in the > getRelativePath method of the DefaultFacelet class. Apache JSF 2.0 code is > not synchronizing on their usage of WeakHashMap in > org.apache.myfaces.view.facelets.impl.DefaultFacelet.getRelativePath. > In order to make the code thread-safe Collections.synchronizedMap method > needs to be used. > A patch has been provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4050) Validators not invoked for emptyselectManyCheckbox components
Bill Lucy created MYFACES-4050: -- Summary: Validators not invoked for emptyselectManyCheckbox components Key: MYFACES-4050 URL: https://issues.apache.org/jira/browse/MYFACES-4050 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.10 Environment: Tomcat, WebSphere Liberty Reporter: Bill Lucy Custom validators are not invoked for selectManyCheckbox component, if the component has no selections made; this can be an issue if we want to handle the null/empty case in a validator. The following context params address this case: javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL true javax.faces.VALIDATE_EMPTY_FIELDS true But these params do not affect the behavior here. Based on my understanding of the spec, it seems that this behavior should be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4050) Validators not invoked for empty selectManyCheckbox components
[ https://issues.apache.org/jira/browse/MYFACES-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4050: --- Status: Patch Available (was: Open) > Validators not invoked for empty selectManyCheckbox components > -- > > Key: MYFACES-4050 > URL: https://issues.apache.org/jira/browse/MYFACES-4050 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.10 > Environment: Tomcat, WebSphere Liberty >Reporter: Bill Lucy > Attachments: MYFACES-4050.patch > > > Custom validators are not invoked for selectManyCheckbox component, if the > component has no selections made; this can be an issue if we want to handle > the null/empty case in a validator. The following context params address > this case: > > > javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL > true > > > > javax.faces.VALIDATE_EMPTY_FIELDS > true > > But these params do not affect the behavior here. Based on my understanding > of the spec, it seems that this behavior should be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4050) Validators not invoked for empty selectManyCheckbox components
[ https://issues.apache.org/jira/browse/MYFACES-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15322783#comment-15322783 ] Bill Lucy commented on MYFACES-4050: The fix I'm proposing here is straightforward - we're overriding UIInput.validateValue() in UISelectMany; we need to check shouldValidateEmptyFields() in the overridden method. > Validators not invoked for empty selectManyCheckbox components > -- > > Key: MYFACES-4050 > URL: https://issues.apache.org/jira/browse/MYFACES-4050 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.10 > Environment: Tomcat, WebSphere Liberty >Reporter: Bill Lucy > Attachments: MYFACES-4050.patch > > > Custom validators are not invoked for selectManyCheckbox component, if the > component has no selections made; this can be an issue if we want to handle > the null/empty case in a validator. The following context params address > this case: > > > javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL > true > > > > javax.faces.VALIDATE_EMPTY_FIELDS > true > > But these params do not affect the behavior here. Based on my understanding > of the spec, it seems that this behavior should be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4051) FacesMessage.Severity always set to ERROR after ValidatorException
Bill Lucy created MYFACES-4051:
--
Summary: FacesMessage.Severity always set to ERROR after
ValidatorException
Key: MYFACES-4051
URL: https://issues.apache.org/jira/browse/MYFACES-4051
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.10
Environment: Tomcat, WebSphere Liberty
Reporter: Bill Lucy
The severity of messages is always set (overwritten) to SEVERITY_ERROR when a
ValidatorException is thrown during validation. In
org.apache.myfaces.view.facelets.compiler._ComponentUtils I see that we always
call
facesMessage.setSeverity(FacesMessage.SEVERITY_ERROR);
when processing a ValidatorException. This might make sense if we're assuming
that all faces messages default to some other severity, but it doesn't seem
right to me that we're overwriting user-set message severities. For example,
given the following custom validator:
public void validate(FacesContext context, UIComponent component,
Object value) {
if (value == null) {
List messageList = new ArrayList<>();
messageList.add(new
FacesMessage(FacesMessage.SEVERITY_INFO,
"ValidatorException#SEVERITY_INFO",
"ValidatorException#SEVERITY_INFO"));
throw new ValidatorException(messageList);
}
}
The severity of the custom message will always be set to SEVERITY.ERROR. I
don't see much guidance in the spec on this, but Mojarra behaves differently -
it does not overwrite custom FacesMessage severities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4049) JSF myfaces unsynchronized access to a WeakHashMap
[ https://issues.apache.org/jira/browse/MYFACES-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4049: --- Resolution: Fixed Assignee: Bill Lucy Fix Version/s: 2.2.11 2.1.19 2.0.25 Status: Resolved (was: Patch Available) Went ahead and committed this patch; thanks Eduardo Breijo! > JSF myfaces unsynchronized access to a WeakHashMap > --- > > Key: MYFACES-4049 > URL: https://issues.apache.org/jira/browse/MYFACES-4049 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.2.10 >Reporter: Eduardo Breijo >Assignee: Bill Lucy > Fix For: 2.0.25, 2.1.19, 2.2.11 > > Attachments: MYFACES-4049.patch > > > WebContainer threads are hanging due to a thread safety issue in the > underlying JSF 2.0 code. A non thread-safe WeakHashMap is being used in the > getRelativePath method of the DefaultFacelet class. Apache JSF 2.0 code is > not synchronizing on their usage of WeakHashMap in > org.apache.myfaces.view.facelets.impl.DefaultFacelet.getRelativePath. > In order to make the code thread-safe Collections.synchronizedMap method > needs to be used. > A patch has been provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4051) FacesMessage.Severity always set to ERROR after ValidatorException
[
https://issues.apache.org/jira/browse/MYFACES-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy updated MYFACES-4051:
---
Status: Patch Available (was: Open)
> FacesMessage.Severity always set to ERROR after ValidatorException
> --
>
> Key: MYFACES-4051
> URL: https://issues.apache.org/jira/browse/MYFACES-4051
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.10
> Environment: Tomcat, WebSphere Liberty
>Reporter: Bill Lucy
>
> The severity of messages is always set (overwritten) to SEVERITY_ERROR when a
> ValidatorException is thrown during validation. In
> org.apache.myfaces.view.facelets.compiler._ComponentUtils I see that we
> always call
> facesMessage.setSeverity(FacesMessage.SEVERITY_ERROR);
> when processing a ValidatorException. This might make sense if we're
> assuming that all faces messages default to some other severity, but it
> doesn't seem right to me that we're overwriting user-set message severities.
> For example, given the following custom validator:
> public void validate(FacesContext context, UIComponent component,
> Object value) {
> if (value == null) {
> List messageList = new ArrayList<>();
> messageList.add(new
> FacesMessage(FacesMessage.SEVERITY_INFO,
> "ValidatorException#SEVERITY_INFO",
> "ValidatorException#SEVERITY_INFO"));
> throw new ValidatorException(messageList);
> }
> }
> The severity of the custom message will always be set to SEVERITY.ERROR. I
> don't see much guidance in the spec on this, but Mojarra behaves differently
> - it does not overwrite custom FacesMessage severities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4051) FacesMessage.Severity always set to ERROR after ValidatorException
[
https://issues.apache.org/jira/browse/MYFACES-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15342234#comment-15342234
]
Bill Lucy commented on MYFACES-4051:
I see that the api for UIData.encodeBegin has "In addition to the default
behavior, ensure that any saved per-row state for our child input components is
discarded unless it is needed to rerender the current page with errors. "
Perhaps I'm missing it, but I don't immediately see anything about updating
preexisting message severities based on an error scenario.
> FacesMessage.Severity always set to ERROR after ValidatorException
> --
>
> Key: MYFACES-4051
> URL: https://issues.apache.org/jira/browse/MYFACES-4051
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.10
> Environment: Tomcat, WebSphere Liberty
>Reporter: Bill Lucy
> Attachments: MYFACES-4051.patch
>
>
> The severity of messages is always set (overwritten) to SEVERITY_ERROR when a
> ValidatorException is thrown during validation. In
> org.apache.myfaces.view.facelets.compiler._ComponentUtils I see that we
> always call
> facesMessage.setSeverity(FacesMessage.SEVERITY_ERROR);
> when processing a ValidatorException. This might make sense if we're
> assuming that all faces messages default to some other severity, but it
> doesn't seem right to me that we're overwriting user-set message severities.
> For example, given the following custom validator:
> public void validate(FacesContext context, UIComponent component,
> Object value) {
> if (value == null) {
> List messageList = new ArrayList<>();
> messageList.add(new
> FacesMessage(FacesMessage.SEVERITY_INFO,
> "ValidatorException#SEVERITY_INFO",
> "ValidatorException#SEVERITY_INFO"));
> throw new ValidatorException(messageList);
> }
> }
> The severity of the custom message will always be set to SEVERITY.ERROR. I
> don't see much guidance in the spec on this, but Mojarra behaves differently
> - it does not overwrite custom FacesMessage severities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4050) Validators not invoked for empty selectManyCheckbox components
[ https://issues.apache.org/jira/browse/MYFACES-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344625#comment-15344625 ] Bill Lucy commented on MYFACES-4050: Thanks for testing this [~lu4242] > Validators not invoked for empty selectManyCheckbox components > -- > > Key: MYFACES-4050 > URL: https://issues.apache.org/jira/browse/MYFACES-4050 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.10 > Environment: Tomcat, WebSphere Liberty >Reporter: Bill Lucy > Fix For: 2.0.25, 2.1.19, 2.2.11 > > Attachments: MYFACES-4050.patch, MYFACES-4050.patch > > > Custom validators are not invoked for selectManyCheckbox component, if the > component has no selections made; this can be an issue if we want to handle > the null/empty case in a validator. The following context params address > this case: > > > javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL > true > > > > javax.faces.VALIDATE_EMPTY_FIELDS > true > > But these params do not affect the behavior here. Based on my understanding > of the spec, it seems that this behavior should be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4051) FacesMessage.Severity always set to ERROR after ValidatorException
[
https://issues.apache.org/jira/browse/MYFACES-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344685#comment-15344685
]
Bill Lucy commented on MYFACES-4051:
Thanks for reviewing this [~lu4242]; I'll close this out
> FacesMessage.Severity always set to ERROR after ValidatorException
> --
>
> Key: MYFACES-4051
> URL: https://issues.apache.org/jira/browse/MYFACES-4051
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.10
> Environment: Tomcat, WebSphere Liberty
>Reporter: Bill Lucy
> Fix For: 1.2.13, 2.0.25, 2.1.19, 2.2.11
>
> Attachments: MYFACES-4051.patch
>
>
> The severity of messages is always set (overwritten) to SEVERITY_ERROR when a
> ValidatorException is thrown during validation. In
> org.apache.myfaces.view.facelets.compiler._ComponentUtils I see that we
> always call
> facesMessage.setSeverity(FacesMessage.SEVERITY_ERROR);
> when processing a ValidatorException. This might make sense if we're
> assuming that all faces messages default to some other severity, but it
> doesn't seem right to me that we're overwriting user-set message severities.
> For example, given the following custom validator:
> public void validate(FacesContext context, UIComponent component,
> Object value) {
> if (value == null) {
> List messageList = new ArrayList<>();
> messageList.add(new
> FacesMessage(FacesMessage.SEVERITY_INFO,
> "ValidatorException#SEVERITY_INFO",
> "ValidatorException#SEVERITY_INFO"));
> throw new ValidatorException(messageList);
> }
> }
> The severity of the custom message will always be set to SEVERITY.ERROR. I
> don't see much guidance in the spec on this, but Mojarra behaves differently
> - it does not overwrite custom FacesMessage severities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4051) FacesMessage.Severity always set to ERROR after ValidatorException
[
https://issues.apache.org/jira/browse/MYFACES-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy updated MYFACES-4051:
---
Resolution: Fixed
Assignee: Bill Lucy
Fix Version/s: 2.2.11
2.1.19
2.0.25
1.2.13
Status: Resolved (was: Patch Available)
> FacesMessage.Severity always set to ERROR after ValidatorException
> --
>
> Key: MYFACES-4051
> URL: https://issues.apache.org/jira/browse/MYFACES-4051
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.10
> Environment: Tomcat, WebSphere Liberty
>Reporter: Bill Lucy
>Assignee: Bill Lucy
> Fix For: 1.2.13, 2.0.25, 2.1.19, 2.2.11
>
> Attachments: MYFACES-4051.patch
>
>
> The severity of messages is always set (overwritten) to SEVERITY_ERROR when a
> ValidatorException is thrown during validation. In
> org.apache.myfaces.view.facelets.compiler._ComponentUtils I see that we
> always call
> facesMessage.setSeverity(FacesMessage.SEVERITY_ERROR);
> when processing a ValidatorException. This might make sense if we're
> assuming that all faces messages default to some other severity, but it
> doesn't seem right to me that we're overwriting user-set message severities.
> For example, given the following custom validator:
> public void validate(FacesContext context, UIComponent component,
> Object value) {
> if (value == null) {
> List messageList = new ArrayList<>();
> messageList.add(new
> FacesMessage(FacesMessage.SEVERITY_INFO,
> "ValidatorException#SEVERITY_INFO",
> "ValidatorException#SEVERITY_INFO"));
> throw new ValidatorException(messageList);
> }
> }
> The severity of the custom message will always be set to SEVERITY.ERROR. I
> don't see much guidance in the spec on this, but Mojarra behaves differently
> - it does not overwrite custom FacesMessage severities.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4060) Required attribute of h:inputFile tag is not working
[ https://issues.apache.org/jira/browse/MYFACES-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15415802#comment-15415802 ] Bill Lucy commented on MYFACES-4060: This is the same issue reported on the mailing list last year: https://mail-archives.apache.org/mod_mbox/myfaces-users/201504.mbox/%3ccam1yojzc-brknl4_dyebbnk0a4_9wzwq93krcp08uobot2s...@mail.gmail.com%3E The patch looks good to me - if there aren't any objections I'll commit it. > Required attribute of h:inputFile tag is not working > > > Key: MYFACES-4060 > URL: https://issues.apache.org/jira/browse/MYFACES-4060 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.10 >Reporter: Eduardo Breijo > Attachments: MYFACES-4060.patch > > > The required attribute of h:inputFile tag doesn't work when set to "true" and > no file is attached. The action will be executed regardless of the value of > the required attribute. > Example: > > > > > > An error message should be expected/displayed when the required attribute is > set to true, and no file is attached. Instead it is executing the action > without attachments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4060) Required attribute of h:inputFile tag is not working
[ https://issues.apache.org/jira/browse/MYFACES-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417818#comment-15417818 ] Bill Lucy commented on MYFACES-4060: Good catch for servlet 3.0 Leonardo. I've tested your patch and it looks fine to me. It's unfortunate that we have to duplicate classes, but I don't see a better solution now. > Required attribute of h:inputFile tag is not working > > > Key: MYFACES-4060 > URL: https://issues.apache.org/jira/browse/MYFACES-4060 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.10 >Reporter: Eduardo Breijo > Attachments: MYFACES-4060-2.patch, MYFACES-4060.patch > > > The required attribute of h:inputFile tag doesn't work when set to "true" and > no file is attached. The action will be executed regardless of the value of > the required attribute. > Example: > > > > > > An error message should be expected/displayed when the required attribute is > set to true, and no file is attached. Instead it is executing the action > without attachments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4065) Did not handled empty string while creating the resource
[ https://issues.apache.org/jira/browse/MYFACES-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4065: --- Status: Patch Available (was: Open) > Did not handled empty string while creating the resource > > > Key: MYFACES-4065 > URL: https://issues.apache.org/jira/browse/MYFACES-4065 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.2.3 > Environment: Windows, Tomcat >Reporter: Madhavi T >Priority: Minor > Attachments: MYFACES-4065.patch > > > java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at java.lang.String.charAt(Unknown Source) > at > org.apache.myfaces.application.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:118) > at > javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:47) > at > org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.createResource(CAPTCHAResourceHandlerWrapper.java:83) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:109) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:61) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:55) > at > javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:35) > at > org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:568) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.handleResourceRequest(CAPTCHAResourceHandlerWrapper.java:212) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > org.primefaces.application.resource.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:87) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:190) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:217) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) > at > org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518) > at > org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:844) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Unknown Source) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4065) Did not handled empty string while creating the resource
[ https://issues.apache.org/jira/browse/MYFACES-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15523826#comment-15523826 ] Bill Lucy commented on MYFACES-4065: The spec doesn't say anything about special handling for an empty string in javax.faces.application.ResourceHandlerWrapper.createResource().. so, in this case, I think it's reasonable to return a null resource in the case of an empty string rather than this StringIndexOutOfBoundsException. Patch attached, let me know if there are any objections. > Did not handled empty string while creating the resource > > > Key: MYFACES-4065 > URL: https://issues.apache.org/jira/browse/MYFACES-4065 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.2.3 > Environment: Windows, Tomcat >Reporter: Madhavi T >Priority: Minor > Attachments: MYFACES-4065.patch > > > java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at java.lang.String.charAt(Unknown Source) > at > org.apache.myfaces.application.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:118) > at > javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:47) > at > org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.createResource(CAPTCHAResourceHandlerWrapper.java:83) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:109) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:61) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:55) > at > javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:35) > at > org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:568) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.handleResourceRequest(CAPTCHAResourceHandlerWrapper.java:212) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > org.primefaces.application.resource.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:87) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:190) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:217) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) > at > org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518) > at > org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:844) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Sou
[jira] [Created] (MYFACES-4066) FlowBuilderFactoryBean Concurrency Issue
Bill Lucy created MYFACES-4066: -- Summary: FlowBuilderFactoryBean Concurrency Issue Key: MYFACES-4066 URL: https://issues.apache.org/jira/browse/MYFACES-4066 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.11 Environment: WebSphere Liberty Reporter: Bill Lucy Assignee: Bill Lucy Priority: Minor I've come accross a concurrency issue in org.apache.myfaces.flow.cdi.FlowBuilderFactoryBean.getFlowDefinitions(). If multiple applications (with programmatic flows) are starting up simultaneously, it's possible that the two responsible threads can concurrently modify the shared object FlowBuilderFactoryBean.flowDefinitions. That can result in the flowDefinitions for one of the applications not being processed. Synchronizing the getFlowDefinitions() method is the simplest fix for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4066) FlowBuilderFactoryBean Concurrency Issue
[ https://issues.apache.org/jira/browse/MYFACES-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4066: --- Status: Patch Available (was: Open) > FlowBuilderFactoryBean Concurrency Issue > > > Key: MYFACES-4066 > URL: https://issues.apache.org/jira/browse/MYFACES-4066 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.11 > Environment: WebSphere Liberty >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Attachments: MYFACES-4066.patch > > > I've come accross a concurrency issue in > org.apache.myfaces.flow.cdi.FlowBuilderFactoryBean.getFlowDefinitions(). If > multiple applications (with programmatic flows) are starting up > simultaneously, it's possible that the two responsible threads can > concurrently modify the shared object FlowBuilderFactoryBean.flowDefinitions. > That can result in the flowDefinitions for one of the applications not being > processed. > Synchronizing the getFlowDefinitions() method is the simplest fix for this > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4066) FlowBuilderFactoryBean Concurrency Issue
[ https://issues.apache.org/jira/browse/MYFACES-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15523924#comment-15523924 ] Bill Lucy commented on MYFACES-4066: I've attached a patch - synchronizing getFlowDefinitions - for review. > FlowBuilderFactoryBean Concurrency Issue > > > Key: MYFACES-4066 > URL: https://issues.apache.org/jira/browse/MYFACES-4066 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.11 > Environment: WebSphere Liberty >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Attachments: MYFACES-4066.patch > > > I've come accross a concurrency issue in > org.apache.myfaces.flow.cdi.FlowBuilderFactoryBean.getFlowDefinitions(). If > multiple applications (with programmatic flows) are starting up > simultaneously, it's possible that the two responsible threads can > concurrently modify the shared object FlowBuilderFactoryBean.flowDefinitions. > That can result in the flowDefinitions for one of the applications not being > processed. > Synchronizing the getFlowDefinitions() method is the simplest fix for this > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4067) UnsatisfiedResolutionException during JNDI lookup of CDI BeanManager
[
https://issues.apache.org/jira/browse/MYFACES-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15527302#comment-15527302
]
Bill Lucy commented on MYFACES-4067:
At a glance, I don't think this is a MyFaces issue; MyFaces is just asking jndi
for a BeanManager:
lookupMethod.invoke(icclazz, "java:comp/BeanManager");
It's more likely that this is a WebSphere configuration issue. WebSphere
doesn't support CDI integration with user-provided JSF implementations:
https://www.ibm.com/support/knowledgecenter/SS7JFU_8.5.5/com.ibm.websphere.nd.doc/ae/cweb_cdi_integration.html
More information is needed for advice on the WebSphere configuration.
> UnsatisfiedResolutionException during JNDI lookup of CDI BeanManager
>
>
> Key: MYFACES-4067
> URL: https://issues.apache.org/jira/browse/MYFACES-4067
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.11
> Environment: Websphere 8.5.5.9
>Reporter: Vincent Privat
>Priority: Minor
>
> When starting MyFaces 2.2.11 on Websphere 8.5.5.9 with a non-CDI application,
> we get the following stacktrace in FFDC incidents:
> {code}
> javax.enterprise.inject.UnsatisfiedResolutionException: The myapp.war module
> in the myapp-ear application is not CDI enabled. The CDI BeanManager is not
> available for applications that are not CDI enabled.
> at
> com.ibm.ws.webbeans.naming.BeanManagerObjectFactory.getObjectInstance(BeanManagerObjectFactory.java:123)
> at
> org.apache.aries.jndi.ObjectFactoryHelper.getObjectInstanceUsingObjectFactoryBuilders(ObjectFactoryHelper.java:351)
> at
> org.apache.aries.jndi.ObjectFactoryHelper.getObjectInstance(ObjectFactoryHelper.java:109)
> at
> org.apache.aries.jndi.OSGiObjectFactoryBuilder.getObjectInstance(OSGiObjectFactoryBuilder.java:62)
> at
> javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:312)
> at
> com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookupExt(Helpers.java:993)
> at
> com.ibm.ws.naming.urlbase.UrlContextHelper.processBoundObjectForLookup(UrlContextHelper.java:182)
> at
> com.ibm.ws.naming.java.javaURLContextRoot.processBoundObjectForLookup(javaURLContextRoot.java:850)
> at
> com.ibm.ws.naming.urlbase.UrlContextImpl.lookupExt(UrlContextImpl.java:1454)
> at
> com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:477)
> at
> com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:485)
> at
> com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
> at
> org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
> at javax.naming.InitialContext.lookup(InitialContext.java:423)
> at javax.naming.InitialContext.doLookup(InitialContext.java:296)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.lookupBeanManagerFromJndi(AbstractFacesInitializer.java:663)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.initCDIIntegration(AbstractFacesInitializer.java:580)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:170)
> at
> org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
> at
> com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1709)
> at
> com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:414)
> at
> com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
> at
> com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:170)
> at
> com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:904)
> at
> com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:789)
> at
> com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:427)
> at
> com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:719)
> at
> com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1178)
> at
> com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1383)
> at
> com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:639)
> at
> com.ibm.ws.runtime.component.DeployedApplicationImpl.start(Dep
[jira] [Updated] (MYFACES-4066) FlowBuilderFactoryBean Concurrency Issue
[ https://issues.apache.org/jira/browse/MYFACES-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4066: --- Resolution: Fixed Fix Version/s: 2.2.12 Status: Resolved (was: Patch Available) I've gone ahead and committed this change. > FlowBuilderFactoryBean Concurrency Issue > > > Key: MYFACES-4066 > URL: https://issues.apache.org/jira/browse/MYFACES-4066 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.11 > Environment: WebSphere Liberty >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Fix For: 2.2.12 > > Attachments: MYFACES-4066.patch > > > I've come accross a concurrency issue in > org.apache.myfaces.flow.cdi.FlowBuilderFactoryBean.getFlowDefinitions(). If > multiple applications (with programmatic flows) are starting up > simultaneously, it's possible that the two responsible threads can > concurrently modify the shared object FlowBuilderFactoryBean.flowDefinitions. > That can result in the flowDefinitions for one of the applications not being > processed. > Synchronizing the getFlowDefinitions() method is the simplest fix for this > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4107) StringIndexOutOfBoundsException in getResourceVersion
[ https://issues.apache.org/jira/browse/MYFACES-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4107: --- Status: Patch Available (was: Open) > StringIndexOutOfBoundsException in getResourceVersion > - > > Key: MYFACES-4107 > URL: https://issues.apache.org/jira/browse/MYFACES-4107 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12 > Environment: WebSphere Liberty >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Attachments: MYFACES-4107.patch > > > I've run into a case where, given an incorrect context parameter, a > StringIndexOutOfBoundsException is thrown. This occurs in WebSphere Liberty > because the server normalizes the external context resource paths during app > initialization. > For example, this parameter: > >javax.faces.WEBAPP_RESOURCES_DIRECTORY >/META-INF/resources > > throws: > java.lang.StringIndexOutOfBoundsException: String index out of range: 35 > at java.lang.String.substring(String.java:1377) > at > org.apache.myfaces.shared.resource.ExternalContextResourceLoader.getResourceVersion(ExternalContextResourceLoader.java:81) > That parameter value is not allowed to have a leading slash. However, the > current exception is not very helpful, and can be easily avoided. > I'll attach a patch which avoids the StringIndexOutOfBoundsException in > getResourceVersion(); we already have this logic in getLibraryVersion(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYFACES-4107) StringIndexOutOfBoundsException in getResourceVersion
Bill Lucy created MYFACES-4107: -- Summary: StringIndexOutOfBoundsException in getResourceVersion Key: MYFACES-4107 URL: https://issues.apache.org/jira/browse/MYFACES-4107 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.12, 2.1.18, 2.0.24 Environment: WebSphere Liberty Reporter: Bill Lucy Assignee: Bill Lucy Priority: Minor Attachments: MYFACES-4107.patch I've run into a case where, given an incorrect context parameter, a StringIndexOutOfBoundsException is thrown. This occurs in WebSphere Liberty because the server normalizes the external context resource paths during app initialization. For example, this parameter: javax.faces.WEBAPP_RESOURCES_DIRECTORY /META-INF/resources throws: java.lang.StringIndexOutOfBoundsException: String index out of range: 35 at java.lang.String.substring(String.java:1377) at org.apache.myfaces.shared.resource.ExternalContextResourceLoader.getResourceVersion(ExternalContextResourceLoader.java:81) That parameter value is not allowed to have a leading slash. However, the current exception is not very helpful, and can be easily avoided. I'll attach a patch which avoids the StringIndexOutOfBoundsException in getResourceVersion(); we already have this logic in getLibraryVersion(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYFACES-4107) StringIndexOutOfBoundsException in getResourceVersion
[ https://issues.apache.org/jira/browse/MYFACES-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15959547#comment-15959547 ] Bill Lucy commented on MYFACES-4107: If no one has any issues with the patch, I'll commit it tomorrow. > StringIndexOutOfBoundsException in getResourceVersion > - > > Key: MYFACES-4107 > URL: https://issues.apache.org/jira/browse/MYFACES-4107 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12 > Environment: WebSphere Liberty >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Attachments: MYFACES-4107.patch > > > I've run into a case where, given an incorrect context parameter, a > StringIndexOutOfBoundsException is thrown. This occurs in WebSphere Liberty > because the server normalizes the external context resource paths during app > initialization. > For example, this parameter: > >javax.faces.WEBAPP_RESOURCES_DIRECTORY >/META-INF/resources > > throws: > java.lang.StringIndexOutOfBoundsException: String index out of range: 35 > at java.lang.String.substring(String.java:1377) > at > org.apache.myfaces.shared.resource.ExternalContextResourceLoader.getResourceVersion(ExternalContextResourceLoader.java:81) > That parameter value is not allowed to have a leading slash. However, the > current exception is not very helpful, and can be easily avoided. > I'll attach a patch which avoids the StringIndexOutOfBoundsException in > getResourceVersion(); we already have this logic in getLibraryVersion(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYFACES-4107) StringIndexOutOfBoundsException in getResourceVersion
[ https://issues.apache.org/jira/browse/MYFACES-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy updated MYFACES-4107: --- Resolution: Fixed Fix Version/s: 2.3.0 2.2.13 2.1.19 2.0.25 Status: Resolved (was: Patch Available) > StringIndexOutOfBoundsException in getResourceVersion > - > > Key: MYFACES-4107 > URL: https://issues.apache.org/jira/browse/MYFACES-4107 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12, 2.3.0 > Environment: WebSphere Liberty >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Fix For: 2.0.25, 2.1.19, 2.2.13, 2.3.0 > > Attachments: MYFACES-4107.patch > > > I've run into a case where, given an incorrect context parameter, a > StringIndexOutOfBoundsException is thrown. This occurs in WebSphere Liberty > because the server normalizes the external context resource paths during app > initialization. > For example, this parameter: > >javax.faces.WEBAPP_RESOURCES_DIRECTORY >/META-INF/resources > > throws: > java.lang.StringIndexOutOfBoundsException: String index out of range: 35 > at java.lang.String.substring(String.java:1377) > at > org.apache.myfaces.shared.resource.ExternalContextResourceLoader.getResourceVersion(ExternalContextResourceLoader.java:81) > That parameter value is not allowed to have a leading slash. However, the > current exception is not very helpful, and can be easily avoided. > I'll attach a patch which avoids the StringIndexOutOfBoundsException in > getResourceVersion(); we already have this logic in getLibraryVersion(). -- 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&focusedCommentId=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] [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=16044523#comment-16044523
]
Bill Lucy commented on MYFACES-3525:
Thanks for the input Leonardo, and thanks for the patch Eduardo. I've
committed the patch (with an updated comment/description) to the 2.0, 2.1, and
2.2 branches.
> 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
> Attachments: 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.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&focusedCommentId=16049316#comment-16049316
]
Bill Lucy commented on MYFACES-3525:
[~bommel] I may be misinterpreting you, but based on my reading of the jsf 2.0
spec we're doing this correctly. In section 11.1.3: "If the
javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter
value is true (ignoring case), and UIInput.getSubmittedValue() returns a
zero-length String call UIInput.setSubmittedValue(null) and continue processing
using null as the current submitted value" Can you clarify how you think we
should fix this?
> 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
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: 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=16100634#comment-16100634
]
Bill Lucy commented on MYFACES-3525:
Would you mind attaching a patch here or on the dev list so I can make sure I
understand your proposal?
> 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
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: 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=16101871#comment-16101871
]
Bill Lucy commented on MYFACES-3525:
Thanks for the patch! The behavior looks good to me - but regarding Leonardo's
comment above, is it OK for us to change the default behavior here?
> 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
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch,
> MYFACES-3525-setsubmittedValueagain.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-4125) Response committed too early due to flush from StateWriter
[ https://issues.apache.org/jira/browse/MYFACES-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137066#comment-16137066 ] Bill Lucy commented on MYFACES-4125: [~eduardobreijo] I've just tested adding a oam.EARLY_FLUSH_ENABLED check to HtmlResponseWriterImpl.endDocument, as you've proposed, and that behaves as you'd expect. I'd be fine going with change. > Response committed too early due to flush from StateWriter > -- > > Key: MYFACES-4125 > URL: https://issues.apache.org/jira/browse/MYFACES-4125 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12 >Reporter: Eduardo Breijo >Assignee: Leonardo Uribe > Attachments: server.log, StateWriter.war > > > We've found a problem where it seems that MyFaces is flushing output too > early in the RENDER_RESPONSE PHASE. As a result the response is committed > before we have a chance to handle an error in that phase. > This is because the renderView method from FaceletViewDeclarationLanguage > calls writer.endDocument() which ends up calling the flush() method from > StateWriter. This commit behavior is different between 2.0 and 2.2. It looks > like a flush() was empty on 2.0, and now a call was added, which causes the > issue we are seeing. > Here's a sample app: > 1) Drive a request: localhost:9080/StateWriter/index.xhtml > 2) You should be able to see in the logs that response was committed, so > redirect to error.xhtml cannot be performed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4058) ProtectedViewException for a protectedview access while checking the OriginHeader for appContextPath
[ https://issues.apache.org/jira/browse/MYFACES-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194833#comment-16194833 ] Bill Lucy commented on MYFACES-4058: I've been looking into this issue as well; in the scenario I'm investigating, protected views are broken in Safari. Similar to the other posts here, I can see an Origin header added by Safari to a non-CORS request. I can see that JSF 2.2 section 2.2.1 says we should be checking the Origin header in the same way we check the Referer header.. but that doesn't make sense: the header is not intended to contain any path info. (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin) So it looks like checking the Origin header in RestoreViewExecutor.checkRefererOrOriginHeader() will always fail. Checking the Origin header against the ExternalContext's host and port makes sense, but not the full path. Changing the default behavior here would make sense to me, given my current understanding, but a custom param would work, given the language in the spec. [~lu4242] what are your thoughts? > ProtectedViewException for a protectedview access while checking the > OriginHeader for appContextPath > > > Key: MYFACES-4058 > URL: https://issues.apache.org/jira/browse/MYFACES-4058 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.2.6 > Environment: Windows, JSF 2.2 >Reporter: Dinesh Kumar A S > > Getting ProtectedViewException while accessing a protectedview/xhtml, while > checking the OriginHeader for appContextPath.. > SO reference : > http://stackoverflow.com/questions/38308431/jsf-2-2-protectedviewexception-due-to-origin-header-and-appcontextpath-mismatch > Any help is much appreciated. > Does the "Origin" request-header is supposed to have the appContextPath in > the path/urlInfo ? -- 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=16309887#comment-16309887
]
Bill Lucy commented on MYFACES-3525:
We need to decide what to do with this issue for 2.3, either pull in Bernd's
change or the EMPTY_VALUES_AS_NULL_CLEAR_INPUT_PARAM_NAME parameter. Correct
me if I'm wrong, but from what I can tell after reading over
https://github.com/javaee/javaserverfaces-spec/issues/671 the 2.3 spec hasn't
actually changed - so the behavior change issue still stands.
> 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] [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)
[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] [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] [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] [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=16320378#comment-16320378
]
Bill Lucy commented on MYFACES-3525:
I agree that 3) is a valid case - but I don't think we care about it here. The
context param gives users the choice of using 2).. so I think it's OK. If we
leave that in, what additional cleanup can be done in the most recent patch?
> 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=16321207#comment-16321207
]
Bill Lucy commented on MYFACES-3525:
Is something like CLEAR_COMPONENT_INPUT_WHEN_NULL_VALUE_SUBMITTED better? Not
an easy param to come up with.
> 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=16322450#comment-16322450
]
Bill Lucy commented on MYFACES-3525:
That covers the behavior a little better; +1 for
CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_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, 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=16322845#comment-16322845
]
Bill Lucy commented on MYFACES-3525:
[~tandraschko] I think the relationship between
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL and
CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY makes sense. As I understand
the patch, the three states you mentioned can be configured:
*always clear -- set CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY=true
(2.3 default case)
*always populate from model -- set
CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY=false and
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL=true
*PRE JSF 2.3 behavior -- set
CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY=false and
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL=true
> 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-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: --- Resolution: Fixed Fix Version/s: 2.3.0 2.2.13 2.1.19 2.0.25 Status: Resolved (was: Patch Available) I've applied the patch here to all branches. > 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 > Fix For: 2.0.25, 2.1.19, 2.2.13, 2.3.0 > > 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] [Commented] (MYFACES-3629) StartupServletContextListener crashes if FacesServlet is defined in web-fragments.
[ https://issues.apache.org/jira/browse/MYFACES-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16578895#comment-16578895 ] Bill Lucy commented on MYFACES-3629: I've been able to reproduce this on the 2.3 release. A possible fix is in the linked PR. I'm actually not sure if we even need to check for the presence of a faces servlet mapping in AbstractFacesInitializer.initFaces() - in my testing, behavior is the same when that check is removed completely. (Except of course we don't have this issue with web fragments when the initFaces check is removed!) The PR I've provided is taking a safe route and not getting rid of that initFaces check, but if anyone with a better understanding of the history of that code thinks it's OK to remove let me know. > StartupServletContextListener crashes if FacesServlet is defined in > web-fragments. > -- > > Key: MYFACES-3629 > URL: https://issues.apache.org/jira/browse/MYFACES-3629 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.1.9 >Reporter: Mark Struberg >Assignee: Bill Lucy >Priority: Major > > I'm trying to move all my common web.xml content from my 12 webapps in an EAR > into a web-fragment.xml which gets referenced. > MyFaces fails with the following Exception if the FacesServlet is defined in > a web-fragment rather than web.xml: > >If you did that and find nothing, the mistake might be due to the fact that > >you use some special > >web-containers which do not support registering context-listeners via TLD > >files and a context listener is not > > setup in your web.xml. > > A typical config looks like this; > > > > > > org.apache.myfaces.webapp.StartupServletContextListener > > > In general the StartupServletContextListener defined in JSF-2.1 is pure PITA > as it does crash apps which do not have any JSF content at all!. > We should scan if we either find a faces-config.xml or any *.xhtml files in > the app and if not we shall not start JSF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-3629) StartupServletContextListener crashes if FacesServlet is defined in web-fragments.
[ https://issues.apache.org/jira/browse/MYFACES-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590363#comment-16590363 ] Bill Lucy commented on MYFACES-3629: Asking again - does anyone else have any thoughts on this scenario? If not I'll merge the changes in PR 16. > StartupServletContextListener crashes if FacesServlet is defined in > web-fragments. > -- > > Key: MYFACES-3629 > URL: https://issues.apache.org/jira/browse/MYFACES-3629 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.1.9 >Reporter: Mark Struberg >Assignee: Bill Lucy >Priority: Major > > I'm trying to move all my common web.xml content from my 12 webapps in an EAR > into a web-fragment.xml which gets referenced. > MyFaces fails with the following Exception if the FacesServlet is defined in > a web-fragment rather than web.xml: > >If you did that and find nothing, the mistake might be due to the fact that > >you use some special > >web-containers which do not support registering context-listeners via TLD > >files and a context listener is not > > setup in your web.xml. > > A typical config looks like this; > > > > > > org.apache.myfaces.webapp.StartupServletContextListener > > > In general the StartupServletContextListener defined in JSF-2.1 is pure PITA > as it does crash apps which do not have any JSF content at all!. > We should scan if we either find a faces-config.xml or any *.xhtml files in > the app and if not we shall not start JSF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MYFACES-3629) StartupServletContextListener crashes if FacesServlet is defined in web-fragments.
[ https://issues.apache.org/jira/browse/MYFACES-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy resolved MYFACES-3629. Resolution: Fixed > StartupServletContextListener crashes if FacesServlet is defined in > web-fragments. > -- > > Key: MYFACES-3629 > URL: https://issues.apache.org/jira/browse/MYFACES-3629 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.1.9 >Reporter: Mark Struberg >Assignee: Bill Lucy >Priority: Major > Fix For: 2.2.13, 2.3.2 > > > I'm trying to move all my common web.xml content from my 12 webapps in an EAR > into a web-fragment.xml which gets referenced. > MyFaces fails with the following Exception if the FacesServlet is defined in > a web-fragment rather than web.xml: > >If you did that and find nothing, the mistake might be due to the fact that > >you use some special > >web-containers which do not support registering context-listeners via TLD > >files and a context listener is not > > setup in your web.xml. > > A typical config looks like this; > > > > > > org.apache.myfaces.webapp.StartupServletContextListener > > > In general the StartupServletContextListener defined in JSF-2.1 is pure PITA > as it does crash apps which do not have any JSF content at all!. > We should scan if we either find a faces-config.xml or any *.xhtml files in > the app and if not we shall not start JSF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4252) Classpath._searchDir can throw NullPointerException
Bill Lucy created MYFACES-4252: -- Summary: Classpath._searchDir can throw NullPointerException Key: MYFACES-4252 URL: https://issues.apache.org/jira/browse/MYFACES-4252 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3.1, 2.2.12, 2.1.18, 2.0.24 Environment: WebSphere 9 Reporter: Bill Lucy Assignee: Bill Lucy In rare cases, Classpath._searchDir can throw a NPE and cause startup to fail. I'll update _searchDir() to tolerate the case where File.listFiles() returns null. DefaultFacesC I Reading config /WEB-INF/faces-config.xml AbstractFaces E An error occured while initializing MyFaces: java.lang.NullPointerException javax.faces.FacesException: java.lang.NullPointerException Caused by: java.lang.NullPointerException at org.apache.myfaces.view.facelets.util.Classpath._searchDir(Classpath.java:143) at org.apache.myfaces.view.facelets.util.Classpath._searchResource(Classpath.java:115) at org.apache.myfaces.view.facelets.util.Classpath.search(Classpath.java:68) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MYFACES-4252) Classpath._searchDir can throw NullPointerException
[ https://issues.apache.org/jira/browse/MYFACES-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy resolved MYFACES-4252. Resolution: Fixed Fix Version/s: 2.3.3 2.2.13 2.1.19 2.0.25 > Classpath._searchDir can throw NullPointerException > --- > > Key: MYFACES-4252 > URL: https://issues.apache.org/jira/browse/MYFACES-4252 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12, 2.3.1 > Environment: WebSphere 9 >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Major > Fix For: 2.0.25, 2.1.19, 2.2.13, 2.3.3 > > > In rare cases, Classpath._searchDir can throw a NPE and cause startup to > fail. I'll update _searchDir() to tolerate the case where File.listFiles() > returns null. > DefaultFacesC I Reading config /WEB-INF/faces-config.xml > AbstractFaces E An error occured while initializing MyFaces: > java.lang.NullPointerException > javax.faces.FacesException: java.lang.NullPointerException > > Caused by: java.lang.NullPointerException > at > org.apache.myfaces.view.facelets.util.Classpath._searchDir(Classpath.java:143) > at > org.apache.myfaces.view.facelets.util.Classpath._searchResource(Classpath.java:115) > at org.apache.myfaces.view.facelets.util.Classpath.search(Classpath.java:68) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4267) transient attribute is not inherited from template to final page.
[
https://issues.apache.org/jira/browse/MYFACES-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699334#comment-16699334
]
Bill Lucy commented on MYFACES-4267:
I spent a little time last week investigating this problem. This behavior is
caused by the fix in https://issues.apache.org/jira/browse/MYFACES-4164
I've opened a PR (see comment above) for a potential fix. The inherited
transient flag isn't set on the view until after buildView(), so checking
isTransient() after buildView() should fix this case. [~antgar9] can you test
out the PR for your case?
> transient attribute is not inherited from template to final page.
> -
>
> Key: MYFACES-4267
> URL: https://issues.apache.org/jira/browse/MYFACES-4267
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 2.3.2
>Reporter: Antgar
>Priority: Major
> Fix For: 2.3.3, 3.0.0-SNAPSHOT
>
>
> After upgrading from Myfaces 2.2 to 2.3, templated transient views stop to
> work, raising "unable to create views" exceptions.
> f:view transient attribute defined in a template seems not to be inherited by
> the final page correctly. With myfaces 2.2 it worked correctly, but in 2.3,
> there is a new check
> {code:java}
> if (!view.isTransient()) ...
> {code}
> on FaceletViewDeclarationLanguage line 2128. On page restoring, transient
> appears as false.
> A workaround is to set transient="true" on the final page too. Other option
> is to use a block
> {code:java}
>
> {code}
> on the final page (f:metadata doc says it shouldn't be used in templates).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4267) transient attribute is not inherited from template to final page.
[
https://issues.apache.org/jira/browse/MYFACES-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699335#comment-16699335
]
Bill Lucy commented on MYFACES-4267:
[~tandraschko] I'll try to get your unit test working for this case before
merging the PR
> transient attribute is not inherited from template to final page.
> -
>
> Key: MYFACES-4267
> URL: https://issues.apache.org/jira/browse/MYFACES-4267
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 2.3.2
>Reporter: Antgar
>Priority: Major
> Fix For: 2.3.3, 3.0.0-SNAPSHOT
>
>
> After upgrading from Myfaces 2.2 to 2.3, templated transient views stop to
> work, raising "unable to create views" exceptions.
> f:view transient attribute defined in a template seems not to be inherited by
> the final page correctly. With myfaces 2.2 it worked correctly, but in 2.3,
> there is a new check
> {code:java}
> if (!view.isTransient()) ...
> {code}
> on FaceletViewDeclarationLanguage line 2128. On page restoring, transient
> appears as false.
> A workaround is to set transient="true" on the final page too. Other option
> is to use a block
> {code:java}
>
> {code}
> on the final page (f:metadata doc says it shouldn't be used in templates).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4267) transient attribute is not inherited from template to final page.
[
https://issues.apache.org/jira/browse/MYFACES-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16702367#comment-16702367
]
Bill Lucy commented on MYFACES-4267:
[~tandraschko] I've updated your test case to reproduce the problem here -
https://github.com/apache/myfaces/pull/28. If everyone's OK with the fix/test
I'll merge the PR.
> transient attribute is not inherited from template to final page.
> -
>
> Key: MYFACES-4267
> URL: https://issues.apache.org/jira/browse/MYFACES-4267
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 2.3.2
>Reporter: Antgar
>Priority: Major
> Fix For: 2.3.3, 3.0.0-SNAPSHOT
>
>
> After upgrading from Myfaces 2.2 to 2.3, templated transient views stop to
> work, raising "unable to create views" exceptions.
> f:view transient attribute defined in a template seems not to be inherited by
> the final page correctly. With myfaces 2.2 it worked correctly, but in 2.3,
> there is a new check
> {code:java}
> if (!view.isTransient()) ...
> {code}
> on FaceletViewDeclarationLanguage line 2128. On page restoring, transient
> appears as false.
> A workaround is to set transient="true" on the final page too. Other option
> is to use a block
> {code:java}
>
> {code}
> on the final page (f:metadata doc says it shouldn't be used in templates).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4267) transient attribute is not inherited from template to final page.
[
https://issues.apache.org/jira/browse/MYFACES-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16708686#comment-16708686
]
Bill Lucy commented on MYFACES-4267:
Thanks - I've been waiting for another user who reported this to me separately
to verify the fix. I'll merge ASAP.
> transient attribute is not inherited from template to final page.
> -
>
> Key: MYFACES-4267
> URL: https://issues.apache.org/jira/browse/MYFACES-4267
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 2.3.2
>Reporter: Antgar
>Priority: Major
> Fix For: 2.3.3, 3.0.0-SNAPSHOT
>
>
> After upgrading from Myfaces 2.2 to 2.3, templated transient views stop to
> work, raising "unable to create views" exceptions.
> f:view transient attribute defined in a template seems not to be inherited by
> the final page correctly. With myfaces 2.2 it worked correctly, but in 2.3,
> there is a new check
> {code:java}
> if (!view.isTransient()) ...
> {code}
> on FaceletViewDeclarationLanguage line 2128. On page restoring, transient
> appears as false.
> A workaround is to set transient="true" on the final page too. Other option
> is to use a block
> {code:java}
>
> {code}
> on the final page (f:metadata doc says it shouldn't be used in templates).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MYFACES-4267) transient attribute is not inherited from template to final page.
[
https://issues.apache.org/jira/browse/MYFACES-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Lucy resolved MYFACES-4267.
Resolution: Fixed
Assignee: Bill Lucy
Fix Version/s: 2.2.13
> transient attribute is not inherited from template to final page.
> -
>
> Key: MYFACES-4267
> URL: https://issues.apache.org/jira/browse/MYFACES-4267
> Project: MyFaces Core
> Issue Type: Bug
> Components: Extension Feature
>Affects Versions: 2.3.2
>Reporter: Antgar
>Assignee: Bill Lucy
>Priority: Major
> Fix For: 2.2.13, 2.3.3, 3.0.0-SNAPSHOT
>
>
> After upgrading from Myfaces 2.2 to 2.3, templated transient views stop to
> work, raising "unable to create views" exceptions.
> f:view transient attribute defined in a template seems not to be inherited by
> the final page correctly. With myfaces 2.2 it worked correctly, but in 2.3,
> there is a new check
> {code:java}
> if (!view.isTransient()) ...
> {code}
> on FaceletViewDeclarationLanguage line 2128. On page restoring, transient
> appears as false.
> A workaround is to set transient="true" on the final page too. Other option
> is to use a block
> {code:java}
>
> {code}
> on the final page (f:metadata doc says it shouldn't be used in templates).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MYFACES-4273) JarFile never released in oam.view.facelets.util.ClassPath
Bill Lucy created MYFACES-4273: -- Summary: JarFile never released in oam.view.facelets.util.ClassPath Key: MYFACES-4273 URL: https://issues.apache.org/jira/browse/MYFACES-4273 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3.2, 2.2.12, 2.1.18, 2.0.24, 3.0.0-SNAPSHOT Reporter: Bill Lucy Assignee: Bill Lucy JarFiles opened in ClassPath._searchResource() aren't ever closed. This can cause a leak, and in some environments that causes problems removing apps after shutdown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MYFACES-4273) JarFile never released in oam.view.facelets.util.ClassPath
[ https://issues.apache.org/jira/browse/MYFACES-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Lucy resolved MYFACES-4273. Resolution: Fixed Fix Version/s: 3.0.0-SNAPSHOT 2.3.3 2.2.13 2.1.19 2.0.25 > JarFile never released in oam.view.facelets.util.ClassPath > -- > > Key: MYFACES-4273 > URL: https://issues.apache.org/jira/browse/MYFACES-4273 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12, 2.3.2, 3.0.0-SNAPSHOT >Reporter: Bill Lucy >Assignee: Bill Lucy >Priority: Minor > Fix For: 2.0.25, 2.1.19, 2.2.13, 2.3.3, 3.0.0-SNAPSHOT > > > JarFiles opened in ClassPath._searchResource() aren't ever closed. This can > cause a leak, and in some environments that causes problems removing apps > after shutdown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4282) Incompatibility with DeltaSpike JSF Module 1.x
[ https://issues.apache.org/jira/browse/MYFACES-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766309#comment-16766309 ] Bill Lucy commented on MYFACES-4282: Thanks for providing the sample project [~j-be]. I worked with Eduardo on the fix for https://issues.apache.org/jira/browse/MYFACES-4260, so I'll start investigating how to rework that change. > Incompatibility with DeltaSpike JSF Module 1.x > -- > > Key: MYFACES-4282 > URL: https://issues.apache.org/jira/browse/MYFACES-4282 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.3 > Environment: Tomcat 9.0.14 > OpenWebBeans 2.0.8 > DeltaSpike 1.x (tested 1.0.0, 1.8.2, 1.9.0) >Reporter: Juri Berlanda >Assignee: Eduardo Breijo >Priority: Major > Fix For: 3.0.0-SNAPSHOT, 2.3.4 > > > Some change in 2.3.3 causes and incompatibility with Apache DeltaSpike's JSF > Module. I am not sure yet what exactly causes it, but MyFaces 2.3.2 is NOT > affected. > The issue arose on our side, as we noticed @PostConstruct of some of our > @ViewScope @Model is called twice. > Mojarra 2.3.8 is NOT affected, which - together with the fact that MyFaces > 2.3.2 is not affected either - brings me to the conclusion this is a bug > introduced with MyFaces 2.3.3. > I have a minimal project showing the issue, which I will link here shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4282) Incompatibility with DeltaSpike JSF Module 1.x
[ https://issues.apache.org/jira/browse/MYFACES-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781660#comment-16781660 ] Bill Lucy commented on MYFACES-4282: Slow progress [~tandraschko] - I haven't yet been able to rework #4260 so that both Juli's test case and the (unwieldy) test case we have for #4260 are passing. I'll try to give more priority to this. > Incompatibility with DeltaSpike JSF Module 1.x > -- > > Key: MYFACES-4282 > URL: https://issues.apache.org/jira/browse/MYFACES-4282 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.3 > Environment: Tomcat 9.0.14 > OpenWebBeans 2.0.8 > DeltaSpike 1.x (tested 1.0.0, 1.8.2, 1.9.0) >Reporter: Juri Berlanda >Assignee: Eduardo Breijo >Priority: Major > Fix For: 3.0.0-SNAPSHOT, 2.3.4 > > > Some change in 2.3.3 causes and incompatibility with Apache DeltaSpike's JSF > Module. I am not sure yet what exactly causes it, but MyFaces 2.3.2 is NOT > affected. > The issue arose on our side, as we noticed @PostConstruct of some of our > @ViewScope @Model is called twice. > Mojarra 2.3.8 is NOT affected, which - together with the fact that MyFaces > 2.3.2 is not affected either - brings me to the conclusion this is a bug > introduced with MyFaces 2.3.3. > I have a minimal project showing the issue, which I will link here shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4282) Incompatibility with DeltaSpike JSF Module 1.x
[ https://issues.apache.org/jira/browse/MYFACES-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790557#comment-16790557 ] Bill Lucy commented on MYFACES-4282: The problem here occurs when DeltaSpike's ViewHandler calls setViewRoot during its createView method - which leads to MyFaces clearing out the view map, since we believe a view scope has ended. This is the stack of the clear() that destroys ViewScopeModel after it's first built, which leads to the second PostConstruct: _at org.apache.myfaces.view.ViewScopeProxyMap.clear(ViewScopeProxyMap.java:148)_ _at org.apache.myfaces.context.servlet.FacesContextImplBase.setViewRoot(FacesContextImplBase.java:299)_ _at javax.faces.context.FacesContextWrapper.setViewRoot(FacesContextWrapper.java:247)_ _at org.apache.deltaspike.jsf.impl.security.SecurityAwareViewHandler.createView(SecurityAwareViewHandler.java:106)_ _at org.apache.deltaspike.jsf.impl.view.DeltaSpikeViewHandler.createView(DeltaSpikeViewHandler.java:70)_ _at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage$FaceletViewMetadata.createMetadataView(FaceletViewDeclarationLanguage.java:2750)_ A potential fix on our side is to skip calling clear() on the view scope map on this path - while we're building the view metadata. I've done a PR at [https://github.com/apache/myfaces/pull/46]. [~j-be] I've tested this PR against your sample and the behavior appears correct; can you verify this? > Incompatibility with DeltaSpike JSF Module 1.x > -- > > Key: MYFACES-4282 > URL: https://issues.apache.org/jira/browse/MYFACES-4282 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.3 > Environment: Tomcat 9.0.14 > OpenWebBeans 2.0.8 > DeltaSpike 1.x (tested 1.0.0, 1.8.2, 1.9.0) >Reporter: Juri Berlanda >Assignee: Eduardo Breijo >Priority: Major > Fix For: 3.0.0-SNAPSHOT, 2.3.4 > > Time Spent: 10m > Remaining Estimate: 0h > > Some change in 2.3.3 causes and incompatibility with Apache DeltaSpike's JSF > Module. I am not sure yet what exactly causes it, but MyFaces 2.3.2 is NOT > affected. > The issue arose on our side, as we noticed @PostConstruct of some of our > @ViewScope @Model is called twice. > Mojarra 2.3.8 is NOT affected, which - together with the fact that MyFaces > 2.3.2 is not affected either - brings me to the conclusion this is a bug > introduced with MyFaces 2.3.3. > I have a minimal project showing the issue, which I will link here shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4284) ClassNotFoundException during initialization
Bill Lucy created MYFACES-4284: -- Summary: ClassNotFoundException during initialization Key: MYFACES-4284 URL: https://issues.apache.org/jira/browse/MYFACES-4284 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3.3 Reporter: Bill Lucy Assignee: Bill Lucy A ClassNotFoundException can occur during initialization when a servlet mapping is defined which cannot be loaded by MyFaces. We should update WebXml.getFacesServletMappings() to not throw an exception when it can't load a class. javax.faces.FacesException: java.lang.ClassNotFoundException: at org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:239) at org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:215) at org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getFacesServletMappings(WebXml.java:136) at org.apache.myfaces.spi.impl.DefaultWebConfigProvider.getFacesServletMappings(DefaultWebConfigProvider.java:46) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:161) This is related to the fix made in MYFACES-3629 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
