[jira] [Commented] (MYFACES-4251) Differences in some API classes between MyFaces 2.3 and Mojarra 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736023#comment-16736023 ] Eduardo Breijo commented on MYFACES-4251: - Removed the processEvent method from UIViewRoot. If no other comments I'll merge the PR. > Differences in some API classes between MyFaces 2.3 and Mojarra 2.3 > --- > > Key: MYFACES-4251 > URL: https://issues.apache.org/jira/browse/MYFACES-4251 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0, 2.3.1, 2.3.2 >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.3, 3.0.0-SNAPSHOT > > Attachments: results (1).html > > Time Spent: 10m > Remaining Estimate: 0h > > Below you will find a list of differences between the MyFaces 2.3 and Mojarra > 2.3 APIs. Also, attached you will find the full generated report with results. > > There are some differences that might not make sense to change/update, but > there are others that make sense, like missing throws or missing methods. > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/Application.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String-] > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ApplicationWrapper.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String-] > - Javadocs says to throw FacesException and NullPointerException but the > actual signature doesn't have the throws in the method > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ConfigurableNavigationHandlerWrapper.html] > - Remove handleNavigation(javax.faces.context.FacesContext, > java.lang.String, java.lang.String, java.lang.String) method > - Note that the class already have public void handleNavigation(FacesContext > context, String fromAction, String outcome) > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/behavior/BehaviorBase.html#broadcast-javax.faces.event.BehaviorEvent-] > - Missing throws AbortProcessingException > > There are some differences in the classes from javax.faces.component.html.* > package > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIColumn.html] > - Remove getId() method, this should be inherited from UIComponentBase > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIComponentBase.html] > - Remove encodeAll method, it should be inherited from UIComponent. But this > method looks different from the one in UIComponent > - Add getListenersForEventClass(), subscribeToEvent() and > unsubscribeFromEvent() methods > - Remove visitTree method, it should be inherited from UIComponent. But this > method looks different from the one in UIComponent > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIData.html] > - Remove encodeEnd method, it should be inherited from UIComponentBase. But > this method looks different from the one in UIComponentBase. > - Remove getContainerClientId method, it should be inherited from > UIComponent. But this method looks different from the one in UIComponent > - Add getClientId() method. > - Add setValueBinding() method, but this method is now deprecated and > replaced by setValueExpression method > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIGraphic.html] > - Add getValueBinding and setValueBinding methods, but they are deprecated > and replaced by getValueExpression and setValueExpression methods. > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIImportConstants.html#setValueExpression-java.lang.String-javax.el.ValueExpression-] > - Add setValueExpression() method. > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIInput.html] > - Remove broadcast() method, it should be inherited from UIComponentBase. > But this method seems different from the one in UIComponentBase. Do we want > to remove it? > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UINamingContainer.html] > - Remove isRendered() method, it should be inherited from UIComponentBase > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectBoolean.html] > - Remove getValue() method, it should be inherited from UIInput > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectItem.html] > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectItems.html] > - Remove setRendered() method, it should be inherited from UIComponentBase > - Remove getFacesContext() method. This should be inherited from > UIComponentBase. Do we really want to do this? This file has not been > modified since 2013
[jira] [Commented] (MYFACES-4251) Differences in some API classes between MyFaces 2.3 and Mojarra 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735983#comment-16735983 ] Eduardo Breijo commented on MYFACES-4251: - I did a quick search for the markRenderedResources method and I found that FaceletsViewDeclarationLanguageUtils class uses it when restoreView(...) is called. Is that the algorithm you are talking about? If that's the case I can remove the processEvent in UIViewRoot. > Differences in some API classes between MyFaces 2.3 and Mojarra 2.3 > --- > > Key: MYFACES-4251 > URL: https://issues.apache.org/jira/browse/MYFACES-4251 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0, 2.3.1, 2.3.2 >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.3, 3.0.0-SNAPSHOT > > Attachments: results (1).html > > Time Spent: 10m > Remaining Estimate: 0h > > Below you will find a list of differences between the MyFaces 2.3 and Mojarra > 2.3 APIs. Also, attached you will find the full generated report with results. > > There are some differences that might not make sense to change/update, but > there are others that make sense, like missing throws or missing methods. > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/Application.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String-] > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ApplicationWrapper.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String-] > - Javadocs says to throw FacesException and NullPointerException but the > actual signature doesn't have the throws in the method > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ConfigurableNavigationHandlerWrapper.html] > - Remove handleNavigation(javax.faces.context.FacesContext, > java.lang.String, java.lang.String, java.lang.String) method > - Note that the class already have public void handleNavigation(FacesContext > context, String fromAction, String outcome) > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/behavior/BehaviorBase.html#broadcast-javax.faces.event.BehaviorEvent-] > - Missing throws AbortProcessingException > > There are some differences in the classes from javax.faces.component.html.* > package > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIColumn.html] > - Remove getId() method, this should be inherited from UIComponentBase > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIComponentBase.html] > - Remove encodeAll method, it should be inherited from UIComponent. But this > method looks different from the one in UIComponent > - Add getListenersForEventClass(), subscribeToEvent() and > unsubscribeFromEvent() methods > - Remove visitTree method, it should be inherited from UIComponent. But this > method looks different from the one in UIComponent > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIData.html] > - Remove encodeEnd method, it should be inherited from UIComponentBase. But > this method looks different from the one in UIComponentBase. > - Remove getContainerClientId method, it should be inherited from > UIComponent. But this method looks different from the one in UIComponent > - Add getClientId() method. > - Add setValueBinding() method, but this method is now deprecated and > replaced by setValueExpression method > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIGraphic.html] > - Add getValueBinding and setValueBinding methods, but they are deprecated > and replaced by getValueExpression and setValueExpression methods. > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIImportConstants.html#setValueExpression-java.lang.String-javax.el.ValueExpression-] > - Add setValueExpression() method. > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIInput.html] > - Remove broadcast() method, it should be inherited from UIComponentBase. > But this method seems different from the one in UIComponentBase. Do we want > to remove it? > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UINamingContainer.html] > - Remove isRendered() method, it should be inherited from UIComponentBase > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectBoolean.html] > - Remove getValue() method, it should be inherited from UIInput > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectItem.html] > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectItems.html] > - Remove setRendered() method, it should be inherited from
[jira] [Comment Edited] (MYFACES-4251) Differences in some API classes between MyFaces 2.3 and Mojarra 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735945#comment-16735945 ] Eduardo Breijo edited comment on MYFACES-4251 at 1/7/19 3:19 PM: - [~tandraschko] can you take a look at the PR I created to update 2.3.x branch? I updated the classes/methods that made sense to me to match the JSF 2.3 JavaDocs. There were a few methods that I could not update, some because of test failures, some because adding the JSFExclude annotation (to not include the method when the file is compiled) didn't make any difference. With these changes, we should be closer to the Mojarra 2.3 API. Once you review the PR I'll merge it and also add the changes for the master branch. was (Author: eduardobreijo): [~tandraschko] can you take a look at the PR I created to update 2.3.x branch? I updated the classes/methods that made sense to me to match the JSF 2.3 JavaDocs. There were a few methods that I could not update, some because test failures, some because adding the JSFExclude annotation (to not include the method when the file is compiled) didn't make any difference. With these changes, we should be closer to the Mojarra 2.3 API. Once you review the PR I'll merge it and also add the changes for the master branch. > Differences in some API classes between MyFaces 2.3 and Mojarra 2.3 > --- > > Key: MYFACES-4251 > URL: https://issues.apache.org/jira/browse/MYFACES-4251 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0, 2.3.1, 2.3.2 >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.3, 3.0.0-SNAPSHOT > > Attachments: results (1).html > > Time Spent: 10m > Remaining Estimate: 0h > > Below you will find a list of differences between the MyFaces 2.3 and Mojarra > 2.3 APIs. Also, attached you will find the full generated report with results. > > There are some differences that might not make sense to change/update, but > there are others that make sense, like missing throws or missing methods. > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/Application.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String-] > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ApplicationWrapper.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String-] > - Javadocs says to throw FacesException and NullPointerException but the > actual signature doesn't have the throws in the method > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ConfigurableNavigationHandlerWrapper.html] > - Remove handleNavigation(javax.faces.context.FacesContext, > java.lang.String, java.lang.String, java.lang.String) method > - Note that the class already have public void handleNavigation(FacesContext > context, String fromAction, String outcome) > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/behavior/BehaviorBase.html#broadcast-javax.faces.event.BehaviorEvent-] > - Missing throws AbortProcessingException > > There are some differences in the classes from javax.faces.component.html.* > package > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIColumn.html] > - Remove getId() method, this should be inherited from UIComponentBase > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIComponentBase.html] > - Remove encodeAll method, it should be inherited from UIComponent. But this > method looks different from the one in UIComponent > - Add getListenersForEventClass(), subscribeToEvent() and > unsubscribeFromEvent() methods > - Remove visitTree method, it should be inherited from UIComponent. But this > method looks different from the one in UIComponent > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIData.html] > - Remove encodeEnd method, it should be inherited from UIComponentBase. But > this method looks different from the one in UIComponentBase. > - Remove getContainerClientId method, it should be inherited from > UIComponent. But this method looks different from the one in UIComponent > - Add getClientId() method. > - Add setValueBinding() method, but this method is now deprecated and > replaced by setValueExpression method > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIGraphic.html] > - Add getValueBinding and setValueBinding methods, but they are deprecated > and replaced by getValueExpression and setValueExpression methods. > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIImportConstants.html#setValueExpression-java.lang.String-javax.el.ValueExpression-] > - Add
[jira] [Commented] (MYFACES-4251) Differences in some API classes between MyFaces 2.3 and Mojarra 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735945#comment-16735945 ] Eduardo Breijo commented on MYFACES-4251: - [~tandraschko] can you take a look at the PR I created to update 2.3.x branch? I updated the classes/methods that made sense to me to match the JSF 2.3 JavaDocs. There were a few methods that I could not update, some because test failures, some because adding the JSFExclude annotation (to not include the method when the file is compiled) didn't make any difference. With these changes, we should be closer to the Mojarra 2.3 API. Once you review the PR I'll merge it and also add the changes for the master branch. > Differences in some API classes between MyFaces 2.3 and Mojarra 2.3 > --- > > Key: MYFACES-4251 > URL: https://issues.apache.org/jira/browse/MYFACES-4251 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0, 2.3.1, 2.3.2 >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.3, 3.0.0-SNAPSHOT > > Attachments: results (1).html > > Time Spent: 10m > Remaining Estimate: 0h > > Below you will find a list of differences between the MyFaces 2.3 and Mojarra > 2.3 APIs. Also, attached you will find the full generated report with results. > > There are some differences that might not make sense to change/update, but > there are others that make sense, like missing throws or missing methods. > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/Application.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String-] > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ApplicationWrapper.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String-] > - Javadocs says to throw FacesException and NullPointerException but the > actual signature doesn't have the throws in the method > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ConfigurableNavigationHandlerWrapper.html] > - Remove handleNavigation(javax.faces.context.FacesContext, > java.lang.String, java.lang.String, java.lang.String) method > - Note that the class already have public void handleNavigation(FacesContext > context, String fromAction, String outcome) > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/behavior/BehaviorBase.html#broadcast-javax.faces.event.BehaviorEvent-] > - Missing throws AbortProcessingException > > There are some differences in the classes from javax.faces.component.html.* > package > > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIColumn.html] > - Remove getId() method, this should be inherited from UIComponentBase > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIComponentBase.html] > - Remove encodeAll method, it should be inherited from UIComponent. But this > method looks different from the one in UIComponent > - Add getListenersForEventClass(), subscribeToEvent() and > unsubscribeFromEvent() methods > - Remove visitTree method, it should be inherited from UIComponent. But this > method looks different from the one in UIComponent > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIData.html] > - Remove encodeEnd method, it should be inherited from UIComponentBase. But > this method looks different from the one in UIComponentBase. > - Remove getContainerClientId method, it should be inherited from > UIComponent. But this method looks different from the one in UIComponent > - Add getClientId() method. > - Add setValueBinding() method, but this method is now deprecated and > replaced by setValueExpression method > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIGraphic.html] > - Add getValueBinding and setValueBinding methods, but they are deprecated > and replaced by getValueExpression and setValueExpression methods. > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIImportConstants.html#setValueExpression-java.lang.String-javax.el.ValueExpression-] > - Add setValueExpression() method. > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIInput.html] > - Remove broadcast() method, it should be inherited from UIComponentBase. > But this method seems different from the one in UIComponentBase. Do we want > to remove it? > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UINamingContainer.html] > - Remove isRendered() method, it should be inherited from UIComponentBase > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectBoolean.html] > - Remove getValue() method, it should be inherited from
[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=16702410#comment-16702410
]
Eduardo Breijo commented on MYFACES-4267:
-
+1
> 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-4269) [perf] getServletRegistrations is slow and not cached
[ https://issues.apache.org/jira/browse/MYFACES-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702327#comment-16702327 ] Eduardo Breijo commented on MYFACES-4269: - +1 > [perf] getServletRegistrations is slow and not cached > - > > Key: MYFACES-4269 > URL: https://issues.apache.org/jira/browse/MYFACES-4269 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Thomas Andraschko >Priority: Major > Fix For: 2.3.3 > > Attachments: MYFACES-4269.patch, MYFACES-4269_v2.patch > > > seems like servletContext#getServletRegistrations does internal always a new > lookup instead of caching it (on tomcat 9.x) > we can simple cache the FacesServletRegistration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4269) [perf] getServletRegistrations is slow and not cached
[ https://issues.apache.org/jira/browse/MYFACES-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700615#comment-16700615 ] Eduardo Breijo commented on MYFACES-4269: - [~tandraschko] the changes look good to me. It makes sense to do the caching in a level above as that should improve performance even more compared to the original caching I did for the "isFacesServlet" method. Thanks! > [perf] getServletRegistrations is slow and not cached > - > > Key: MYFACES-4269 > URL: https://issues.apache.org/jira/browse/MYFACES-4269 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Thomas Andraschko >Priority: Major > Fix For: 2.3.3 > > Attachments: MYFACES-4269.patch > > > seems like servletContext#getServletRegistrations does internal always a new > lookup instead of caching it (on tomcat 9.x) > we can simple cache the FacesServletRegistration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MYFACES-4260) Context map from CDI ViewScope is not being cleared at destroy time
[ https://issues.apache.org/jira/browse/MYFACES-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo resolved MYFACES-4260. - Resolution: Fixed Fix Version/s: 3.0.0-SNAPSHOT 2.3.3 2.2.13 > Context map from CDI ViewScope is not being cleared at destroy time > --- > > Key: MYFACES-4260 > URL: https://issues.apache.org/jira/browse/MYFACES-4260 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.12, 2.3.2 >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.2.13, 2.3.3, 3.0.0-SNAPSHOT > > > The context map that stores Contextual Instances in a CDI Context is not > being cleared when destroying a CDI ViewScope bean. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4260) Context map from CDI ViewScope is not being cleared at destroy time
Eduardo Breijo created MYFACES-4260: --- Summary: Context map from CDI ViewScope is not being cleared at destroy time Key: MYFACES-4260 URL: https://issues.apache.org/jira/browse/MYFACES-4260 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.12, 2.3.2 Reporter: Eduardo Breijo Assignee: Eduardo Breijo The context map that stores Contextual Instances in a CDI Context is not being cleared when destroying a CDI ViewScope bean. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4251) Differences in some API classes between MyFaces 2.3 and Mojarra 2.3
Eduardo Breijo created MYFACES-4251: --- Summary: Differences in some API classes between MyFaces 2.3 and Mojarra 2.3 Key: MYFACES-4251 URL: https://issues.apache.org/jira/browse/MYFACES-4251 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Affects Versions: 2.3.1, 2.3.0, 2.3.2 Reporter: Eduardo Breijo Below you will find a list of differences between the MyFaces 2.3 and Mojarra 2.3 APIs. There are some differences that might not make sense to change/update, but there are others that make sense, like missing throws or missing methods. https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/Application.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String- https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ApplicationWrapper.html#getResourceBundle-javax.faces.context.FacesContext-java.lang.String- - Javadocs says to throw FacesException and NullPointerException but the actual signature doesn't have the throws in the method https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ConfigurableNavigationHandlerWrapper.html - Remove handleNavigation(javax.faces.context.FacesContext, java.lang.String, java.lang.String, java.lang.String) method - Note that the class already have public void handleNavigation(FacesContext context, String fromAction, String outcome) https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/behavior/BehaviorBase.html#broadcast-javax.faces.event.BehaviorEvent- - Missing throws AbortProcessingException ** There are some differences in the classes from javax.faces.component.html.* package https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIColumn.html - Remove getId() method, this should be inherited from UIComponentBase https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIComponentBase.html - Remove encodeAll method, it should be inherited from UIComponent. But this method looks different from the one in UIComponent - Add getListenersForEventClass(), subscribeToEvent() and unsubscribeFromEvent() methods - Remove visitTree method, it should be inherited from UIComponent. But this method looks different from the one in UIComponent https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIData.html - Remove encodeEnd method, it should be inherited from UIComponentBase. But this method looks different from the one in UIComponentBase. - Remove getContainerClientId method, it should be inherited from UIComponent. But this method looks different from the one in UIComponent - Add getClientId() method. - Add setValueBinding() method, but this method is now deprecated and replaced by setValueExpression method https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIGraphic.html - Add getValueBinding and setValueBinding methods, but they are deprecated and replaced by getValueExpression and setValueExpression methods. https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIImportConstants.html#setValueExpression-java.lang.String-javax.el.ValueExpression- - Add setValueExpression() method. https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIInput.html - Remove broadcast() method, it should be inherited from UIComponentBase. But this method seems different from the one in UIComponentBase. Do we want to remove it? https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UINamingContainer.html - Remove isRendered() method, it should be inherited from UIComponentBase https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIViewParameter.html - Remove setRendered() method, it should be inherited from UIComponentBase - Remove getFacesContext() method. This should be inherited from UIComponentBase. Do we really want to do this? This file has not been modified since 2013 https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectBoolean.html - Remove getValue() method, it should be inherited from UIInput https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectItem.html https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectItems.html - Remove setRendered() method, it should be inherited from UIComponentBase - Remove getFacesContext() method. This should be inherited from UIComponentBase. Do we really want to do this? This file has not been modified since 2013 https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UISelectMany.html - getConvertedValue() method should be inherited from UIInput, but the implementation in UISelectMany class is a bit different. Do we want to remove it anyway? https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIViewAction.html#isRendered--
[jira] [Created] (MYFACES-4233) Support generic return type on myfaces-builder-plugin
Eduardo Breijo created MYFACES-4233: --- Summary: Support generic return type on myfaces-builder-plugin Key: MYFACES-4233 URL: https://issues.apache.org/jira/browse/MYFACES-4233 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Reporter: Eduardo Breijo On the JIRA issue below, there was an issue with the _UIWebsocket.getEventNames() method where the generic in the return type of the method was missing in the auto-generated file UIWebsocket. //BEGIN CODE COPIED FROM javax.faces.component._UIWebsocket public java.util.Collection getEventNames() JIRA issue: https://issues.apache.org/jira/browse/MYFACES-4232 To workaround this, the api/src/main/resources/META-INF/componentClass20.vm file was modified to actually generate the getEventNames() method with the correct return type. But I think we should fix this in the myfaces-builder-plugin, and then revert back the changes in the componentClass20.vm and javax.faces.component._UIWebsocket files. I'm not familiar with the myfaces-builder-plugin, so any help here would be appreciated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MYFACES-4232) Update UIWebsocket signature in the JSF 2.3 API
[
https://issues.apache.org/jira/browse/MYFACES-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduardo Breijo resolved MYFACES-4232.
-
Resolution: Fixed
Fix Version/s: 2.3.2
> Update UIWebsocket signature in the JSF 2.3 API
> ---
>
> Key: MYFACES-4232
> URL: https://issues.apache.org/jira/browse/MYFACES-4232
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
>Priority: Major
> Fix For: 2.3.2
>
>
> 1) Currently, javax.faces.component.UIWebsocket is extending
> javax.faces.component.UIOutput.
> According to the JSF 2.3 API it needs to extend
> javax.faces.component.UIComponentBase
> [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIWebsocket.html]
>
> I tried to made this update but it also requires an update in the
> org.apache.myfaces.push.WebsocketComponentRenderer implementation as
> UIComponentBase does not have the getValue() and setValue() methods.
>
> 2) I also noticed that the following method in the auto-generated class
> javax.faces.component.UIWebsocket from javax.faces.component._UIWebsocket is
> missing the ** in the return type.
> {code:java}
> //BEGIN CODE COPIED FROM javax.faces.component._UIWebsocket
> public java.util.Collection getEventNames()
> {code}
> But javax.faces.component._UIWebsocket does have the in the return
> type as defined in the API:
> [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIWebsocket.html#getEventNames--]
>
> It seems that myfaces-builder-plugin is not working properly in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4232) Update UIWebsocket signature in the JSF 2.3 API
[ https://issues.apache.org/jira/browse/MYFACES-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494027#comment-16494027 ] Eduardo Breijo commented on MYFACES-4232: - [~lu4242] can you please take a look to this? Not sure how to update the implementation. Is the component.getValue() and component.setValue() required in the WebsocketComponentRenderer implementation class for websocket to work correctly? > Update UIWebsocket signature in the JSF 2.3 API > --- > > Key: MYFACES-4232 > URL: https://issues.apache.org/jira/browse/MYFACES-4232 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0, 2.3.1 >Reporter: Eduardo Breijo >Priority: Major > > Currently, javax.faces.component.UIWebsocket is extending > javax.faces.component.UIOutput. > According to the JSF 2.3 API it needs to extend > javax.faces.component.UIComponentBase > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIWebsocket.html] > > I tried to made this update but it also requires an update in the > org.apache.myfaces.push.WebsocketComponentRenderer implementation as > UIComponentBase does not have the getValue() and setValue() methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MYFACES-4231) Update SearchExpressionContextFactory and FaceletCache signature methods in the JSF 2.3 API
[ https://issues.apache.org/jira/browse/MYFACES-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo resolved MYFACES-4231. - Resolution: Fixed > Update SearchExpressionContextFactory and FaceletCache signature methods in > the JSF 2.3 API > --- > > Key: MYFACES-4231 > URL: https://issues.apache.org/jira/browse/MYFACES-4231 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0, 2.3.1 >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.3.2 > > Attachments: MYFACES-4231.patch > > > Update signature methods according to the JSF 2.3 API > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/search/SearchExpressionContextFactory.html] > [https://javaee.github.io/javaee-spec/javadocs/javax/faces/view/facelets/FaceletCache.html#setMemberFactories-javax.faces.view.facelets.FaceletCache.MemberFactory-javax.faces.view.facelets.FaceletCache.MemberFactory-] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4232) Update UIWebsocket signature in the JSF 2.3 API
Eduardo Breijo created MYFACES-4232: --- Summary: Update UIWebsocket signature in the JSF 2.3 API Key: MYFACES-4232 URL: https://issues.apache.org/jira/browse/MYFACES-4232 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Affects Versions: 2.3.1, 2.3.0 Reporter: Eduardo Breijo Currently, javax.faces.component.UIWebsocket is extending javax.faces.component.UIOutput. According to the JSF 2.3 API it needs to extend javax.faces.component.UIComponentBase https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/UIWebsocket.html I tried to made this update but it also requires an update in the org.apache.myfaces.push.WebsocketComponentRenderer implementation as UIComponentBase does not have the getValue() method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4231) Update SearchExpressionContextFactory and FaceletCache signature methods in the JSF 2.3 API
Eduardo Breijo created MYFACES-4231: --- Summary: Update SearchExpressionContextFactory and FaceletCache signature methods in the JSF 2.3 API Key: MYFACES-4231 URL: https://issues.apache.org/jira/browse/MYFACES-4231 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Affects Versions: 2.3.1, 2.3.0 Reporter: Eduardo Breijo Assignee: Eduardo Breijo Update signature methods according to the JSF 2.3 API [https://javaee.github.io/javaee-spec/javadocs/javax/faces/component/search/SearchExpressionContextFactory.html] [https://javaee.github.io/javaee-spec/javadocs/javax/faces/view/facelets/FaceletCache.html#setMemberFactories-javax.faces.view.facelets.FaceletCache.MemberFactory-javax.faces.view.facelets.FaceletCache.MemberFactory-] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4229) Regression in Spec Issue 790: Cross form submit
[
https://issues.apache.org/jira/browse/MYFACES-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466271#comment-16466271
]
Eduardo Breijo commented on MYFACES-4229:
-
I suspect this could be related to some changes made in:
https://issues.apache.org/jira/browse/MYFACES-4204
[~werpu] can you take a look at this when you have some time?
> Regression in Spec Issue 790: Cross form submit
> ---
>
> Key: MYFACES-4229
> URL: https://issues.apache.org/jira/browse/MYFACES-4229
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
>Reporter: Eduardo Breijo
>Priority: Major
> Attachments: JSF23Spec790.war
>
>
> After releasing MyFaces 2.3.1, I noticed a regression in cross form submit
> from Spec Issue 790:
> [https://github.com/javaee/javaserverfaces-spec/issues/790]
> HTML sample code:
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
>
> The issue is that on MyFaces 2.3.1 the hidden input javax.faces.ViewState is
> being removed from form "b" after we submit form "a" and viceversa.
> Rendered page on MyFaces 2.3.0
> {code:java}
> enctype="application/x-www-form-urlencoded"> This is 'form a'
> Enter a new value for input1:
>
> onclick="jsf.util.chain(this, event,'jsf.ajax.request(this,event,{execute:\'a
> b \',render:\'b \',\'javax.faces.behavior.event\':\'action\'})'); return
> false;"/>
>
> id="j_id__v_0:javax.faces.ViewState:1"
> value="RjhDMEFGQUMwNDI4NTUwRDAwMDAwMDAx" autocomplete="off"/>
>
> enctype="application/x-www-form-urlencoded"> This is 'form b'
> Enter a new value for input2:
>
> id="b:commandLink1" name="b:commandLink1"> Click here to execute 'form a' and
> 'form b' but re-render 'form a'
>
> name="javax.faces.ViewState" value="RjhDMEFGQUMwNDI4NTUwRDAwMDAwMDAx"/>
>
> {code}
>
> Rendered page on MyFaces 2.3.1
> {code:java}
> enctype="application/x-www-form-urlencoded"> This is 'form a'
> Enter a new value for input1:
>
> onclick="jsf.util.chain(this, event,'jsf.ajax.request(this,event,{execute:\'a
> b \',render:\'b \',\'javax.faces.behavior.event\':\'action\'})'); return
> false;"/>
>
> id="j_id__v_0:javax.faces.ViewState:1"
> value="RjY3MjAyMTY3N0U2ODE3RDAwMDAwMDAx" autocomplete="off"/>
>
> enctype="application/x-www-form-urlencoded"> This is 'form b'
> Enter a new value for input2:
>
> id="b:commandLink1" name="b:commandLink1"> Click here to execute 'form a' and
> 'form b' but re-render 'form a'
>
>
> {code}
>
> I have provided a sample app that shows the issue when MyFaces 2.3.1 is used.
> # Just deploy the app on Tomcat and drive a request to:
> [http://localhost:8080/JSF23Spec790/test1.xhtml]
> # Enter a text in input1 and click submit button next to the input. Check
> the rendered page.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MYFACES-4229) Regression in Spec Issue 790: Cross form submit
Eduardo Breijo created MYFACES-4229:
---
Summary: Regression in Spec Issue 790: Cross form submit
Key: MYFACES-4229
URL: https://issues.apache.org/jira/browse/MYFACES-4229
Project: MyFaces Core
Issue Type: Task
Components: JSR-372
Affects Versions: 2.3.1
Reporter: Eduardo Breijo
After releasing MyFaces 2.3.1, I noticed a regression in cross form submit from
Spec Issue 790: [https://github.com/javaee/javaserverfaces-spec/issues/790]
HTML sample code:
{code:java}
{code}
The issue is that on MyFaces 2.3.1 the hidden input javax.faces.ViewState is
being removed from form "b" after the we submit form "a" and viceversa.
Rendered page on MyFaces 2.3.0
{code:java}
This is 'form a'
Enter a new value for input1:
This is 'form b'
Enter a new value for input2:
Click here to execute 'form a' and
'form b' but re-render 'form a'
{code}
Rendered page on MyFaces 2.3.1
{code:java}
This is 'form a'
Enter a new value for input1:
This is 'form b'
Enter a new value for input2:
Click here to execute 'form a' and
'form b' but re-render 'form a'
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MYFACES-4226) Update ExternalContextWrapper.getInitParameterMap signature method
[ https://issues.apache.org/jira/browse/MYFACES-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4226: Resolution: Fixed Status: Resolved (was: Patch Available) > Update ExternalContextWrapper.getInitParameterMap signature method > -- > > Key: MYFACES-4226 > URL: https://issues.apache.org/jira/browse/MYFACES-4226 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0 >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.3.1 > > Attachments: MYFACES-4226.patch > > > Currently the method getInitParameterMap from ExternalContextWrapper does not > match with the spec: > https://javaserverfaces.github.io/docs/2.3/javadocs/javax/faces/context/ExternalContextWrapper.html#getInitParameterMap-- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4226) Update ExternalContextWrapper.getInitParameterMap signature method
[ https://issues.apache.org/jira/browse/MYFACES-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4226: Status: Patch Available (was: Open) > Update ExternalContextWrapper.getInitParameterMap signature method > -- > > Key: MYFACES-4226 > URL: https://issues.apache.org/jira/browse/MYFACES-4226 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0 >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: MYFACES-4226.patch > > > Currently the method getInitParameterMap from ExternalContextWrapper does not > match with the spec: > https://javaserverfaces.github.io/docs/2.3/javadocs/javax/faces/context/ExternalContextWrapper.html#getInitParameterMap-- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4226) Update ExternalContextWrapper.getInitParameterMap signature method
Eduardo Breijo created MYFACES-4226: --- Summary: Update ExternalContextWrapper.getInitParameterMap signature method Key: MYFACES-4226 URL: https://issues.apache.org/jira/browse/MYFACES-4226 Project: MyFaces Core Issue Type: Task Components: JSR-372 Affects Versions: 2.3.0 Reporter: Eduardo Breijo Assignee: Eduardo Breijo Currently the method getInitParameterMap from ExternalContextWrapper does not match with the spec: https://javaserverfaces.github.io/docs/2.3/javadocs/javax/faces/context/ExternalContextWrapper.html#getInitParameterMap-- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4212) onSelect / getSelect should not be implemented on some components
[ https://issues.apache.org/jira/browse/MYFACES-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417719#comment-16417719 ] Eduardo Breijo commented on MYFACES-4212: - Patch looks good. Thanks! > onSelect / getSelect should not be implemented on some components > - > > Key: MYFACES-4212 > URL: https://issues.apache.org/jira/browse/MYFACES-4212 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0 >Reporter: Paul Nicolucci >Assignee: Paul Nicolucci >Priority: Trivial > Fix For: 2.3.1 > > Attachments: MYFACES-4212.patch > > > HtmlSelectManyListbox -> > https://javaserverfaces.github.io/docs/2.3/javadocs/javax/faces/component/html/HtmlSelectManyListbox.html > HtmlSelectManyMenu -> > https://javaserverfaces.github.io/docs/2.3/javadocs/javax/faces/component/html/HtmlSelectManyMenu.html > HtmlSelectOneListbox -> > https://javaserverfaces.github.io/docs/2.3/javadocs/javax/faces/component/html/HtmlSelectOneListbox.html > HtmlSelectOneMenu -> > https://javaserverfaces.github.io/docs/2.3/javadocs/javax/faces/component/html/HtmlSelectOneMenu.html > > The above all have onSelect / getSelect methods generated but they are not > necessary and are not part of the javadoc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4202) [perf] FacesServletMappingUtils.isFacesServlet calls ClassUtils.simpleClassForName on every request
[ https://issues.apache.org/jira/browse/MYFACES-4202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4202: Resolution: Fixed Status: Resolved (was: Patch Available) > [perf] FacesServletMappingUtils.isFacesServlet calls > ClassUtils.simpleClassForName on every request > --- > > Key: MYFACES-4202 > URL: https://issues.apache.org/jira/browse/MYFACES-4202 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.0 > > Attachments: MYFACES-4202.patch > > > FacesServletMappingUtils.isFacesServlet is invoked on every request. This > means that ClassUtils.simpleClassForName() will also be invoked on every > request. We need to cache the boolean value for each servletClassName to > improve performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4201) InstantiationException for ConfigurableNavigationHandler that does not have a default constructor
[ https://issues.apache.org/jira/browse/MYFACES-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4201: Resolution: Fixed Status: Resolved (was: Patch Available) > InstantiationException for ConfigurableNavigationHandler that does not have a > default constructor > - > > Key: MYFACES-4201 > URL: https://issues.apache.org/jira/browse/MYFACES-4201 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0 > Environment: MyFaces-2.3.0-SNAPSHOT > Revision: 1823978 > Apache Tomcat 9.0.5 > JDK 1.8.0.152 > PrimeFaces 6.1 >Reporter: Holger Sunke >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.0 > > Attachments: MYFACES-4201.patch > > > Knowing it's bleeding edge work in progress, I wanted to report a regression > in MyFaces-2.3.0-SNAPSHOT current Revision 1823978 - likely introduced with > this commit: > Revision: 1823976 > Author: embreijo > Date: Montag, 12. Februar 2018 15:36:05 > Message: > MYFACES-4198 Injection on custom navigation handlers does not work > > Modified : > /myfaces/core/branches/2.3.x/impl/src/main/java/org/apache/myfaces/config/FacesConfigurator.java > Modified : > /myfaces/core/branches/2.3.x/shared-public/src/main/java/org/apache/myfaces/shared/util/ClassUtils.java > When initializing a Primefaces 6.1 application I get an Exception for a > NavigationHandler that does not provide a zero argument default constructor: > > An error occured while initializing MyFaces: > java.lang.InstantiationException: > org.primefaces.application.DialogNavigationHandler > javax.faces.FacesException: java.lang.InstantiationException: > org.primefaces.application.DialogNavigationHandler > at > org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:436) > at > org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:629) > at > org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:534) > at > org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:734) > at > org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:606) > at > org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:449) > at > org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:70) > at > org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:181) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:103) > at > org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4637) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5099) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1425) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1415) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) > at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:941) > at > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1425) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1415) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) > at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:941) > at > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:258) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardService.startInternal(StandardService.java:422) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:770) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at
[jira] [Updated] (MYFACES-4202) [perf] FacesServletMappingUtils.isFacesServlet calls ClassUtils.simpleClassForName on every request
[ https://issues.apache.org/jira/browse/MYFACES-4202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4202: Status: Patch Available (was: Open) > [perf] FacesServletMappingUtils.isFacesServlet calls > ClassUtils.simpleClassForName on every request > --- > > Key: MYFACES-4202 > URL: https://issues.apache.org/jira/browse/MYFACES-4202 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.0 > > Attachments: MYFACES-4202.patch > > > FacesServletMappingUtils.isFacesServlet is invoked on every request. This > means that ClassUtils.simpleClassForName() will also be invoked on every > request. We need to cache the boolean value for each servletClassName to > improve performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4202) [perf] FacesServletMappingUtils.isFacesServlet calls ClassUtils.simpleClassForName on every request
[ https://issues.apache.org/jira/browse/MYFACES-4202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362996#comment-16362996 ] Eduardo Breijo commented on MYFACES-4202: - Yeah that's what I'm doing, put a mapping with ClasName, true|false in application map. > [perf] FacesServletMappingUtils.isFacesServlet calls > ClassUtils.simpleClassForName on every request > --- > > Key: MYFACES-4202 > URL: https://issues.apache.org/jira/browse/MYFACES-4202 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.0 > > > FacesServletMappingUtils.isFacesServlet is invoked on every request. This > means that ClassUtils.simpleClassForName() will also be invoked on every > request. We need to cache the boolean value for each servletClassName to > improve performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4202) [perf] FacesServletMappingUtils.isFacesServlet calls ClassUtils.simpleClassForName on every request
[ https://issues.apache.org/jira/browse/MYFACES-4202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362994#comment-16362994 ] Eduardo Breijo commented on MYFACES-4202: - I think what we should avoid calling on every request ClassUtils.simpleClassForName() which will end up calling Class.forName(). By caching FacesServletMapping, do we avoid that? How do you propose caching the FacesServletMapping? > [perf] FacesServletMappingUtils.isFacesServlet calls > ClassUtils.simpleClassForName on every request > --- > > Key: MYFACES-4202 > URL: https://issues.apache.org/jira/browse/MYFACES-4202 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.0 > > > FacesServletMappingUtils.isFacesServlet is invoked on every request. This > means that ClassUtils.simpleClassForName() will also be invoked on every > request. We need to cache the boolean value for each servletClassName to > improve performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4202) FacesServletMappingUtils.isFacesServlet calls ClassUtils.simpleClassForName on every request
Eduardo Breijo created MYFACES-4202: --- Summary: FacesServletMappingUtils.isFacesServlet calls ClassUtils.simpleClassForName on every request Key: MYFACES-4202 URL: https://issues.apache.org/jira/browse/MYFACES-4202 Project: MyFaces Core Issue Type: Improvement Components: JSR-372 Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo Assignee: Eduardo Breijo FacesServletMappingUtils.isFacesServlet is invoked on every request. This means that ClassUtils.simpleClassForName() will also be invoked on every request. We need to cache the boolean value for each servletClassName to improve performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4201) InstantiationException for ConfigurableNavigationHandler that does not have a default constructor
[ https://issues.apache.org/jira/browse/MYFACES-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4201: Status: Patch Available (was: Open) > InstantiationException for ConfigurableNavigationHandler that does not have a > default constructor > - > > Key: MYFACES-4201 > URL: https://issues.apache.org/jira/browse/MYFACES-4201 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0 > Environment: MyFaces-2.3.0-SNAPSHOT > Revision: 1823978 > Apache Tomcat 9.0.5 > JDK 1.8.0.152 > PrimeFaces 6.1 >Reporter: Holger Sunke >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.0 > > Attachments: MYFACES-4201.patch > > > Knowing it's bleeding edge work in progress, I wanted to report a regression > in MyFaces-2.3.0-SNAPSHOT current Revision 1823978 - likely introduced with > this commit: > Revision: 1823976 > Author: embreijo > Date: Montag, 12. Februar 2018 15:36:05 > Message: > MYFACES-4198 Injection on custom navigation handlers does not work > > Modified : > /myfaces/core/branches/2.3.x/impl/src/main/java/org/apache/myfaces/config/FacesConfigurator.java > Modified : > /myfaces/core/branches/2.3.x/shared-public/src/main/java/org/apache/myfaces/shared/util/ClassUtils.java > When initializing a Primefaces 6.1 application I get an Exception for a > NavigationHandler that does not provide a zero argument default constructor: > > An error occured while initializing MyFaces: > java.lang.InstantiationException: > org.primefaces.application.DialogNavigationHandler > javax.faces.FacesException: java.lang.InstantiationException: > org.primefaces.application.DialogNavigationHandler > at > org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:436) > at > org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:629) > at > org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:534) > at > org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:734) > at > org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:606) > at > org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:449) > at > org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:70) > at > org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:181) > at > org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:103) > at > org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4637) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5099) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1425) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1415) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) > at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:941) > at > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:839) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1425) > at > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1415) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134) > at > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:941) > at > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:258) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardService.startInternal(StandardService.java:422) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:770) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at org.apache.catalina.startup.Catalina.start(Catalina.java:682) > at
[jira] [Updated] (MYFACES-4197) Injected bean storage list is created on every request in development mode
[ https://issues.apache.org/jira/browse/MYFACES-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4197: Resolution: Fixed Fix Version/s: 2.3.0 2.2.13 Status: Resolved (was: Patch Available) > Injected bean storage list is created on every request in development mode > -- > > Key: MYFACES-4197 > URL: https://issues.apache.org/jira/browse/MYFACES-4197 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.2.13, 2.3.0 > > Attachments: MYFACES-4197.patch > > > When working on development mode, FacesConfigurator is created for every > request, as a result, the list that stores the injected beans is created for > every request as well causing to lose track of objects that has been injected > already. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4198) Injection on custom navigation handlers does not work
[ https://issues.apache.org/jira/browse/MYFACES-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4198: Resolution: Fixed Fix Version/s: 2.3.0 Status: Resolved (was: Patch Available) > Injection on custom navigation handlers does not work > - > > Key: MYFACES-4198 > URL: https://issues.apache.org/jira/browse/MYFACES-4198 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.3.0 > > Attachments: MYFACES-4198.patch > > > When a custom navigation handler is used, injection is not working because we > are wrapping the object to the BackwardsCompatibleNavigationHandlerWrapper, > and then calling injectAndPostConstruct on that > BackwardsCompatibleNavigationHandler object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4198) Injection on custom navigation handlers does not work
[ https://issues.apache.org/jira/browse/MYFACES-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4198: Status: Patch Available (was: Open) > Injection on custom navigation handlers does not work > - > > Key: MYFACES-4198 > URL: https://issues.apache.org/jira/browse/MYFACES-4198 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: MYFACES-4198.patch > > > When a custom navigation handler is used, injection is not working because we > are wrapping the object to the BackwardsCompatibleNavigationHandlerWrapper, > and then calling injectAndPostConstruct on that > BackwardsCompatibleNavigationHandler object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4198) Injection on custom navigation handlers does not work
Eduardo Breijo created MYFACES-4198: --- Summary: Injection on custom navigation handlers does not work Key: MYFACES-4198 URL: https://issues.apache.org/jira/browse/MYFACES-4198 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo Assignee: Eduardo Breijo When a custom navigation handler is used, injection is not working because we are wrapping the object to the BackwardsCompatibleNavigationHandlerWrapper, and then calling injectAndPostConstruct on that BackwardsCompatibleNavigationHandler object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4197) Injected bean storage list is created on every request in development mode
[ https://issues.apache.org/jira/browse/MYFACES-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4197: Status: Patch Available (was: Open) > Injected bean storage list is created on every request in development mode > -- > > Key: MYFACES-4197 > URL: https://issues.apache.org/jira/browse/MYFACES-4197 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: MYFACES-4197.patch > > > When working on development mode, FacesConfigurator is created for every > request, as a result, the list that stores the injected beans is created for > every request as well causing to lose track of objects that has been injected > already. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4197) Injected bean storage list is created on every request in development mode
Eduardo Breijo created MYFACES-4197: --- Summary: Injected bean storage list is created on every request in development mode Key: MYFACES-4197 URL: https://issues.apache.org/jira/browse/MYFACES-4197 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo Assignee: Eduardo Breijo When working on development mode, FacesConfigurator is created for every request, as a result, the list that stores the injected beans is created for every request as well causing to lose track of objects that has been injected already. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4195) Unexpected NullPointerException thrown in IterableDataModel
[ https://issues.apache.org/jira/browse/MYFACES-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4195: Resolution: Fixed Status: Resolved (was: Patch Available) > Unexpected NullPointerException thrown in IterableDataModel > --- > > Key: MYFACES-4195 > URL: https://issues.apache.org/jira/browse/MYFACES-4195 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.3.0 > > Attachments: MYFACES-4195.patch > > > The new API class IterableDataModel is throwing an unexpected NPE in the > setRowIndex() method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4195) Unexpected NullPointerException thrown in IterableDataModel
[ https://issues.apache.org/jira/browse/MYFACES-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4195: Status: Patch Available (was: Open) > Unexpected NullPointerException thrown in IterableDataModel > --- > > Key: MYFACES-4195 > URL: https://issues.apache.org/jira/browse/MYFACES-4195 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: MYFACES-4195.patch > > > The new API class IterableDataModel is throwing an unexpected NPE in the > setRowIndex() method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4195) Unexpected NullPointerException thrown in IterableDataModel
Eduardo Breijo created MYFACES-4195: --- Summary: Unexpected NullPointerException thrown in IterableDataModel Key: MYFACES-4195 URL: https://issues.apache.org/jira/browse/MYFACES-4195 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo Assignee: Eduardo Breijo The new API class IterableDataModel is throwing an unexpected NPE in the setRowIndex() method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4190) Remove onselect attribute from SELECT elements
[ https://issues.apache.org/jira/browse/MYFACES-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4190: Resolution: Fixed Fix Version/s: 2.3.0 Status: Resolved (was: Patch Available) > Remove onselect attribute from SELECT elements > -- > > Key: MYFACES-4190 > URL: https://issues.apache.org/jira/browse/MYFACES-4190 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Fix For: 2.3.0 > > Attachments: MYFACES-4190-v2.patch, MYFACES-4190.patch > > > According to JSF 2.3 spec issue > [https://github.com/javaee/javaserverfaces-spec/issues/1113] we need to > remove the onselect attribute from > h:selectOneMenu/h:selectManyMenu/h:selectOneListbox/h:selectManyListbox. > I have tested on Mojarra 2.3 and they don't actually render the onselect > attribute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4190) Remove onselect attribute from SELECT elements
[ https://issues.apache.org/jira/browse/MYFACES-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333164#comment-16333164 ] Eduardo Breijo commented on MYFACES-4190: - I have uploaded a new patch which is actually a lot easier/simpler. The test changes remain the same, and the change in the implementation code is under org.apache.myfaces.shared.renderkit.html.HtmlSelectableRendererBase. Now onselect attribute does not get rendered for the selectable components in a facelet and in a jsp. Same as Mojarra. > Remove onselect attribute from SELECT elements > -- > > Key: MYFACES-4190 > URL: https://issues.apache.org/jira/browse/MYFACES-4190 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Attachments: MYFACES-4190-v2.patch, MYFACES-4190.patch > > > According to JSF 2.3 spec issue > [https://github.com/javaee/javaserverfaces-spec/issues/1113] we need to > remove the onselect attribute from > h:selectOneMenu/h:selectManyMenu/h:selectOneListbox/h:selectManyListbox. > I have tested on Mojarra 2.3 and they don't actually render the onselect > attribute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4190) Remove onselect attribute from SELECT elements
[ https://issues.apache.org/jira/browse/MYFACES-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16333025#comment-16333025 ] Eduardo Breijo commented on MYFACES-4190: - I forgot to do a clean, so the auto-generated classes in the implementation were not being updated. After doing the clean the auto-generated classes in the implementation were updated (no setter methods for onselect attribute in the classes that don't need it anymore), I started getting the following error when driving a request to the jsp page that has the onselect attribute: org.apache.jasper.JasperException: /passthroughtest.jsp (line: [18], column: [12]) Attribute [onselect] invalid for tag [selectManyListbox] according to TLD org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:42) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:292) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:115) org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1268) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:881) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1544) So I noticed that myfaces_taglib.tld is updated as well with the patch I provided, so that's why it is complaining about, because onselect is no longer in the TLD file for selectManyListBox. On the other hand, Mojarra seems to have "onselect" defined in the TLD for the classes that we don't need it anymore, and they have their setter methods in the implementation as well. I'm not sure if my patch is what we really need here, or if it just needs some additions to what I did. Maybe we need to do something in the renderer? > Remove onselect attribute from SELECT elements > -- > > Key: MYFACES-4190 > URL: https://issues.apache.org/jira/browse/MYFACES-4190 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Attachments: MYFACES-4190.patch > > > According to JSF 2.3 spec issue > [https://github.com/javaee/javaserverfaces-spec/issues/1113] we need to > remove the onselect attribute from > h:selectOneMenu/h:selectManyMenu/h:selectOneListbox/h:selectManyListbox. > I have tested on Mojarra 2.3 and they don't actually render the onselect > attribute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4190) Remove onselect attribute from SELECT elements
[ https://issues.apache.org/jira/browse/MYFACES-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332890#comment-16332890 ] Eduardo Breijo commented on MYFACES-4190: - [~tandraschko] do you know where to update the JSP rendered attributes? The patch I provided only works with facelets, but if I use a JSP page, I can still see the "onselect" attribute being rendered, and we don't want that. > Remove onselect attribute from SELECT elements > -- > > Key: MYFACES-4190 > URL: https://issues.apache.org/jira/browse/MYFACES-4190 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Major > Attachments: MYFACES-4190.patch > > > According to JSF 2.3 spec issue > [https://github.com/javaee/javaserverfaces-spec/issues/1113] we need to > remove the onselect attribute from > h:selectOneMenu/h:selectManyMenu/h:selectOneListbox/h:selectManyListbox. > I have tested on Mojarra 2.3 and they don't actually render the onselect > attribute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MYFACES-4190) Remove onselect attribute from SELECT elements
[ https://issues.apache.org/jira/browse/MYFACES-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4190: Status: Patch Available (was: Open) > Remove onselect attribute from SELECT elements > -- > > Key: MYFACES-4190 > URL: https://issues.apache.org/jira/browse/MYFACES-4190 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Priority: Major > Attachments: MYFACES-4190.patch > > > According to JSF 2.3 spec issue > [https://github.com/javaee/javaserverfaces-spec/issues/1113] we need to > remove the onselect attribute from > h:selectOneMenu/h:selectManyMenu/h:selectOneListbox/h:selectManyListbox. > I have tested on Mojarra 2.3 and they don't actually render the onselect > attribute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4190) Remove onselect attribute from SELECT elements
Eduardo Breijo created MYFACES-4190: --- Summary: Remove onselect attribute from SELECT elements Key: MYFACES-4190 URL: https://issues.apache.org/jira/browse/MYFACES-4190 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo According to JSF 2.3 spec issue [https://github.com/javaee/javaserverfaces-spec/issues/1113] we need to remove the onselect attribute from h:selectOneMenu/h:selectManyMenu/h:selectOneListbox/h:selectManyListbox. I have tested on Mojarra 2.3 and they don't actually render the onselect attribute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-2497) INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL on required fields
[ https://issues.apache.org/jira/browse/MYFACES-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327760#comment-16327760 ] Eduardo Breijo commented on MYFACES-2497: - This issue is the same as MYFACES-3525 which was fixed. I'm closing out this one as duplicate. > INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL on required fields > -- > > Key: MYFACES-2497 > URL: https://issues.apache.org/jira/browse/MYFACES-2497 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Ingo Hofmann >Priority: Major > Attachments: interpret_empty_string_testcase.patch, > interpret_empty_strings_setValue.patch > > > Similar issue as seen in 1.1.6 and 1.2.6. > 1.) set property javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL > = true. > 2.) Have an input field with required="true". > 3.) User enters empty string. > 4.) After submitted the form, the input field shows its previous value (is > not empty, as entered before and expected). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-3181) wrong behaviour in combination with javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
[ https://issues.apache.org/jira/browse/MYFACES-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327750#comment-16327750 ] Eduardo Breijo commented on MYFACES-3181: - Yes, this one looks to be the same issue as MYFACES-3525 which was fixed. I'm closing out this issue. > wrong behaviour in combination with > javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL > --- > > Key: MYFACES-3181 > URL: https://issues.apache.org/jira/browse/MYFACES-3181 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.6 >Reporter: Gerhard Petracek >Assignee: Leonardo Uribe >Priority: Major > > constellation: > javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL > + a property annotated with @NotNull > if an input component has a value and it gets removed by the user, a > validation error occurs as expected but the old value of the model gets > displayed instead of the wrong value (which is the empty string) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MYFACES-4188) Forward port changes in MYFACES-4048 to JSF 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo resolved MYFACES-4188. - Resolution: Fixed Fix Version/s: 2.3.0 > Forward port changes in MYFACES-4048 to JSF 2.3 > --- > > Key: MYFACES-4188 > URL: https://issues.apache.org/jira/browse/MYFACES-4188 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Trivial > Fix For: 2.3.0 > > Attachments: MYFACES-4188.patch > > > On MyFaces 2.2, we added some null checker for context.getCurrentPhaseId() > under https://issues.apache.org/jira/browse/MYFACES-4048. It looks like this > was never forward ported to MyFaces 2.3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MYFACES-4188) Add currentPhaseId null checker in UIComponentBase.saveState method
Eduardo Breijo created MYFACES-4188: --- Summary: Add currentPhaseId null checker in UIComponentBase.saveState method Key: MYFACES-4188 URL: https://issues.apache.org/jira/browse/MYFACES-4188 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo Assignee: Eduardo Breijo On MyFaces 2.2, we added a new null checker for context.getCurrentPhaseId() in UIComponentBase.saveState method. It looks like this was never forward ported to MyFaces 2.3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322751#comment-16322751
]
Eduardo Breijo edited comment on MYFACES-3525 at 1/11/18 7:05 PM:
--
CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY is independent now. However,
if we still want to restore the previous model value, then
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL needs to be enabled, and the
new parameter CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY should be
disabled.
was (Author: eduardobreijo):
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is independent now. However, if
we still want to restore the previous model value, then
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL needs to be enabled, and the
new parameter CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY should be
disabled.
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT, 2.3.0
>
> Attachments: MYFACES-3525-JSF23.patch,
> MYFACES-3525-setsubmittedValueagain.patch, MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322751#comment-16322751
]
Eduardo Breijo edited comment on MYFACES-3525 at 1/11/18 7:02 PM:
--
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is independent now. However, if
we still want to restore the previous model value, then
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL needs to be enabled, and the
new parameter CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY should be
disabled.
was (Author: eduardobreijo):
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is independent now. However, if
we still want to restore the previous model value, then we
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL needs to be enabled, and the
new parameter CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY should be
disabled.
> 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=16322751#comment-16322751
]
Eduardo Breijo commented on MYFACES-3525:
-
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is independent now. However, if
we still want to restore the previous model value, then we
INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL needs to be enabled, and the
new parameter CLEAR_INPUT_WHEN_SUBMITTED_VALUE_IS_NULL_OR_EMPTY should be
disabled.
> 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=16320463#comment-16320463
]
Eduardo Breijo commented on MYFACES-3525:
-
Uploaded the patch again with Thomas recommendation.
> 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=16319107#comment-16319107
]
Eduardo Breijo commented on MYFACES-3525:
-
I have uploaded a patch for JSF 2.3. The patch is a combination of Bernd patch
and the initial patch provided here. It uses the
org.apache.myfaces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL_CLEAR_INPUT
context parameter, but in this case it will be "true" by default. So Bernd fix
will be enabled by default on JSF 2.3. Also, we can port this new patch to JSF
2.0-2.2 but have the context parameter set to "false" by default, meaning that
the fix will not be enabled by default, keeping the old behavior on JSF
2.0-2.2.
If there are no objections, I can commit the patch to JSF 2.3 and port it to
JSF 2.0-2.2.
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT, 2.3.0
>
> Attachments: MYFACES-3525-JSF23.patch,
> MYFACES-3525-setsubmittedValueagain.patch, MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-4185) MYFACES-4183 causes an issue with getViews
[
https://issues.apache.org/jira/browse/MYFACES-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316457#comment-16316457
]
Eduardo Breijo commented on MYFACES-4185:
-
Patch looks good to me. Thanks for the fix!
> MYFACES-4183 causes an issue with getViews
> --
>
> Key: MYFACES-4185
> URL: https://issues.apache.org/jira/browse/MYFACES-4185
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
>Assignee: Paul Nicolucci
> Fix For: 2.3.0
>
> Attachments: MYFACES-4185.patch
>
>
> Since the JSFViewDeclarationLanguageStrategy.java always returns true now :
> https://issues.apache.org/jira/browse/MYFACES-4183
> A issue is now found in the JSPViewDeclarationLanguage.getViews:
> {code:java}
> @Override
> public Stream getViews(FacesContext facesContext, String path,
> int maxDepth, ViewVisitOption... options)
> {
> Stream stream = super.getViews(facesContext, path, maxDepth,
> options);
> stream = stream.filter(f -> _strategy.handles(f));
> if (options != null &&
> Arrays.binarySearch(options,
> ViewVisitOption.RETURN_AS_MINIMAL_IMPLICIT_OUTCOME) >= 0)
> {
> stream = stream.map(f -> _strategy.getMinimalImplicitOutcome(f));
> }
> return stream;
> }
> {code}
> As you can see from the code above it would be possible to now return views
> here that are not actually handled specifically by the JSP vdl. For instance
> in the FaceletViewDeclarationLanguage we have the following filter in place:
> {code:java}
> stream = stream.filter(f -> (_strategy.handles(f) &&
>
> !FaceletsTemplateMappingUtils.matchTemplate(runtimeConfig, f) ) );
> {code}
> This filter allows us to specify something like the following in the
> faces-config.xml and avoid returning a view from getViews(), however now it
> would be returned incorrectly by the JSP vdl:
> {code:java}
>
>
> /templates/*
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
[ https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4183: Resolution: Fixed Status: Resolved (was: Patch Available) > Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes > --- > > Key: MYFACES-4183 > URL: https://issues.apache.org/jira/browse/MYFACES-4183 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.3.0 > > Attachments: JSF20FacesConfigAnotherServlet.war, MYFACES-4183.patch > > > There is a difference in behavior between JSF 2.2 and JSF 2.3 when using > facelet prefixes. > I have a sample app that demonstrate this behavior difference. In the app we > just define a random servlet and map it to the same prefixes we would > normally map to the FacesServlet. We don't map /faces/* to the testServlet > but it is automatically added to the FacesServlet, so if you drove a request > to something other than .jsf (testServlet) or *.faces (testServlet) the > FacesServlet would be invoked for all of the prefix mappings of /faces/*. So > that would mean you should see TEST SERVLET printed for the suffix mapping > (.jsf and .faces) and then the page1 should be rendered for /faces/*. > When you drive a request to: > http://localhost:8080/JSF20FacesConfigAnotherServlet/faces/page1.jsf > On JSF 2.2: You should see an output of "TEST SERVLET". So it ensures that > .jsf mapping is invoking the testServlet. > On JSF 2.3: You get a 404, page1.jsf not found. I think that in the case of > JSF 2.3, it is invoking the FacesServlet but can't find the .jsf file because > it doesn't actually exist. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
[ https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311943#comment-16311943 ] Eduardo Breijo commented on MYFACES-4183: - I found that this doesn't have to do with extensionless mapping views. After debugging, I found that on MyFaces 2.3, VDL is returning null in ViewHandlerImpl.createView resulting in a 404 error. This is because JspViewDeclarationLanguageStrategy.handles changed from MyFaces 2.2 to MyFaces 2.3. Previously we were always returning true, as a result VDL was set to JspViewDeclarationLanguage, and when JspViewDeclarationLanguageBase.renderView() calls buildView method from JSPViewDeclarationLanguage, a dispatch with "/page1.jsf" is made, then we go through the servlet container and we end up at the TestServlet since that matches the "*.jsf" mapping. I have tested this same scenario using Mojarra 2.3 and it works fine, the behavior is the same as MyFaces 2.0 and MyFaces 2.2. With the change made in MyFaces 2.3 under https://issues.apache.org/jira/browse/MYFACES-4103, the JspViewDeclarationLanguageStrategy.handles changed, leading to the regression described in this issue. I have provided a patch, changing JspViewDeclarationLanguageStrategy.handles to what we have in JSF 2.0 and JSF 2.2. > Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes > --- > > Key: MYFACES-4183 > URL: https://issues.apache.org/jira/browse/MYFACES-4183 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: JSF20FacesConfigAnotherServlet.war, MYFACES-4183.patch > > > There is a difference in behavior between JSF 2.2 and JSF 2.3 when using > facelet prefixes. > I have a sample app that demonstrate this behavior difference. In the app we > just define a random servlet and map it to the same prefixes we would > normally map to the FacesServlet. We don't map /faces/* to the testServlet > but it is automatically added to the FacesServlet, so if you drove a request > to something other than .jsf (testServlet) or *.faces (testServlet) the > FacesServlet would be invoked for all of the prefix mappings of /faces/*. So > that would mean you should see TEST SERVLET printed for the suffix mapping > (.jsf and .faces) and then the page1 should be rendered for /faces/*. > When you drive a request to: > http://localhost:8080/JSF20FacesConfigAnotherServlet/faces/page1.jsf > On JSF 2.2: You should see an output of "TEST SERVLET". So it ensures that > .jsf mapping is invoking the testServlet. > On JSF 2.3: You get a 404, page1.jsf not found. I think that in the case of > JSF 2.3, it is invoking the FacesServlet but can't find the .jsf file because > it doesn't actually exist. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
[ https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4183: Status: Patch Available (was: Open) > Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes > --- > > Key: MYFACES-4183 > URL: https://issues.apache.org/jira/browse/MYFACES-4183 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: JSF20FacesConfigAnotherServlet.war, MYFACES-4183.patch > > > There is a difference in behavior between JSF 2.2 and JSF 2.3 when using > facelet prefixes. > I have a sample app that demonstrate this behavior difference. In the app we > just define a random servlet and map it to the same prefixes we would > normally map to the FacesServlet. We don't map /faces/* to the testServlet > but it is automatically added to the FacesServlet, so if you drove a request > to something other than .jsf (testServlet) or *.faces (testServlet) the > FacesServlet would be invoked for all of the prefix mappings of /faces/*. So > that would mean you should see TEST SERVLET printed for the suffix mapping > (.jsf and .faces) and then the page1 should be rendered for /faces/*. > When you drive a request to: > http://localhost:8080/JSF20FacesConfigAnotherServlet/faces/page1.jsf > On JSF 2.2: You should see an output of "TEST SERVLET". So it ensures that > .jsf mapping is invoking the testServlet. > On JSF 2.3: You get a 404, page1.jsf not found. I think that in the case of > JSF 2.3, it is invoking the FacesServlet but can't find the .jsf file because > it doesn't actually exist. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
[ https://issues.apache.org/jira/browse/MYFACES-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297170#comment-16297170 ] Eduardo Breijo commented on MYFACES-4183: - I think changes in MYFACES-4105 could be related to this difference in behavior. > Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes > --- > > Key: MYFACES-4183 > URL: https://issues.apache.org/jira/browse/MYFACES-4183 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Priority: Minor > Attachments: JSF20FacesConfigAnotherServlet.war > > > There is a difference in behavior between JSF 2.2 and JSF 2.3 when using > facelet prefixes. > I have a sample app that demonstrate this behavior difference. In the app we > just define a random servlet and map it to the same prefixes we would > normally map to the FacesServlet. We don't map /faces/* to the testServlet > but it is automatically added to the FacesServlet, so if you drove a request > to something other than .jsf (testServlet) or *.faces (testServlet) the > FacesServlet would be invoked for all of the prefix mappings of /faces/*. So > that would mean you should see TEST SERVLET printed for the suffix mapping > (.jsf and .faces) and then the page1 should be rendered for /faces/*. > When you drive a request to: > http://localhost:8080/JSF20FacesConfigAnotherServlet/faces/page1.jsf > On JSF 2.2: You should see an output of "TEST SERVLET". So it ensures that > .jsf mapping is invoking the testServlet. > On JSF 2.3: You get a 404, page1.jsf not found. I think that in the case of > JSF 2.3, it is invoking the FacesServlet but can't find the .jsf file because > it doesn't actually exist. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYFACES-4183) Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes
Eduardo Breijo created MYFACES-4183: --- Summary: Behavior difference between JSF 2.2 and JSF 2.3 when using facelet prefixes Key: MYFACES-4183 URL: https://issues.apache.org/jira/browse/MYFACES-4183 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo Priority: Minor Attachments: JSF20FacesConfigAnotherServlet.war There is a difference in behavior between JSF 2.2 and JSF 2.3 when using facelet prefixes. I have a sample app that demonstrate this behavior difference. In the app we just define a random servlet and map it to the same prefixes we would normally map to the FacesServlet. We don't map /faces/* to the testServlet but it is automatically added to the FacesServlet, so if you drove a request to something other than .jsf (testServlet) or *.faces (testServlet) the FacesServlet would be invoked for all of the prefix mappings of /faces/*. So that would mean you should see TEST SERVLET printed for the suffix mapping (.jsf and .faces) and then the page1 should be rendered for /faces/*. When you drive a request to: http://localhost:8080/JSF20FacesConfigAnotherServlet/faces/page1.jsf On JSF 2.2: You should see an output of "TEST SERVLET". So it ensures that .jsf mapping is invoking the testServlet. On JSF 2.3: You get a 404, page1.jsf not found. I think that in the case of JSF 2.3, it is invoking the FacesServlet but can't find the .jsf file because it doesn't actually exist. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4182) javax.faces.component.search.ComponentNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295115#comment-16295115
]
Eduardo Breijo commented on MYFACES-4182:
-
It doesn't work on Mojarra 2.2 either. Same behavior as described in my last
comment.
> javax.faces.component.search.ComponentNotFoundException
> ---
>
> Key: MYFACES-4182
> URL: https://issues.apache.org/jira/browse/MYFACES-4182
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: TestApp.war
>
>
> I noticed a behavior difference when using a composite component and ajax
> between jsf 2.3 and jsf 2.2. I've attached a test application that reproduces.
> *JSF 2.2 Behavior when form prependId=false:*
> 1 )If we reference the outputText id in the render attribute with the form id
> prepended then the page is successfully rendered (testpage1.jsf)
> 2) If we reference the outputText id without the form id prepended we get the
> following failure (testpage2.jsf) when requesting the page:
> {code:java}
> javax.faces.FacesException: Component with id:output2 not found
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getComponentId(HtmlAjaxBehaviorRenderer.java:505)
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.build(HtmlAjaxBehaviorRenderer.java:467)
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.mapToString(HtmlAjaxBehaviorRenderer.java:439)
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.makeAjax(HtmlAjaxBehaviorRenderer.java:158)
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getScript(HtmlAjaxBehaviorRenderer.java:102)
> at
> javax.faces.component.behavior.ClientBehaviorBase.getScript(ClientBehaviorBase.java:101)
> at
> org.apache.myfaces.shared.renderkit.html.CommonEventUtils.renderBehaviorizedAttribute(CommonEventUtils.java:188)
> at
> org.apache.myfaces.shared.renderkit.html.CommonEventUtils.renderBehaviorizedAttribute(CommonEventUtils.java:120)
> at
> org.apache.myfaces.shared.renderkit.html.CommonEventUtils.renderBehaviorizedEventHandlers(CommonEventUtils.java:283)
> at
> org.apache.myfaces.shared.renderkit.html.CommonEventUtils.renderBehaviorizedEventHandlers(CommonEventUtils.java:202)
>
> {code}
> *JSF 2.3 Behavior when form preprendId=false:*
> 1) If we reference the outputText id in the render attribute with the form id
> prepended then we get the following failure (testpage1.jsf) when requesting
> the page:
> {code:java}
> Cannot find component for expression "testForm:output2" referenced from
> "input1:input".
> viewId=/testpage1.xhtml
> location=C:\libertyGit\libertycdopen\WS-CD-Open\dev\build.image\wlp\usr\servers\test1\apps\expanded\TestApp.war\testpage1.xhtml
> phaseId=RENDER_RESPONSE(6)
> Caused by:
> javax.faces.component.search.ComponentNotFoundException - Cannot find
> component for expression "testForm:output2" referenced from "input1:input".
> at
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.resolveClientId(SearchExpressionHandlerImpl.java:104)
> {code}
> 2) If we reference the outputText id without the form id prepended then the
> page is successfully rendered (testpage2.jsf)
> The behavior between jsf 2.2 and jsf 2.3 is reverse, in jsf 2.3 we do not
> work with the prepended form id and in jsf 2.2 we require the prepended form
> id.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-4182) javax.faces.component.search.ComponentNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295062#comment-16295062
]
Eduardo Breijo commented on MYFACES-4182:
-
I tried to test the app on Mojarra 2.3 but I could not get the pages to render.
It doesn't look like the composite component even renders on Mojarra. Not sure
if it needs to be configured in a different way.
> javax.faces.component.search.ComponentNotFoundException
> ---
>
> Key: MYFACES-4182
> URL: https://issues.apache.org/jira/browse/MYFACES-4182
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: TestApp.war
>
>
> I noticed a behavior difference when using a composite component and ajax
> between jsf 2.3 and jsf 2.2. I've attached a test application that reproduces.
> *JSF 2.2 Behavior when form prependId=false:*
> 1 )If we reference the outputText id in the render attribute with the form id
> prepended then the page is successfully rendered (testpage1.jsf)
> 2) If we reference the outputText id without the form id prepended we get the
> following failure (testpage2.jsf) when requesting the page:
> {code:java}
> javax.faces.FacesException: Component with id:output2 not found
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getComponentId(HtmlAjaxBehaviorRenderer.java:505)
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.build(HtmlAjaxBehaviorRenderer.java:467)
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.mapToString(HtmlAjaxBehaviorRenderer.java:439)
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.makeAjax(HtmlAjaxBehaviorRenderer.java:158)
> at
> org.apache.myfaces.renderkit.html.HtmlAjaxBehaviorRenderer.getScript(HtmlAjaxBehaviorRenderer.java:102)
> at
> javax.faces.component.behavior.ClientBehaviorBase.getScript(ClientBehaviorBase.java:101)
> at
> org.apache.myfaces.shared.renderkit.html.CommonEventUtils.renderBehaviorizedAttribute(CommonEventUtils.java:188)
> at
> org.apache.myfaces.shared.renderkit.html.CommonEventUtils.renderBehaviorizedAttribute(CommonEventUtils.java:120)
> at
> org.apache.myfaces.shared.renderkit.html.CommonEventUtils.renderBehaviorizedEventHandlers(CommonEventUtils.java:283)
> at
> org.apache.myfaces.shared.renderkit.html.CommonEventUtils.renderBehaviorizedEventHandlers(CommonEventUtils.java:202)
>
> {code}
> *JSF 2.3 Behavior when form preprendId=false:*
> 1) If we reference the outputText id in the render attribute with the form id
> prepended then we get the following failure (testpage1.jsf) when requesting
> the page:
> {code:java}
> Cannot find component for expression "testForm:output2" referenced from
> "input1:input".
> viewId=/testpage1.xhtml
> location=C:\libertyGit\libertycdopen\WS-CD-Open\dev\build.image\wlp\usr\servers\test1\apps\expanded\TestApp.war\testpage1.xhtml
> phaseId=RENDER_RESPONSE(6)
> Caused by:
> javax.faces.component.search.ComponentNotFoundException - Cannot find
> component for expression "testForm:output2" referenced from "input1:input".
> at
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.resolveClientId(SearchExpressionHandlerImpl.java:104)
> {code}
> 2) If we reference the outputText id without the form id prepended then the
> page is successfully rendered (testpage2.jsf)
> The behavior between jsf 2.2 and jsf 2.3 is reverse, in jsf 2.3 we do not
> work with the prepended form id and in jsf 2.2 we require the prepended form
> id.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MYFACES-4066) FlowBuilderFactoryBean Concurrency Issue
[ https://issues.apache.org/jira/browse/MYFACES-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo resolved MYFACES-4066. - Resolution: Fixed > 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: Eduardo Breijo >Priority: Minor > Fix For: 2.3.0, 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.4.14#64029)
[jira] [Reopened] (MYFACES-4066) FlowBuilderFactoryBean Concurrency Issue
[ https://issues.apache.org/jira/browse/MYFACES-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo reopened MYFACES-4066: - Assignee: Eduardo Breijo (was: Bill Lucy) I'm reopening this issue to forward port the fix to JSF 2.3 > 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: Eduardo Breijo >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.4.14#64029)
[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16276893#comment-16276893 ] Eduardo Breijo commented on MYFACES-4160: - I have retested both cases reported by Thomas and me, and both are working now. Thanks Werner for fix in it! :) > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > Attachments: test1.xhtml > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4177) FacesServletMappingUtils.isFacesServlet improvement
[ https://issues.apache.org/jira/browse/MYFACES-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4177: Resolution: Fixed Fix Version/s: 2.3.0 Status: Resolved (was: Patch Available) > FacesServletMappingUtils.isFacesServlet improvement > --- > > Key: MYFACES-4177 > URL: https://issues.apache.org/jira/browse/MYFACES-4177 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.3.0 > > Attachments: MYFACES-4177.patch > > > Right now the isFacesServlet method from FacesServletMappingUtils is using > ClassUtils.simpleClassForName which logs and throws a lot of classes that > cannot find. We can change it to use > ClassUtils.simpleClassForName(servletClassName, false) so it doesn't log > every class not found. > I'll provide a patch -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4177) FacesServletMappingUtils.isFacesServlet improvement
[ https://issues.apache.org/jira/browse/MYFACES-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273104#comment-16273104 ] Eduardo Breijo commented on MYFACES-4177: - If no objections, I'll commit this patch in the next days > FacesServletMappingUtils.isFacesServlet improvement > --- > > Key: MYFACES-4177 > URL: https://issues.apache.org/jira/browse/MYFACES-4177 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: MYFACES-4177.patch > > > Right now the isFacesServlet method from FacesServletMappingUtils is using > ClassUtils.simpleClassForName which logs and throws a lot of classes that > cannot find. We can change it to use > ClassUtils.simpleClassForName(servletClassName, false) so it doesn't log > every class not found. > I'll provide a patch -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4177) FacesServletMappingUtils.isFacesServlet improvement
[ https://issues.apache.org/jira/browse/MYFACES-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4177: Status: Patch Available (was: Open) > FacesServletMappingUtils.isFacesServlet improvement > --- > > Key: MYFACES-4177 > URL: https://issues.apache.org/jira/browse/MYFACES-4177 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: MYFACES-4177.patch > > > Right now the isFacesServlet method from FacesServletMappingUtils is using > ClassUtils.simpleClassForName which logs and throws a lot of classes that > cannot find. We can change it to use > ClassUtils.simpleClassForName(servletClassName, false) so it doesn't log > every class not found. > I'll provide a patch -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYFACES-4177) FacesServletMappingUtils.isFacesServlet improvement
Eduardo Breijo created MYFACES-4177: --- Summary: FacesServletMappingUtils.isFacesServlet improvement Key: MYFACES-4177 URL: https://issues.apache.org/jira/browse/MYFACES-4177 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo Assignee: Eduardo Breijo Priority: Minor Right now the isFacesServlet method from FacesServletMappingUtils is using ClassUtils.simpleClassForName which logs and throws a lot of classes that cannot find. We can change it to use ClassUtils.simpleClassForName(servletClassName, false) so it doesn't log every class not found. I'll provide a patch -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4174) Use Locale.forLanguageTag as defined in JSF 2.3 spec section 2.5.2.1
[ https://issues.apache.org/jira/browse/MYFACES-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4174: Resolution: Fixed Fix Version/s: 2.3.0 Status: Resolved (was: Patch Available) > Use Locale.forLanguageTag as defined in JSF 2.3 spec section 2.5.2.1 > > > Key: MYFACES-4174 > URL: https://issues.apache.org/jira/browse/MYFACES-4174 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.3.0 > > Attachments: MYFACES-4174.patch > > > We need to use the Locale.forLanguage tag method to as defined in the JSF 2.3 > spec section 2.5.2.1. > "To facilitate BCP 47 support, the Locale parsing mentioned above is done > only if the JDK Locale.languageForTag method does not return a Locale with a > language in it. The additional format of the Locale string is as specified by > that method." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4174) Use Locale.forLanguageTag as defined in JSF 2.3 spec section 2.5.2.1
[ https://issues.apache.org/jira/browse/MYFACES-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4174: Status: Patch Available (was: Open) > Use Locale.forLanguageTag as defined in JSF 2.3 spec section 2.5.2.1 > > > Key: MYFACES-4174 > URL: https://issues.apache.org/jira/browse/MYFACES-4174 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Attachments: MYFACES-4174.patch > > > We need to use the Locale.forLanguage tag method to as defined in the JSF 2.3 > spec section 2.5.2.1. > "To facilitate BCP 47 support, the Locale parsing mentioned above is done > only if the JDK Locale.languageForTag method does not return a Locale with a > language in it. The additional format of the Locale string is as specified by > that method." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYFACES-4174) Use Locale.forLanguageTag as defined in JSF 2.3 spec section 2.5.2.1
Eduardo Breijo created MYFACES-4174: --- Summary: Use Locale.forLanguageTag as defined in JSF 2.3 spec section 2.5.2.1 Key: MYFACES-4174 URL: https://issues.apache.org/jira/browse/MYFACES-4174 Project: MyFaces Core Issue Type: Bug Reporter: Eduardo Breijo Assignee: Eduardo Breijo Priority: Minor We need to use the Locale.forLanguage tag method to as defined in the JSF 2.3 spec section 2.5.2.1. "To facilitate BCP 47 support, the Locale parsing mentioned above is done only if the JDK Locale.languageForTag method does not return a Locale with a language in it. The additional format of the Locale string is as specified by that method." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo resolved MYFACES-4169. - Resolution: Fixed > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255426#comment-16255426 ] Eduardo Breijo edited comment on MYFACES-4169 at 11/16/17 2:47 PM: --- I noticed that moving the super.processValidators inside the if block will only work if the radio buttons have a group defined. If no group is defined, then validation will not be processed. It makes more sense to only call super.processValidators when there is a submittedValue. I'll provide a new patch with that minor change. was (Author: eduardobreijo): I noticed that there moving the super.processValidators inside the if block will only work if the radio buttons have a group defined. If no group is defined, then validation will not be processed. It makes more sense to only call super.processValidators when there is a submittedValue. I'll provide a new patch with that minor change. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255426#comment-16255426 ] Eduardo Breijo commented on MYFACES-4169: - I noticed that there moving the super.processValidators inside the if block will only work if the radio buttons have a group defined. If no group is defined, then validation will not be processed. It makes more sense to only call super.processValidators when there is a submittedValue. I'll provide a new patch with that minor change. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253813#comment-16253813 ] Eduardo Breijo commented on MYFACES-4169: - Just uploaded a new patch that address your comment. If no issues, I'll commit the patch > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253813#comment-16253813 ] Eduardo Breijo edited comment on MYFACES-4169 at 11/15/17 5:08 PM: --- Just uploaded a new patch that addresses your comment. If no issues, I'll commit the patch was (Author: eduardobreijo): Just uploaded a new patch that address your comment. If no issues, I'll commit the patch > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253788#comment-16253788 ] Eduardo Breijo commented on MYFACES-4169: - You are totally right. I can actually move the super.processValidators inside the if block. That way we don't have to call it all time. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253735#comment-16253735 ] Eduardo Breijo commented on MYFACES-4169: - We still need to go through the super.processValidators to validate the values. If we don't go through that, then after submitting the form, no value is populated to the backing bean. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252807#comment-16252807 ] Eduardo Breijo commented on MYFACES-4169: - I have uploaded a new patch that solves the rendering issue mentioned in my last comment. If no objections I will commit the patch. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252068#comment-16252068 ] Eduardo Breijo edited comment on MYFACES-4169 at 11/14/17 8:13 PM: --- I have uploaded a patch that solves the Validation Error issue for the specific case in selectOneRadioGroupOneValue.xhtml. But there is still one more issue I noticed, when submitting the value of a component that doesn't contain a Value Expression, that radio does not stay checked (selected), although the value was submitted and processed in the bean. Could it be some kind of issue with the rendering of this specific case? I didn't notice that behavior with the case described in last (above) comment. was (Author: eduardobreijo): I have uploaded a patch that solves the Validation Error issue for the specific case in selectOneRadioGroupOneValue.xhtml. But there is still one more issue I noticed, when submitting the value of a component that doesn't contain a Value Expression, that radio does not stay checked (selected), although the value was submitted and processed in the bean. Could it be some kind of issue with the rendering of this specific case? I didn't noticed that behavior with the case described in last (above) comment. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169-1.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252068#comment-16252068 ] Eduardo Breijo edited comment on MYFACES-4169 at 11/14/17 8:07 PM: --- I have uploaded a patch that solves the Validation Error issue for the specific case in selectOneRadioGroupOneValue.xhtml. But there is still one more issue I noticed, when submitting the value of a component that doesn't contain a Value Expression, that radio does not stay checked (selected), although the value was submitted and processed in the bean. Could it be some kind of issue with the rendering of this specific case? I didn't noticed that behavior with the case described in last (above) comment. was (Author: eduardobreijo): I have uploaded a patch that solves the Validation Error issue for the specific case in selectOneRadioGroupOneValue.xhtml. But there is still one more issue I noticed, when submitting the value of a component that doesn't contain a Value Expression, that radio does not stay checked (selected), although the value was submitted and processed in the bean. Could it be some kind of issue with the rendering of this specific case? > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169-1.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252068#comment-16252068 ] Eduardo Breijo commented on MYFACES-4169: - I have uploaded a patch that solves the Validation Error issue for the specific case in selectOneRadioGroupOneValue.xhtml. But there is still one more issue I noticed, when submitting the value of a component that doesn't contain a Value Expression, that radio does not stay checked (selected), although the value was submitted and processed in the bean. Could it be some kind of issue with the rendering of this specific case? > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, MYFACES-4169-1.patch, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249861#comment-16249861 ] Eduardo Breijo edited comment on MYFACES-4169 at 11/13/17 5:39 PM: --- I have found the root cause of the issue. The visit() method in HtmlRendererUtils under SelectOneGroupSetSubmittedValueCallback only considers the following case: It will set the submittedValue to the first h:selectOneRadio component (since it has the value expression), and then in the validateValue() method of UISelectOne in the API, we go through each of the select items and verify if it is in there. Now for the case where there is an issue, the submittedValue will be set to the first component as well (since it has the VE), but in the validateValue() method of UISelectOne in the API, there is only one select item in the first component, which does not match the submitted value, resulting in the Validation Error. was (Author: eduardobreijo): I have found the root cause of the issue. The visit() method in HtmlRendererUtils under SelectOneGroupSetSubmittedValueCallback only considers the following case: It will set the submittedValue to the first h:selectOneRadio component (since it has the value expression), and then in the validate() method of UISelectOne in the API, we go through each of the select items and verify if it is in there. Now for the case where there is an issue, the submittedValue will be set to the first component as well (since it has the VE), but in the validate() method of UISelectOne in the API, there is only one select item in the first component, which does not match the submitted value, resulting in the Validation Error. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, > SelectOneRadioGroupBean.java, index.xhtml, selectOneRadioGroupOneValue.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249861#comment-16249861 ] Eduardo Breijo commented on MYFACES-4169: - I have found the root cause of the issue. The visit() method in HtmlRendererUtils under SelectOneGroupSetSubmittedValueCallback only considers the following case: It will set the submittedValue to the first h:selectOneRadio component (since it has the value expression), and then in the validate() method of UISelectOne in the API, we go through each of the select items and verify if it is in there. Now for the case where there is an issue, the submittedValue will be set to the first component as well (since it has the VE), but in the validate() method of UISelectOne in the API, there is only one select item in the first component, which does not match the submitted value, resulting in the Validation Error. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, > SelectOneRadioGroupBean.java, index.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249674#comment-16249674 ] Eduardo Breijo edited comment on MYFACES-4169 at 11/13/17 2:55 PM: --- That solution does not seem to solve the issue. It is needed anyway for the rest of the selectOneRadio that does not contain a value expression, but it is being bypassed the first time because the referenced component "radio0" has a value expression, and the submitted value is "Value3" from the third component "radio2", leading to the Validation Error. The submitted value for both the second component "radio1" and the third component "radio2" is null. I would expect that submitted value is null for "radio0" and "radio1" if I'm submitting the third component value. If you add a value expression to each component from the above case, it will behave as expected. It will go through each component as well, and if I'm submitting the third component value, then the submitted value for the other components are null. was (Author: eduardobreijo): That solution does not seem to solve the issue. It is needed anyway for the rest of the selectOneRadio that does not contain a value expression, but it is being bypassed the first time because the referenced component "radio0" has a value expression, and the submitted value is "Value3" from the third component "radio2", leading to the Validation Error. The submitted value for both the second component "radio1" and the third component "radio2" is null. I would expect that submitted value is null for "radio0" and "radio1" if I'm submitting the third component value. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, > SelectOneRadioGroupBean.java, index.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249674#comment-16249674 ] Eduardo Breijo commented on MYFACES-4169: - That solution does not seem to solve the issue. It is needed anyway for the rest of the selectOneRadio that does not contain a value expression, but it is being bypassed the first time because the referenced component "radio0" has a value expression, and the submitted value is "Value3" from the third component "radio2", leading to the Validation Error. The submitted value for both the second component "radio1" and the third component "radio2" is null. I would expect that submitted value is null for "radio0" and "radio1" if I'm submitting the third component value. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, > SelectOneRadioGroupBean.java, index.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248093#comment-16248093 ] Eduardo Breijo commented on MYFACES-4169: - >From the case I mentioned above, what I found is that, for some reason, if I >submit "Value3", then when we do validate() in UIInput, the >getSubmittedValue() is returning "Value3" but the actual component being >referenced is the "radio0". So when we execute _SelectItemsUtil.matchValue() >to compare the submitted value with the actual value of "radio0", it does not >match, ending in the validation error. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, > SelectOneRadioGroupBean.java, index.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248000#comment-16248000 ] Eduardo Breijo commented on MYFACES-4169: - Hey [~tandraschko] I have found a case where I'm getting a validation error when submitting the values of selectOneRadio in a form. This only happens when we have selectItem in each of the selectOneRadio components and one value attribute in the first selectOneRadio component. Case 1: Error: If I submit radio0 value, there is no issue. But if I submit radio1 or radio2 then I get this message: radio0: Validation Error: Value is not valid > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, > SelectOneRadioGroupBean.java, index.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16246673#comment-16246673 ] Eduardo Breijo commented on MYFACES-4169: - Aside from the issue you mentioned, all the rendering looks good now :) > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, > SelectOneRadioGroupBean.java, index.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio grouping broken
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16246527#comment-16246527 ] Eduardo Breijo commented on MYFACES-4169: - Do you have a patch for the logic you mentioned in the comment above? If so, please upload that code and I can test it. > selectOneRadio grouping broken > -- > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war, > SelectOneRadioGroupBean.java, index.xhtml > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYFACES-4172) Fix addSearchExpressionHandler method name and getSearchExpressionContextFactory return list
[ https://issues.apache.org/jira/browse/MYFACES-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo resolved MYFACES-4172. - Resolution: Fixed > Fix addSearchExpressionHandler method name and > getSearchExpressionContextFactory return list > > > Key: MYFACES-4172 > URL: https://issues.apache.org/jira/browse/MYFACES-4172 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo >Priority: Minor > Fix For: 2.3.0 > > Attachments: MYFACES-4172.patch > > > The addSearchExpressionHandler method in ApplicationImpl class is written > incorrectly as "addSearchExpressionHandlerHandler". > The getSearchExpressionContextFactory method in FactoryImpl should return > searchExpressionContextFactories and not clientWindowFactories -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYFACES-4172) Fix addSearchExpressionHandler method name and getSearchExpressionContextFactory return list
Eduardo Breijo created MYFACES-4172: --- Summary: Fix addSearchExpressionHandler method name and getSearchExpressionContextFactory return list Key: MYFACES-4172 URL: https://issues.apache.org/jira/browse/MYFACES-4172 Project: MyFaces Core Issue Type: Bug Components: JSR-372 Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo Assignee: Eduardo Breijo Priority: Minor The addSearchExpressionHandler method in ApplicationImpl class is written incorrectly as "addSearchExpressionHandlerHandler". The getSearchExpressionContextFactory method in FactoryImpl should return searchExpressionContextFactories and not clientWindowFactories -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4169) selectOneRadio does not work properly in JSF 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16246141#comment-16246141 ] Eduardo Breijo commented on MYFACES-4169: - According to Mojarra, this is the rendered markup for the case you mentioned: And yes, I think it makes sense that you need to also execute radio0 as you mentioned. > selectOneRadio does not work properly in JSF 2.3 > > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci > Fix For: 2.3.0 > > Attachments: JSF23SelectOneRadioGroup.war > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4171) Create a new web-facesconfig.xsd schema for JSF 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4171: Resolution: Fixed Status: Resolved (was: Patch Available) > Create a new web-facesconfig.xsd schema for JSF 2.3 > --- > > Key: MYFACES-4171 > URL: https://issues.apache.org/jira/browse/MYFACES-4171 > Project: MyFaces Core > Issue Type: Task > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo >Assignee: Eduardo Breijo > Fix For: 2.3.0 > > Attachments: MYFACES-4171.patch > > > I noticed that the schema file web-facesconfig.xsd has not been updated since > JSF 2.1. > The following spec issue was opened to add the element > /faces-config/factory/client-window-factory in the schema because it was > missing on JSF 2.2. > https://github.com/javaee/javaserverfaces-spec/issues/1241 > I also noticed that the following new elements need to be added to the JSF > 2.3 schema. > /faces-config/factory/search-expression-context-factory > /faces-config/application/search-expression-handler > /faces-config/application/search-keyword-resolver > We need to create a new web-facesconfig.xsd schema for JSF 2.3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4171) Create a new web-facesconfig.xsd schema for JSF 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244665#comment-16244665 ] Eduardo Breijo commented on MYFACES-4171: - I'll commit the changes. Thanks for the review. > Create a new web-facesconfig.xsd schema for JSF 2.3 > --- > > Key: MYFACES-4171 > URL: https://issues.apache.org/jira/browse/MYFACES-4171 > Project: MyFaces Core > Issue Type: Task > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo > Fix For: 2.3.0 > > Attachments: MYFACES-4171.patch > > > I noticed that the schema file web-facesconfig.xsd has not been updated since > JSF 2.1. > The following spec issue was opened to add the element > /faces-config/factory/client-window-factory in the schema because it was > missing on JSF 2.2. > https://github.com/javaee/javaserverfaces-spec/issues/1241 > I also noticed that the following new elements need to be added to the JSF > 2.3 schema. > /faces-config/factory/search-expression-context-factory > /faces-config/application/search-expression-handler > /faces-config/application/search-keyword-resolver > We need to create a new web-facesconfig.xsd schema for JSF 2.3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4171) Create a new web-facesconfig.xsd schema for JSF 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Breijo updated MYFACES-4171: Status: Patch Available (was: Open) > Create a new web-facesconfig.xsd schema for JSF 2.3 > --- > > Key: MYFACES-4171 > URL: https://issues.apache.org/jira/browse/MYFACES-4171 > Project: MyFaces Core > Issue Type: Task > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo > Attachments: MYFACES-4171.patch > > > I noticed that the schema file web-facesconfig.xsd has not been updated since > JSF 2.1. > The following spec issue was opened to add the element > /faces-config/factory/client-window-factory in the schema because it was > missing on JSF 2.2. > https://github.com/javaee/javaserverfaces-spec/issues/1241 > I also noticed that the following new elements need to be added to the JSF > 2.3 schema. > /faces-config/factory/search-expression-context-factory > /faces-config/application/search-expression-handler > /faces-config/application/search-keyword-resolver > We need to create a new web-facesconfig.xsd schema for JSF 2.3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4171) Create a new web-facesconfig.xsd schema for JSF 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242877#comment-16242877 ] Eduardo Breijo commented on MYFACES-4171: - Yeah it's my bad, there is a spec issue opened for that: https://github.com/javaee/javaserverfaces-spec/issues/1457 > Create a new web-facesconfig.xsd schema for JSF 2.3 > --- > > Key: MYFACES-4171 > URL: https://issues.apache.org/jira/browse/MYFACES-4171 > Project: MyFaces Core > Issue Type: Task > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo > > I noticed that the schema file web-facesconfig.xsd has not been updated since > JSF 2.1. > The following spec issue was opened to add the element > /faces-config/factory/client-window-factory in the schema because it was > missing on JSF 2.2. > https://github.com/javaee/javaserverfaces-spec/issues/1241 > I also noticed that the following new elements need to be added to the JSF > 2.3 schema. > /faces-config/factory/search-expression-context-kit-factory > /faces-config/application/search-expression-handler > /faces-config/application/search-keyword-resolver > We need to create a new web-facesconfig.xsd schema for JSF 2.3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYFACES-4171) Create a new web-facesconfig.xsd schema for JSF 2.3
Eduardo Breijo created MYFACES-4171: --- Summary: Create a new web-facesconfig.xsd schema for JSF 2.3 Key: MYFACES-4171 URL: https://issues.apache.org/jira/browse/MYFACES-4171 Project: MyFaces Core Issue Type: Task Components: JSR-372 Affects Versions: 2.3.0-beta Reporter: Eduardo Breijo I noticed that the schema file web-facesconfig.xsd has not been updated since JSF 2.1. The following spec issue was opened to add the element /faces-config/factory/client-window-factory in the schema because it was missing on JSF 2.2. https://github.com/javaee/javaserverfaces-spec/issues/1241 I also noticed that the following new elements need to be added to the JSF 2.3 schema. /faces-config/factory/search-expression-context-kit-factory /faces-config/application/search-expression-handler /faces-config/application/search-keyword-resolver We need to create a new web-facesconfig.xsd schema for JSF 2.3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4169) selectOneRadio does not work properly in JSF 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238236#comment-16238236 ] Eduardo Breijo edited comment on MYFACES-4169 at 11/3/17 7:49 PM: -- I have better identified the issues. I'm not completely sure if they are valid cases. Issue #1 When ID does not contain a number at the end: Rendered markup has the same id: staticValue1 staticValue2 staticValue3 Issue #2 When ID contains a number at end that it is greater than the number of selectItems, an IndexOutOfBound exception is thrown. java.lang.IndexOutOfBoundsException: Index: 8, Size: 3 at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.myfaces.shared.renderkit.html.HtmlRadioRendererBase.encodeEnd(HtmlRadioRendererBase.java:166) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:675) at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:555) at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551) Issue #3 When ID contains a number at the end, and that number is not 0, for example “radio1”, it will select the second item in the list, instead of starting from the first. Rendered markup: staticValue2 staticValue3 Issue #4 When you start the selectOneRadio with an ID that ends with a number, but then the next selectOneRadio doesn’t contain the next number in sequence, and they are part of the same group. Only the first one is rendered. Rendered markup: staticValue1 I think there should not any difference when the ID ends with a number or ends with a letter. This should work the same regardless. was (Author: eduardobreijo): I have better identified the issues. I'm not completely sure if they are valid cases. Issue #1 When ID does not contain a number at the end: Rendered markup has the same id: staticValue1 staticValue2 staticValue3 Issue #2 When ID contains a number at end that it is greater than the number of selectItems, an IndexOutOfBound exception is thrown. java.lang.IndexOutOfBoundsException: Index: 8, Size: 3 at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.myfaces.shared.renderkit.html.HtmlRadioRendererBase.encodeEnd(HtmlRadioRendererBase.java:166) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:675) at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:555) at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551) Issue #3 When ID contains a number at the end, and that number is not 0, for example “radio1”, it will select the second item in the list, instead of starting from the first. Rendered markup: staticValue2 staticValue3 Issue #4 When you start the selectOneRadio with an ID that ends with a number, but then the next selectOneRadio doesn’t contain the next number in sequence, and they are part of the same group. Only the first one is rendered. Rendered markup: staticValue1 > selectOneRadio does not work properly in JSF 2.3 > > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Priority: Major > Attachments: JSF23SelectOneRadioGroup.war > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml >
[jira] [Commented] (MYFACES-4169) selectOneRadio does not work properly in JSF 2.3
[ https://issues.apache.org/jira/browse/MYFACES-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16238236#comment-16238236 ] Eduardo Breijo commented on MYFACES-4169: - I have better identified the issues. I'm not completely sure if they are valid cases. Issue #1 When ID does not contain a number at the end: Rendered markup has the same id: staticValue1 staticValue2 staticValue3 Issue #2 When ID contains a number at end that it is greater than the number of selectItems, an IndexOutOfBound exception is thrown. java.lang.IndexOutOfBoundsException: Index: 8, Size: 3 at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.myfaces.shared.renderkit.html.HtmlRadioRendererBase.encodeEnd(HtmlRadioRendererBase.java:166) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:675) at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:555) at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551) Issue #3 When ID contains a number at the end, and that number is not 0, for example “radio1”, it will select the second item in the list, instead of starting from the first. Rendered markup: staticValue2 staticValue3 Issue #4 When you start the selectOneRadio with an ID that ends with a number, but then the next selectOneRadio doesn’t contain the next number in sequence, and they are part of the same group. Only the first one is rendered. Rendered markup: staticValue1 > selectOneRadio does not work properly in JSF 2.3 > > > Key: MYFACES-4169 > URL: https://issues.apache.org/jira/browse/MYFACES-4169 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-372 >Affects Versions: 2.3.0-beta >Reporter: Paul Nicolucci >Priority: Major > Attachments: JSF23SelectOneRadioGroup.war > > > I was testing out the new group attribute on the > component and found that it does not look to work in all scenarios: > I've provided a test application to shows a working scenario and then > multiple scenarios that I think should work but don't. > The app can be deployed on tomcat. > You can drive a request to the index page which will contain the links what > doesn't work: > http://localhost:8080/JSF23SelectOneRadioGroup/index.xhtml > Or you can directly verify what does not work by sending requests to: > localhost:8080/JSF23SelectOneRadioGroup/error.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error2.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error3.xhtml > localhost:8080/JSF23SelectOneRadioGroup/error4.xhtml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
