[JBoss JIRA] (WFLY-2200) NoSuchElementException after upgrade from Beta13 to Beta14
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2200:
------------------------------
Fix Version/s: 8.0.0.Beta1
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
> Key: WFLY-2200
> URL: https://issues.jboss.org/browse/WFLY-2200
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Beta1
>
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-2200) NoSuchElementException after upgrade from Beta13 to Beta14
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2200:
------------------------------
Affects Version/s: 8.0.0.Beta1
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
> Key: WFLY-2200
> URL: https://issues.jboss.org/browse/WFLY-2200
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-2201) Server-side XTS handlers not added if @WebService#portName is missing
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-2201?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris moved JBTM-1940 to WFLY-2201:
---------------------------------------------
Project: WildFly (was: JBoss Transaction Manager)
Key: WFLY-2201 (was: JBTM-1940)
Component/s: XTS
(was: XTS)
(was: TXFramework)
Security: (was: Public)
Fix Version/s: 8.0.0.Beta1
(was: 5.0.0.Final)
> Server-side XTS handlers not added if @WebService#portName is missing
> ---------------------------------------------------------------------
>
> Key: WFLY-2201
> URL: https://issues.jboss.org/browse/WFLY-2201
> Project: WildFly
> Issue Type: Bug
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 8.0.0.Beta1
>
>
> To reproduce, remove portName or targetNameSpace attributes from org.jboss.narayana.compensations.functional.distributed.DistributedTest in the TXFramework suite. You will see that the test fails with:
> {code}
> "MustUnderstand headers: [{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CoordinationContext] are not understood"
> {code}
> The problem is that the Endpoint is not recognised, by the XTS subsytem, as having a valid @WebService annotation if these attributes are missing. In reality they are optional and an application should be allowed to leave them off. However, these attribute values are used by the XTS subsytem, so we would need to find a way of using the defaults if they are missing from the annotation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-2200) NoSuchElementException after upgrade from Beta13 to Beta14
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created WFLY-2200:
----------------------------------------
Summary: NoSuchElementException after upgrade from Beta13 to Beta14
Key: WFLY-2200
URL: https://issues.jboss.org/browse/WFLY-2200
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Juergen Zimmermann
Assignee: Stuart Douglas
I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
{code}
SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-2118) PersistenceException breaks default error page
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-2118:
------------------------------------------
When I change stack-trace-on-error="local-only" to stack-trace-on-error="none" ("disabled" caused an XML parse error), then I get the default error page as expected.
> PersistenceException breaks default error page
> ----------------------------------------------
>
> Key: WFLY-2118
> URL: https://issues.jboss.org/browse/WFLY-2118
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> ... 68 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JASSIST-209) Nested classes read from ClassMemberValue cannot be loaded
by Ben Romberg (JIRA)
[ https://issues.jboss.org/browse/JASSIST-209?page=com.atlassian.jira.plugi... ]
Ben Romberg updated JASSIST-209:
--------------------------------
Description:
I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).
In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).
In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.
I don't see any way to work around the issue without hacking into internal API, as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.
was:
I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).
In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).
In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.
I don't see any way to work around the issue without hacking into internal API (by inheriting from ClassMemberValue within my own package javassist.bytecode.annotation to gain access to the package private fields), as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.
> Nested classes read from ClassMemberValue cannot be loaded
> ----------------------------------------------------------
>
> Key: JASSIST-209
> URL: https://issues.jboss.org/browse/JASSIST-209
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Reporter: Ben Romberg
> Assignee: Shigeru Chiba
>
> I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).
> In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).
> In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.
> I don't see any way to work around the issue without hacking into internal API, as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JASSIST-209) Nested classes read from ClassMemberValue cannot be loaded
by Ben Romberg (JIRA)
[ https://issues.jboss.org/browse/JASSIST-209?page=com.atlassian.jira.plugi... ]
Ben Romberg commented on JASSIST-209:
-------------------------------------
Workaround (hack):
{code}
package javassist.bytecode.annotation;
import javassist.bytecode.Descriptor;
public class ClassMemberValueReader {
public static String readClassMemberValue(ClassMemberValue classMemberValue) {
String v = classMemberValue.cp.getUtf8Info(classMemberValue.valueIndex);
return Descriptor.toClassName(v);
}
}
{code}
> Nested classes read from ClassMemberValue cannot be loaded
> ----------------------------------------------------------
>
> Key: JASSIST-209
> URL: https://issues.jboss.org/browse/JASSIST-209
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Reporter: Ben Romberg
> Assignee: Shigeru Chiba
>
> I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).
> In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).
> In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.
> I don't see any way to work around the issue without hacking into internal API, as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBRULES-3699) Large memory allocation per request in drools-camel-server
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3699?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on JBRULES-3699:
--------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 958387|https://bugzilla.redhat.com/show_bug.cgi?id=958387] from ASSIGNED to MODIFIED
> Large memory allocation per request in drools-camel-server
> ----------------------------------------------------------
>
> Key: JBRULES-3699
> URL: https://issues.jboss.org/browse/JBRULES-3699
> Project: JBRULES
> Issue Type: Quality Risk
> Security Level: Public(Everyone can see)
> Components: drools-camel
> Affects Versions: 5.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mark Proctor
> Attachments: JBoss_Benchmark_Request.xml, numbers.drl
>
>
> In drools-camel-server, memory allocation during request/response message handling is quite larger than actual request/response size.
> For example, with attached numbers.drl and JBoss_Benchmark_Request.xml, one SOAP request results in 45MB+ object allocation while the actual request size is 200KB and the response size is 650KB. They are short-lived objects so wouldn't be a memory leak but affect performance especially under high load.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (JBRULES-3699) Large memory allocation per request in drools-camel-server
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3699?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on JBRULES-3699:
--------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> made a comment on [bug 958387|https://bugzilla.redhat.com/show_bug.cgi?id=958387]
As evidenced by Toshiya the biggest part of this memory occupation is caused by the conversion of InputStreams to Strings. Unfortunately I don't think this is avoidable. Moreover there are many ways to perform this conversion, but as for example reported here:
http://www.journaldev.com/706/how-to-convert-inputstream-to-string-in-java
we are apparently already using the most memory efficient one.
I can't find a way a to improve this issue but any other suggestion is welcome.
> Large memory allocation per request in drools-camel-server
> ----------------------------------------------------------
>
> Key: JBRULES-3699
> URL: https://issues.jboss.org/browse/JBRULES-3699
> Project: JBRULES
> Issue Type: Quality Risk
> Security Level: Public(Everyone can see)
> Components: drools-camel
> Affects Versions: 5.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mark Proctor
> Attachments: JBoss_Benchmark_Request.xml, numbers.drl
>
>
> In drools-camel-server, memory allocation during request/response message handling is quite larger than actual request/response size.
> For example, with attached numbers.drl and JBoss_Benchmark_Request.xml, one SOAP request results in 45MB+ object allocation while the actual request size is 200KB and the response size is 650KB. They are short-lived objects so wouldn't be a memory leak but affect performance especially under high load.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months