[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3778:
--------------------------------------
I am reasonably certain that most of the current intermittent vault failures are due to SECURITY-851, which will be resolved with the next picketbox release.
> Tests in Manualmode test suite fail occasionally
> ------------------------------------------------
>
> Key: WFLY-3778
> URL: https://issues.jboss.org/browse/WFLY-3778
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remoting, Test Suite
> Affects Versions: 9.0.0.Beta1
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67.
> Reporter: Frank Langelage
> Assignee: David Lloyd
> Attachments: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt, TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml
>
>
> I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
> But I saw a very similar failure today on Linux first time for PR 6638.
> See https://github.com/wildfly/wildfly/pull/6638.
> Last failure on my machine:
> {noformat}
> Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
> java.lang.AssertionError: Password should be right and authentication successful
> Expected: a string containing "\"outcome\" => \"success\""
> but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
> INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
> INFO [org.xnio] XNIO version 3.3.0.Beta1
> INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
> INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
> "
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3335) JAXB transformer initiation
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3335?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3335:
------------------------------
Priority: Critical (was: Blocker)
> JAXB transformer initiation
> ---------------------------
>
> Key: WFLY-3335
> URL: https://issues.jboss.org/browse/WFLY-3335
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Class Loading
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Ubuntu 14.04 with java 7 openjdk
> Reporter: Ghet Ghetolay
> Assignee: David Lloyd
> Priority: Critical
>
> I'm not directly using JAXB and SaxTransformer, it's part of a the [dcm4chee-arc project|https://github.com/dcm4che/dcm4chee-arc] which I tried to use on Wildfly. It's a rather big and complicated project so I've create a test application to illustrate the bug. I've used a JAR-RS application to illustrate the bug (like the original case) but this should not be related to it.
> {code:title=TestRS.java}
> @Path("test")
> public class TestRS {
>
> private static SAXTransformerFactory factory =
> (SAXTransformerFactory) TransformerFactory.newInstance();
>
> @GET
> public Response test(){
> try {
> Templates template = factory.newTemplates(new StreamSource(
> TestRS.class.getResource("json_compact.xsl").toString()));
>
> factory.newTransformerHandler(template);
>
> } catch (TransformerConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> return Response.ok().build();
> }
> }
> {code}
> {code:title=json_compact.xsl}
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
> <xsl:output method="text"/>
> <xsl:template match="/">
> <xsl:text>Test</xsl:text>
> </xsl:template>
> </xsl:stylesheet>
> {code}
> {quote}
> 15:24:48,564 ERROR [stderr] (default task-1) javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 15:24:48,564 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformerHandler(TransformerFactoryImpl.java:1062)
> 15:24:48,565 ERROR [stderr] (default task-1) at __redirected.__TransformerFactory.newTransformerHandler(__TransformerFactory.java:193)
> 15:24:48,566 ERROR [stderr] (default task-1) at test.TestRS.test(TestRS.java:25)
> {quote}
> I've discovered that the initial exception is :
> {quote}
> java.lang.NoClassDefFoundError: com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet
> {quote}
> Both my test case and dcm4che-arc project works fine on JBoss 7.1.1.Final.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (JBMETA-379) Missing param-name in a web.xml causes NullPointerException during deployment
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/JBMETA-379?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on JBMETA-379:
------------------------------------
current PR is https://github.com/jboss/metadata/pull/68
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: JBMETA-379
> URL: https://issues.jboss.org/browse/JBMETA-379
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: web
> Affects Versions: 8.0.0.Final
> Reporter: Jay Kumar SenSharma
> Assignee: Jean-Frederic Clere
> Attachments: ContextParamNullDemo.war
>
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (JBMETA-379) Missing param-name in a web.xml causes NullPointerException during deployment
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/JBMETA-379?page=com.atlassian.jira.plugin... ]
Tomaz Cerar moved WFLY-3699 to JBMETA-379:
------------------------------------------
Project: JBoss Metadata (was: WildFly)
Key: JBMETA-379 (was: WFLY-3699)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Affects Version/s: 8.0.0.Final
(was: 9.0.0.Beta1)
Assignee: Jean-Frederic Clere (was: Jay Kumar SenSharma)
Component/s: web
(was: Web (Undertow))
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: JBMETA-379
> URL: https://issues.jboss.org/browse/JBMETA-379
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: web
> Affects Versions: 8.0.0.Final
> Reporter: Jay Kumar SenSharma
> Assignee: Jean-Frederic Clere
> Attachments: ContextParamNullDemo.war
>
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3778:
------------------------------
Description:
I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
But I saw a very similar failure today on Linux first time for PR 6638.
See https://github.com/wildfly/wildfly/pull/6638.
Last failure on my machine:
{noformat}
Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
java.lang.AssertionError: Password should be right and authentication successful
Expected: a string containing "\"outcome\" => \"success\""
but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
INFO [org.xnio] XNIO version 3.3.0.Beta1
INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:865)
at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
{noformat}
was:
I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
But I saw a very similar failure today on Linux first time for PR 6638.
See https://github.com/wildfly/wildfly/pull/6638.
Last failure on my machine:
Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
java.lang.AssertionError: Password should be right and authentication successful
Expected: a string containing "\"outcome\" => \"success\""
but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
INFO [org.xnio] XNIO version 3.3.0.Beta1
INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:865)
at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
> Tests in Manualmode test suite fail occasionally
> ------------------------------------------------
>
> Key: WFLY-3778
> URL: https://issues.jboss.org/browse/WFLY-3778
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remoting, Test Suite
> Affects Versions: 9.0.0.Beta1
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67.
> Reporter: Frank Langelage
> Assignee: David Lloyd
> Attachments: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt, TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml
>
>
> I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
> But I saw a very similar failure today on Linux first time for PR 6638.
> See https://github.com/wildfly/wildfly/pull/6638.
> Last failure on my machine:
> {noformat}
> Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
> java.lang.AssertionError: Password should be right and authentication successful
> Expected: a string containing "\"outcome\" => \"success\""
> but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
> INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
> INFO [org.xnio] XNIO version 3.3.0.Beta1
> INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
> INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
> "
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky commented on WFLY-3492:
-----------------------------------------
Right
truststore=>{password=1234test
is not valid. => is not expected after parameter name, it has to be '='. => can only be used in parameter values (DMR values). E.g.
truststore={password=>1234test
is valid. Originally it was the only supported syntax for complex values. Then a simplified version became supported too, e.g.
truststore={password=1234test
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (DROOLS-589) Removing a rule with a join node having the same alpha node as both right and left input causes an Exception
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-589?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-589.
--------------------------------
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/042350294
> Removing a rule with a join node having the same alpha node as both right and left input causes an Exception
> ------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-589
> URL: https://issues.jboss.org/browse/DROOLS-589
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Mario Fusco
> Assignee: Mario Fusco
>
> Reproducer:
> {code}
> @Test
> public void testRemoveWithDuplicatedCondition() {
> String packageName = "test_same_condition_pk" ;
> String rule = "package " + packageName + ";" +
> "rule 'test_same_condition' \n" +
> "when \n" +
> " String(this == \"1\") \n" +
> " String(this == \"1\") \n" +
> "then \n" +
> "System.out.println('test same condition rule'); \n"+
> "end";
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add( ResourceFactory.newByteArrayResource( rule.getBytes() ), ResourceType.DRL );
> if ( kbuilder.hasErrors() ) {
> fail( kbuilder.getErrors().toString() );
> }
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
> kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() );
> kbase.removeKnowledgePackage(packageName);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (DROOLS-589) Removing a rule with a join node having the same alpha node as both right and left input causes an Exception
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-589:
----------------------------------
Summary: Removing a rule with a join node having the same alpha node as both right and left input causes an Exception
Key: DROOLS-589
URL: https://issues.jboss.org/browse/DROOLS-589
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
Reproducer:
{code}
@Test
public void testRemoveWithDuplicatedCondition() {
String packageName = "test_same_condition_pk" ;
String rule = "package " + packageName + ";" +
"rule 'test_same_condition' \n" +
"when \n" +
" String(this == \"1\") \n" +
" String(this == \"1\") \n" +
"then \n" +
"System.out.println('test same condition rule'); \n"+
"end";
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add( ResourceFactory.newByteArrayResource( rule.getBytes() ), ResourceType.DRL );
if ( kbuilder.hasErrors() ) {
fail( kbuilder.getErrors().toString() );
}
KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() );
kbase.removeKnowledgePackage(packageName);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months