July 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-157) drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-157?page=com.atlassian.jira.plugin... ] Geoffrey De Smet updated DROOLS-157: ------------------------------------ Summary: drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time (was: drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 or higher) > drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time > ------------------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-157 > URL: https://issues.jboss.org/browse/DROOLS-157 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Marcel May > Assignee: Geoffrey De Smet > Priority: Trivial > Labels: maven > > drools-compiler uses antlr 3.3 but has an additional dependency on old antlr:antlr 2.7.7 version. > The v2 dependency is obsolete since antlr 3.1 (see http://www.antlr.org/jira/browse/ANTLR-180). > Please remove the antlr:antlr dependency, for the next 5.2.x / 5.3.x release - thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-157) drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-157?page=com.atlassian.jira.plugin... ] Geoffrey De Smet updated DROOLS-157: ------------------------------------ Priority: Critical (was: Trivial) > drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time > ------------------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-157 > URL: https://issues.jboss.org/browse/DROOLS-157 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Marcel May > Assignee: Geoffrey De Smet > Priority: Critical > Labels: maven > > drools-compiler uses antlr 3.3 but has an additional dependency on old antlr:antlr 2.7.7 version. > The v2 dependency is obsolete since antlr 3.1 (see http://www.antlr.org/jira/browse/ANTLR-180). > Please remove the antlr:antlr dependency, for the next 5.2.x / 5.3.x release - thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-157) drools-compiler depends on antlr 2.7.7. Upgrade to antlr 3.4 or higher

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-157?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on DROOLS-157: ----------------------------------------- Still an issue: {code} [INFO] --- maven-dependency-plugin:2.5:tree (default-cli) @ drools-compiler --- [INFO] org.drools:drools-compiler:bundle:6.0.0-SNAPSHOT ... [INFO] +- org.antlr:antlr-runtime:jar:3.3:compile [INFO] +- org.antlr:antlr:jar:3.3:compile [INFO] +- org.antlr:stringtemplate:jar:3.2.1:compile [INFO] +- antlr:antlr:jar:2.7.7:compile [INFO] +- org.antlr:gunit:jar:3.3:test {code} > drools-compiler depends on antlr 2.7.7. Upgrade to antlr 3.4 or higher > ---------------------------------------------------------------------- > > Key: DROOLS-157 > URL: https://issues.jboss.org/browse/DROOLS-157 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Marcel May > Assignee: Geoffrey De Smet > Priority: Trivial > Labels: maven > > drools-compiler uses antlr 3.3 but has an additional dependency on old antlr:antlr 2.7.7 version. > The v2 dependency is obsolete since antlr 3.1 (see http://www.antlr.org/jira/browse/ANTLR-180). > Please remove the antlr:antlr dependency, for the next 5.2.x / 5.3.x release - thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-157) drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 or higher

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-157?page=com.atlassian.jira.plugin... ] Geoffrey De Smet updated DROOLS-157: ------------------------------------ Summary: drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 or higher (was: drools-compiler depends on antlr 2.7.7. Upgrade to antlr 3.4 or higher) > drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 or higher > ------------------------------------------------------------------------------ > > Key: DROOLS-157 > URL: https://issues.jboss.org/browse/DROOLS-157 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Marcel May > Assignee: Geoffrey De Smet > Priority: Trivial > Labels: maven > > drools-compiler uses antlr 3.3 but has an additional dependency on old antlr:antlr 2.7.7 version. > The v2 dependency is obsolete since antlr 3.1 (see http://www.antlr.org/jira/browse/ANTLR-180). > Please remove the antlr:antlr dependency, for the next 5.2.x / 5.3.x release - thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1654) Register WeldTerminalListener

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-1654?page=com.atlassian.jira.plugin.... ] Jozef Hartinger commented on WFLY-1654: --------------------------------------- Now that WFLY-1653 has been resolved this issue is not blocked any longer > Register WeldTerminalListener > ----------------------------- > > Key: WFLY-1654 > URL: https://issues.jboss.org/browse/WFLY-1654 > Project: WildFly > Issue Type: Task > Components: CDI / Weld > Affects Versions: 8.0.0.Alpha2 > Reporter: Jozef Hartinger > Assignee: Marko Lukša > Fix For: 8.0.0.Beta1 > > > This fixes WELD-1269. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-152) NPE during benchmark in LeftTupleIndexRBTree.remove

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-152?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on DROOLS-152: ----------------------------------------- [~arno_hernach] Sorry, I lost track of this issue. Could you verify if you still have the issue with 6.0.0.Beta5 or 6.0.0.CR1 (which is about to go out)? > NPE during benchmark in LeftTupleIndexRBTree.remove > --------------------------------------------------- > > Key: DROOLS-152 > URL: https://issues.jboss.org/browse/DROOLS-152 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Beta2 > Reporter: Arno Hernach > Assignee: Geoffrey De Smet > Attachments: tournament_scheduling_system_gui.zip > > > Exception in thread "main" java.lang.NullPointerException > at org.drools.core.util.index.LeftTupleIndexRBTree.remove(LeftTupleIndexRBTree.java:63) > at org.drools.core.reteoo.ExistsNode.modifyRightTuple(ExistsNode.java:388) > at org.drools.core.reteoo.BetaNode.modifyObject(BetaNode.java:673) > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:508) > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:433) > at org.drools.core.reteoo.AlphaNode.modifyObject(AlphaNode.java:161) > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateModifyObject(SingleObjectSinkAdapter.java:69) > at org.drools.core.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:386) > at org.drools.core.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:294) > at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:505) > at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:393) > at org.drools.core.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:903) > at org.drools.core.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:872) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:294) > at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:131) > at org.optaplanner.core.impl.heuristic.selector.move.generic.SwapMove.doMove(SwapMove.java:81) > at org.optaplanner.core.impl.localsearch.decider.DefaultDecider.doMove(DefaultDecider.java:143) > at org.optaplanner.core.impl.localsearch.decider.DefaultDecider.decideNextStep(DefaultDecider.java:116) > at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) > at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) > at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) > at org.optaplanner.benchmark.impl.ProblemBenchmark.warmUp(ProblemBenchmark.java:163) > at org.optaplanner.benchmark.impl.DefaultPlannerBenchmark.warmUp(DefaultPlannerBenchmark.java:244) > at org.optaplanner.benchmark.impl.DefaultPlannerBenchmark.benchmark(DefaultPlannerBenchmark.java:189) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-186) Enforce maven 3.0.5+ to build droolsjbpm

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-186?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-186. ------------------------------------------- Labels: maven (was: ) Resolution: Done > Enforce maven 3.0.5+ to build droolsjbpm > ---------------------------------------- > > Key: DROOLS-186 > URL: https://issues.jboss.org/browse/DROOLS-186 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Labels: maven > Fix For: 6.0.0.CR1 > > > Reasons: > - To have stable, reproducible builds, it's important that no one is building this our project with bugs that already fixed in a newer maven version (while others don't see those bugs because they build with the latest). > - Also see the dangerous issue described on thecore list: "mvn 3.0.4+ vs 3.0.3 - different dependency resolution ?!" > TODO list: > - The change itself in the sources is simple. Open droolsjbpm-parent and change the enforcer-plugin like this > {code} > <requireMavenVersion> > <version>[3.0.5,)</version> > </requireMavenVersion> > {code} > Notify porcelli to do the same for uberfire. > - Bigger issue is communicating this change to the team. Expect that many people still to use 3.0.3 and 3.0.4 and suddenly "won't be able to build". Send them an advance notice before pushing the change. Expect some people not to read that and to complain anyway - so push early in the morning and watch the IRC so you can help them :) > - Last, but not least: configure all jenkins jobs for droolsjbpm master to use maven 3.0.5 or they 'll start failing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-199) The entire kie build should work on maven 3.1.0 too

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-199: --------------------------------------- Summary: The entire kie build should work on maven 3.1.0 too Key: DROOLS-199 URL: https://issues.jboss.org/browse/DROOLS-199 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Reporter: Geoffrey De Smet Assignee: Michael Biarnes Kiefer To reproduce: - Install maven 3.1.0 - Run mvn-all.sh clean install -Dfull Note: Any changes to the pom must still allow them to run with 3.0.5 too. 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). 2) There might be other surprises... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1665) UNICAST3 / NAKACK2: problem with flow control and message batching

by Bela Ban (JIRA)

Bela Ban created JGRP-1665: ------------------------------ Summary: UNICAST3 / NAKACK2: problem with flow control and message batching Key: JGRP-1665 URL: https://issues.jboss.org/browse/JGRP-1665 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Critical Fix For: 3.3.4, 3.4 When a message is received by UNICAST3 or NAKACK2 and passed up to the application, but the app in turn sends large amounts of data down, then it may block in the flow control protocol (UFC or MFC). We did remove ignore_sync_response (in https://issues.jboss.org/browse/JGRP-1655), which would let sync responses pass through flow control, assuming that credit responses would be received as OOBs. However, the issue with credits being received as part of *message batches* is that they're received as *internal* batches, not *OOB* batches. This means that they are delivered sequentially (since they're from the same sender) and are thus not applied until *after* the blocking request returns, which is not the case: deadlock ! The reason is that credits are marked as INTERNAL (and also OOB), but the code which reads batches adds all INTERNAL|OOB messages to the internal batch, which is processed by the internal pool, but since the batch itself is not tagged as OOB, the messages will not get processed immediately. SOLUTION: treat INTERNAL the same as OOB, e.g. check for OOB and INTERNAL: {code} if(batch.mode() == INTERNAL || batch.mode() == OOB) {code} An alternative would be to revisit the idea of the internal thread pool: is it really needed ? And possibly get rid of it. Git bisect shows the faulty commit on July 16: {noformat} [linux]/home/bela/JGroups$ git bisect good 87cf70d936bb3b15860bf4cd89fe2fff49e85d1e is the first bad commit commit 87cf70d936bb3b15860bf4cd89fe2fff49e85d1e Author: Bela Ban <belaban(a)yahoo.com> Date: Tue Jul 16 14:51:10 2013 +0200 Removed ignore_synchronous_thread and ignore_thread from FlowControl; not needed anymore as we cannot block anymore on credit responses (https://issues.jboss.org/browse/JGRP-1655) :040000 040000 d0e4647ab4b89d320e45a460f0385311e2e4eba0 fefac0eb21ab3609ccf440eec9ec8f659a819f6b M src {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1737) org.jboss.as.model.test.ModelTestUtils String[] is incompatible with expected argument type String

by Filipe Ferraz (JIRA)

[ https://issues.jboss.org/browse/WFLY-1737?page=com.atlassian.jira.plugin.... ] Filipe Ferraz edited comment on WFLY-1737 at 7/23/13 3:12 AM: -------------------------------------------------------------- Changing the pe.getKeyValuePair() to pe.getKey() can resolve this bug? children is a set<String> of names and the pe.getkey() return the name (String) that can be verified if exists in the set was (Author: filipeferraz): Changing the pe.getKeyValuePair() to pe.getKey() can resolve this bug? children is a set<String> of names and the pe.getkey() return the name (String) that can be verified if exits in the set > org.jboss.as.model.test.ModelTestUtils String[] is incompatible with expected argument type String > -------------------------------------------------------------------------------------------------- > > Key: WFLY-1737 > URL: https://issues.jboss.org/browse/WFLY-1737 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Tomaz Cerar > Fix For: 8.0.0.Beta1 > > > children is a Set<String>, but pe.getKeyValuePair() is String[], so it will always return false. > {code} > } else { > if (children.contains(pe.getKeyValuePair())) { > String name = pe.getValue(); > ModelNode value = model.get(pe.getKeyValuePair()); > ManagementResourceRegistration sub = rr.getSubModel(PathAddress.pathAddress(pe)); > Assert.assertNotNull(getComparePathAsString(stack) + " Child with name '" + name + "' not found", sub); > if (value.isDefined()) { > stack.push(pe); > checkModelAgainstDefinition(value, sub, stack); > stack.pop(); > } > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 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 2013