January 2010 - 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: (EJBTHREE-1935) Enable client to connect to server by IP, not host name

by Vasya Vasilchikov (JIRA)

Enable client to connect to server by IP, not host name ------------------------------------------------------- Key: EJBTHREE-1935 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1935 Project: EJB 3.0 Issue Type: Feature Request Environment: JBoss 4.2.3 Reporter: Vasya Vasilchikov When a client lookups an EJB on the server for the first time, InitialContext is initialized and the client receives NamingServer_Stub. The stub contains server host name, not IP address, although the client called server with IP. If client machine fails to resolve the host name, subsequent calls for NamingServer_Stub fail. In Jboss 4.0.4GA the stub contained IP address. Please allow to configure IP-based stubs in Jboss 4.2.x also. Client code: jndiProp.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory"); jndiProp.setProperty(Context.PROVIDER_URL, "172.17.0.6:1099"); Context context = null; try { context = new InitialContext(jndiProp); NMSDBManager manager = (NMSDBManager)context.lookup("NMSDBManagerBean/remote"); return manager; } catch (Throwable t) { t.printStackTrace(); } Exception: javax.naming.CommunicationException [Root exception is java.rmi.UnknownHostException: Unknown host: NMS-74; nested exception is: java.net.UnknownHostException: NMS-74] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:780) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627) at javax.naming.InitialContext.lookup(Unknown Source) at com.ethos.appserver.client.ServerLogin.getServerManager(ServerLogin.java:43) at com.ethos.gui.nms.view.dialog.LoginEthosNMSDialog.connectoToServer(LoginEthosNMSDialog.java:370) at com.ethos.gui.nms.view.dialog.LoginEthosNMSDialog.access$2(LoginEthosNMSDialog.java:355) at com.ethos.gui.nms.view.dialog.LoginEthosNMSDialog$1.construct(LoginEthosNMSDialog.java:390) at com.ethos.gui.infra.worker.SwingWorker$1.call(SwingWorker.java:63) at com.ethos.gui.infra.worker.FutureResult$1.run(FutureResult.java:81) at com.ethos.gui.infra.worker.SwingWorker.run(SwingWorker.java:79) at java.lang.Thread.run(Unknown Source) Caused by: java.rmi.UnknownHostException: Unknown host: NMS-74; nested exception is: java.net.UnknownHostException: NMS-74 at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source) at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source) at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at org.jnp.server.NamingServer_Stub.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667) ... 10 more Caused by: java.net.UnknownHostException: NMS-74 at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.<init>(Unknown Source) at java.net.Socket.<init>(Unknown Source) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown Source) at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown Source) ... 16 more -- 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

2
1
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, 1 month

3
7
0 / 0

[JBoss JIRA] Created: (JBRULES-2344) Pattern analysis can never be satisfied, however the rule is logically correct

by Claudio Gargiulo (JIRA)

Pattern analysis can never be satisfied, however the rule is logically correct ------------------------------------------------------------------------------ Key: JBRULES-2344 URL: https://jira.jboss.org/jira/browse/JBRULES-2344 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-verifier Affects Versions: 5.0.1.FINAL Environment: MacBook Pro 17" Core 2 Duo Ubuntu 9.10 64bit (native, not virtualized) - Apache Tomcat 6.0.18 - Java 6 Reporter: Claudio Gargiulo Assignee: Mark Proctor When I launch the analysis of a rule I get the following message: Pattern, name: TrafficoEntrata in Rule 'backToNormal' can never be satisfied. Pattern, name: StatoRete in Rule 'backToNormal' can never be satisfied. The Rule "backToNormal" is the following: rule "backToNormal" dialect "mvel" when exists Attacco( ) attack : Attacco( ) StatoRete( numero_utenti > "25" && < "80" ) TrafficoEntrata( banda_occupata > "20" && < "80" ) then retract( attack ); end The integer values are taken from an enumeration. Altering the conditions in this way: numero_utenti >"25", numero_utenti < "80" makes no difference at analysis time. -- 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

4
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1970) Upgrade to jboss-ejb3-deployers 1.0.1

by Carlo de Wolf (JIRA)

Upgrade to jboss-ejb3-deployers 1.0.1 ------------------------------------- Key: EJBTHREE-1970 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1970 Project: EJB 3.0 Issue Type: Thirdparty Change Components: ejb3 Reporter: Carlo de Wolf Assignee: Carlo de Wolf Priority: Critical Fix For: 1.1.23 -- 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

1
2
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, 1 month

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, 1 month

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, 1 month

2
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 January 2010