September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7071) use-try-lock option in data source configuration files is ignored

by Mike Conner (JIRA)

use-try-lock option in data source configuration files is ignored ----------------------------------------------------------------- Key: JBAS-7071 URL: https://jira.jboss.org/jira/browse/JBAS-7071 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-5.1.0.GA Environment: Windows XP Professional V2002, service pack 3 Reporter: Mike Conner Assignee: Jesper Pedersen (FYI your "READ THIS BEFORE ENTERING NEW REPORTS" points to a "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. ) The data source configuration property "use-try-lock" is effectively ignored. This is because the value is defined in configuration as a long, but the object that is actually set on an org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory extends org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory This class defines it as taking an int, not a long: public void setUseTryLock(int useTryLock) As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

5
9
0 / 0

[JBoss JIRA] Created: (JBAS-5245) JBossMQ services: table creation fails with Sybase Adaptive Server Anywhere (ASA)

by Luc Texier (JIRA)

JBossMQ services: table creation fails with Sybase Adaptive Server Anywhere (ASA) --------------------------------------------------------------------------------- Key: JBAS-5245 URL: http://jira.jboss.com/jira/browse/JBAS-5245 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.2.2.GA Reporter: Luc Texier Assigned To: Adrian Brock the database is Sybase Adaptive Server Anywhere (ASA). The JDBC driver jConnect for JDBC 3.0 v6.0x 2008-02-14 18:25:01,640 DEBUG [org.jboss.mq.pm.jdbc2.PersistenceManager] Could not create table with SQL: CREATE TABLE dbo.JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL, DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER NULL, TXOP CHAR(1) NOT NULL, MESSAGEBLOB IMAGE NOT NULL, PRIMARY KEY (MESSAGEID, DESTINATION) ) LOCK DATAROWS com.sybase.jdbc3.jdbc.SybSQLException: SQL Anywhere Error -131: Syntax error near 'LOCK' on line 1 at com.sybase.jdbc3.tds.Tds.a(Unknown Source) at com.sybase.jdbc3.tds.Tds.nextResult(Unknown Source) at com.sybase.jdbc3.jdbc.ResultGetter.nextResult(Unknown Source) at com.sybase.jdbc3.jdbc.SybStatement.nextResult(Unknown Source) at com.sybase.jdbc3.jdbc.SybStatement.nextResult(Unknown Source) at com.sybase.jdbc3.jdbc.SybStatement.updateLoop(Unknown Source) at com.sybase.jdbc3.jdbc.SybStatement.executeUpdate(Unknown Source) at com.sybase.jdbc3.jdbc.SybPreparedStatement.executeUpdate(Unknown Source) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251) at org.jboss.mq.pm.jdbc2.PersistenceManager.createSchema(PersistenceManager.java:280) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1796) Note that those issues do NOT occur when these services are connected to Adaptive Server Enterprise (ASE) Note2: internal reference Issue #162081 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1667) MBeans cannot have heirarchical names

by Richard Kennard (JIRA)

MBeans cannot have heirarchical names ------------------------------------- Key: JBMESSAGING-1667 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667 Project: JBoss Messaging Issue Type: Bug Components: JMS Destination Manager Affects Versions: 1.4.4.GA Environment: JBoss 5.1.0.GA Reporter: Richard Kennard Assignee: Tim Fox In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example: <mbean code="..." name="...,name=app1/emails"> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time. A workaround proposed on the forums is to use the 'JNDIName' attribute: <mbean code="..." name="...,name=emails"> <attribute name="JNDIName">app1/emails</attribute> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes: <mbean code="..." name="...,name=emails"> <attribute name="JNDIName">app1/emails</attribute> <mbean code="..." name="...,name=emails"> <attribute name="JNDIName">app2/emails</attribute> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

3
15
0 / 0

[JBoss JIRA] Created: (JBAS-5631) Access to HAPartiiton membership is not thread-safe

by Paul Ferraro (JIRA)

Access to HAPartiiton membership is not thread-safe --------------------------------------------------- Key: JBAS-5631 URL: http://jira.jboss.com/jira/browse/JBAS-5631 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-4.2.0.CR2, JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA, JBossAS-4.0.4.CR2, JBossAS-3.2.8.SP1, JBossAS-3.2.8 Final, JBossAS-4.0.4RC1, JBossAS-3.2.8RC1, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final, JBossAS-4.0.3RC2, JBossAS-4.0.3RC1, JBossAS-4.0.2 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-4.0.1RC1, JBossAS-4.0.0 Final Reporter: Paul Ferraro Assigned To: Brian Stansberry There are 2 problems with the current implementation. 1. Currently, the membership collections, while synchronized, are both non-volatile and updated in a non-final fashion, so concurrent access by both view changes and rpc invocations is not thread-safe. 2. Membership is expressed in 4 different vectors. During view change, these vectors are not updated atomically. To address both problems, the 4 vectors ought to be encapsulated into a single volatile, immutable object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

3
7
0 / 0

[JBoss JIRA] Created: (JBRULES-2118) comment makes Work Definition parser fail

by Wolfgang Laun (JIRA)

comment makes Work Definition parser fail ----------------------------------------- Key: JBRULES-2118 URL: https://jira.jboss.org/jira/browse/JBRULES-2118 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-eclipse (flow) Affects Versions: 5.0.1.FINAL Environment: Eclipse Reporter: Wolfgang Laun Assignee: Mark Proctor See example in Drools Flow, section 8.2.1., Creating the Work Definition: The comment // add more work items here ... makes the parser fail when calling up the RuleFlow editor ("Could not parse work definitions ...: null") -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

5
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2232) NullPointerException using drools-persistance-jpa and Drools Flows (WorkItemInfo)

by Noel Keating (JIRA)

NullPointerException using drools-persistance-jpa and Drools Flows (WorkItemInfo) --------------------------------------------------------------------------------- Key: JBRULES-2232 URL: https://jira.jboss.org/jira/browse/JBRULES-2232 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.0.M1 Reporter: Noel Keating Assignee: Mark Proctor I'm getting a NPE exception when using drools-persistence-jpa with Drools Flow (I'm working with the trunk version 28274). It occurs in MarshallerReaderContext and seems to be a result of JBRULES-2149. When loading a WorkItemInfo from the database a MarshallerReaderContext is created without the ruleBase set, however the MarshallerReaderContext expects the ruleBase to be set. In the attached patch I have added a null check and call the super method if it is not set. This seems to be working correctly and would have been the behaviour before JBRULES-2149. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

4
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2095) MVEL action in Flow does not support .* imports

by Kris Verlaenen (JIRA)

MVEL action in Flow does not support .* imports ----------------------------------------------- Key: JBRULES-2095 URL: https://jira.jboss.org/jira/browse/JBRULES-2095 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core (flow) Reporter: Kris Verlaenen Assignee: Kris Verlaenen Fix For: 5.1.0.M1 There seems to be an issue where MVEL is not picking up the imports in a Flow Action node if the imports are package imports. For example: context.getKnowledgeRuntime().insert( new Fact() ); results in "could not resolve class: Fact" when using import org.drools.examples.model.* Using import org.drools.examples.model.Fact works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2098) Internal TupleSink list is not properly cleaned up when removing rules from a RuleBase

by Christian NedregÃ¥rd (JIRA)

Internal TupleSink list is not properly cleaned up when removing rules from a RuleBase -------------------------------------------------------------------------------------- Key: JBRULES-2098 URL: https://jira.jboss.org/jira/browse/JBRULES-2098 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 4.0.7 Environment: Drools 4.0.7 Win XP Sun JDK 1.4.2_11 Reporter: Christian NedregÃ¥rd Assignee: Mark Proctor When a new rule is added to a rule base that has shareBetaNodes=true 'BuildUtils.attachNode' will iterate through existing TupleSink nodes and try to find an equal node to re-use. In our production code we are seing NoClassDefFoundErrors from 'EvalConditionNode.equals' in scenarios where rules are both removed from and added to a rule base. The NoClassDefFoundErrors occours when a rule has recently been removed from the rule base and we are trying to add a new rule. When BuildUtils.attachNode' iterates through the existing TupleSinks it also encounters TupleSinks that belongs to the rule that was removed. The call to the TupleSinks 'equal' method yields a NoClassDefFoundErrors because the target TupleSink are trying to reference the rule class that has been removed. In this scenario we have removed rule 10418 and are adding 11140: java.lang.NoClassDefFoundError: rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0 at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.class$(Unknown Source) at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.getMethodBytecode(Unknown Source) at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_11140_0Eval0Invoker.equals(Unknown Source) at org.drools.rule.EvalCondition.equals(EvalCondition.java:121) at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201) at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101) Attached is a stand-alone JUnit 4 testcase where the test 'testWithBetaNodeSharing' shows this problem. It does not produce a NoClassDefFoundError but we get a NPE from <removed rule>Eval0Invoker.getMethodBytecode instead (rule 1 has been removed, rule 3 is about to be added): java.lang.NullPointerException at failure_on_removal.Rule_rule_1_0Eval0Invoker.getMethodBytecode(Unknown Source) at failure_on_removal.Rule_rule_3_0Eval0Invoker.equals(Unknown Source) at org.drools.rule.EvalCondition.equals(EvalCondition.java:121) at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201) at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101) We intepret this to be a symptom of the same problem. The workaround is to disable beta node sharing wich will bypass the TupleSink iteration alltogheter. This is shown in the test 'testWithoutBetaNodeSharing'. Kind regards Christian Nedregård -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2097) Implementation for the BPM web-console

by Kris Verlaenen (JIRA)

Implementation for the BPM web-console -------------------------------------- Key: JBRULES-2097 URL: https://jira.jboss.org/jira/browse/JBRULES-2097 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kris Verlaenen Assignee: Kris Verlaenen Fix For: 5.1.0.M1 Provide a back-end implementation using Drools Flow for the BPM console by Heiko Braun. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2240) True modify

by Geoffrey De Smet (JIRA)

True modify ----------- Key: JBRULES-2240 URL: https://jira.jboss.org/jira/browse/JBRULES-2240 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.1.FINAL Reporter: Geoffrey De Smet Assignee: Mark Proctor Fix For: 5.1.0.M1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

3
3
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 September 2009