[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)
8 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)
8 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)
8 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)
8 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)
8 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)
8 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)
8 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 reassigned DROOLS-1158:
-----------------------------------
Assignee: Matteo Mortari (was: Mario Fusco)
> 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)
8 years, 5 months
[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up
by Will Wright (JIRA)
Will Wright created JGRP-2090:
---------------------------------
Summary: JGRP000027: failed passing message up
Key: JGRP-2090
URL: https://issues.jboss.org/browse/JGRP-2090
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.10
Reporter: Will Wright
Assignee: Bela Ban
The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header.
The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine.
java.lang.NullPointerException: null
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months