December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-37) Operators on java.lang.Comparable object doesn't work if JIT is enable

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-37?page=com.atlassian.jira.plugin.... ] Mario Fusco commented on DROOLS-37: ----------------------------------- Do you have a reproducer for this issue? > Operators on java.lang.Comparable object doesn't work if JIT is enable > ---------------------------------------------------------------------- > > Key: DROOLS-37 > URL: https://issues.jboss.org/browse/DROOLS-37 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Windows XP > Java 1.5 > joda-time 1.6.2 > Reporter: Jérémy SOULA > Assignee: Mario Fusco > Labels: 5.5, comparable, localDate > Fix For: 5.5.1.Final, 6.0.0.Alpha9 > > Attachments: drools-bugs.zip > > > In my application, i have rules that used org.joda.time.LocalDate to compare date like > {noformat} > rule "toto" > when > LocalDateForDroolsTestBean( > infDate>=supDate > ) > then > //Anything > end > {noformat} > With Drools 5.3, all works fine. > With Drools 5.5, an exception occured because JIT optimizer automaticaly enabled: > {noformat} > Exception in thread "main" java.lang.NoSuchMethodError: org.joda.time.LocalDate.compareTo(Lorg/joda/time/LocalDate;)I > at ConditionEvaluatorf8ba8fa3003345adbf3979e901488f23.evaluate(Unknown Source) > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200) > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157) > at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137) > at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) > at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269) > at org.drools.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:304) > at fr.jsoula.jboss.drools.bugs.comparable.ComparableBug.main(ComparableBug.java:39) > {noformat} > After search, it seems that the bytecode generated by org.drools.rule.builder.dialect.asm.ClassGenerator can't call the method public int compareTo(Object partial) of org.joda.time.LocalDate. The parameter of the method must be the same class of the current object. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-37) Operators on java.lang.Comparable object doesn't work if JIT is enable

by stevearoonie (JIRA)

[ https://issues.jboss.org/browse/DROOLS-37?page=com.atlassian.jira.plugin.... ] stevearoonie commented on DROOLS-37: ------------------------------------ I just got this error using the 5.5.1 snapshot. Looking at the source for the fix it seems as though it was around parameterized types, however joda LocalDates are not parameterized. > Operators on java.lang.Comparable object doesn't work if JIT is enable > ---------------------------------------------------------------------- > > Key: DROOLS-37 > URL: https://issues.jboss.org/browse/DROOLS-37 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Windows XP > Java 1.5 > joda-time 1.6.2 > Reporter: Jérémy SOULA > Assignee: Mario Fusco > Labels: 5.5, comparable, localDate > Fix For: 5.5.1.Final, 6.0.0.Alpha9 > > Attachments: drools-bugs.zip > > > In my application, i have rules that used org.joda.time.LocalDate to compare date like > {noformat} > rule "toto" > when > LocalDateForDroolsTestBean( > infDate>=supDate > ) > then > //Anything > end > {noformat} > With Drools 5.3, all works fine. > With Drools 5.5, an exception occured because JIT optimizer automaticaly enabled: > {noformat} > Exception in thread "main" java.lang.NoSuchMethodError: org.joda.time.LocalDate.compareTo(Lorg/joda/time/LocalDate;)I > at ConditionEvaluatorf8ba8fa3003345adbf3979e901488f23.evaluate(Unknown Source) > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200) > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157) > at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137) > at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) > at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269) > at org.drools.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:304) > at fr.jsoula.jboss.drools.bugs.comparable.ComparableBug.main(ComparableBug.java:39) > {noformat} > After search, it seems that the bytecode generated by org.drools.rule.builder.dialect.asm.ClassGenerator can't call the method public int compareTo(Object partial) of org.joda.time.LocalDate. The parameter of the method must be the same class of the current object. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2609) ExtensionRegistry.DeploymentManagementResourceRegistration returns incorrect type from getSubModel

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-2609: -------------------------------------- Summary: ExtensionRegistry.DeploymentManagementResourceRegistration returns incorrect type from getSubModel Key: WFLY-2609 URL: https://issues.jboss.org/browse/WFLY-2609 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 8.0.0.Beta1 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 8.0.0.CR1 DeploymentManagementResourceRegistration.getSubModel() and getOverrideModel() are not returning another DeploymentManagementResourceRegistration. Instead they are returning the normal ManagementResourceRegistration in the "deployments" tree. The effect of this is if getSubModel() is called, and then the returned MRR is modified, the modification only happens in the deployment tree instead of being copied to both it and the subdeployment tree by the special DeploymentManagementResourceRegistration logic. This is showing up as an issue in the JPA subsystem, which defers registration of part of its model and calls getSubModel() when it needs to do the registration. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1124) Eclipse plugin update for resource adapter 1.1

by Lin Gao (JIRA)

Lin Gao created JBJCA-1124: ------------------------------ Summary: Eclipse plugin update for resource adapter 1.1 Key: JBJCA-1124 URL: https://issues.jboss.org/browse/JBJCA-1124 Project: IronJacamar Issue Type: Task Components: Eclipse Reporter: Lin Gao Assignee: Jeff Zhang Update eclipse plugin with new features included in resource adapter 1.1 schema, which includes: * an id attribute in resource-adapter * work manager security configuration * initial-pool-size for the pool configuration * capacity for the pool configuration -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1124) Eclipse plugin update for resource adapter 1.1

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1124?page=com.atlassian.jira.plugin... ] Lin Gao reassigned JBJCA-1124: ------------------------------ Assignee: Lin Gao (was: Jeff Zhang) > Eclipse plugin update for resource adapter 1.1 > ---------------------------------------------- > > Key: JBJCA-1124 > URL: https://issues.jboss.org/browse/JBJCA-1124 > Project: IronJacamar > Issue Type: Task > Components: Eclipse > Reporter: Lin Gao > Assignee: Lin Gao > > Update eclipse plugin with new features included in resource adapter 1.1 schema, which includes: > * an id attribute in resource-adapter > * work manager security configuration > * initial-pool-size for the pool configuration > * capacity for the pool configuration -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-82) Generate source in a more deterministic order

by James Perkins (JIRA)

James Perkins created LOGTOOL-82: ------------------------------------ Summary: Generate source in a more deterministic order Key: LOGTOOL-82 URL: https://issues.jboss.org/browse/LOGTOOL-82 Project: Log Tool Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins The generated source does not always generate the source in the same order. Creating a more deterministic order of the generated methods and fields would likely be better. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2451) Allow basic WS subsystem updates without requiring reload

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-2451?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-2451: --------------------------------------- Work completed and on hold at https://github.com/asoldano/wildfly/commits/update-attributes . Waiting for next WFLY version development to be started. > Allow basic WS subsystem updates without requiring reload > --------------------------------------------------------- > > Key: WFLY-2451 > URL: https://issues.jboss.org/browse/WFLY-2451 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 9.0.0.CR1 > > > Currently any change to the WS subsystem model requires reload for being applied to the runtime. > It should be possible to actually perform some runtime updates without reload in some situations, basically when there's no WS deployment active yet. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2451) Allow basic WS subsystem updates without requiring reload

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-2451?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-2451: ---------------------------------- Fix Version/s: 9.0.0.CR1 > Allow basic WS subsystem updates without requiring reload > --------------------------------------------------------- > > Key: WFLY-2451 > URL: https://issues.jboss.org/browse/WFLY-2451 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 9.0.0.CR1 > > > Currently any change to the WS subsystem model requires reload for being applied to the runtime. > It should be possible to actually perform some runtime updates without reload in some situations, basically when there's no WS deployment active yet. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2608) MDB not receiving messages from JMS queue.

by Corey Puffalt (JIRA)

Corey Puffalt created WFLY-2608: ----------------------------------- Summary: MDB not receiving messages from JMS queue. Key: WFLY-2608 URL: https://issues.jboss.org/browse/WFLY-2608 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS Affects Versions: 8.0.0.Beta1 Reporter: Corey Puffalt Assignee: Jeff Mesnil Priority: Blocker We've run into a situation where MDBs stopped receiving messages from a JMS queue although the JMS queue itself was continuing to receive new messages from an EJB. The forum thread referenced below has more background information but basically at some point we see the following in our server logs: {code} 00:50:28,915 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3] 00:50:29,208 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653 00:50:29,235 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653 [the above two messages are repeated a number of times in rapid succession...and then finally we get...] 00:50:30,187 WARN [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-18647 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected] at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] 00:50:29,240 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-18651 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected] at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] 00:50:38,633 INFO [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) Starting RecoveryDiscovery on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null] 00:50:38,636 INFO [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) RecoveryDiscovery started fine on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null] {code} After this our MDB never receives any further messages until a server restart. HornetQ should be recovering from this situation (whatever the cause). -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2595) Logging DUP leaking class loaders

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2595?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2595: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1038305 > Logging DUP leaking class loaders > --------------------------------- > > Key: WFLY-2595 > URL: https://issues.jboss.org/browse/WFLY-2595 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 8.0.0.CR1 > > > When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL. > The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector. -- 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

12 years, 7 months

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