July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3066) NPE in Drools org.drools.core.rule.SingleAccumulate.reverse(SingleAccumulate.java:124)

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-3066?page=com.atlassian.jira.plugi... ] Luca Molteni updated DROOLS-3066: --------------------------------- Sprint: 2019 Week 26-28 (was: 2019 Week 26-28, 2019 Week 29-31) > NPE in Drools org.drools.core.rule.SingleAccumulate.reverse(SingleAccumulate.java:124) > --------------------------------------------------------------------------------------- > > Key: DROOLS-3066 > URL: https://issues.jboss.org/browse/DROOLS-3066 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.1.Final > Environment: Windows 7 > Oracle Java Development Kit 1.8.0_111 > Eclipse Oxygen 3a > Optaplanner 7.4.1.Final > Reporter: Philip Harding > Assignee: Luca Molteni > Priority: Major > Attachments: NPE_Drools_MWE.zip > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The rule > {code:java} > rule "globalRequiredPredecessorAfterMe" > when > $rpAll: Set(size>1) from accumulate ( > Customer(Domicile != null, $rpAfterMe: requiredPredecessorsAfterMe); > collectSet($rpAfterMe) > ) > then > scoreHolder.addMediumConstraintMatch(kcontext, - $rpAll.size()-1); > end > {code} > gives following NPE within the attached Optaplanner model: > {code:java} > Exception in thread "main" java.lang.RuntimeException: java.lang.NullPointerException > at org.drools.core.rule.SingleAccumulate.reverse(SingleAccumulate.java:124) > at org.drools.core.phreak.PhreakAccumulateNode.removeMatch(PhreakAccumulateNode.java:796) > at org.drools.core.phreak.PhreakAccumulateNode.doRightUpdatesProcessChildren(PhreakAccumulateNode.java:517) > at org.drools.core.phreak.PhreakAccumulateNode.doRightUpdates(PhreakAccumulateNode.java:450) > at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:76) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:581) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:552) > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:379) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:339) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:175) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:133) > 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:1337) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1328) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1312) > at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:117) > at org.optaplanner.core.impl.score.director.AbstractScoreDirector.doAndProcessMove(AbstractScoreDirector.java:187) > at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:126) > at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:100) > at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74) > at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:88) > at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:191) > at canihazafischbroetchenplz.app.TestApp.main(TestApp.java:35) > Caused by: java.lang.NullPointerException > at org.drools.core.base.accumulators.CollectSetAccumulateFunction.reverse(CollectSetAccumulateFunction.java:118) > at org.drools.core.base.accumulators.CollectSetAccumulateFunction.reverse(CollectSetAccumulateFunction.java:49) > at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor.reverse(JavaAccumulatorFunctionExecutor.java:133) > at org.drools.core.rule.SingleAccumulate.reverse(SingleAccumulate.java:116) > ... 28 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-2733) Support MVEL Dialect using custom inline accumulate code with external declarations in the executable model

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-2733?page=com.atlassian.jira.plugi... ] Luca Molteni updated DROOLS-2733: --------------------------------- Sprint: 2019 Week 26-28 (was: 2019 Week 26-28, 2019 Week 29-31) > Support MVEL Dialect using custom inline accumulate code with external declarations in the executable model > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2733 > URL: https://issues.jboss.org/browse/DROOLS-2733 > Project: Drools > Issue Type: Feature Request > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Optional > > The executable model doesn't support custom inline accumulate code that uses external declarations such as > {code:java} > String str = "import " + Person.class.getCanonicalName() + ";\n" + > "rule R dialect \"mvel\" when\n" + > " String( $l : length )" + > " $sum : Integer() from accumulate (\n" + > " Person( age > 18, $age : age ), init( int sum = 0 * $l; ), action( sum += $age; ), reverse( sum -= $age; ), result( sum )\n" + > " )" + > "then\n" + > " insert($sum);\n" + > "end"; > {code} > (Notice that in the init we multiply the sum value with the length of string) > But it can support such style using the "classic" generation of accumulate classes which gets compiled among the executable model and instantiate during the execution of the DSL. > This mechanism is broken with the MVEL dialect, as we don't have such generated classes. > Probably what we should do instead is putting MVEL expressions in the DSL directly such as > {code:java} > accumulateScript("initCode", "accCode", "reverseCode"); > {code} > and then during interpretation create a new MVEL context and execute the accumulate in memory > See > AccumulateUnsupportedTest.testMVELAccumulate > AccumulateUnsupportedTest.testMVELAccumulate2WM -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4339) Avoid implicit conversion while accumulating, type is always one returned from the function

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-4339?page=com.atlassian.jira.plugi... ] Luca Molteni resolved DROOLS-4339. ---------------------------------- Resolution: Done > Avoid implicit conversion while accumulating, type is always one returned from the function > ------------------------------------------------------------------------------------------- > > Key: DROOLS-4339 > URL: https://issues.jboss.org/browse/DROOLS-4339 > Project: Drools > Issue Type: Enhancement > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4344) DMN DT Analysis normalize Contractions for complete 2NF check

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4344: -------------------------------------- Summary: DMN DT Analysis normalize Contractions for complete 2NF check Key: DROOLS-4344 URL: https://issues.jboss.org/browse/DROOLS-4344 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Attachments: image-2019-07-19-09-11-29-910.png In a table such as !image-2019-07-19-09-11-29-910.png|thumbnail! rule 3, 6 are not in 2NF and this is already correctly reported. Was missing to report rules 4,5,6 are also violating 2NF because of input 2. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4343) Change FactHandle ID from a Integer into a Long

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4343?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-4343: -------------------------------- Component/s: core engine Tester: Tibor Zimanyi Description: Change FactHandle ID from a Integer into a Long keeping backward compatibility of serialized KieSession. Story Points: 5 Sprint: 2019 Week 29-31 > Change FactHandle ID from a Integer into a Long > ----------------------------------------------- > > Key: DROOLS-4343 > URL: https://issues.jboss.org/browse/DROOLS-4343 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > > Change FactHandle ID from a Integer into a Long keeping backward compatibility of serialized KieSession. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4343) Change FactHandle ID from a Integer into a Long

by Mario Fusco (Jira)

Mario Fusco created DROOLS-4343: ----------------------------------- Summary: Change FactHandle ID from a Integer into a Long Key: DROOLS-4343 URL: https://issues.jboss.org/browse/DROOLS-4343 Project: Drools Issue Type: Enhancement Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12299) More fine grain dependency for galleon basic layers

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12299?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12299: ----------------------------------------- Back to "what makes a xxx-server"... I think it does work triggered by external activity of some sort or has some sort of internal trigger. It handles the triggering event, so its layer includes/depends on whatever is needed for that. web-server ejb-server (remote session beans; listens for requests) mdb-server (pulls messages from a broker) batch-server messaging-server If we limit ourselves to cases that involve deployments, then messaging-server comes off the list. (Which is fine; Artemis itself provides a server; wrapping it in WF for no users other than external clients is an anti-pattern.) Since they all involve deployments, they all get deployment-scanner just to keep it simple. Then the other layers are either 1) dependencies of servers 2) "decorators" of one particular server (and thus can depend on it) -- e.g. jax-rs, webservices, jsf 3) "decorators" for potentially many servers (and thus don't depend on them) -- cdi, jpa, lots of stuff And then a xxx-profile is a server + a set of decorators. > More fine grain dependency for galleon basic layers > --------------------------------------------------- > > Key: WFLY-12299 > URL: https://issues.jboss.org/browse/WFLY-12299 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > Having basic layers to only depend on the layers (and features) they do require will offer more flexibility than depending on web-server layer. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12301) CallerPrincipal will be anonymous (randomly) if EJB2 is called

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12301?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-12301: ------------------------------ Component/s: Security > CallerPrincipal will be anonymous (randomly) if EJB2 is called > -------------------------------------------------------------- > > Key: WFLY-12301 > URL: https://issues.jboss.org/browse/WFLY-12301 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 17.0.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Cheng Fang > Priority: Major > Labels: EJB2, security > Attachments: reproducer.zip > > > An EJB application which call an EJB2 SLSB will fail (randomly) to show the correct user if getCallerPrincipal is used inside. Also the roles are not set. > The EJB2 Bean is secured by ejb-jar.xml so it is not expected that it will be called without role > <assembly-descriptor> > <method-permission> > <role-name>testRole</role-name> > <method> > <ejb-name>simpleejb.server.SomeEJB2Bean</ejb-name> > <method-intf>Remote</method-intf> > <method-name>*</method-name> > </method> > </method-permission> > This error is constant seen if the server is up and running but each restart will change the behaviour randomly. > Note that an EJB3 bean of the same EAR file will work always correctly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12299) More fine grain dependency for galleon basic layers

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12299?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12299: ----------------------------------------- [~jdenise] In the above, I think a 'jaxrs-server' would only differ from 'jaxrs' in not having a dependency on deployment-scanner. Otherwise all the layers in 'web-server' are things a JAX-RS app would need. I'm doubtful about having two variants just to include/exclude the scanner. Tangent -- what do you think makes a "xxx-server"? (Let's ignore core-server for now). I'll try and come back later and brainstorm about that... > More fine grain dependency for galleon basic layers > --------------------------------------------------- > > Key: WFLY-12299 > URL: https://issues.jboss.org/browse/WFLY-12299 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > Having basic layers to only depend on the layers (and features) they do require will offer more flexibility than depending on web-server layer. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12299) More fine grain dependency for galleon basic layers

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12299?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12299: ----------------------------------------- jfdenise yesterday Author Member @bstansberry , now that I see these "mini aggregations" of web-server+feature, it looks wrong. We are loosing some flexibility to make layers "simpler" to use. Having to express web-server in some cases is not that difficult and makes sense. For future layers definition it would create, as you noted, some un-necessary complexity. This transactions layer should depend on elytron+ee (it needs it in order to set use-transaction-setup-provider). I would be ready to open another JIRA and update layers and doc with the removal of web-server for all layers that don't 100% require a web-server. If we keep the web-server dependency for jaxrs, we could possibly rename it to be "jaxrs-server" that would be the aggregation, jaxrs layer would not depend on web-server (for very exotic case). That would seem more homogeneous. We would keep the rule that all layers identified to be used from user configuration should be provisioned and runnable alone (even if they don't offer any valid feature). > More fine grain dependency for galleon basic layers > --------------------------------------------------- > > Key: WFLY-12299 > URL: https://issues.jboss.org/browse/WFLY-12299 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > Having basic layers to only depend on the layers (and features) they do require will offer more flexibility than depending on web-server layer. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2019