[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
by nathan dennis (JIRA)
[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ]
nathan dennis commented on WFLY-1376:
-------------------------------------
Actual I believe the bug which I was seeing was WFLY-2688. It has also been fixed in trunk.
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
> Key: WFLY-1376
> URL: https://issues.jboss.org/browse/WFLY-1376
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
> <error-page>
> <error-code>404</error-code>
> <location>/error/pageNotFound.jsf</location>
> </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
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, 11 months
[JBoss JIRA] (WFLY-2856) Classloader leak caused by xnio-file-watcher
by Harald Wellmann (JIRA)
Harald Wellmann created WFLY-2856:
-------------------------------------
Summary: Classloader leak caused by xnio-file-watcher
Key: WFLY-2856
URL: https://issues.jboss.org/browse/WFLY-2856
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.CR1
Reporter: Harald Wellmann
After redeploying my application from Eclipe/JBoss Tools via "Full Publish" a couple of times in a row, I'm getting a PermGen OutOfMemoryError.
In jvisualvm, I can see multiple threads named xnio-file-watcher, each having its context classloader set to the module classloader of my (undeployed) application. Probably the thread should be stopped (but isn't) when the application is undeployed.
This leak only occurs with unzipped deployments.
I also see these extra threads independent of Eclipse when copying an unzipped deployment to {{standalone/deployments}} and adding/removing the dodeploy/deployed marker files.
--
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, 11 months
[JBoss JIRA] (WFLY-2611) Unify JSF action listener and CDI integration
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Description:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/actionlist.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
was:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
> Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/actionlist.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>
--
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, 11 months
[JBoss JIRA] (WFLY-1380) Undertow: Error initialize the net.jawr.web.servlet.JawrServlet with undertow
by Laszlo Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-1380?page=com.atlassian.jira.plugin.... ]
Laszlo Varga commented on WFLY-1380:
------------------------------------
I have the same error message, but not with Liferay.
Do you use drw spring integration? In case yes, this might cause the problem.
> Undertow: Error initialize the net.jawr.web.servlet.JawrServlet with undertow
> -----------------------------------------------------------------------------
>
> Key: WFLY-1380
> URL: https://issues.jboss.org/browse/WFLY-1380
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Igor Shulika
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> I'm deploying a OSGi WAB file on the latest WildFly 8.0.0.Alpha2-SNAPSHOT server. Can not initialize the JavascriptServlet from JAWR Bundle. Note: When I used the <extension module="org.jboss.as.web"/> insted of <extension module="org.wildfly.extension.undertow"/> it works.
> Please see error trace below.
> Thanks!
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Jawr servlet with name JavascriptServlet failed to initialize properly.
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Cause:
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Illegal char <:> at index 3: dwr:WebServiceDocService: java.nio.file.InvalidPathException: Illegal char <:> at index 3: dwr:WebServiceDocService
> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255) [rt.jar:1.7.0_21]
> at sun.nio.fs.AbstractPath.resolve(AbstractPath.java:53) [rt.jar:1.7.0_21]
> at io.undertow.server.handlers.resource.FileResourceManager.getResource(FileResourceManager.java:57) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.resource.CachingResourceManager.getResource(CachingResourceManager.java:68) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.ServletContextImpl.getResourceAsStream(ServletContextImpl.java:175) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at net.jawr.web.resource.handler.reader.ServletContextResourceReader.getResource(ServletContextResourceReader.java:70) [ServletContextResourceReader.class:]
> at net.jawr.web.resource.handler.reader.ServletContextResourceReaderHandler.getResource(ServletContextResourceReaderHandler.java:192) [ServletContextResourceReaderHandler.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostprocessBundle(ResourceBundlesHandlerImpl.java:892) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostProcessBundle(ResourceBundlesHandlerImpl.java:835) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndStoreBundle(ResourceBundlesHandlerImpl.java:766) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.initAllBundles(ResourceBundlesHandlerImpl.java:542) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.CachedResourceBundlesHandler.initAllBundles(CachedResourceBundlesHandler.java:126) [CachedResourceBundlesHandler.class:]
> at net.jawr.web.resource.bundle.factory.BundlesHandlerFactory.buildResourceBundlesHandler(BundlesHandlerFactory.java:233) [BundlesHandlerFactory.class:]
> at net.jawr.web.resource.bundle.factory.PropertiesBasedBundlesHandlerFactory.buildResourceBundlesHandler(PropertiesBasedBundlesHandlerFactory.java:204) [PropertiesBasedBundlesHandlerFactory.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initializeJawrConfig(JawrRequestHandler.java:349) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initRequestHandler(JawrRequestHandler.java:262) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.<init>(JawrRequestHandler.java:184) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrServlet.init(JawrServlet.java:56) [JawrServlet.class:]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244) [jboss-servlet-api_3.1_spec-1.0.0.Alpha1.jar:1.0.0.Alpha1]
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:145) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:62) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:599) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:77)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
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, 11 months
[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1376:
------------------------------------------
I don't see this issue with Undertow 1.0.0.CR1 in the latest WildFly snapshot
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
> Key: WFLY-1376
> URL: https://issues.jboss.org/browse/WFLY-1376
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
> <error-page>
> <error-code>404</error-code>
> <location>/error/pageNotFound.jsf</location>
> </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
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, 11 months
[JBoss JIRA] (DROOLS-410) Drools invokes superclass static method
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-410:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1057550|https://bugzilla.redhat.com/show_bug.cgi?id=1057550] from ASSIGNED to MODIFIED
> Drools invokes superclass static method
> ---------------------------------------
>
> Key: DROOLS-410
> URL: https://issues.jboss.org/browse/DROOLS-410
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Michaël Mathieu
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta1
>
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
> private String ref;
> protected ARef(String ref) {
> this.ref = ref;
> }
> public static ARef valueOf(String ref) {
> System.out.println("ARef> " + ref);
> return new ARef(ref);
> }
> @Override
> public String toString() {
> return ref;
> }
> @Override
> public int hashCode() {
> final int prime = 31;
> int result = 1;
> result = prime * result + ((ref == null) ? 0 : ref.hashCode());
> return result;
> }
> @Override
> public boolean equals(Object obj) {
> if (this == obj) return true;
> if (obj == null) return false;
> if (getClass() != obj.getClass()) return false;
> ARef other = (ARef) obj;
> if (ref == null) {
> if (other.ref != null) return false;
> } else if (!ref.equals(other.ref)) return false;
> return true;
> }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
> private BRef(String ref) {
> super(ref);
> }
> public static BRef valueOf(String ref) {
> System.out.println("BRef> " + ref);
> return new BRef(ref);
> }
> }
> {code}
> {code}
> package test;
> public class Criteria {
> private BRef ref;
> private boolean ok = false;
> public Criteria(BRef ref) {
> this.ref = ref;
> }
> public BRef getRef() {
> return ref;
> }
> public boolean isOk() {
> return ok;
> }
> public void setOk() {
> this.ok = true;
> }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
> private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
> + " criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + " criteria.setOk();\r\n" + "end";
> public static void main(String[] args) {
> System.out.println(DRL);
> try {
> PackageBuilder builder = new PackageBuilder();
> builder.addPackageFromDrl(new StringReader(DRL));
> Package pkg = builder.getPackage();
> RuleBase ruleBase = RuleBaseFactory.newRuleBase();
> ruleBase.addPackage(pkg);
> for (int i = 0; i < 1000; i++) {
> Criteria criteria = new Criteria(BRef.valueOf("toto"));
> StatelessSession session = ruleBase.newStatelessSession();
> session.execute(criteria);
> System.out.println("[" + i + "] " + criteria.isOk());
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
> criteria:Criteria(ref == BRef.valueOf("toto"))
> then
> criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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, 11 months
[JBoss JIRA] (JBLOGGING-95) Add Logger/LoggerProvider to support new Log4j 2 to improve performance
by Nicholas Williams (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-95?page=com.atlassian.jira.plug... ]
Nicholas Williams edited comment on JBLOGGING-95 at 2/2/14 2:46 PM:
--------------------------------------------------------------------
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. I'd at least like to get 3.2.0.Beta1 rolling in the next week or two. There haven't been many changes at all to this version. :-)
Is there anything I can do to help move things along?
was (Author: beamerblvd):
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. :-)
Is there anything I can do to help move things along?
> Add Logger/LoggerProvider to support new Log4j 2 to improve performance
> -----------------------------------------------------------------------
>
> Key: JBLOGGING-95
> URL: https://issues.jboss.org/browse/JBLOGGING-95
> Project: JBoss Logging
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: jboss-logging-spi
> Affects Versions: 3.2.0.Beta1
> Reporter: Nicholas Williams
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 3.2.0.Beta1
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> The new Log4j 2 project will be released soon. It has major improvements over Log4j and Logback. Currently, JBoss Logging can log to Log4j 2 indirectly by way of SLF4J (if the log4j-slf4j artifact is on the classpath) or the Log4j 1.2 API (if the log4j-1.2-api artifact is on the classpath and when JBLOGGING-94 is fixed). However, performance would be improved if JBoss Logging could log directly to the Log4j 2 API.
> Looks like we just need a new {{Log4j2Logger}} and {{Log4j2LoggerProvider}}. I'll try to submit a pull request in the next few weeks. I'm currently working on other tasks in Log4j 2.
--
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, 11 months