[JBoss JIRA] (RF-12131) Switchable panels do not work after rerendering whole page
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-12131?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-12131:
-------------------------------
Environment:
RichFaces 4.5.0-SNAPSHOT
Metamer 4.5.0-SNAPSHOT
Mojarra 2.2.6/2.2.7
Apache Tomcat 7.0.54, WildFly 8.1.0.Final
OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux
Firefox 30.0 @ Linux x86_64
was:
RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1
Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1
Mojarra 2.1.7-jbossorg-1
JBoss AS 7.1.1.Final
OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux
Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64
> Switchable panels do not work after rerendering whole page
> ----------------------------------------------------------
>
> Key: RF-12131
> URL: https://issues.jboss.org/browse/RF-12131
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1
> Environment: RichFaces 4.5.0-SNAPSHOT
> Metamer 4.5.0-SNAPSHOT
> Mojarra 2.2.6/2.2.7
> Apache Tomcat 7.0.54, WildFly 8.1.0.Final
> OpenJDK Runtime Environment 1.8.0_05-b13 @ Linux
> Firefox 30.0 @ Linux x86_64
> Reporter: Pavol Pitonak
> Fix For: 5-Tracking
>
>
> # deploy Metamer and open one of these pages:
> ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.x...
> ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simpl...
> # switch/collapse panel
> # verify that the panel was switched
> # click "Full Page Refresh" button (3th button in page header)
> # verify that the panel is still switched
> result:
> after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded)
> this error appears in following templates:
> * a4jRepeat
> * richCollapsibleSubTable
> * richDataGrid
> * richDataTable
> * richExtendedDataTable
> * richList
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13727?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13727:
-------------------------------
Description:
# deploy Metamer and open one of these pages:
## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.x...
## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simpl...
# switch/collapse panel
# verify that the panel was switched
# click "Full Page Refresh" button (3th button in page header)
# verify that the panel is still switched
result:
* after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded)
* it works in other templates
* seems to be JSF 2.2 issue
was:
# deploy Metamer and open one of these pages:
## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.x...
## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simpl...
# switch/collapse panel
# verify that the panel was switched
# click "Full Page Refresh" button (3th button in page header)
# verify that the panel is still switched
result:
after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded)
this error appears in following templates:
* a4jRepeat
* richCollapsibleSubTable
* richDataGrid
* richDataTable
* richExtendedDataTable
* richList
> Switchable panels do not work after rerendering whole page
> ----------------------------------------------------------
>
> Key: RF-13727
> URL: https://issues.jboss.org/browse/RF-13727
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.5.0.Alpha3
> Environment: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1
> Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1
> Mojarra 2.1.7-jbossorg-1
> JBoss AS 7.1.1.Final
> OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux
> Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64
> Reporter: Pavol Pitonak
> Fix For: 5-Tracking
>
>
> # deploy Metamer and open one of these pages:
> ## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.x...
> ## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simpl...
> # switch/collapse panel
> # verify that the panel was switched
> # click "Full Page Refresh" button (3th button in page header)
> # verify that the panel is still switched
> result:
> * after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded)
> * it works in other templates
> * seems to be JSF 2.2 issue
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13727) Switchable panels do not work after rerendering whole page
by Pavol Pitonak (JIRA)
Pavol Pitonak created RF-13727:
----------------------------------
Summary: Switchable panels do not work after rerendering whole page
Key: RF-13727
URL: https://issues.jboss.org/browse/RF-13727
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: component-panels-layout-themes
Affects Versions: 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1
Environment: RichFaces 4.1.0.Final, 4.2.0.Final, 4.2.1.CR1
Metamer 4.2.0.20120217-Final, 4.2.1.20120330-CR1
Mojarra 2.1.7-jbossorg-1
JBoss AS 7.1.1.Final
OpenJDK Runtime Environment 1.6.0_24-b24 @ Linux
Chrome 18.0.1025.142 @ Linux i686, Firefox 11.0 @ Linux x86_64
Reporter: Pavol Pitonak
Fix For: 5-Tracking
# deploy Metamer and open one of these pages:
## http://localhost:8080/metamer/faces/components/richAccordionItem/simple.x...
## http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simpl...
# switch/collapse panel
# verify that the panel was switched
# click "Full Page Refresh" button (3th button in page header)
# verify that the panel is still switched
result:
after full page refresh, the panel loses its state (i.e. accordion shows item3, collapsible panel is expanded)
this error appears in following templates:
* a4jRepeat
* richCollapsibleSubTable
* richDataGrid
* richDataTable
* richExtendedDataTable
* richList
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-11568) Collapsible panel: toggleListener doesn't work inside iteration components
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-11568?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-11568:
------------------------------------
It works on EAP 6.2, EAP 6.3 (both JSF 2.1.x) and Tomcat 7 (JSF 2.2.7) but fails on WildFly 8.1.0.Final (JSF 2.2.6) and Tomcat 7 (JSF 2.2.6).
> Collapsible panel: toggleListener doesn't work inside iteration components
> --------------------------------------------------------------------------
>
> Key: RF-11568
> URL: https://issues.jboss.org/browse/RF-11568
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.1.0.Milestone3
> Environment: RichFaces 4.1.0-SNAPSHOT
> Metamer 4.1.0-SNAPSHOT r.22819
> JBoss Web 7.0.2.Final (Mojarra 2.1.3)
> OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux
> Chrome 14.0.835.202 @ Linux i686, Firefox 7.0.1
> Reporter: Pavol Pitonak
> Labels: ci_issue
> Fix For: 5-Future
>
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richCollapsiblePanel/simpl...
> # collapse the panel and verify that string "* panel collapsed" appeared in the page header
> # expand the panel and verify that string "* panel expanded" appeared in the page header
> # open the same page in iteration component (e.g. richList)
> # collapse the panel and verify that string "* panel collapsed" appeared in the page header
> # expand the panel and verify that string "* panel expanded" appeared in the page header
> result:
> listener is called only for collapsed panel, not for expanded panel
> the component behaves wrong only in following templates:
> * a4jRepeat
> * richCollapsibleSubTable
> * richDataGrid
> * richDataTable
> * richExtendedDataTable
> * richList
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13690) DataTable in uiRepeat - scrolling in table makes columns unsorted again
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13690?page=com.atlassian.jira.plugin.s... ]
Michal Petrov commented on RF-13690:
------------------------------------
What we need to happen is for the {{setIndex()}} method to execute during RestoreViewPhase.
This is what's happening in {{FaceletPartialStateManagementStrategy.restoreView()}}:
{code}
Set<VisitHint> hints = EnumSet.of(VisitHint.SKIP_ITERATION, VisitHint.EXECUTE_LIFECYCLE);
VisitContext visitContext = VisitContext.createVisitContext(context, null, hints);
viewRoot.visitTree(visitContext, new VisitCallback() {
…
});
{code}
The {{VisitHint.SKIP_ITERATION}} is what prevents setIndex from executing.
We can intercept the creation of the visitContext in our {{ExtendedVisitContextFactory.getVisitContext()}} but I do not know if that is of any use.
> DataTable in uiRepeat - scrolling in table makes columns unsorted again
> -----------------------------------------------------------------------
>
> Key: RF-13690
> URL: https://issues.jboss.org/browse/RF-13690
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.5.0.Alpha3
> Environment: WildFly 8.1.
> Reporter: Juraj Húska
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> When {{DataTable}} is nested in {{uiRepeat}}, then scrolling over the table with {{dataScroller}} makes sorting according to some column broken - the columns are unsorted.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13568) IllegalArgumentException for PushResource.jsf
by Martin Tomasek (JIRA)
[ https://issues.jboss.org/browse/RF-13568?page=com.atlassian.jira.plugin.s... ]
Martin Tomasek commented on RF-13568:
-------------------------------------
[~juergen.zimmermann] could you please provide steps to reproduce this issue?
> IllegalArgumentException for PushResource.jsf
> ---------------------------------------------
>
> Key: RF-13568
> URL: https://issues.jboss.org/browse/RF-13568
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha3
> Environment: WildFly snapshot with Undertow 1.0.1
> Reporter: Juergen Zimmermann
> Assignee: Martin Tomasek
>
> Im using the latest WildFly snapshot containing Undertow 1.0.1. I'm getting tons of stacktraces like the following:
> {code}
> [io.undertow.request] UT005023: Exception handling request to /shop/rfRes/org.richfaces.ui.ajax.push.PushResource.jsf: java.lang.IllegalArgumentException: pushTopic request parameter must be present
> at org.richfaces.ui.ajax.push.PushResource.encode(PushResource.java:87) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:187) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-5.0.0.Alpha3.jar:5.0.0.Alpha3]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.1.Final.jar:1.0.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13726) partialViewContext.release triggering assertNotReleased
by mel turphin (JIRA)
[ https://issues.jboss.org/browse/RF-13726?page=com.atlassian.jira.plugin.s... ]
mel turphin updated RF-13726:
-----------------------------
Description:
when the release method is called on
com.sun.faces.context.FacesContextImpl
the first thing that is done is to mark relased=true
released = true;
later on partialViewContext.release can be called
partialViewContext.release();
this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released
ExtendedPartialViewContextImpl
org.richfaces.context.ExtendedPartialViewContext.release()
setInstance(facesContext, null);
facesContext.getAttributes().put(ATTRIBUTE_NAME, instance);
getAttributes --> assertNotReleased();
stack trace:
SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/rf43] threw exception
java.lang.IllegalStateException
at com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:705)
at com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:237)
at org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55)
at org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64)
at org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:424)
at com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:591)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:744)
was:
when the release method is called on
com.sun.faces.context.FacesContextImpl
the first thing that is done is to mark relased=true
released = true;
later on partialViewContext.release can be called
partialViewContext.release();
this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released
ExtendedPartialViewContextImpl
org.richfaces.context.ExtendedPartialViewContext.release()
setInstance(facesContext, null);
facesContext.getAttributes().put(ATTRIBUTE_NAME, instance);
getAttributes --> assertNotReleased();
> partialViewContext.release triggering assertNotReleased
> -------------------------------------------------------
>
> Key: RF-13726
> URL: https://issues.jboss.org/browse/RF-13726
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.7
> Environment: JSF 2.2 Mojarra + Richfaces 4.3
> Eclipse + Tomcat
> Reporter: mel turphin
> Priority: Critical
>
> when the release method is called on
> com.sun.faces.context.FacesContextImpl
> the first thing that is done is to mark relased=true
>
> released = true;
> later on partialViewContext.release can be called
> partialViewContext.release();
> this is following some set of calls that ends with getAttributes and assertNotReleased raising an exception since the context was already marked as released
> ExtendedPartialViewContextImpl
> org.richfaces.context.ExtendedPartialViewContext.release()
> setInstance(facesContext, null);
> facesContext.getAttributes().put(ATTRIBUTE_NAME, instance);
> getAttributes --> assertNotReleased();
> stack trace:
> SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/rf43] threw exception
> java.lang.IllegalStateException
> at com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:705)
> at com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:237)
> at org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55)
> at org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64)
> at org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:424)
> at com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:591)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:744)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-13725:
----------------------------------
I have tried to deploy Showcase with {{weld-servlet-1.1.18.Final.jar}}, and it was successful.
Therefore, upgrading of {{weld-servlet}} dependency would resolve this issue.
> Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration
> ------------------------------------------------------------------------
>
> Key: RF-13725
> URL: https://issues.jboss.org/browse/RF-13725
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: showcase
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
>
> Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown:
> {code}
> SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener
> java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor
> at org.jboss.weld.logging.WeldMessageConveyor.<init>(WeldMessageConveyor.java:61)
> at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27)
> at org.jboss.weld.logging.LoggerFactory.<init>(LoggerFactory.java:37)
> at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51)
> at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:124)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36)
> at org.jboss.weld.environment.servlet.Listener.<init>(Listener.java:70)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
> at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083)
> at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-13725:
----------------------------------
Metamer *can* be deployed on Tomcat 7, and it is because it uses different Weld version.
Showcase uses Weld dependency which brings {{weld-servlet-1.1.4.Final.jar}}.
Metamer works with {{weld-servlet-1.1.18.Final.jar}}.
> Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration
> ------------------------------------------------------------------------
>
> Key: RF-13725
> URL: https://issues.jboss.org/browse/RF-13725
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: showcase
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
>
> Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown:
> {code}
> SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener
> java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor
> at org.jboss.weld.logging.WeldMessageConveyor.<init>(WeldMessageConveyor.java:61)
> at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27)
> at org.jboss.weld.logging.LoggerFactory.<init>(LoggerFactory.java:37)
> at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51)
> at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:124)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36)
> at org.jboss.weld.environment.servlet.Listener.<init>(Listener.java:70)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
> at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083)
> at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.s... ]
Juraj Húska updated RF-13725:
-----------------------------
Summary: Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration (was: Showcase can not be deployed on Tomcat 7 due to IllegalAccessException)
> Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration
> ------------------------------------------------------------------------
>
> Key: RF-13725
> URL: https://issues.jboss.org/browse/RF-13725
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: showcase
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
>
> Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown:
> {code}
> SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener
> java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor
> at org.jboss.weld.logging.WeldMessageConveyor.<init>(WeldMessageConveyor.java:61)
> at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27)
> at org.jboss.weld.logging.LoggerFactory.<init>(LoggerFactory.java:37)
> at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51)
> at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:124)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36)
> at org.jboss.weld.environment.servlet.Listener.<init>(Listener.java:70)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
> at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083)
> at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months