[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 updated DROOLS-1742:
--------------------------------
Sprint: 2017 Week 38-39
> 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] (AG-36) Implement as OSGi test
by Luis Barreiro (JIRA)
[ https://issues.jboss.org/browse/AG-36?page=com.atlassian.jira.plugin.syst... ]
Luis Barreiro resolved AG-36.
-----------------------------
Resolution: Done
Implemented using PaxExam to bootstrap an Apache Felix container.
OSGi tests will be disabled by default, has it can potentially have issues when the maven version is bumped (the bundles are loaded by maven an a new version may not be available). The same goes for building an older version for the first time.
Note that due to lack of support of the ServiceLoader mechanism on OSGi, the implementation has to be instantiated directly.
> Implement as OSGi test
> ----------------------
>
> Key: AG-36
> URL: https://issues.jboss.org/browse/AG-36
> Project: Agroal
> Issue Type: Bug
> Components: test
> Affects Versions: 0.2
> Reporter: Luis Barreiro
> Assignee: Luis Barreiro
> Fix For: 0.3
>
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (AG-36) Implement as OSGi test
by Luis Barreiro (JIRA)
Luis Barreiro created AG-36:
-------------------------------
Summary: Implement as OSGi test
Key: AG-36
URL: https://issues.jboss.org/browse/AG-36
Project: Agroal
Issue Type: Bug
Components: test
Affects Versions: 0.2
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 0.3
--
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 Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3316:
------------------------------------------
Thanks. This looks like a fairly complex fix then. The configured validator on the attribute appears to not be working (which seems like a general problem), plus the xml parser is bypassing the normal validation handling. The parsing fails, as should happen, but I doubt it's failing in a good way.
> 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] (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 commented on WFCORE-3316:
-----------------------------------------
[~brian.stansberry] The validation of the attribute value did not happen when the attribute was added, so the invalid value is written to the xml. That is why the server start fails when reading xml configuration.
This issue is copied from the JBEAP, but neither of the suggested options works for me.
> 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] (WFCORE-3316) Server fails to start after submitting invalid security attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3316:
------------------------------------------
Are you sure the "Only fix for the configuration is to manually change the XML file directly"? Does starting in admin-only mode not work, either with the CLI embed-server command or with a remote CLI?
> 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] (WFLY-9376) TransportGuaranteeTestCase fails due to missing application.keystore
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-9376?page=com.atlassian.jira.plugin.... ]
Jan Stourac updated WFLY-9376:
------------------------------
Labels: (was: eap7.1-ok-for-cr3)
> TransportGuaranteeTestCase fails due to missing application.keystore
> --------------------------------------------------------------------
>
> Key: WFLY-9376
> URL: https://issues.jboss.org/browse/WFLY-9376
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.CR1
> Reporter: Jan Stourac
> Assignee: Jan Stourac
>
> org.jboss.as.test.integration.web.security.tg.TransportGuaranteeTestCase successful execution depends on presence of application.keystore file in standalone configuration directory. There is a task defined in pom.xml named {{ts.integ.web.copy-keystores}} which should copy the required resources from target file of shared module. Since the web module doesn't depend on shared module, there is no way one can guarantee that target directory of the shared module will exist - it does not in our automation.
> The test could pass in case that org.jboss.as.test.integration.web.handlers.RequestDumpingHandlerTestCase is run prior it (this test seem to generate an own application.keystore).
> *reproduce*
> {noformat}
> cd testsuite/integration/web
> rm -rf ../../shared/target/
> mvn clean test -Dtest=TransportGuaranteeTestCase
> Results :
> Tests in error:
> TransportGuaranteeTestCase.testTransportGuaranteedAnnotation:221->performRequestsAndCheck:235->checkGetURL:189
> TransportGuaranteeTestCase.testTransportGuaranteedDD:226->performRequestsAndCheck:235->checkGetURL:189
> TransportGuaranteeTestCase.testTransportGuaranteedMixed:231->performRequestsAndCheck:235->checkGetURL:189
> Tests run: 3, Failures: 0, Errors: 3, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9376) TransportGuaranteeTestCase fails due to missing application.keystore
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-9376?page=com.atlassian.jira.plugin.... ]
Jan Stourac moved JBEAP-13245 to WFLY-9376:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9376 (was: JBEAP-13245)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: 11.0.0.CR1
(was: 7.1.0.CR2)
> TransportGuaranteeTestCase fails due to missing application.keystore
> --------------------------------------------------------------------
>
> Key: WFLY-9376
> URL: https://issues.jboss.org/browse/WFLY-9376
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.CR1
> Reporter: Jan Stourac
> Assignee: Jan Stourac
> Labels: eap7.1-ok-for-cr3
>
> org.jboss.as.test.integration.web.security.tg.TransportGuaranteeTestCase successful execution depends on presence of application.keystore file in standalone configuration directory. There is a task defined in pom.xml named {{ts.integ.web.copy-keystores}} which should copy the required resources from target file of shared module. Since the web module doesn't depend on shared module, there is no way one can guarantee that target directory of the shared module will exist - it does not in our automation.
> The test could pass in case that org.jboss.as.test.integration.web.handlers.RequestDumpingHandlerTestCase is run prior it (this test seem to generate an own application.keystore).
> *reproduce*
> {noformat}
> cd testsuite/integration/web
> rm -rf ../../shared/target/
> mvn clean test -Dtest=TransportGuaranteeTestCase
> Results :
> Tests in error:
> TransportGuaranteeTestCase.testTransportGuaranteedAnnotation:221->performRequestsAndCheck:235->checkGetURL:189
> TransportGuaranteeTestCase.testTransportGuaranteedDD:226->performRequestsAndCheck:235->checkGetURL:189
> TransportGuaranteeTestCase.testTransportGuaranteedMixed:231->performRequestsAndCheck:235->checkGetURL:189
> Tests run: 3, Failures: 0, Errors: 3, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months