[JBoss JIRA] (WFLY-6726) Add help text about jboss.undefinded.host for the wsdl-host attribute
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-6726?page=com.atlassian.jira.plugin.... ]
Claudio Miranda updated WFLY-6726:
----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/9047
> Add help text about jboss.undefinded.host for the wsdl-host attribute
> ---------------------------------------------------------------------
>
> Key: WFLY-6726
> URL: https://issues.jboss.org/browse/WFLY-6726
> Project: WildFly
> Issue Type: Enhancement
> Components: Web Services
> Reporter: Claudio Miranda
> Assignee: Alessio Soldano
>
> would be doable to add the text to the
> resource-description of wsdl-url, related to the use of
> jboss.undefined.host ?
> The path
> /deployment=*/subsystem=webservices/endpoint=*:read-resource-description
> I ask that because HAL consumes and exposes the resource-description
> of each attribute and having the help text about the
> jboss.undefined.host in wsdl-host also helps CLI users.
> A suggestion for the text:
> "Webservice endpoint WSDL URL. If wsdl-host is set to
> jbossws.undefined.host, Wildfly uses the requester's host when
> rewriting the <soap:address>"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6841) Add backup service support for singleton services
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6841?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6841:
-------------------------------
Description: Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. (was: Currently, singleton services are started on the primary node only - no service is started on the backup node. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.)
> Add backup service support for singleton services
> -------------------------------------------------
>
> Key: WFLY-6841
> URL: https://issues.jboss.org/browse/WFLY-6841
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Alpha1
>
>
> Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6841) Add backup service support for singleton services
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6841:
----------------------------------
Summary: Add backup service support for singleton services
Key: WFLY-6841
URL: https://issues.jboss.org/browse/WFLY-6841
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 11.0.0.Alpha1
Currently, singleton services are started on the primary node only - no service is started on the backup node. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (ELY-405) Add a KeyStore implementation backed by LDAP
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-405?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-405:
--------------------------------
objectClasses and attributes usable for this:
* inetOrgPerson
** certificate - X.509 certificate of user
** userSMIMECertificate - PKCS#7 certificate chain (.p7b)
** userPKCS12 - PKCS#12 keypair (certificate+encrypted private key)
> Add a KeyStore implementation backed by LDAP
> --------------------------------------------
>
> Key: ELY-405
> URL: https://issues.jboss.org/browse/ELY-405
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SSL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> It is possible for private keys, public keys and certificates to all be stored in LDAP - this task is to create a Java KeyStore implementation that can work with this.
> LDAP most likely will take a reasonable amount of configuration so it may not be possible to be purely provider based and instead this type of KeyStore may need to be manually configured and instantiated.
> Properties could be passed in using the InputStream to initialise the KeyStore but that doesn't help where we may want to pass in factories for connecting to a remote LDAP server.
> In addition to the usual keys and certificates the entry types as used for CredentialStore should also be considered.
> The implementation should also support manipulation of the entries - in this case this may mean immediate updates to the directory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (DROOLS-1069) UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple
by Anantjot Anand (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1069?page=com.atlassian.jira.plugi... ]
Anantjot Anand commented on DROOLS-1069:
----------------------------------------
Mario, I don't have reproducer for it. This happen during muti-threaded evaluation where each evaluation was using it own ksession and RHS has initiated retarct of a Object from WM.
> UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1069
> URL: https://issues.jboss.org/browse/DROOLS-1069
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Anantjot Anand
> Assignee: Mario Fusco
>
> BaseLeftTuple class is inherited by EvalNodeLeftTuple, FromNodeLeftTuple, JoinNodeLeftTuple, LeftTupleImpl, NotNodeLeftTuple, QueryElementNodeLeftTuple, QueryRiaFixerNodeLeftTuple, RuleTerminalNodeLeftTuple classes.
> FromNodeLeftTuple, JoinNodeLeftTuple, QueryElementNodeLeftTuple, QueryRiaFixerNodeLeftTuple and RuleTerminalNodeLeftTuple doesn’t implement its overridden methods.
> at org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)
> at org.drools.core.phreak.PhreakExistsNode.doLeftDeletes(PhreakExistsNode.java:425)
> at org.drools.core.phreak.PhreakExistsNode.doNode(PhreakExistsNode.java:53)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:560)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at com.wellsfargo.ARGenT.Execution.RuleBase.processDataWithRules(RuleBase.java:1618)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6782) Unable to add JGroups protocol at a given index via CLI
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6782?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6782:
--------------------------------------
I agree above/below-protocol (before/after would be a bit more vague as it's not clear in which representation; above/below is more suited with jgroups terminology) would improve :add command usability, although I don't think it would justify the effort unless there is an explicit request for it. Surely you could open a Jira with PM. Moreover, in jgroups its possible to have the same protocol multiple times which would defeat the purpose completely (although, this is not allowed in wildfly iiuc). Also note that the "add-index" attribute is a generic concept for ordered children resource, not a jgroups subsystem specific one, although, it's the only usage of it at the moment.
> Unable to add JGroups protocol at a given index via CLI
> -------------------------------------------------------
>
> Key: WFLY-6782
> URL: https://issues.jboss.org/browse/WFLY-6782
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 10.1.0.Final
>
>
> Unable to use this via CLI, tests pass since they use management client which won't check against the operation description:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add(add-index=4)
> 'add-index' is not found among the supported properties: [socket-binding, module, properties, type]
> {noformat}
> add index is missing in the description, after the fix:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=MPING:read-operation-description(name=add
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "add",
> "description" => "Add a protocol to a protocol stack.",
> "request-properties" => {
> "add-index" => {
> "type" => INT,
> "description" => "If specified inserts the protocol at the given (zero-based) index. If null it will add at the end.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true
> },
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (DROOLS-1158) NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1158?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1158:
-------------------------------------
Just to better clarify what it's happening here is the following:
First round
# Add pkg "A" to the kbase1 generating kpkgA, kbase1 now has a reference "A" -> pkgA
# Add pkg "B" to the kbase1 generating kpkgB, kbase1 now has a reference "B" -> pkgB
# Internally kpkgA and kpkgB now reference each other
Second round
# Try to add kpkg A to kbase2, now kbase2 doesn't have any reference for pkg "B" but kpkgA has a reference to it coming from the former compilation
# kpkgA asks kbase2 to resolve pkg "B" but you haven't added that package yet to kbase2 thus causing the exception
> NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1158
> URL: https://issues.jboss.org/browse/DROOLS-1158
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Matteo Mortari
> Attachments: drools-reusepackage.tar, screenshot-1.png
>
>
> Having a set of DecisionTables which KnowledgePackages are cached in our application, after we detect a change in any of those XLS files, we build a KnowledgePackages from it, and then try to create a new KnowledgeBase with the new KnowledgePackages + the rest of the cached one that that were not modified, but it fails with a NPE internally in Drools (6.3.0 and 6.4.0)
> This is not a problem for the drools version (6.0.1.Final) that we currently uses using in production.
> After debugging and putting a breakpoint into the *MvelConstraint.java:619*, it shows that it is trying to look for a packageName which hasn't being loaded yet in the new kbase (but belong to others XLS).
> I have attached a project with a testcase that shows the problem, it has 2 DecisionTable which i had to cut down a little bit (from our real files) and removes some sensitive information (replacing some of text with FOO-BAR).
> {code}
> java.lang.NullPointerException
> at org.drools.core.rule.constraint.MvelConstraint.equals(MvelConstraint.java:619)
> at org.drools.core.reteoo.AlphaNode.internalEquals(AlphaNode.java:199)
> at org.drools.core.common.BaseNode.thisNodeEquals(BaseNode.java:194)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.getMatchingNode(CompositeObjectSinkAdapter.java:531)
> at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:121)
> at org.drools.core.reteoo.builder.PatternBuilder.buildAlphaNodeChain(PatternBuilder.java:332)
> at org.drools.core.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:313)
> at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:130)
> at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:78)
> at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:106)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1567)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1547)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:920)
> at org.drools.core.impl.KnowledgeBaseImpl.access$000(KnowledgeBaseImpl.java:117)
> at org.drools.core.impl.KnowledgeBaseImpl$1.run(KnowledgeBaseImpl.java:708)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:716)
> at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:705)
> at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:273)
> at org.drools.impl.adapters.KnowledgeBaseAdapter.addKnowledgePackages(KnowledgeBaseAdapter.java:62)
> at bug.demo.BugReloadableDecisionTableTest.addRuleSetToKnowledgeBase(BugReloadableDecisionTableTest.java:63)
> at bug.demo.BugReloadableDecisionTableTest.testReuseKnowledgePackage(BugReloadableDecisionTableTest.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (DROOLS-1158) NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1158?page=com.atlassian.jira.plugi... ]
Matteo Mortari closed DROOLS-1158.
----------------------------------
Resolution: Rejected
> NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1158
> URL: https://issues.jboss.org/browse/DROOLS-1158
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Matteo Mortari
> Attachments: drools-reusepackage.tar, screenshot-1.png
>
>
> Having a set of DecisionTables which KnowledgePackages are cached in our application, after we detect a change in any of those XLS files, we build a KnowledgePackages from it, and then try to create a new KnowledgeBase with the new KnowledgePackages + the rest of the cached one that that were not modified, but it fails with a NPE internally in Drools (6.3.0 and 6.4.0)
> This is not a problem for the drools version (6.0.1.Final) that we currently uses using in production.
> After debugging and putting a breakpoint into the *MvelConstraint.java:619*, it shows that it is trying to look for a packageName which hasn't being loaded yet in the new kbase (but belong to others XLS).
> I have attached a project with a testcase that shows the problem, it has 2 DecisionTable which i had to cut down a little bit (from our real files) and removes some sensitive information (replacing some of text with FOO-BAR).
> {code}
> java.lang.NullPointerException
> at org.drools.core.rule.constraint.MvelConstraint.equals(MvelConstraint.java:619)
> at org.drools.core.reteoo.AlphaNode.internalEquals(AlphaNode.java:199)
> at org.drools.core.common.BaseNode.thisNodeEquals(BaseNode.java:194)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.getMatchingNode(CompositeObjectSinkAdapter.java:531)
> at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:121)
> at org.drools.core.reteoo.builder.PatternBuilder.buildAlphaNodeChain(PatternBuilder.java:332)
> at org.drools.core.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:313)
> at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:130)
> at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:78)
> at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:106)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1567)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1547)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:920)
> at org.drools.core.impl.KnowledgeBaseImpl.access$000(KnowledgeBaseImpl.java:117)
> at org.drools.core.impl.KnowledgeBaseImpl$1.run(KnowledgeBaseImpl.java:708)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:716)
> at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:705)
> at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:273)
> at org.drools.impl.adapters.KnowledgeBaseAdapter.addKnowledgePackages(KnowledgeBaseAdapter.java:62)
> at bug.demo.BugReloadableDecisionTableTest.addRuleSetToKnowledgeBase(BugReloadableDecisionTableTest.java:63)
> at bug.demo.BugReloadableDecisionTableTest.testReuseKnowledgePackage(BugReloadableDecisionTableTest.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (DROOLS-1158) NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1158?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1158:
----------------------------------------
Hello [~jcgarciam], thanks for the feedback. We've checked and the problem originates by the manual use of the internal API, internally invoked some deprecated code superseded already by the public Kie API.
The thing about Java 8, turns out to be just a coincidence by the new way Iterators work on the Java Collection API. So really cannot be relied upon.
In details: at the second round of loading your packages, it is making reference to a package name which is not been loaded yet in the internalKnowledgeBase. Turns out switching to Java 8 would return package names in a different order, hence passes this check, but can't guarantee the actual behavior down the line is the expected one (ref. above)
We invite you to use the public Kie API to address your use-case, which is the only way to guarantee the internals will be working correctly as expected.
> NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1158
> URL: https://issues.jboss.org/browse/DROOLS-1158
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Matteo Mortari
> Attachments: drools-reusepackage.tar, screenshot-1.png
>
>
> Having a set of DecisionTables which KnowledgePackages are cached in our application, after we detect a change in any of those XLS files, we build a KnowledgePackages from it, and then try to create a new KnowledgeBase with the new KnowledgePackages + the rest of the cached one that that were not modified, but it fails with a NPE internally in Drools (6.3.0 and 6.4.0)
> This is not a problem for the drools version (6.0.1.Final) that we currently uses using in production.
> After debugging and putting a breakpoint into the *MvelConstraint.java:619*, it shows that it is trying to look for a packageName which hasn't being loaded yet in the new kbase (but belong to others XLS).
> I have attached a project with a testcase that shows the problem, it has 2 DecisionTable which i had to cut down a little bit (from our real files) and removes some sensitive information (replacing some of text with FOO-BAR).
> {code}
> java.lang.NullPointerException
> at org.drools.core.rule.constraint.MvelConstraint.equals(MvelConstraint.java:619)
> at org.drools.core.reteoo.AlphaNode.internalEquals(AlphaNode.java:199)
> at org.drools.core.common.BaseNode.thisNodeEquals(BaseNode.java:194)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.getMatchingNode(CompositeObjectSinkAdapter.java:531)
> at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:121)
> at org.drools.core.reteoo.builder.PatternBuilder.buildAlphaNodeChain(PatternBuilder.java:332)
> at org.drools.core.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:313)
> at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:130)
> at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:78)
> at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:106)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1567)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1547)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:920)
> at org.drools.core.impl.KnowledgeBaseImpl.access$000(KnowledgeBaseImpl.java:117)
> at org.drools.core.impl.KnowledgeBaseImpl$1.run(KnowledgeBaseImpl.java:708)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:716)
> at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:705)
> at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:273)
> at org.drools.impl.adapters.KnowledgeBaseAdapter.addKnowledgePackages(KnowledgeBaseAdapter.java:62)
> at bug.demo.BugReloadableDecisionTableTest.addRuleSetToKnowledgeBase(BugReloadableDecisionTableTest.java:63)
> at bug.demo.BugReloadableDecisionTableTest.testReuseKnowledgePackage(BugReloadableDecisionTableTest.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months