[JBoss JIRA] (WFLY-9370) Fix failing SingletonTunnelTestCase(ASYNC-tunnel)#testSingletonService
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9370?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-9370 at 9/25/17 8:59 AM:
---------------------------------------------------------------
The problems/changes:
* old service name jboss.clustering.group.default is org.wildfly.clustering.default-group
* no singleton cache container
* transport protocol (TUNNEL) requires socket-binding
* stack should be based off UDP (or fix XSLT to copy over also multicast protocols)
was (Author: rhusar):
The problems/changes:
* old service name jboss.clustering.group.default is org.wildfly.clustering.default-group
* no singleton cache container
* transport protocol (TUNNEL) requires socket-binding
* stack should be based off UDP
> Fix failing SingletonTunnelTestCase(ASYNC-tunnel)#testSingletonService
> -----------------------------------------------------------------------
>
> Key: WFLY-9370
> URL: https://issues.jboss.org/browse/WFLY-9370
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be moved to the right location and renamed (i.e. drop tunnel since that has nothing to do with what it is testing).
> {noformat}
> [0m[31m04:44:19,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "singleton.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.clustering.group.default"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.test1.service.default is missing [jboss.clustering.group.default]",
> "jboss.test2.service.default is missing [jboss.clustering.group.default]"
> ],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.discovery.\"singleton.war\"",
> "jboss.deployment.unit.\"singleton.war\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"singleton.war\".WeldStartService",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.JndiBindingsService",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.START",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.VIEW.\"org.jboss.as.test.clustering.TopologyChangeListener\".REMOTE",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInterceptorBindingsService",
> "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".deploymentCompleteService",
> "jboss.deployment.unit.\"singleton.war\".ejb3.client-context.registration-service",
> "jboss.deployment.unit.\"singleton.war\".jndiDependencyService",
> "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformation",
> "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.app.singleton.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.app.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.naming.context.java.global.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.global.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.naming.context.java.module.singleton.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.module.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.undertow.deployment.default-server.default-host./singleton",
> "jboss.undertow.deployment.default-server.default-host./singleton.UndertowDeploymentInfoService"
> ],
> "Services that may be the cause:" => [
> "jboss.clustering.group.default",
> "org.wildfly.network.socket-binding.undefined"
> ]
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9370) Fix failing SingletonTunnelTestCase(ASYNC-tunnel)#testSingletonService
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9370?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9370:
--------------------------------------
The problems/changes:
* old service name jboss.clustering.group.default is org.wildfly.clustering.default-group
* no singleton cache container
* transport protocol (TUNNEL) requires socket-binding
* stack should be based off UDP
> Fix failing SingletonTunnelTestCase(ASYNC-tunnel)#testSingletonService
> -----------------------------------------------------------------------
>
> Key: WFLY-9370
> URL: https://issues.jboss.org/browse/WFLY-9370
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be moved to the right location and renamed (i.e. drop tunnel since that has nothing to do with what it is testing).
> {noformat}
> [0m[31m04:44:19,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "singleton.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.clustering.group.default"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.test1.service.default is missing [jboss.clustering.group.default]",
> "jboss.test2.service.default is missing [jboss.clustering.group.default]"
> ],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.discovery.\"singleton.war\"",
> "jboss.deployment.unit.\"singleton.war\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"singleton.war\".WeldStartService",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.JndiBindingsService",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.START",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.VIEW.\"org.jboss.as.test.clustering.TopologyChangeListener\".REMOTE",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInterceptorBindingsService",
> "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START",
> "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator",
> "jboss.deployment.unit.\"singleton.war\".deploymentCompleteService",
> "jboss.deployment.unit.\"singleton.war\".ejb3.client-context.registration-service",
> "jboss.deployment.unit.\"singleton.war\".jndiDependencyService",
> "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformation",
> "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.app.singleton.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.app.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.naming.context.java.global.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.global.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.naming.context.java.module.singleton.singleton.TopologyChangeListenerBean",
> "jboss.naming.context.java.module.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"",
> "jboss.undertow.deployment.default-server.default-host./singleton",
> "jboss.undertow.deployment.default-server.default-host./singleton.UndertowDeploymentInfoService"
> ],
> "Services that may be the cause:" => [
> "jboss.clustering.group.default",
> "org.wildfly.network.socket-binding.undefined"
> ]
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (JASSIST-269) javassist.CannotCompileException: by java.lang.LinkageError when Application deployment on Java 8 Server
by vinay kp (JIRA)
vinay kp created JASSIST-269:
--------------------------------
Summary: javassist.CannotCompileException: by java.lang.LinkageError when Application deployment on Java 8 Server
Key: JASSIST-269
URL: https://issues.jboss.org/browse/JASSIST-269
Project: Javassist
Issue Type: Bug
Affects Versions: 3.19.0-GA
Environment: JDK 8 , Java 8
Reporter: vinay kp
Assignee: Shigeru Chiba
Priority: Critical
Attachments: error_logs.txt, java file.txt
With javassit 3.12.0.GA and JDK 1.6 , I can able to deploy .EAR application successfully . After changing to *Java 8 support* with * javassit 3.19.0-GA* , i am getting some_ IllegalStateException: javassist.CannotCompileException: by java.lang.LinkageError_
Please find the attached error log . I tried different scenarios to solve this problem like
* Changing parent class first /last property
* I have added asm , cglib dependency in POM,xml file
I think this is due to class loader issue . Can you please check this ?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ELY-1373) IBM JDK, SPNEGO + FORM; with invalid ticket 200 status code is returned
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1373?page=com.atlassian.jira.plugin.s... ]
Jan Kalina closed ELY-1373.
---------------------------
> IBM JDK, SPNEGO + FORM; with invalid ticket 200 status code is returned
> -----------------------------------------------------------------------
>
> Key: ELY-1373
> URL: https://issues.jboss.org/browse/ELY-1373
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta3
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Given SPNEGO + FORM authentication configuration. And running on IBM java.
> When invalid kerberos ticket is send
> Then status code 200 is returned with http form.
> While on Oracle JDK {{gssContext.isEstablished()}} returns true for invalid client ticket (negotiate with wrong domain JBOSS.COM), so SPNEGO mechanism sends bare challenge after failed authorization, on IBM JDK it returns false immediately, so mechanism fail without sending challenge - to be consistent should be send in both cases.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes
by Martin Stefanko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ]
Martin Stefanko edited comment on WFCORE-3316 at 9/25/17 7:40 AM:
------------------------------------------------------------------
[~jdenise] value validator is not actually checking the allowed values on addition of the attribute, I've already got fix in progress
[~dlofthouse] thanks, in that case it should be remoting subsystem
was (Author: mstefank):
[~jdenise] value validator is not actually checking the allowed values on addition of the attribute, I've already got fix in progress
[~dlofthouse] thanks, in that case it should be remoting subsytem
> Server fails to start after submitting invalid security attributes
> ------------------------------------------------------------------
>
> Key: WFCORE-3316
> URL: https://issues.jboss.org/browse/WFCORE-3316
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 3.0.3.Final
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Critical
>
> Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength)
> Only fix for the configuration is to manually change the XML file directly
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1742) NPE in RuleNEtworkEvaluator after incremental compilation
by Théophane Charbonnier (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1742?page=com.atlassian.jira.plugi... ]
Théophane Charbonnier commented on DROOLS-1742:
-----------------------------------------------
Thank you [~mfusco] for this quick answer,
Indeed you're right, the drl name is very relevant in this issue and my description is not fully extensive (that's why I attached a reproducer).
I've used the internal test class of drools mainly to "minify" the reproducer for this issue, and what you describe is actually the issue I wanted to reproduce.
Thanks a lot for having a look
> NPE in RuleNEtworkEvaluator after incremental compilation
> ---------------------------------------------------------
>
> Key: DROOLS-1742
> URL: https://issues.jboss.org/browse/DROOLS-1742
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.3.0.Final
> Reporter: Théophane Charbonnier
> Assignee: Mario Fusco
> Attachments: drools-path-memory-reproducer.zip
>
>
> Having the following drl files :
> {code:drl}
> package org.hightea.a
> import org.drools.compiler.Message
> import org.drools.compiler.FirstClass
> rule "RG_1"
> when
> $event : Message()
> FirstClass(item1 == $event.message1)
> then
> System.out.println("RG_1");
> end
> {code}
> and
> {code:drl}
> package org.hightea.b
> import org.drools.compiler.Message
> import org.drools.compiler.SecondClass
> rule "RG_2"
> when
> $event: Message()
> SecondClass(item1 == $event.message1)
> then
> System.out.println("RG_2");
> end
> {code}
> We create a module containing the two packages in two drl files and insert a `SecondClass` fact in the WM.
> Then we want to incrementally update to a new module containing only the second DRL.
> At first fireAllrules after update, we encounter a NPE in RuleNetwork evaluator (a Segment memory is not defined in the path memory)
> {code:java}
> java.lang.NullPointerException
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:114)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87)
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067)
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> at org.hightea.IncrementalRemoveRuleTest.testNpeInRuleNetworkEvaluator(IncrementalRemoveRuleTest.java:66)
> {code}
> Note that we don't encounter this issue when the packages names are the same, or if we exchange the order of drl file name in the first module.
> A reproducer is attached with its source code at [https://github.com/hightea/drools-reproducer/tree/path-memory-issue|https...]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1742) NPE in RuleNEtworkEvaluator after incremental compilation
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1742?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1742:
-------------------------------------
[~hightea] I ran your project and reproduced the problem, thanks a lot for it. However I'm seeing that you're using internal test classes of drools and I just wanted to warn you that what's happening there is probably a bit different from what you expect or anyway it's different from what you wrote in the description of this issue.
The reason why you see 2 different behaviours in your apparently identical test cases is that in the working case you're indeed only removing one of the 2 rules, while in the failing one you're removing *both* rules and then *readding* one of them. This is because how that createJar method works internally ( see https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/j... ). There it creates artificial names for drl files based on their position in the varargs. In the breaking case the drl file containing the rule that you want to keep is named r1.drl during first compilation and r0.drl during incremental one. Incremental compilation compares files content based on their names this means that it cannot do anything else than what I described. Note indeed that if you replace line 62 of your reproducer
{code}
createAndDeployJar( ks, releaseId2, DRL_PACKAGE_A);
{code}
with
{code}
createAndDeployJar( ks, releaseId2, null, DRL_PACKAGE_A);
{code}
the position (and then the name) of the file containing the rule that you want to keep is preserved and the test passes.
To recap, I'm not saying that we don't have a bug: we do and I'm about to start working right now to investigate and fix it. I just wanted to clarify that the situation when this bug shows up is slightly different and a bit more complex of what you described.
> NPE in RuleNEtworkEvaluator after incremental compilation
> ---------------------------------------------------------
>
> Key: DROOLS-1742
> URL: https://issues.jboss.org/browse/DROOLS-1742
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.3.0.Final
> Reporter: Théophane Charbonnier
> Assignee: Mario Fusco
> Attachments: drools-path-memory-reproducer.zip
>
>
> Having the following drl files :
> {code:drl}
> package org.hightea.a
> import org.drools.compiler.Message
> import org.drools.compiler.FirstClass
> rule "RG_1"
> when
> $event : Message()
> FirstClass(item1 == $event.message1)
> then
> System.out.println("RG_1");
> end
> {code}
> and
> {code:drl}
> package org.hightea.b
> import org.drools.compiler.Message
> import org.drools.compiler.SecondClass
> rule "RG_2"
> when
> $event: Message()
> SecondClass(item1 == $event.message1)
> then
> System.out.println("RG_2");
> end
> {code}
> We create a module containing the two packages in two drl files and insert a `SecondClass` fact in the WM.
> Then we want to incrementally update to a new module containing only the second DRL.
> At first fireAllrules after update, we encounter a NPE in RuleNetwork evaluator (a Segment memory is not defined in the path memory)
> {code:java}
> java.lang.NullPointerException
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:114)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87)
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067)
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> at org.hightea.IncrementalRemoveRuleTest.testNpeInRuleNetworkEvaluator(IncrementalRemoveRuleTest.java:66)
> {code}
> Note that we don't encounter this issue when the packages names are the same, or if we exchange the order of drl file name in the first module.
> A reproducer is attached with its source code at [https://github.com/hightea/drools-reproducer/tree/path-memory-issue|https...]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months