[jira] [Commented] (TOBAGO-1759) Update Bootstrap to 4.0.0 beta 1 (from alpha 6)
[ https://issues.apache.org/jira/browse/TOBAGO-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199100#comment-16199100 ] Hudson commented on TOBAGO-1759: SUCCESS: Integrated in Jenkins build Tobago Trunk #1069 (See [https://builds.apache.org/job/Tobago%20Trunk/1069/]) TOBAGO-1759 Update Bootstrap to 4.0.0 beta 1 (from alpha 6) * fix (hnoeth: rev bfecb48c56c5c01f5bcff2a9b73c89b64b7933da) * (edit) tobago-core/src/main/resources/scss/_tobago.scss * (edit) tobago-example/tobago-example-demo/src/main/webapp/content/40-test/6-manual/5000-messageLayout/messageLayout.xhtml > Update Bootstrap to 4.0.0 beta 1 (from alpha 6) > --- > > Key: TOBAGO-1759 > URL: https://issues.apache.org/jira/browse/TOBAGO-1759 > Project: MyFaces Tobago > Issue Type: Task > Components: Core, Themes >Reporter: Udo Schnurpfeil >Assignee: Henning Noeth > Fix For: 4.0.0 > > > Can be started after Bootstrap has released an beta version. > * Remind: Check if the problem with BootstrapClass.FADE in PopupRenderer is > solved (TOBAGO-1758). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198723#comment-16198723 ] Dora Rajappan commented on MYFACES-4162: I got the redirect flag fundamental from the mkyong example. After all its just a display error of browser and cant we ignore it!!! at the cost of a redirect for all non ajaxed navigations!!! > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198611#comment-16198611 ] Werner Punz edited comment on MYFACES-4162 at 10/10/17 12:52 PM: - As I mentioned before... for non ajaxed cases use a redirect flag in your navigational definitions. This should fix it. https://www.mkyong.com/jsf2/jsf-page-forward-vs-page-redirect/ In the ajax navigational case, there is nothing we can do atm we probably would need a spec extension regarding url rewriting here, which at the time the ajax api was specified originally was not supported by any browser. was (Author: werpu): As I mentioned before... for non ajaxed cases use a redirect true flag in your navigational definitions. This should fix it. https://www.mkyong.com/jsf2/jsf-page-forward-vs-page-redirect/ In the ajax navigational case, there is nothing we can do atm we probably would need a spec extension regarding url rewriting here, which at the time the ajax api was specified originally was not supported by any browser. > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198611#comment-16198611 ] Werner Punz edited comment on MYFACES-4162 at 10/10/17 12:51 PM: - As I mentioned before... for non ajaxed cases use a redirect true flag in your navigational definitions. This should fix it. https://www.mkyong.com/jsf2/jsf-page-forward-vs-page-redirect/ In the ajax navigational case, there is nothing we can do atm we probably would need a spec extension regarding url rewriting here, which at the time the ajax api was specified originally was not supported by any browser. was (Author: werpu): As I mentioned before... for non ajaxed cases use a redirect true flag in your navigational definitions. This should fix it. In the ajax navigational case, there is nothing we can do atm we probably would need a spec extension regarding url rewriting here, which at the time the ajax api was specified originally was not supported by any browser. > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198611#comment-16198611 ] Werner Punz commented on MYFACES-4162: -- As I mentioned before... for non ajaxed cases use a redirect true flag in your navigational definitions. This should fix it. In the ajax navigational case, there is nothing we can do atm we probably would need a spec extension regarding url rewriting here, which at the time the ajax api was specified originally was not supported by any browser. > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-3805) check handling of serializable converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198575#comment-16198575 ] Thomas Andraschko commented on MYFACES-3805: Is this still an issue for 2.3 or can we close it? > check handling of serializable converters and validators > > > Key: MYFACES-3805 > URL: https://issues.apache.org/jira/browse/MYFACES-3805 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Affects Versions: 2.2.0 >Reporter: Gerhard Petracek >Assignee: Leonardo Uribe > > it doesn't work as specified in paragraph 7.8.1. > once we change something here, we also have to handle it for MYFACES-3797. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4037) RuntimePermissions required for protected packages when security manager enabled
[
https://issues.apache.org/jira/browse/MYFACES-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198573#comment-16198573
]
Thomas Andraschko commented on MYFACES-4037:
No response since 1,5 years. Should we close it?
> RuntimePermissions required for protected packages when security manager
> enabled
>
>
> Key: MYFACES-4037
> URL: https://issues.apache.org/jira/browse/MYFACES-4037
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.2.9
> Environment: Tomcat 8
>Reporter: Neil Richards
>
> Deploying myfaces-example-simple-1.1.14.war with security manager enabled
> causes AccessControlExceptions as follows:
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass Security
> Violation, attempt to use Restricted Class:
> org.apache.catalina.servlets.DefaultServlet
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission"
> "accessClassInPackage.org.apache.catalina.servlets")
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission"
> "accessClassInPackage.org.apache.catalina.servlets")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at
> java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1564)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1243)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1142)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.myfaces.ee6.MyFacesContainerInitializer.isDelegatedFacesServlet(MyFacesContainerInitializer.java:280)
> at
> org.apache.myfaces.ee6.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:150)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5244)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
> at
> org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:131)
> at
> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:153)
> at
> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:143)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:699)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
> at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:939)
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1812)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass Security
> Violation, attempt to use Restricted Class:
> org.apache.jasper.compiler.JspRuntimeContext
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission"
> "accessClassInPackage.org.apache.jasper.compiler")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at
> java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1564)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1243)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1142)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.myfaces.webapp.Jsp21FacesInitializer.getJspFactory(Jsp21FacesInitializer.java:88)
> at
> org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:62)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
>
[jira] [Resolved] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly
[ https://issues.apache.org/jira/browse/MYFACES-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4154. Resolution: Not A Problem See https://issues.apache.org/jira/browse/MYFACES-4162 > The browser (chrome) always show the previous page name while its on the > current page rendered properly > --- > > Key: MYFACES-4154 > URL: https://issues.apache.org/jira/browse/MYFACES-4154 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Dora Rajappan > Attachments: mf23test.zip > > > The browser (chrome) always show the previous page name while its on the > current page rendered properly . This bug is already logged in jira not sure > of the bug id. Not sure its browser problem or jsf. Not checked this with > mojarra also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4055) Localized JSF error and information messages not displayed
[
https://issues.apache.org/jira/browse/MYFACES-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198566#comment-16198566
]
Thomas Andraschko commented on MYFACES-4055:
[~lu4242] I think it doesn't hurt if check for for webapplication resources
first?!
> Localized JSF error and information messages not displayed
> --
>
> Key: MYFACES-4055
> URL: https://issues.apache.org/jira/browse/MYFACES-4055
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-344
>Affects Versions: 2.2.10
> Environment: Java 8, TomEE 7, Primefaces 6.0, Omnifaces 2.3
>Reporter: Petras
> Labels: localization, messages
> Attachments: full-submit.png, partial-submit.png
>
>
> I have localized JSF error and information messages as described in JSR-344
> Section "2.5.2.4 Localized Application Messages", which defines how
> applications may provide own JSF messages, and prepared resource bundle
> "javax.faces.Messages". In _faces-config.xml_ I set:
> {{javax.faces.Messages}}.
> But these resources are not always used, when value validation in UI input
> component fail. Consider the following snippet which illustrates the issue.
> It contains 2 input text fields, the first one has "required" attribute. The
> second field is validated using Bean Validation framework:
> {code:xml}
>
>
>
>
>
>
> value="#{validationModel.requiredClient}" required="true"/>
>
>
>
>
> value="#{validationModel.requiredAnnotated}" />
>
>
>
>
>
> actionListener="#{validationModel.save}" >
>
>
>
>
> {code}
> The backing bean:
> {code:java}
> @Named @RequestScoped
> public class ValidationModel implements DecisionProcessable {
> @NotNull @Length(min = 1, max = 64)
> private String requiredAnnotated;
> private String requiredClient;
> // getters and setters
> public void save() {
> System.out.println(this);
> }
> }
> {code}
> If I click the button "Save", which performs full submit, I get localized
> error message. If I click "Save (ajax)", which performs partial submit with
> ajax, the JSF validation error message is not localized.
> I did some debugging and noticed that validation logic uses {{_MessageUtils}}
> class to obtain resource bundle for the messages, but this utility class uses
> FacesContext class ClassLoader to find resource bundle. The problem is that
> this ClassLoader does not always refer to web application classloader. When
> the partial submit is performed, it refers to Tomcat common classloader,
> which surely does not see web application resources.
> The fix probably would be the same as implemented in {{MessageUtils}}, which
> uses Thread.currentThread().getContextClassLoader() on ResourceBundle
> (MYFACES-338).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198563#comment-16198563 ] Dora Rajappan commented on MYFACES-4162: Its true that both mojarra and myfaces behave same way displaying previous page names in browser. Yes its the urls. Guess its how things work. And 4154 can be closed then. > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198544#comment-16198544 ] Werner Punz edited comment on MYFACES-4162 at 10/10/17 12:02 PM: - https://issues.apache.org/jira/browse/MYFACES-4154 if you mean with the browser name, the url in the browser, that is unfortunately to be expected since you navigate from the login page to the main page with an ajax call. ATM there is no url rewriting for such cases specified. Also jsf used to be always one xhtml behind anway in its url due to its basic postback -> forward navigational mechanism. Both myfaces and mojarra behave the same here, that the first navigational call is a postback into the same page with a forward into a new page. So I guess MYFACES-4154 is not a bug it is more how things work. Afair there is a redirect true navigational xml flag for the url rewriting of non ajaxed navigational cases. So I would recommend to close 4154 as well. This as it is per spec atm and has been since JSF 1.0. was (Author: werpu): https://issues.apache.org/jira/browse/MYFACES-4154 if you mean with the browser name, the url in the browser, that is unfortunately to be expected since you navigate from the login page to the main page with an ajax call. ATM there is no url rewriting for such cases specified. Also jsf used to be always one xhtml behind anway in its url due to its basic postback -> forward navigational mechanism. Both myfaces and mojarra behave the same here, that the first navigational call is a postback into the same page with a forward into a new page. So I guess MYFACES-4154 is not a bug it is more how things work. Afair there is a redirect true navigational xml flag for the url rewriting of non ajaxed navigational cases. > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198540#comment-16198540 ] Dora Rajappan edited comment on MYFACES-4162 at 10/10/17 12:01 PM: --- I just checked below two are related and cause by repeated ajax calls. Only first ajax call one was succeeding. Subsequent calls whether to show another error message or navigate to a different page wasnt working. With the latest fix they both work very well. .https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4160 https://issues.apache.org/jira/browse/MYFACES-4162 . 4154 is purely a navigation and page name error not related to ajax. Ie after login page (very first page) when navigated to a new page it shows in browser, name of the previous page while its at a current page rendered properly). 4154 is not fixed. 4160, 4162 are fixed and works both with IE and chrome!!! Thanks to Werner! was (Author: dorarajappan): I just checked below two are related and cause by repeated ajax calls. Only first ajax call one was succeeding. Subsequent calls whether to show another error message or navigate to a different page wasnt working. With the latest fix they both work very well. .https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4160 https://issues.apache.org/jira/browse/MYFACES-4162 . 4154 is purely a navigation and page name error not related to ajax. Ie after login page (very first page) when navigated to a new page it shows in browser name of the previous page while its at a current page rendered properly). 4154 is not fixed. 4160, 4162 are fixed and works both with IE and chrome!!! Thanks to Werner! > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYFACES-4065) Did not handled empty string while creating the resource
[ https://issues.apache.org/jira/browse/MYFACES-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-4065: --- Resolution: Fixed Assignee: Thomas Andraschko Status: Resolved (was: Patch Available) > Did not handled empty string while creating the resource > > > Key: MYFACES-4065 > URL: https://issues.apache.org/jira/browse/MYFACES-4065 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.2.3 > Environment: Windows, Tomcat >Reporter: Madhavi T >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 2.2.13, 2.3.0 > > Attachments: MYFACES-4065.patch > > > java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at java.lang.String.charAt(Unknown Source) > at > org.apache.myfaces.application.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:118) > at > javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:47) > at > org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.createResource(CAPTCHAResourceHandlerWrapper.java:83) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:109) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:61) > at > org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:55) > at > javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:35) > at > org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:568) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.handleResourceRequest(CAPTCHAResourceHandlerWrapper.java:212) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59) > at > org.primefaces.application.resource.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:87) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:190) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:217) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) > at > org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518) > at > org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:844) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at
[jira] [Updated] (MYFACES-4122) Auto scroll doesn't work anymore for some environment
[ https://issues.apache.org/jira/browse/MYFACES-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-4122: --- Resolution: Fixed Status: Resolved (was: Patch Available) Fixed in core. Not sure if we need to fix this in tomahawk, too. [~lu4242]? > Auto scroll doesn't work anymore for some environment > - > > Key: MYFACES-4122 > URL: https://issues.apache.org/jira/browse/MYFACES-4122 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12 >Reporter: Taro App >Assignee: Thomas Andraschko > Fix For: 2.0.25, 2.1.19, 2.2.13, 2.3.0 > > Attachments: HtmlJavaScriptUtils.java.patch > > > Auto Scroll doesn't work anymore for some environment. This is because auto > scroll code assumes scroll position to be integer value where some browsers > begin to return floating numbers. See > org.apache.myfaces.shared.renderkit.html.HtmlJavaScriptUtils.getAutoScrollFunction > where it parses scroll positions assuming they are integers, and if not, it > ignores those values and prints out error "Error getting y offset for > autoscroll feature. Bad param value" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198544#comment-16198544 ] Werner Punz edited comment on MYFACES-4162 at 10/10/17 11:44 AM: - https://issues.apache.org/jira/browse/MYFACES-4154 if you mean with the browser name, the url in the browser, that is unfortunately to be expected since you navigate from the login page to the main page with an ajax call. ATM there is no url rewriting for such cases specified. Also jsf used to be always one xhtml behind anway in its url due to its basic postback -> forward navigational mechanism. Both myfaces and mojarra behave the same here, that the first navigational call is a postback into the same page with a forward into a new page. So I guess MYFACES-4154 is not a bug it is more how things work. Afair there is a redirect true navigational xml flag for the url rewriting of non ajaxed navigational cases. was (Author: werpu): https://issues.apache.org/jira/browse/MYFACES-4154 if you mean with the browser name, the url in the browser, that is unfortunately to be expected since you navigate from the login page to the main page with an ajax call. ATM there is no url rewriting for such cases specified. Also jsf used to be always one xhtml behind anway in its url due to its basic postback -> forward navigational mechanism. Both myfaces and mojarra behave the same here, that the first navigational call is a postback into the same page with a forward into a new page. So I guess MYFACES-4154 is not a bug it is more how things work. > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198544#comment-16198544 ] Werner Punz commented on MYFACES-4162: -- https://issues.apache.org/jira/browse/MYFACES-4154 if you mean with the browser name, the url in the browser, that is unfortunately to be expected since you navigate from the login page to the main page with an ajax call. ATM there is no url rewriting for such cases specified. Also jsf used to be always one xhtml behind anway in its url due to its basic postback -> forward navigational mechanism. Both myfaces and mojarra behave the same here, that the first navigational call is a postback into the same page with a forward into a new page. So I guess MYFACES-4154 is not a bug it is more how things work. > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198540#comment-16198540 ] Dora Rajappan commented on MYFACES-4162: I just checked below two are related and cause by repeated ajax calls. Only first ajax call one was succeeding. Subsequent calls whether to show another error message or navigate to a different page wasnt working. With the latest fix they both work very well. .https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4160 https://issues.apache.org/jira/browse/MYFACES-4162 . 4154 is purely a navigation and page name error not related to ajax. Ie after login page (very first page) when navigated to a new page it shows in browser name of the previous page while its at a current page rendered properly). 4154 is not fixed. 4160, 4162 are fixed and works both with IE and chrome!!! Thanks to Werner! > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198523#comment-16198523 ] Werner Punz commented on MYFACES-4162: -- Yes i am waiting for the final confirmation from Dora atm... > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198517#comment-16198517 ] Thomas Andraschko commented on MYFACES-4162: Ok, so we also set the status of MYFACES-4154 as fixed? > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198494#comment-16198494 ] Werner Punz commented on MYFACES-4162: -- I guess we are done with this set of issues https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4154 works for me now https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4160 also and https://issues.apache.org/jira/browse/MYFACES-4162 passes also now > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198492#comment-16198492 ] Werner Punz commented on MYFACES-4162: -- Ok the the final logout issue also was caused by the client side. The code added the viewroot prefix to the names of the newly attached viewstate fields. This is fixed now. Doras example now works for me end to end. No need for a server side investigation. > bug in the response handling if a full page is sent via ajax > > > Key: MYFACES-4162 > URL: https://issues.apache.org/jira/browse/MYFACES-4162 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Werner Punz >Assignee: Werner Punz > > The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back > an entire page due to a page navigation triggered from an ajax call, and > apparently the page is inserted but the viewstate is lost along the way. I > need to investigate what happens for such a corner case, since triggering a > page change navigation from Ajax is rather seldom but needs to be addressed. > I will need a handful of days to fix this, due to my limited time. -- 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=16198455#comment-16198455 ] Werner Punz commented on MYFACES-4160: -- Ok I found another issue, Fixed now. The login the error case and the logout now works as expected. I guess 4156 and 4160 are now fixed. > 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 > > > 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] [Commented] (MYFACES-4156) Myface is not showing the FacesMessage after validation when ValidatorException is thown.
[
https://issues.apache.org/jira/browse/MYFACES-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198449#comment-16198449
]
Werner Punz commented on MYFACES-4156:
--
I found the issue, it was not on the server but on the client.
the names of the viewstates were prefixed with the viewroot id in certain cases.
No need to search on the server. Doras Example and the logout now goes through.
> Myface is not showing the FacesMessage after validation when
> ValidatorException is thown.
> -
>
> Key: MYFACES-4156
> URL: https://issues.apache.org/jira/browse/MYFACES-4156
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
> Attachments: MessageBean.java, MyValidator.java, login.xhtml,
> mf23test.zip
>
>
> Myfaces 2.3 is not showing the FacesMessage after validation when
> ValidatorException is thrown. Same works with mojarra 2.2.
> if (param.length() > 32) {
> FacesMessage msg = new FacesMessage("Username should
> not exceed 32");
>
> throw new ValidatorException(msg);
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
