July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6793) Batch subsystem cannot be removed with a remove operation

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6793?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-6793: -------------------------------- Description: The {{batch-jberet}} subsystem fails when a {{remove}} operation is invoked. {code} [standalone@localhost:9990 /] /subsystem=batch-jberet:remove { "outcome" => "failed", "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: Service org.wildfly.batch.thread.pool.batch was depended upon by service org.wildfly.batch.configuration", "rolled-back" => true, "response-headers" => undefined } {code} -The batch configuration dependency needs to be removed before the its dependencies are removed.- -The thread-pool resource should also require a reload before removal.- The thread-pool is used in deployments and therefore shouldn't just be removed without a reload if there are deployments using it. was: The {{batch-jberet}} subsystem fails when a {{remove}} operation is invoked. {code} [standalone@localhost:9990 /] /subsystem=batch-jberet:remove { "outcome" => "failed", "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: Service org.wildfly.batch.thread.pool.batch was depended upon by service org.wildfly.batch.configuration", "rolled-back" => true, "response-headers" => undefined } {code} -The batch configuration dependency needs to be removed before the its dependencies are removed.- The thread-pool resource should also require a reload before removal. It's used in deployments and therefore shouldn't just be removed without a reload. > Batch subsystem cannot be removed with a remove operation > --------------------------------------------------------- > > Key: WFLY-6793 > URL: https://issues.jboss.org/browse/WFLY-6793 > Project: WildFly > Issue Type: Bug > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > The {{batch-jberet}} subsystem fails when a {{remove}} operation is invoked. > {code} > [standalone@localhost:9990 /] /subsystem=batch-jberet:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service org.wildfly.batch.thread.pool.batch was depended upon by service org.wildfly.batch.configuration", > "rolled-back" => true, > "response-headers" => undefined > } > {code} > -The batch configuration dependency needs to be removed before the its dependencies are removed.- > -The thread-pool resource should also require a reload before removal.- The thread-pool is used in deployments and therefore shouldn't just be removed without a reload if there are deployments using it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6793) Batch subsystem cannot be removed with a remove operation

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6793?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-6793: -------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/9010) > Batch subsystem cannot be removed with a remove operation > --------------------------------------------------------- > > Key: WFLY-6793 > URL: https://issues.jboss.org/browse/WFLY-6793 > Project: WildFly > Issue Type: Bug > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > The {{batch-jberet}} subsystem fails when a {{remove}} operation is invoked. > {code} > [standalone@localhost:9990 /] /subsystem=batch-jberet:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service org.wildfly.batch.thread.pool.batch was depended upon by service org.wildfly.batch.configuration", > "rolled-back" => true, > "response-headers" => undefined > } > {code} > -The batch configuration dependency needs to be removed before the its dependencies are removed.- > The thread-pool resource should also require a reload before removal. It's used in deployments and therefore shouldn't just be removed without a reload. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1224) Not able to update kie-server container version using REST API

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1224?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1224: ---------------------------------- Summary: Not able to update kie-server container version using REST API (was: Not able to update kie-server container version using REAT API) > Not able to update kie-server container version using REST API > -------------------------------------------------------------- > > Key: DROOLS-1224 > URL: https://issues.jboss.org/browse/DROOLS-1224 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Reporter: Maciej Swiderski > Assignee: Maciej Swiderski > > I updated a kie-container's release Id using "UpdateReleaseIdCommand". It worked fine, but after the server restart it's going back to the old release Id's version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1224) Not able to update kie-server container version using REAT API

by Maciej Swiderski (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1224?page=com.atlassian.jira.plugi... ] Maciej Swiderski moved RHBPMS-4074 to DROOLS-1224: -------------------------------------------------- Project: Drools (was: JBoss BPMS Platform) Key: DROOLS-1224 (was: RHBPMS-4074) Workflow: GIT Pull Request workflow (was: CDW v1) Docs QE Status: NEW Component/s: kie server (was: Kie-Server) Affects Version/s: 6.4.0.Final (was: 6.3.0.GA) QE Status: NEW > Not able to update kie-server container version using REAT API > -------------------------------------------------------------- > > Key: DROOLS-1224 > URL: https://issues.jboss.org/browse/DROOLS-1224 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Reporter: Maciej Swiderski > Assignee: Edson Tirelli > > I updated a kie-container's release Id using "UpdateReleaseIdCommand". It worked fine, but after the server restart it's going back to the old release Id's version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1224) Not able to update kie-server container version using REAT API

by Maciej Swiderski (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1224?page=com.atlassian.jira.plugi... ] Maciej Swiderski reassigned DROOLS-1224: ---------------------------------------- Assignee: Maciej Swiderski (was: Edson Tirelli) > Not able to update kie-server container version using REAT API > -------------------------------------------------------------- > > Key: DROOLS-1224 > URL: https://issues.jboss.org/browse/DROOLS-1224 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Reporter: Maciej Swiderski > Assignee: Maciej Swiderski > > I updated a kie-container's release Id using "UpdateReleaseIdCommand". It worked fine, but after the server restart it's going back to the old release Id's version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1636) --<description-property> are no more supported by ls command

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1636: -------------------------------------------- Summary: --<description-property> are no more supported by ls command Key: WFCORE-1636 URL: https://issues.jboss.org/browse/WFCORE-1636 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Alexey Loubyansky - ls -l --storage will make the CLI to throw an exception. storage being not known by the Command runtime. - Furthermore completion is not offered for these options. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1069) UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1069?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1069: ------------------------------------- Do you have a reproducer triggering that exception? If so can you provide it? > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1069) UnsupportedOperationException due to missing blocker in overriding classes FromNodeLeftTuple, JoinNodeLeftTuple

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1069?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1069: ----------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1100) Decision table conversion to DRL logic change in some version later than 6.1.0.Final

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1100?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1100. --------------------------------- Resolution: Rejected 2 patterns in a single CONDITION is unsupported and hence the behaviour is undetermined. In other words you were relying on a previous bug. In this case 2 columns should be used: one for each pattern. > Decision table conversion to DRL logic change in some version later than 6.1.0.Final > ------------------------------------------------------------------------------------ > > Key: DROOLS-1100 > URL: https://issues.jboss.org/browse/DROOLS-1100 > Project: Drools > Issue Type: Bug > Reporter: Vytautas Gimbutas > Assignee: Mario Fusco > Attachments: Screen Shot 2016-03-19 at 8.40.40 PM.png > > > It seems there was a change of how decision tables are converted to DRL in some version later than 6.1.0. See attached screenshot for decision table i'm trying to generate. > In 6.1.0.Final this gets converted to: > {code} > // rule values at C42, header at C37 > rule "X_42" > no-loop true > salience 65494 > when > $p: Project(id == "40098") > $c: Client() > then > modify($c) { incrementPricingStep(2, 8); } > end > {code} > but in 6.4.0.CR1 it gets converted to: > {code} > // rule values at C42, header at C37 > rule "X_42" > no-loop true > salience 65494 > when > $p: Project() > $c: Client(id == "40098") > then > modify($c) { incrementPricingStep(2, 8); } > end > {code} > Maybe this is not intentional and caused by accident? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1100) Decision table conversion to DRL logic change in some version later than 6.1.0.Final

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1100?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1100: ----------------------------------- Assignee: Mario Fusco > Decision table conversion to DRL logic change in some version later than 6.1.0.Final > ------------------------------------------------------------------------------------ > > Key: DROOLS-1100 > URL: https://issues.jboss.org/browse/DROOLS-1100 > Project: Drools > Issue Type: Bug > Reporter: Vytautas Gimbutas > Assignee: Mario Fusco > Attachments: Screen Shot 2016-03-19 at 8.40.40 PM.png > > > It seems there was a change of how decision tables are converted to DRL in some version later than 6.1.0. See attached screenshot for decision table i'm trying to generate. > In 6.1.0.Final this gets converted to: > {code} > // rule values at C42, header at C37 > rule "X_42" > no-loop true > salience 65494 > when > $p: Project(id == "40098") > $c: Client() > then > modify($c) { incrementPricingStep(2, 8); } > end > {code} > but in 6.4.0.CR1 it gets converted to: > {code} > // rule values at C42, header at C37 > rule "X_42" > no-loop true > salience 65494 > when > $p: Project() > $c: Client(id == "40098") > then > modify($c) { incrementPricingStep(2, 8); } > end > {code} > Maybe this is not intentional and caused by accident? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016