January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5120) Problem with JBoss Messaging Post Office Service in all config with new classloader

by Adrian Brock (JIRA)

Problem with JBoss Messaging Post Office Service in all config with new classloader ----------------------------------------------------------------------------------- Key: JBAS-5120 URL: http://jira.jboss.com/jira/browse/JBAS-5120 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JMS service Reporter: Adrian Brock Assigned To: Clebert Suconic Fix For: JBossAS-5.0.0.Beta4 When booting the all configuration I see this error message: 15:48:33,126 ERROR [ClusterConnectionManager] Failed to start connection info java.lang.NullPointerException at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:87) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:106) at org.jboss.jms.client.delegate.ClientConnectionDelegate$start_N8025343665958530775.invokeNext(ClientConnectionDelegate$start_N8025343665958530775.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:106) at org.jboss.jms.client.delegate.ClientConnectionDelegate$start_N8025343665958530775.invokeNext(ClientConnectionDelegate$start_N8025343665958530775.java) at org.jboss.jms.client.delegate.ClientConnectionDelegate.start(ClientConnectionDelegate.java) at org.jboss.jms.client.JBossConnection.start(JBossConnection.java:121) at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo.start(ClusterConnectionManager.java:664) at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.ensureAllConnectionsCreated(ClusterConnectionManager.java:426) at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.notify(ClusterConnectionManager.java:247) at org.jboss.messaging.core.impl.DefaultClusterNotifier.sendNotification(DefaultClusterNotifier.java:72) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.putReplicantLocally(MessagingPostOffice.java:1167) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.put(MessagingPostOffice.java:1420) at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:240) at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:201) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) This is supposedly already fixed in the linked task? -- 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

18 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1118) Abstract base classes of remote proxies are not declaring serialVersionUIDs

by Carlo de Wolf (JIRA)

Abstract base classes of remote proxies are not declaring serialVersionUIDs --------------------------------------------------------------------------- Key: EJBTHREE-1118 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1118 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.2.GA, AS 4.2.1.GA Reporter: Carlo de Wolf Priority: Blocker Fix For: AS 5.0.0.Beta3, AS 4.2.3.GA javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3 .remoting.BaseRemoteProxy; local class incompatible: stream classdesc serialVersionUID = -2711693270411201590, local class serialVersionUID = 1126421850898582900] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:724) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:589) at javax.naming.InitialContext.lookup(InitialContext.java:351) ...... -- 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

18 years, 4 months

3
8
0 / 0

[JBoss JIRA] Created: (JBRULES-1289) BRMS gives unusable error messages when validating DSL based rules

by Phil Verghese (JIRA)

BRMS gives unusable error messages when validating DSL based rules ------------------------------------------------------------------ Key: JBRULES-1289 URL: http://jira.jboss.com/jira/browse/JBRULES-1289 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.2 Reporter: Phil Verghese Assigned To: Mark Proctor The error messages that are shown when you click "Validate" when editing a business rule that uses a DSL in the BRMS are not user-friendly at all. If I make a small typo and misspell the name of an attribute (a very likely thing for a BRMS user to do), and click the Validate button, the error I get back is a big stack trace starting with "java.lang.RuntimeException: SNO: Conversion failed at org.codehaus.janino.UnitCompiler.numericPromotion(UnitCompiler.java) at ..." Nowhere in that stack trace is anything that gives a hint that the error is just a typo of an attribute name. Contrast this with the rather helpful error message I get if I make the same typo when editing a DRL rule: "Unable to create Field Extractor for 'overtimHours'". (The error is that I misspelled overtimeHours). The BRMS needs to give the same type of helpful error message on validation errors when editing a DSL rule. -- 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

18 years, 4 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1133) Janino and eclipse compiler might need to be optional for 4.1

by Geoffrey De Smet (JIRA)

Janino and eclipse compiler might need to be optional for 4.1 ------------------------------------------------------------- Key: JBRULES-1133 URL: http://jira.jboss.com/jira/browse/JBRULES-1133 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.GA Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Minor Fix For: FUTURE I didn't want to make this change for 4.0.x as it would require our users to put a direct dependency on either janino or eclipse-compiler. Drools-compiler needs one of both. Currently users get bloated with a transitive dependency on both. Making them optional would force them to make a dependency on one of the themselves... which makes the "hello world" program harder. As it would also force jbrms's etc tests to choose one. Why shouldn't do this before 4.1, if we even want to do this. What do you think? -- 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

18 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1335) Add Welcome Screen , Tooltips (or 1 para of descriptive text) to BRMS to help new users and links to Help Docs

by Paul Browne (JIRA)

Add Welcome Screen ,Tooltips (or 1 para of descriptive text) to BRMS to help new users and links to Help Docs ------------------------------------------------------------------------------------------------------------- Key: JBRULES-1335 URL: http://jira.jboss.com/jira/browse/JBRULES-1335 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Environment: Drools BRMS Reporter: Paul Browne BRMS is very powerful, but can be intimidating for first time users. Suggest adding 1) Welcome screen (e.g. Like Eclipse after 1st install) giving 3/4 pointers to users as to where they might begin 2) Within the various BRMS screens, add Tooltips / descriptive text to explain what each command does . Give advanced users options to close / hide this 3) Link to HTML Help doc (even current drools manual) from every screen. -- 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

18 years, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1150) Drools 4.0 BRMS not working with geronimo-jetty6-jee5-2.0.1

by Bhagwath Vadyala (JIRA)

Drools 4.0 BRMS not working with geronimo-jetty6-jee5-2.0.1 ----------------------------------------------------------- Key: JBRULES-1150 URL: http://jira.jboss.com/jira/browse/JBRULES-1150 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Environment: geronimo-jetty6-jee5-2.0.1 drools-4.0.1.SNAPSHOT-brms Reporter: Bhagwath Vadyala Assigned To: Mark Proctor I am trying to test and see whether Drools 4.0 BRMS works with Geronimo-jetty6-jee5-2.0.1 or not. Drools BRMS version which I am using is drools-4.0.1.SNAPSHOT-brms. It deploys fine in Geronimo but when I open the BRMS error message I am getting is HTTP ERROR:404. Please let me know whether we can make Drools 4.0 work with Geronimo-jetty version -- 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

18 years, 4 months

4
11
0 / 0

[JBoss JIRA] Created: (JBRULES-686) Query on rule field usage information

by Michael Neale (JIRA)

Query on rule field usage information ------------------------------------- Key: JBRULES-686 URL: http://jira.jboss.com/jira/browse/JBRULES-686 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale -- 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

18 years, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1249) Allow repository location to be specified in BRMS web client

by Shahad Ahmed (JIRA)

Allow repository location to be specified in BRMS web client ------------------------------------------------------------ Key: JBRULES-1249 URL: http://jira.jboss.com/jira/browse/JBRULES-1249 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.1 Reporter: Shahad Ahmed Assigned To: Mark Proctor At present, any custom location of the repository is set in a components.xml file inside the WEB-INF directory of the BRMS war file. It would be better if the user could specify the location using the BRMS web client itself, rather than have to unzip, modify and zip up the WAR file. Perhaps this functionality could be added to the Admin section of the BRMS. One advantage of this is that users could also then work with multiple repositories (e.g. for different projects). In effect there would be an option to create a new repository (specified by a directory given by the user), open an existing repository and close a repository. -- 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

18 years, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1190) Eviction configuration should consider buddy backup regions as well.

by Manik Surtani (JIRA)

Eviction configuration should consider buddy backup regions as well. -------------------------------------------------------------------- Key: JBCACHE-1190 URL: http://jira.jboss.com/jira/browse/JBCACHE-1190 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 2.0.0.GA Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.2.0.GA -- 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

18 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-805) Channel is set to AUTO_GET_STATE even if cache doesn't want initial state transfer

by Brian Stansberry (JIRA)

Channel is set to AUTO_GET_STATE even if cache doesn't want initial state transfer ---------------------------------------------------------------------------------- Key: JBCACHE-805 URL: http://jira.jboss.com/jira/browse/JBCACHE-805 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani The channel should probably only be set to AUTO_GET_STATE if getFetchStateOnStartup() returns true. Otherwise if the node is shunned and reconnects, a full state transfer will occur. Presumably the cache can't or doesn't want to handle that, or getFetchStateOnStartup() would not have returned true. One problem is what if getFetchStateOnStartup() returns false because the config uses a shared cache loader (so no persistent state transfer) and a cold cache at startup is OK (so no in-memory state transfer). But, following reconnect the cache is no longer "cold" -- the in-memory tree now has potentially stale data. -- 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

18 years, 5 months

3
8
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 2008