[JBoss JIRA] (DROOLS-3651) [DMN Designer] Table input clause generation in a decision service
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3651?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3651:
----------------------------------------
[~jomarko] I followed your steps but was unable to reproduce.
I also tried creating the same diagram from scratch in different ways:
*_Add DS and Ds first_*
# Add Decision Service to graph
# Add Decision 1 to graph
# Add Decision 2 to graph
# Add InputData to graph
# Connect ID and D1 and D2
# Drag D1 into DS
# Set both D1 and D2 to Decision Tables
# InputClauses were correct
*_Add DS and one D directly into DS_*
# Add Decision Service to graph
# Add Decision 1 to DS
# Add Decision 2 to graph
# Add InputData
# Connect ID and D1 and D2
# Set both D1 and D2 to Decision Tables
# InputClauses were correct
If there's some other way to replicate please advise!
> [DMN Designer] Table input clause generation in a decision service
> ------------------------------------------------------------------
>
> Key: DROOLS-3651
> URL: https://issues.jboss.org/browse/DROOLS-3651
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: violation.dmn
>
>
> The dmn designer has a feature of autogeneration *input clauses* for a *decision table*, if this one is connected with *input nodes*, however this feature doesn't work if a *decision node* is placed inside a *decision service* node.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Paul Ferraro reopened WFLY-11489:
---------------------------------
Not sure why this was set to resolved, as PR was not yet merged.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 16.0.0.Beta1
>
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11639) mod_cluster and HTTP2 enabled (the default) not working
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11639?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-11639:
---------------------------------------
Great find [~aspan]. Requires Undertow upgrade 2.0.18.Final.
> mod_cluster and HTTP2 enabled (the default) not working
> -------------------------------------------------------
>
> Key: WFLY-11639
> URL: https://issues.jboss.org/browse/WFLY-11639
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 15.0.1.Final
> Environment: Mac OS X 10.14.3
> Tested on both
> AdoptOpenJDK 1.8.0_202-b08
> AdoptOpenJDK 11.0.1+13
> Reporter: Andreas Asplund
> Assignee: Radoslav Husar
> Priority: Major
>
> mod cluster and HTTP2 enabled (the default) when using listener default in the modcluster subsystem. When turning off HTTP2 the clustering starts working again. Nothing is printed in the logs by default so DEBUG logging has to be turned on for undertow.
> Steps to reproduce:
> {code}
> unzip wildfly-dist-15.0.1.Final.zip
> # Terminal 1
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-load-balancer.xml -Djava.net.preferIPv4Stack=true -b 127.0.0.1 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 2
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=100 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 3
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=200 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 4
> cd wildfly-15.0.1.Final/bin/
> ./jboss-cli.sh -c
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> connect localhost:10090
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> /subsystem=modcluster/proxy=default:write-attribute(name=listener,value=default)
> reload
> connect localhost:10190
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> /subsystem=modcluster/proxy=default:write-attribute(name=listener,value=default)
> reload
> {code}
> The following can be seen in the logs on the proxied servers:
> {code}
> 16:30:23,409 TRACE [io.undertow.request] (default I/O-7) Opened connection with /127.0.0.1:50002
> 16:30:23,410 DEBUG [io.undertow.request.error-response] (default I/O-7) Setting error code 500 for exchange HttpServerExchange{ OPTIONS * request {HTTP2-Settings=[AAEAABAAAAIAAAABAAQAAP//AAUAAEAA], Connection=[Upgrade, HTTP2-Settings], Upgrade=[h2c], User-Agent=[mod_cluster ping], Host=[127.0.0.1]} response {}}: java.lang.RuntimeException
> at io.undertow.server.HttpServerExchange.setStatusCode(HttpServerExchange.java:1410)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:393)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 16:30:23,410 DEBUG [io.undertow.request.io] (default I/O-7) UT005013: An IOException occurred: java.io.IOException: Invalid base64 character encountered: 47
> at io.undertow.util.FlexBase64$Decoder.nextByte(FlexBase64.java:1048)
> at io.undertow.util.FlexBase64$Decoder.nextByte(FlexBase64.java:1015)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1277)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1347)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1413)
> at io.undertow.util.FlexBase64$Decoder.access$500(FlexBase64.java:983)
> at io.undertow.util.FlexBase64.decodeURL(FlexBase64.java:320)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleHttp2Upgrade(Http2UpgradeHandler.java:158)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleUpgradeBody(Http2UpgradeHandler.java:107)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:97)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 16:30:23,411 TRACE [io.undertow.server.HttpServerExchange] (default I/O-7) Starting to write response for HttpServerExchange{ OPTIONS * request {HTTP2-Settings=[AAEAABAAAAIAAAABAAQAAP//AAUAAEAA], Connection=[Upgrade, HTTP2-Settings], Upgrade=[h2c], User-Agent=[mod_cluster ping], Host=[127.0.0.1]} response {Connection=[keep-alive], Content-Length=[0], Date=[Wed, 23 Jan 2019 15:30:23 GMT]}}
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11639) mod_cluster and HTTP2 enabled (the default) not working
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11639?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-11639:
----------------------------------
Summary: mod_cluster and HTTP2 enabled (the default) not working (was: mod cluster and HTTP2 enabled (the default) not working)
> mod_cluster and HTTP2 enabled (the default) not working
> -------------------------------------------------------
>
> Key: WFLY-11639
> URL: https://issues.jboss.org/browse/WFLY-11639
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 15.0.1.Final
> Environment: Mac OS X 10.14.3
> Tested on both
> AdoptOpenJDK 1.8.0_202-b08
> AdoptOpenJDK 11.0.1+13
> Reporter: Andreas Asplund
> Assignee: Radoslav Husar
> Priority: Major
>
> mod cluster and HTTP2 enabled (the default) when using listener default in the modcluster subsystem. When turning off HTTP2 the clustering starts working again. Nothing is printed in the logs by default so DEBUG logging has to be turned on for undertow.
> Steps to reproduce:
> {code}
> unzip wildfly-dist-15.0.1.Final.zip
> # Terminal 1
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-load-balancer.xml -Djava.net.preferIPv4Stack=true -b 127.0.0.1 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 2
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=100 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 3
> cd wildfly-15.0.1.Final/bin/
> ./standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=200 -Djboss.modcluster.multicast.address=230.0.0.4
> # Terminal 4
> cd wildfly-15.0.1.Final/bin/
> ./jboss-cli.sh -c
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> connect localhost:10090
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> /subsystem=modcluster/proxy=default:write-attribute(name=listener,value=default)
> reload
> connect localhost:10190
> /subsystem=logging/logger=io.undertow:add(level=ALL)
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> /subsystem=modcluster/proxy=default:write-attribute(name=listener,value=default)
> reload
> {code}
> The following can be seen in the logs on the proxied servers:
> {code}
> 16:30:23,409 TRACE [io.undertow.request] (default I/O-7) Opened connection with /127.0.0.1:50002
> 16:30:23,410 DEBUG [io.undertow.request.error-response] (default I/O-7) Setting error code 500 for exchange HttpServerExchange{ OPTIONS * request {HTTP2-Settings=[AAEAABAAAAIAAAABAAQAAP//AAUAAEAA], Connection=[Upgrade, HTTP2-Settings], Upgrade=[h2c], User-Agent=[mod_cluster ping], Host=[127.0.0.1]} response {}}: java.lang.RuntimeException
> at io.undertow.server.HttpServerExchange.setStatusCode(HttpServerExchange.java:1410)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:393)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 16:30:23,410 DEBUG [io.undertow.request.io] (default I/O-7) UT005013: An IOException occurred: java.io.IOException: Invalid base64 character encountered: 47
> at io.undertow.util.FlexBase64$Decoder.nextByte(FlexBase64.java:1048)
> at io.undertow.util.FlexBase64$Decoder.nextByte(FlexBase64.java:1015)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1277)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1347)
> at io.undertow.util.FlexBase64$Decoder.decode(FlexBase64.java:1413)
> at io.undertow.util.FlexBase64$Decoder.access$500(FlexBase64.java:983)
> at io.undertow.util.FlexBase64.decodeURL(FlexBase64.java:320)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleHttp2Upgrade(Http2UpgradeHandler.java:158)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleUpgradeBody(Http2UpgradeHandler.java:107)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:97)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 16:30:23,411 TRACE [io.undertow.server.HttpServerExchange] (default I/O-7) Starting to write response for HttpServerExchange{ OPTIONS * request {HTTP2-Settings=[AAEAABAAAAIAAAABAAQAAP//AAUAAEAA], Connection=[Upgrade, HTTP2-Settings], Upgrade=[h2c], User-Agent=[mod_cluster ping], Host=[127.0.0.1]} response {Connection=[keep-alive], Content-Length=[0], Date=[Wed, 23 Jan 2019 15:30:23 GMT]}}
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3651) [DMN Designer] Table input clause generation in a decision service
by Jozef Marko (Jira)
Jozef Marko created DROOLS-3651:
-----------------------------------
Summary: [DMN Designer] Table input clause generation in a decision service
Key: DROOLS-3651
URL: https://issues.jboss.org/browse/DROOLS-3651
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.18.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: violation.dmn
The dmn designer has a feature of autogeneration *input clauses* for a *decision table*, if this one is connected with *input nodes*, however this feature doesn't work if a *decision node* is placed inside a *decision service* node.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11514) NPE in ServletContextImpl#getContextPath on undeploy
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11514?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-11514:
---------------------------------------
Assigning to new component lead :-)
> NPE in ServletContextImpl#getContextPath on undeploy
> ----------------------------------------------------
>
> Key: WFLY-11514
> URL: https://issues.jboss.org/browse/WFLY-11514
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 15.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Flavia Rainone
> Priority: Major
>
> Reproduced intermittently with {{org.jboss.as.test.clustering.cluster.web.DistributableTestCase}} (as reported on WFLY-11403).
> {noformat}
> 15:22:51,695 ERROR [io.undertow.request] (default task-2) UT005071: Undertow request failed HttpServerExchange{ GET /DistributableTestCase/simple request {Connection=[Keep-Alive], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONID=4Djfh5OorcTQsOL7EDiIJrFN1zWdBXx46cg5BdXu.node-1], User-Agent=[Apache-HttpClient/4.5.4 (Java/1.8.0_152)], Host=[[::1]:8080]} response {}}: java.lang.NullPointerException
> at io.undertow.servlet.spec.ServletContextImpl.getContextPath(ServletContextImpl.java:210)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getContextPath(HttpServletRequestImpl.java:293)
> at io.undertow.servlet.handlers.ServletDebugPageHandler.handleRequest(ServletDebugPageHandler.java:107)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:332)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11514) NPE in ServletContextImpl#getContextPath on undeploy
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11514?page=com.atlassian.jira.plugin... ]
Radoslav Husar reassigned WFLY-11514:
-------------------------------------
Assignee: Flavia Rainone (was: Stuart Douglas)
> NPE in ServletContextImpl#getContextPath on undeploy
> ----------------------------------------------------
>
> Key: WFLY-11514
> URL: https://issues.jboss.org/browse/WFLY-11514
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 15.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Flavia Rainone
> Priority: Major
>
> Reproduced intermittently with {{org.jboss.as.test.clustering.cluster.web.DistributableTestCase}} (as reported on WFLY-11403).
> {noformat}
> 15:22:51,695 ERROR [io.undertow.request] (default task-2) UT005071: Undertow request failed HttpServerExchange{ GET /DistributableTestCase/simple request {Connection=[Keep-Alive], Accept-Encoding=[gzip,deflate], Cookie=[JSESSIONID=4Djfh5OorcTQsOL7EDiIJrFN1zWdBXx46cg5BdXu.node-1], User-Agent=[Apache-HttpClient/4.5.4 (Java/1.8.0_152)], Host=[[::1]:8080]} response {}}: java.lang.NullPointerException
> at io.undertow.servlet.spec.ServletContextImpl.getContextPath(ServletContextImpl.java:210)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getContextPath(HttpServletRequestImpl.java:293)
> at io.undertow.servlet.handlers.ServletDebugPageHandler.handleRequest(ServletDebugPageHandler.java:107)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:332)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-9622) Eliminate uses of ModelNode.resolve()
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-9622?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9622:
---------------------------------
Component/s: (was: Clustering)
(was: mod_cluster)
Already done for clustering and mod_cluster – removing from the component list.
> Eliminate uses of ModelNode.resolve()
> -------------------------------------
>
> Key: WFLY-9622
> URL: https://issues.jboss.org/browse/WFLY-9622
> Project: WildFly
> Issue Type: Task
> Components: JCA, JMS, JPA / Hibernate, Management
> Reporter: Brian Stansberry
> Priority: Major
>
> Code inspection shows there are 16 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 4 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER.
> Current uses:
> {code}
> Method
> resolve()
> Found usages (16 usages found)
> Production (12 usages found)
> Unclassified usage (12 usages found)
> wildfly-connector (3 usages found)
> org.jboss.as.connector.subsystems.common.pool (2 usages found)
> PoolConfigurationRWHandler.PoolConfigurationWriteHandler (1 usage found)
> revertUpdateToRuntime(OperationContext, ModelNode, String, ModelNode, ModelNode, List<PoolConfiguration>) (1 usage found)
> 126 updatePoolConfigs(handback, parameterName, valueToRestore.resolve());
> PoolStatisticsRuntimeAttributeWriteHandler (1 usage found)
> execute(OperationContext, ModelNode) (1 usage found)
> 58 final ModelNode resolvedValue = newValue.resolve();
> org.jboss.as.connector.subsystems.datasources (1 usage found)
> Constants (1 usage found)
> 297 validateParameter(parameterName, value.resolve());
> wildfly-jpa (4 usages found)
> org.jboss.as.jpa.management (1 usage found)
> ManagementResourceDefinition (1 usage found)
> registerAttributes(ManagementResourceRegistration) (1 usage found)
> 154 final ModelNode value = operation.get(ModelDescriptionConstants.VALUE).resolve();
> org.jboss.as.jpa.subsystem (3 usages found)
> JPASubSystemAdd (3 usages found)
> performBoottime(OperationContext, ModelNode, ModelNode) (3 usages found)
> 78 runtimeValidator.validate(operation.resolve());
> 125 final String dataSourceName = defaultDSNode.resolve().asString();
> 131 ExtendedPersistenceInheritance.valueOf(defaultExtendedPersistenceInheritanceNode.resolve().asString());
> wildfly-messaging-activemq (4 usages found)
> org.wildfly.extension.messaging.activemq.deployment (4 usages found)
> MessagingXmlInstallDeploymentUnitProcessor (4 usages found)
> deploy(DeploymentPhaseContext) (4 usages found)
> 76 final ModelNode entries = topic.getDestination().resolve().get(CommonAttributes.DESTINATION_ENTRIES.getName());
> 97 final ModelNode entries = destination.resolve().get(CommonAttributes.DESTINATION_ENTRIES.getName());
> 100 final String selector = destination.hasDefined(SELECTOR.getName()) ? destination.get(SELECTOR.getName()).resolve().asString() : null;
> 101 final boolean durable = destination.hasDefined(DURABLE.getName()) ? destination.get(DURABLE.getName()).resolve().asBoolean() : false;
> wildfly-mod_cluster-extension (1 usage found)
> org.wildfly.extension.mod_cluster (1 usage found)
> ProxyListValidator (1 usage found)
> validateResolvedParameter(String, ModelNode) (1 usage found)
> 59 validateParameter(parameterName, value.resolve());
> Test (4 usages found)
> Unclassified usage (4 usages found)
> wildfly-clustering-jgroups-extension (4 usages found)
> org.jboss.as.clustering.jgroups.subsystem (4 usages found)
> OperationsTestCase (4 usages found)
> testSubsystemReadWriteOperations() (1 usage found)
> 52 Assert.assertEquals("ee", result.get(RESULT).resolve().asString());
> testTransportReadWriteOperation() (1 usage found)
> 75 Assert.assertEquals("rack1", result.get(RESULT).resolve().asString());
> testTransportPropertyReadWriteOperation() (1 usage found)
> 114 Assert.assertEquals("true", result.get(RESULT).resolve().asString());
> testProtocolPropertyReadWriteOperation() (1 usage found)
> 195 Assert.assertEquals("value", result.get(RESULT).resolve().asString());
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months