[JBoss JIRA] (DROOLS-1751) NullPointerException on org.mvel2.MVEL.executeExpression()
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1751?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-1751:
--------------------------------------
Git Pull Request: https://github.com/kiegroup/drools/pull/1515
sent a PR with Unit test and Fix
> NullPointerException on org.mvel2.MVEL.executeExpression()
> ----------------------------------------------------------
>
> Key: DROOLS-1751
> URL: https://issues.jboss.org/browse/DROOLS-1751
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.3.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
>
> Under the conditions:
> - 2 KiePackages with the same package name but different rules
> - Those packages are used by a kbase so "inUse = true"
> - Create another kbase and call kbase.addPackages() for those packages
> MVELDialectRuntimeData has a problem in merging mvelReaders so later rule execution fails with NullPointerException.
> {noformat}
> java.lang.NullPointerException: null
> at org.mvel2.MVEL.executeExpression(MVEL.java:953)
> at org.drools.core.util.MVELSafeHelper$RawMVELEvaluator.executeExpression(MVELSafeHelper.java:506)
> at org.drools.core.base.extractors.MVELObjectClassFieldReader.getValue(MVELObjectClassFieldReader.java:140)
> at org.drools.core.rule.Declaration.getValue(Declaration.java:222)
> at org.drools.core.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:386)
> at org.drools.core.base.mvel.MVELCompilationUnit.getFactory(MVELCompilationUnit.java:320)
> at org.drools.core.base.dataproviders.MVELDataProvider.evaluate(MVELDataProvider.java:137)
> at org.drools.core.base.dataproviders.MVELDataProvider.getResults(MVELDataProvider.java:133)
> at org.drools.core.phreak.PhreakFromNode.doLeftInserts(PhreakFromNode.java:106)
> at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:68)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:387)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:127)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87)
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067)
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> at org.drools.compiler.integrationtests.Misc2Test.testMergeMVELDialect(Misc2Test.java:9109)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1751) NullPointerException on org.mvel2.MVEL.executeExpression()
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created DROOLS-1751:
-----------------------------------------
Summary: NullPointerException on org.mvel2.MVEL.executeExpression()
Key: DROOLS-1751
URL: https://issues.jboss.org/browse/DROOLS-1751
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.3.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
Under the conditions:
- 2 KiePackages with the same package name but different rules
- Those packages are used by a kbase so "inUse = true"
- Create another kbase and call kbase.addPackages() for those packages
MVELDialectRuntimeData has a problem in merging mvelReaders so later rule execution fails with NullPointerException.
{noformat}
java.lang.NullPointerException: null
at org.mvel2.MVEL.executeExpression(MVEL.java:953)
at org.drools.core.util.MVELSafeHelper$RawMVELEvaluator.executeExpression(MVELSafeHelper.java:506)
at org.drools.core.base.extractors.MVELObjectClassFieldReader.getValue(MVELObjectClassFieldReader.java:140)
at org.drools.core.rule.Declaration.getValue(Declaration.java:222)
at org.drools.core.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:386)
at org.drools.core.base.mvel.MVELCompilationUnit.getFactory(MVELCompilationUnit.java:320)
at org.drools.core.base.dataproviders.MVELDataProvider.evaluate(MVELDataProvider.java:137)
at org.drools.core.base.dataproviders.MVELDataProvider.getResults(MVELDataProvider.java:133)
at org.drools.core.phreak.PhreakFromNode.doLeftInserts(PhreakFromNode.java:106)
at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:68)
at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:387)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:127)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87)
at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067)
at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
at org.drools.compiler.integrationtests.Misc2Test.testMergeMVELDialect(Misc2Test.java:9109)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3338) Management returning success for read-attribute on non-existent path
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3338?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFCORE-3338:
---------------------------------
Summary: Management returning success for read-attribute on non-existent path (was: Management returning success for read-attribute on non-existant path)
> Management returning success for read-attribute on non-existent path
> --------------------------------------------------------------------
>
> Key: WFCORE-3338
> URL: https://issues.jboss.org/browse/WFCORE-3338
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.4.Final
> Reporter: Brad Maxwell
> Assignee: Brian Stansberry
>
> In Wildfly, a command such as this with a non-existent path returns success instead of failed:
> {code}
> /host=master/server=nonExistant:read-attribute(name=runtime-configuration-state)
> {
> "outcome" => "success",
> "result" => "stopped"
> }
> {code}
> Where as in EAP 6.4:
> {code}
> [domain@localhost:9999 /] /host=master/server=server-NOT-EXIST:read-attribute(name=server-state)
> Failed to get the list of the operation properties: "JBAS014883: No resource definition is registered for address [
> ("host" => "master"),
> ("server" => "server-NOT-EXIST")
> ]"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3338) Management returning success for read-attribute on non-existant path
by Brad Maxwell (JIRA)
Brad Maxwell created WFCORE-3338:
------------------------------------
Summary: Management returning success for read-attribute on non-existant path
Key: WFCORE-3338
URL: https://issues.jboss.org/browse/WFCORE-3338
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.4.Final
Reporter: Brad Maxwell
Assignee: Brian Stansberry
In Wildfly, a command such as this with a non-existent path returns success instead of failed:
{code}
/host=master/server=nonExistant:read-attribute(name=runtime-configuration-state)
{
"outcome" => "success",
"result" => "stopped"
}
{code}
Where as in EAP 6.4:
{code}
[domain@localhost:9999 /] /host=master/server=server-NOT-EXIST:read-attribute(name=server-state)
Failed to get the list of the operation properties: "JBAS014883: No resource definition is registered for address [
("host" => "master"),
("server" => "server-NOT-EXIST")
]"
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3339) [GSS](7.2.0) Management returning success for read-attribute on non-existant path
by Brad Maxwell (JIRA)
Brad Maxwell created WFCORE-3339:
------------------------------------
Summary: [GSS](7.2.0) Management returning success for read-attribute on non-existant path
Key: WFCORE-3339
URL: https://issues.jboss.org/browse/WFCORE-3339
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.4.Final
Reporter: Brad Maxwell
Assignee: Brian Stansberry
In Wildfly, a command such as this with a non-existent path returns success instead of failed:
{code}
/host=master/server=nonExistant:read-attribute(name=runtime-configuration-state)
{
"outcome" => "success",
"result" => "stopped"
}
{code}
Where as in EAP 6.4:
{code}
[domain@localhost:9999 /] /host=master/server=server-NOT-EXIST:read-attribute(name=server-state)
Failed to get the list of the operation properties: "JBAS014883: No resource definition is registered for address [
("host" => "master"),
("server" => "server-NOT-EXIST")
]"
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3337:
---------------------------------------
For some reason I thought capabilities required services. If that's not that case that would probably work quite well and give a more standard error message.
> Logging resources shouldn't be allowed to removed if they are in-use
> --------------------------------------------------------------------
>
> Key: WFCORE-3337
> URL: https://issues.jboss.org/browse/WFCORE-3337
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
> Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3337:
------------------------------------------
Never mind, kind of. You want to check the original thing being removed and trigger reload-required instead of removing, which is a different thing. The WFCORE-1106 thing might then be useful to prevent subsequent config changes that might assume the removed things is gone from taking effect. But that's a further step.
> Logging resources shouldn't be allowed to removed if they are in-use
> --------------------------------------------------------------------
>
> Key: WFCORE-3337
> URL: https://issues.jboss.org/browse/WFCORE-3337
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
> Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3337:
------------------------------------------
Capabilities and requirements can do this for you if the relationships between things are tracked via caps/reqs. See discussion of WFCORE-1106.
> Logging resources shouldn't be allowed to removed if they are in-use
> --------------------------------------------------------------------
>
> Key: WFCORE-3337
> URL: https://issues.jboss.org/browse/WFCORE-3337
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
> Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by James Perkins (JIRA)
James Perkins created WFCORE-3337:
-------------------------------------
Summary: Logging resources shouldn't be allowed to removed if they are in-use
Key: WFCORE-3337
URL: https://issues.jboss.org/browse/WFCORE-3337
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months