March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-740) NoSuchMethodError at runtime while evaluating String and Long

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-740?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-740: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1202365|https://bugzilla.redhat.com/show_bug.cgi?id=1202365] from ASSIGNED to MODIFIED > NoSuchMethodError at runtime while evaluating String and Long > ------------------------------------------------------------- > > Key: DROOLS-740 > URL: https://issues.jboss.org/browse/DROOLS-740 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Fix For: 6.3.0.Beta1 > > > When you write a LHS like this, > {noformat} > Person( name == "Elizabeth" + new Long(2L) ) > {noformat} > you will face NoSuchMethodError after 20 times evaluation. > {noformat} > testJittedConstraintStringAndLong(org.drools.compiler.integrationtests.Misc2Test) Time elapsed: 1.216 sec <<< ERROR! > java.lang.NoSuchMethodError: java.lang.StringBuilder.append(Ljava/lang/Long;)Ljava/lang/StringBuilder; > at ConditionEvaluator80a8832efb1646d488df2cde72963f02.evaluate(Unknown Source) > at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230) > at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187) > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141) > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) > at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:294) > at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:255) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:277) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:237) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1495) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1450) > at org.drools.compiler.integrationtests.Misc2Test.testJittedConstraintStringAndLong(Misc2Test.java:7253) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-718) Reloading KJAR which contains DSL and RDSLR via KieScanner fails.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-718?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-718: ------------------------------------------------ Tibor Zimanyi <tzimanyi(a)redhat.com> changed the Status of [bug 1195125|https://bugzilla.redhat.com/show_bug.cgi?id=1195125] from ON_QA to VERIFIED > Reloading KJAR which contains DSL and RDSLR via KieScanner fails. > ----------------------------------------------------------------- > > Key: DROOLS-718 > URL: https://issues.jboss.org/browse/DROOLS-718 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR4 > Environment: Mac OS X 10.10.2, Oracle HotSpot 1.7.0_71 > Reporter: Duncan Doyle > Assignee: Mario Fusco > > When using the KieScanner to reload a KJAR with a DSL and RDSLR, reloading fails due to that the compiler is unable to find mappings for the language in the RDSLR. > This is the error I get in my reproducer: > 2015-02-18 00:45:02,764 [ERROR] [main] [org.drools.compiler.kie.builder.impl.KieContainerImpl] ERROR Unable to update KieBase: KBase1 to release org.kie:scanner-test:1.0-SNAPSHOT > [7] No mapping entries for expanding: There is a SimpleFact > [7] Unable to expand: There is a SimpleFact > [8] No mapping entries for expanding: -with id "2" > [8] Unable to expand: -with id "2" > [10] No mapping entries for expanding: Print "Found a simple fact with id 2." > [10] Unable to expand: Print "Found a simple fact with id 2." > [7,7]: [ERR 102] Line 7:7 mismatched input 'is' in rule "bla" > Reproducer project can be found here: https://github.com/DuncanDoyle/brms-kjar-with-dsl-kiescanner > Just clone the repo and run 'mvn clean test'. > Note that the reproducer creates the first KJAR, runs test, and then creates the second KJAR. Compilation of the second KJAR fails. When you alter the test to only load the second KJAR, everything works fine. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-741) 6.3.0-SNAPSHOT build error. setOrganization... no longer a method of RepoRequest

by Frank Norman (JIRA)

Frank Norman created DROOLS-741: ----------------------------------- Summary: 6.3.0-SNAPSHOT build error. setOrganization... no longer a method of RepoRequest Key: DROOLS-741 URL: https://issues.jboss.org/browse/DROOLS-741 Project: Drools Issue Type: Bug Reporter: Frank Norman Assignee: Mark Proctor Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3886) add org.jboss.remote-naming dep to org.hornetq.ra module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3886?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3886: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1202440, https://bugzilla.redhat.com/show_bug.cgi?id=1202441 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1202440) > add org.jboss.remote-naming dep to org.hornetq.ra module > -------------------------------------------------------- > > Key: WFLY-3886 > URL: https://issues.jboss.org/browse/WFLY-3886 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Add an optional dependency to org.jboss.remote-naming to the org.hornetq.ra to be able to create a RA that connects to a remote hornetq-server. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3886) add org.jboss.remote-naming dep to org.hornetq.ra module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3886?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3886: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1202440 > add org.jboss.remote-naming dep to org.hornetq.ra module > -------------------------------------------------------- > > Key: WFLY-3886 > URL: https://issues.jboss.org/browse/WFLY-3886 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Add an optional dependency to org.jboss.remote-naming to the org.hornetq.ra to be able to create a RA that connects to a remote hornetq-server. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4384) ContextService (JSR236): transactional context always suspended

by Maxim Frolov (JIRA)

[ https://issues.jboss.org/browse/WFLY-4384?page=com.atlassian.jira.plugin.... ] Maxim Frolov closed WFLY-4384. ------------------------------ Resolution: Rejected It works as defined by the specification. See also: https://java.net/projects/concurrency-ee-spec/lists/users/archive/2015-03... > ContextService (JSR236): transactional context always suspended > --------------------------------------------------------------- > > Key: WFLY-4384 > URL: https://issues.jboss.org/browse/WFLY-4384 > Project: WildFly > Issue Type: Bug > Components: EE > Affects Versions: 8.2.0.Final, 9.0.0.Alpha1 > Reporter: Maxim Frolov > Assignee: Eduardo Martins > Priority: Critical > > According to §3.3.5 of JSR-236 specification: > ??By using an execution property when creating the contextual proxy object, application components can choose to not suspend the transactional context on the thread ...?? > Given the following EJB and Task: > {code:java} > @WebService(serviceName = "Jsr236WebService") > @Stateless > public class Jsr236WebService { > @Inject Jsr236ManagedTask jsr236ManagedTask; > @Resource ManagedExecutorService executor; > @Resource ContextService contextService; > > @WebMethod(operationName = "hello") > public String hello(@WebParam(name = "name") String txt) { > Map<String, String> execProps = new HashMap<>(); > execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD); > Future<String> future = executor.submit( > contextService.createContextualProxy(jsr236ManagedTask, execProps, Callable.class)); > try { > return future.get(); > } catch (InterruptedException | ExecutionException e) { > throw new RuntimeException(e); > } > } > } > {code} > {code:java} > @Dependent > @Transactional(Transactional.TxType.MANDATORY) > public class Jsr236ManagedTask implements Callable<String>, ManagedTask { > @Override > public String call() { > return "called"; > } > @Override > public Map<String, String> getExecutionProperties() { > Map<String, String> execProps = new HashMap<>(); > execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD); > return execProps; > } > } > {code} > When the {{call()}} Method of the task is called the following exception occurs: > {noformat} > javax.transaction.TransactionalException: ARJUNA016110: Transaction is required for invocation > {noformat} > See maven test project [https://github.com/wrungel/bugs/tree/master/jsr236-test] on GitHub. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-95) RemotingConnector violates JMXConnector#connect contract and leads to threads hanging around

by Sergiy Barlabanov (JIRA)

[ https://issues.jboss.org/browse/REMJMX-95?page=com.atlassian.jira.plugin.... ] Sergiy Barlabanov updated REMJMX-95: ------------------------------------ Summary: RemotingConnector violates JMXConnector#connect contract and leads to threads hanging around (was: RemotingConnector violates JMXConnector#connect contract and leads to thread explosion) > RemotingConnector violates JMXConnector#connect contract and leads to threads hanging around > -------------------------------------------------------------------------------------------- > > Key: REMJMX-95 > URL: https://issues.jboss.org/browse/REMJMX-95 > Project: Remoting JMX > Issue Type: Feature Request > Components: Connection > Affects Versions: 2.0.0.Final > Environment: Wildfly 8.2.0 > Reporter: Sergiy Barlabanov > Assignee: Darran Lofthouse > > The javadoc of javax.management.remote.JMXConnector#connect says that "If connect has already been called successfully on this object, calling it again has no effect.". > But this does not work with org.jboss.remotingjmx.RemotingConnector. Every connect result in a creation of a remoting endpoint with the corresponding io/worker threads, which are not closed when close() method is called. Only the threads from the first connect() invocation are closed, all threads created from the subsequent connect() invocations are not closed and stay alive until the VM shutdown. > Our application currently crashes after 10 minutes running - it pulls some JMX data periodically and after some time, the VM refuses to create new threads. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-95) RemotingConnector violates JMXConnector#connect contract and leads to thread explosion

by Sergiy Barlabanov (JIRA)

Sergiy Barlabanov created REMJMX-95: --------------------------------------- Summary: RemotingConnector violates JMXConnector#connect contract and leads to thread explosion Key: REMJMX-95 URL: https://issues.jboss.org/browse/REMJMX-95 Project: Remoting JMX Issue Type: Feature Request Components: Connection Affects Versions: 2.0.0.Final Environment: Wildfly 8.2.0 Reporter: Sergiy Barlabanov Assignee: Darran Lofthouse The javadoc of javax.management.remote.JMXConnector#connect says that "If connect has already been called successfully on this object, calling it again has no effect.". But this does not work with org.jboss.remotingjmx.RemotingConnector. Every connect result in a creation of a remoting endpoint with the corresponding io/worker threads, which are not closed when close() method is called. Only the threads from the first connect() invocation are closed, all threads created from the subsequent connect() invocations are not closed and stay alive until the VM shutdown. Our application currently crashes after 10 minutes running - it pulls some JMX data periodically and after some time, the VM refuses to create new threads. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-740) NoSuchMethodError at runtime while evaluating String and Long

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-740?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-740: ------------------------------------------------ Edson Tirelli <etirelli(a)redhat.com> changed the Status of [bug 1202365|https://bugzilla.redhat.com/show_bug.cgi?id=1202365] from MODIFIED to ASSIGNED > NoSuchMethodError at runtime while evaluating String and Long > ------------------------------------------------------------- > > Key: DROOLS-740 > URL: https://issues.jboss.org/browse/DROOLS-740 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Fix For: 6.3.0.Beta1 > > > When you write a LHS like this, > {noformat} > Person( name == "Elizabeth" + new Long(2L) ) > {noformat} > you will face NoSuchMethodError after 20 times evaluation. > {noformat} > testJittedConstraintStringAndLong(org.drools.compiler.integrationtests.Misc2Test) Time elapsed: 1.216 sec <<< ERROR! > java.lang.NoSuchMethodError: java.lang.StringBuilder.append(Ljava/lang/Long;)Ljava/lang/StringBuilder; > at ConditionEvaluator80a8832efb1646d488df2cde72963f02.evaluate(Unknown Source) > at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230) > at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187) > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141) > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) > at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:294) > at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:255) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:277) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:237) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1495) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1450) > at org.drools.compiler.integrationtests.Misc2Test.testJittedConstraintStringAndLong(Misc2Test.java:7253) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4164) New JTS record types are not showing up in the CLI

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-4164?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-4164: ------------------------------------- Fixed in Narayana 5.0.5-SNAPSHOT (master) - needs release and version upgrade > New JTS record types are not showing up in the CLI > -------------------------------------------------- > > Key: WFLY-4164 > URL: https://issues.jboss.org/browse/WFLY-4164 > Project: WildFly > Issue Type: Enhancement > Components: CLI, Transactions > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > We need to expose the new JTS record types in the tooling: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} > We need these because if a transaction ends up in a heuristic state we can't actually view this using the CLI even though the records are in the object store. This has the consequence that a transaction can remain in the object store indefinitely. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 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 March 2015