January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-998) NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-998?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-998: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1302141|https://bugzilla.redhat.com/show_bug.cgi?id=1302141] from ASSIGNED to MODIFIED > NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > --------------------------------------------------------------------------------------------------------- > > Key: DROOLS-998 > URL: https://issues.jboss.org/browse/DROOLS-998 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.14.04.1) > Reporter: Christian Spurk > Assignee: Mario Fusco > Fix For: 6.4.0.CR1 > > > The following {{NullPointerException}} occurs for the following rule: > {code} > Exception in thread "main" java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.phreak.PhreakAccumulateNode.doLeftDeletes(PhreakAccumulateNode.java:603) > at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:65) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:565) > 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.fire(RuleExecutor.java:142) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > 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 org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109) > at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34) > at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:292) > at Test.main(Test.java:13) > {code} > {code} > rule "test" > when > not( String() ) > accumulate( > Long(); > sum(1) > ) > ( Boolean() or not( Float() ) ) > then > insert(new String()); > end > {code} > (Please ignore the nonsensical rule; I simply couldn't reproduce this issue in any better way without providing you my larger system where the (more complex) rule makes more sense.) > I'm using a default KIE configuration to load the rule: > {{kmodule.xml}}: > {code} > <?xml version="1.0" encoding="UTF-8"?> > <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule" /> > {code} > {{Test.java}}: > {code} > import org.kie.api.KieBase; > import org.kie.api.KieServices; > import org.kie.api.runtime.StatelessKieSession; > import org.kie.internal.command.CommandFactory; > public class Test { > public static void main(String[] args) { > KieBase kieBase = KieServices.Factory.get().getKieClasspathContainer() > .getKieBase(); > StatelessKieSession session = kieBase.newStatelessKieSession(); > session.execute(CommandFactory.newFireAllRules()); > } > } > {code} > This issue might be related with DROOLS-987. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6072) channel.receiveMessage(this); should not be called till all message data is read

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6072?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-6072. ---------------------------------- Resolution: Rejected > channel.receiveMessage(this); should not be called till all message data is read > -------------------------------------------------------------------------------- > > Key: WFLY-6072 > URL: https://issues.jboss.org/browse/WFLY-6072 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2007: -------------------------------- Thanks for the advice, Johno! I'll re-check where I'm using for loops... > Adapt code to use new Java 8 features > ------------------------------------- > > Key: JGRP-2007 > URL: https://issues.jboss.org/browse/JGRP-2007 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > E.g replace loops for forEach() etc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6074) Undertow migration operation does not translate access log patterns

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6074: ------------------------------------ Summary: Undertow migration operation does not translate access log patterns Key: WFLY-6074 URL: https://issues.jboss.org/browse/WFLY-6074 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6075) Undertow migration operation does not translate access log patterns

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6075: ------------------------------------ Summary: Undertow migration operation does not translate access log patterns Key: WFLY-6075 URL: https://issues.jboss.org/browse/WFLY-6075 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6073) WFLY-3551 addition of bv subsystem breaks mixed domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6073?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-6073. ------------------------------------ Resolution: Won't Fix I've changed my mind on this. If a profile including old ee xsd versions is included in a WF 10 domain.xml, there could be two possible scenarios: 1) User wants to migrate that profile for use on WF 10 servers. 2) User wants the profile for use on legacy servers. If I make the change envisioned here, case 1) will break, as BV will not be in the profile, and the user may not even notice. If I don't make the change the user will get errors using the profile on the legacy slaves, but they can fix this by removing the subsystem. Basically, we can't always know the best way to migrate and sometimes need to pick. WFCORE-1311 was different, as an IO worker is always needed, and the question there was just how to declare the config. Here, BV may or may not be wanted. > WFLY-3551 addition of bv subsystem breaks mixed domain > ------------------------------------------------------ > > Key: WFLY-6073 > URL: https://issues.jboss.org/browse/WFLY-6073 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EE > Affects Versions: 10.0.0.CR5 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 10.0.0.Final > > > Same problem as WFCORE-1311 -- to assist migration, a ProfileParsingCompletionHandler adds an extension that a legacy slave won't understand. > I'll do the same thing as I did with WFCORE-1311 -- only do this for a standalone server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4782) ; jsessionid= in URL not supported

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4782?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-4782: -------------------------------------- https://issues.jboss.org/browse/UNDERTOW-621 > ;jsessionid= in URL not supported > --------------------------------- > > Key: WFLY-4782 > URL: https://issues.jboss.org/browse/WFLY-4782 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.CR2 > Environment: Linux/jdk1.7/mysql > Reporter: Micheal Delson Nadar > Assignee: Stuart Douglas > Priority: Blocker > > I get the below url with jsessionid after logging in my application and get "Not Found" > http://xxx.yy.xxx.x:pppp/portal/;jsessionid=dDIsgr_KfIXFBmxvClAWbY2Z.wfst... > if i remove the ;jsessionid=dDIsgr_KfIXFBmxvClAWbY2Z.wfstandalone from url then it works fine... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6071) Mixed domain test suite should test using the legacy domain.xml files

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6071?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6071: -------------------------------------- Assignee: Brian Stansberry > Mixed domain test suite should test using the legacy domain.xml files > --------------------------------------------------------------------- > > Key: WFLY-6071 > URL: https://issues.jboss.org/browse/WFLY-6071 > Project: WildFly > Issue Type: Task > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The mixed domain testsuite is doing a lot of testing starting with the current release standard configs, then manipulating to get to something interoperable, and then launching a slave. > This is fine, but we need explicit coverage of the primary use case: take a config that worked in the legacy release, install it on the DC, and then have the slave start, confirming that the slave was able to join. > This is basically what users will do -- take profiles that worked and try and use them with a current DC and legacy slaves. Trying to take new profiles and adapt them to work on legacy slaves is more of a corner case. And testing that corner case as the primary coverage leads to holes, where the "correction" logic ends up hiding problems that shouldn't be hidden, e.g. WFCORE-1311. > So, for each legacy release we should boot the current DC with the standard domain.xml for that release and then start a legacy slave from that release. > We may need to apply some correction here too, but if we do it's a good opportunity to check why it's necessary, and whether a more user-friendly solution can be found. > That's not 100% coverage as there are things that weren't in our standard domain.xml, but it's a good smoke test. Subsystem specific test suites can check for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1333) Editing of default deployment scanner's relative-to attribute can cause server crash

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1333?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-3054 to WFCORE-1333: ------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1333 (was: JBEAP-3054) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Server) Target Release: (was: 7.0.0.GA) Affects Version/s: 2.0.7.Final (was: 7.0.0.ER4) > Editing of default deployment scanner's relative-to attribute can cause server crash > ------------------------------------------------------------------------------------ > > Key: WFCORE-1333 > URL: https://issues.jboss.org/browse/WFCORE-1333 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.7.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Critical > > Setting value of {{relative-to}} attribute of default deployment scanner on standalone server to a path which does not exists in file system causes server crash. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6073) WFLY-3551 addition of bv subsystem breaks mixed domain

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-6073: -------------------------------------- Summary: WFLY-3551 addition of bv subsystem breaks mixed domain Key: WFLY-6073 URL: https://issues.jboss.org/browse/WFLY-6073 Project: WildFly Issue Type: Bug Components: Domain Management, EE Affects Versions: 10.0.0.CR5 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 10.0.0.Final Same problem as WFCORE-1311 -- to assist migration, a ProfileParsingCompletionHandler adds an extension that a legacy slave won't understand. I'll do the same thing as I did with WFCORE-1311 -- only do this for a standalone server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016