[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)
9 years, 8 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)
9 years, 8 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)
9 years, 8 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)
9 years, 8 months
[JBoss JIRA] (DROOLS-588) Constraints with same expression causes a node sharing even if they shouldn't
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-588:
----------------------------------
Summary: Constraints with same expression causes a node sharing even if they shouldn't
Key: DROOLS-588
URL: https://issues.jboss.org/browse/DROOLS-588
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
Reoroducer:
{code}
@Test
public void testWrongNodeSharing() {
String drl1 =
"package test1\n" +
"import static " + Misc2Test.class.getCanonicalName() + ".parseInt;\n" +
"global java.util.List list;\n" +
"rule R when\n" +
" String( parseInt(this) == 0 )\n" +
"then\n" +
" list.add(\"OK\");\n" +
"end";
String drl2 =
"package test2\n" +
"import static java.lang.Integer.parseInt;\n" +
"global java.util.List list;\n" +
"rule R when\n" +
" String( parseInt(this) == 0 )\n" +
"then\n" +
" list.add(\"NOT OK\");\n" +
"end";
KieHelper helper = new KieHelper();
helper.addContent( drl1, ResourceType.DRL );
helper.addContent( drl2, ResourceType.DRL );
KieSession kieSession = helper.build().newKieSession();
List list = new ArrayList();
kieSession.setGlobal( "list", list );
kieSession.insert( "3" );
kieSession.fireAllRules();
assertEquals( 1, list.size() );
assertEquals( "OK", list.get(0) );
}
public static int parseInt(String s) {
return 0;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-1264) Create a test to get notifications when hosts join/leave a domain
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-1264?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos commented on WFLY-1264:
-----------------------------------------------
Arquilllian test created to test monitoring when hosts join/leave a domain using ManagementClient. This functionality is not yet supported by ManagementClient.
> Create a test to get notifications when hosts join/leave a domain
> -----------------------------------------------------------------
>
> Key: WFLY-1264
> URL: https://issues.jboss.org/browse/WFLY-1264
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Andrew Rubinger
> Assignee: Panagiotis Sotiropoulos
>
> Should be implemented by using the mechanism provided by AS7-1415, injection of the ManagementClient into the test. Verify this is working to fulfill the feature request from QE to get notifications on hosts joining/leaving the Domain. May depend upon the presence of an AS7 Domain Controller Container.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
Kabir Khan edited comment on WFLY-3492 at 9/1/14 11:57 AM:
-----------------------------------------------------------
Looking a bit more into this, if I use:
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore={password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore *=* {...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => {
"password" => "1234test",
"url" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks"
},
---SNIP---
}
{code}
However, if I do
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore=>{password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore *=>* {...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => ">",
--- SNIP ----
}
{code}
So perhaps rather than a validation error, this is a CLI parsing problem in general? It seems that *=>* should get rejected.
[~loubyansky] [~brian.stansberry] What do you think?
was (Author: kabirkhan):
Looking a bit more into this, if I use:
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore={password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore*=*{...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => {
"password" => "1234test",
"url" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks"
},
---SNIP---
}
{code}
However, if I do
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore=>{password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore*=>*{...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => ">",
--- SNIP ----
}
{code}
So perhaps rather than a validation error, this is a CLI parsing problem in general? It seems that *=>* should get rejected.
[~loubyansky] [~brian.stansberry] What do you think?
> 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)
9 years, 8 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3492:
----------------------------------
Looking a bit more into this, if I use:
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore={password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore*=*{...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => {
"password" => "1234test",
"url" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks"
},
---SNIP---
}
{code}
However, if I do
{code}
/subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore=>{password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{code}
e.g. truststore*=>*{...} the operation becomes:
{code}
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => ">",
--- SNIP ----
}
{code}
So perhaps rather than a validation error, this is a CLI parsing problem in general? It seems that *=>* should get rejected.
[~loubyansky] [~brian.stansberry] What do you think?
> 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)
9 years, 8 months
[JBoss JIRA] (DROOLS-242) Add out-of-the-box possibility to dump DRL created from decision tables
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-242?page=com.atlassian.jira.plugin... ]
Petr Široký updated DROOLS-242:
-------------------------------
Description:
To get the DRL generated from decision table one has to currently use following code:
{code}
File dtable = new File("../resources/dtable.xls");
KieResources kieResources = KieServices.Factory.get().getResources();
Resource dtableResource = kieResources.newFileSystemResource(dtable);
SpreadsheetCompiler compiler = new SpreadsheetCompiler();
String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
{code}
It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
Using the 'drools.dump.dir' property seems like the best option. The name is general enough and users would have to use/remember yet another config. property.
Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
- get the value of `drools.dump.dir` manually using the ChainedProperties.
- add this config. option into DecisionTableConfiguration. This would prevent the backwards compatibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
- pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
was:
To get the DRL generated from decision table one has to currently use following code:
{code}
File dtable = new File("../resources/dtable.xls");
KieResources kieResources = KieServices.Factory.get().getResources();
Resource dtableResource = kieResources.newFileSystemResource(dtable);
SpreadsheetCompiler compiler = new SpreadsheetCompiler();
String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
{code}
It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
- get the value of `drools.dump.dir` manually using the ChainedProperties.
- add this config. option into DecisionTableConfiguration. This would prevent the backwards comptibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
- pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
> Add out-of-the-box possibility to dump DRL created from decision tables
> ------------------------------------------------------------------------
>
> Key: DROOLS-242
> URL: https://issues.jboss.org/browse/DROOLS-242
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR2
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> To get the DRL generated from decision table one has to currently use following code:
> {code}
> File dtable = new File("../resources/dtable.xls");
> KieResources kieResources = KieServices.Factory.get().getResources();
> Resource dtableResource = kieResources.newFileSystemResource(dtable);
> SpreadsheetCompiler compiler = new SpreadsheetCompiler();
> String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
> {code}
> It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
> Using the 'drools.dump.dir' property seems like the best option. The name is general enough and users would have to use/remember yet another config. property.
> Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
> - get the value of `drools.dump.dir` manually using the ChainedProperties.
> - add this config. option into DecisionTableConfiguration. This would prevent the backwards compatibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
> - pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months