[JBoss JIRA] (RF-13603) unsupported classversion 51.0 while deploying ear
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13603?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13603:
-------------------------------
Assignee: (was: Matej Novotny)
> unsupported classversion 51.0 while deploying ear
> -------------------------------------------------
>
> Key: RF-13603
> URL: https://issues.jboss.org/browse/RF-13603
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 5.0.0.Alpha3
> Environment: Windows 7, Weblogic 10.3.5, JDK 6
> Reporter: Nestor Armando Bohorquez
> Labels: ResourceServlet, classversion
> Fix For: 5-Tracking
>
>
> An exception is thrown when applicattion is been deployed:
> {code}
> java.lang.UnsupportedClassVersionError: org/richfaces/servlet/ResourceServlet : unsupported classversion 51.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:630)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:614)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at weblogic.utils.classloaders.GenericClassLoader.defineClass(GenericClassLoader.java:343)
> at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:302)
> at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:270)
> at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:64)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:305)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:246)
> at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:179)
> at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:43)
> at weblogic.servlet.internal.WebAnnotationProcessorImpl.processServlets(WebAnnotationProcessorImpl.java:225)
> at weblogic.servlet.internal.WebAnnotationProcessorImpl.processJ2eeAnnotations(WebAnnotationProcessorImpl.java:209)
> at weblogic.servlet.internal.WebAnnotationProcessorImpl.processAnnotations(WebAnnotationProcessorImpl.java:105)
> at weblogic.servlet.internal.WebAppServletContext.processAnnotations(WebAppServletContext.java:1368)
> at weblogic.servlet.internal.WebAppServletContext.<init>(WebAppServletContext.java:449)
> at weblogic.servlet.internal.WebAppServletContext.<init>(WebAppServletContext.java:493)
> at weblogic.servlet.internal.HttpServer.loadWebApp(HttpServer.java:418)
> at weblogic.servlet.internal.WebAppModule.registerWebApp(WebAppModule.java:972)
> at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:382)
> at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176)
> at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
> at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:517)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
> at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:159)
> at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:45)
> at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:613)
> at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
> at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:184)
> at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:58)
> at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:154)
> at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
> at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:207)
> at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98)
> at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)
> at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747)
> at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)
> at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)
> at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
> at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
> at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13)
> at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46)
> at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
> {code}
> I'm using this in the web.xml file.
> {code}
> <servlet>
> <servlet-name>Resource Servlet</servlet-name>
> <servlet-class>org.richfaces.servlet.ResourceServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Marcel Kolsteren (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
Marcel Kolsteren commented on RF-13706:
---------------------------------------
Thanks! I changed the RichFaces dependency to the 4.5 snapshot artifact supplied by Pavol, and deployed my sample application in WildFly 8.1.0.Final. The problem was still there (as expected).
It would be great if you included the fix for this issue in the upcoming 4.3.8 release as well.
> dequeued Ajax request not processed correctly if its source element has been updated
> ------------------------------------------------------------------------------------
>
> Key: RF-13706
> URL: https://issues.jboss.org/browse/RF-13706
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.7
> Reporter: Marcel Kolsteren
> Assignee: Juraj Húska
> Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip
>
>
> I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page.
> The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen.
> To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked:
> {noformat}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:a4j="http://richfaces.org/a4j">
> <h:head/>
> <h:body>
> <form action="http://www.meandi.nl"/>
> <h:form>
> <a4j:commandLink action="#{richBean.waitThreeSeconds}" value="Click Me" render="@this"/>
> </h:form>
> </h:body>
> </html>
> {noformat}
> The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7.
> The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-13706:
------------------------------------
[~marcelkolsteren], just FYI, Maven GAV changed in 4.5 so you can find 4.5.0-SNAPSHOT artefacts in http://repository.jboss.org/nexus/content/groups/public/org/richfaces/ric...
> dequeued Ajax request not processed correctly if its source element has been updated
> ------------------------------------------------------------------------------------
>
> Key: RF-13706
> URL: https://issues.jboss.org/browse/RF-13706
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.7
> Reporter: Marcel Kolsteren
> Assignee: Juraj Húska
> Attachments: queuetest-javaee6.zip, queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip
>
>
> I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page.
> The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen.
> To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked:
> {noformat}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:a4j="http://richfaces.org/a4j">
> <h:head/>
> <h:body>
> <form action="http://www.meandi.nl"/>
> <h:form>
> <a4j:commandLink action="#{richBean.waitThreeSeconds}" value="Click Me" render="@this"/>
> </h:form>
> </h:body>
> </html>
> {noformat}
> The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7.
> The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13710) popupPanel (modal and autosized) doesn't resize then content resizes (eg. after ajax request)
by Dariusz M (JIRA)
Dariusz M created RF-13710:
------------------------------
Summary: popupPanel (modal and autosized) doesn't resize then content resizes (eg. after ajax request)
Key: RF-13710
URL: https://issues.jboss.org/browse/RF-13710
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: base functionality
Affects Versions: 4.3.7
Reporter: Dariusz M
In 4.3.5 it was fine.
In 4.3.7 popupPanel with autosized has now width and height set in style attribute for div id's "xxx_container" and "xxx_content_scroller" (width and height calculated for current content rendered during show). Therefore when any element in content changes its size, for example validation on "Store" button is done and message components are rendered (with some errors) then popupPanel stay still and doesn't resizes (scrollbars appears in div) because height in _content_scroller is set to fix value (good at the beginning).
In 4.3.5 height and width in style for popupPanel divs wasn't set (in autosized mode) that's why when content was resized then whole popupPanel was resized automatically. It was nice, especially when using popupPanel as in dataTable editing example (data changes in single window with validation messages) or when popupPanel is used in a wizard mode (with some steps, each with little different size)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months