October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-608) Add a new compatibity and stress test layer based on JMS CTS

by Ovidiu Feodorov (JIRA)

Add a new compatibity and stress test layer based on JMS CTS ------------------------------------------------------------ Key: JBMESSAGING-608 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-608 Project: JBoss Messaging Issue Type: Task Components: Tests and Performance Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.1 http://jmscts.sourceforge.net/index.html The stress part is especially interesting. -- 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
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1102) JBM should use TransactionManagerLocator instead of the MBean API as that is being removed from JBAS code

by Clebert Suconic (JIRA)

JBM should use TransactionManagerLocator instead of the MBean API as that is being removed from JBAS code --------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1102 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1102 Project: JBoss Messaging Issue Type: Feature Request Affects Versions: 1.4.0.GA Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.4.0.SP1, AS 5.0 Integration, EAP 4.3 Integration -- 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
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1128) Message not routed from one node to node with only consumer.

by Mike Clark (JIRA)

Message not routed from one node to node with only consumer. ------------------------------------------------------------ Key: JBMESSAGING-1128 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1128 Project: JBoss Messaging Issue Type: Bug Components: JMS Clustering Affects Versions: 1.4.0.GA Environment: Sun JDK 1.5.0_12, JBoss EAP 4.2.0, JBoss Messaging 1.4.GA installed against the "all" configuration running on RHEL5 (CSB), MySQL 5 used as backing database. Reporter: Mike Clark Assigned To: Tim Fox In trying to reproduce behavior described in case 18885, I can reproduce the following: Start two instances of JBoss (ports-01 and ports-02 using the usual binding manager approach). Deployed a simple MDB to ports-02; simply logs messages with INFO priority. Deployed a simple MBean to both ports-01 and ports-02 that allows me to send TextMessage messages to the respective boxes from the JMX console. Messages sent to ports-02 are consumed by the MDB as expected. Messages sent to ports-01 are not consumed unless ports-02 is shutdown (normal shutdown) and restarted. The MDB on ports-02 will consume the messages queued to ports-01 regardless of whether ports-01 is up or not (ports-01 shutdown cleanly). Messages sent to ports-01 are, of course, seen in the database as soon as they are submitted (I'm using PERSISTENT delivery mode.) Both instances were created from a clean "all" instance. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1094) Integrate JSR-77

by Clebert Suconic (JIRA)

Integrate JSR-77 ---------------- Key: JBMESSAGING-1094 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1094 Project: JBoss Messaging Issue Type: Task Reporter: Clebert Suconic Assigned To: Tim Fox Fix For: AS 5.0 Integration, EAP 4.3 Integration -- 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
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1099) Potential deadlock in shutting down server

by Tim Fox (JIRA)

Potential deadlock in shutting down server ------------------------------------------ Key: JBMESSAGING-1099 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1099 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.GA Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.SP1 Need to investigate -- 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
22
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1095) ServerPeer won't survive a stop/start of the service

by Clebert Suconic (JIRA)

ServerPeer won't survive a stop/start of the service ---------------------------------------------------- Key: JBMESSAGING-1095 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1095 Project: JBoss Messaging Issue Type: Bug Reporter: Clebert Suconic Assigned To: Clebert Suconic Few NullPointerExceptions would happen.. This won't affect any production system... It would affect the JBossAS testsuite only... so this is not a critical production bug. -- 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
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-979) Servlet transport for JBoss Messaging

by Daniel Weeks (JIRA)

Servlet transport for JBoss Messaging ------------------------------------- Key: JBMESSAGING-979 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-979 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Remoting Affects Versions: 1.2.0.SP1 Environment: Windows 2003 with IIS as front-end web server. Reporter: Daniel Weeks Assigned To: Tim Fox Although there is an https transport for JBoss Messaging, it does not support going over the same port that Tomcat is using like the JBoss MQ jbossmq-httpil.sar does. This capability is required for environments in which port 443 is the only port that is open for communication. Although url proxying/forwarding could be used under Apache to work around this issue, there is not a good solution for doing this with IIS (or for applications that don't use a front-end web server and are limited to port 443). Many enterprise PKI solutions (such as DoD) favor the use of IIS over Apache due to cost of COTS products, so this is a show stopper for JBoss Messaging in those environments. This issue is preventing us from migrating an enterprise application that runs in the DoD environment to to JBoss Messaging. The application makes heavy use of JMS and would benefit greatly from the improved performance that JBoss Messaging provides. This feature request is originating from a JBoss Customer Support Portal case at the following URL: https://network.jboss.com/jbossnetwork/restricted/caseDetail.html?caseId=... -- 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
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1107) Less noisy client-side failover

by Ovidiu Feodorov (JIRA)

Less noisy client-side failover ------------------------------- Key: JBMESSAGING-1107 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1107 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Clustering Affects Versions: 1.4.0.GA Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor When a cluster node failure occurs, the client side reports a significant amount of ERROR logging. This is technically correct, those errors are actually occurring, but a clustered connection factory has in-place a fail-over mechanism whose job is to cope with those errors and hopefully make them disappear. If the fail-over succeeds, the user should not see any ERROR-level logging. At most, there should be a WARN along the lines of "node failure detected, the fail-over mechanism is dealing with it". The user should see ERRORs only if the fail-over itself fails. Tons of stack traces produce a significant level of discomfort even if the fail-over succeeds, leaving the user in doubt whether actually the process worked. The logging information should be naturally still available, but at DEBUG level. -- 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
8
0 / 0

[JBoss JIRA] Created: (JBAS-4858) SecurityDeployer changes with metadata

by Anil Saldhana (JIRA)

SecurityDeployer changes with metadata -------------------------------------- Key: JBAS-4858 URL: http://jira.jboss.com/jira/browse/JBAS-4858 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta3 The Security Deployer needs to be changed as per the following rant from Adrian ============================= To me this is the wrong approach anyway. There shouldn't be any code that does if (ejbdeployment) doThis(); else if (webdeployment) doThat(); else if (unknowntype) // OOPS (pun intended ;-) cantDoIt(); The webservice deployers should be working off some generic metadata that triggers them to operate. Then each type of deployment can populate that metadata to say "I want a webservice endpoint for this". This is a seperate deployer for each type we know how to map to a webservice it takes the ejb/web/other metadata and maps or bridges it to the webservice metadata. It shouldn't just be restricted to ejbs and wars. e.g. An MBean should be capable of being an endpoint if there is a deployer that creates the relevant metadata attachment from say a META-INF/jboss-webservice.xml in the sar. The security deployers take the same brain dead (non object orientated) approach. ============================================================ -- 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

1
5
0 / 0

[JBoss JIRA] Created: (JBRULES-1229) separate compile classpath from class loader's getResource() facility

by Godmar Back (JIRA)

separate compile classpath from class loader's getResource() facility --------------------------------------------------------------------- Key: JBRULES-1229 URL: http://jira.jboss.com/jira/browse/JBRULES-1229 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.1 Reporter: Godmar Back Assigned To: Mark Proctor Priority: Minor The current compiler relies on being able to read the bytecode for referred-to classes as a resource. For instance, to resolve the name "org.jboss.pkg.Clazz", a resource "org/jboss/pkg/Clazz.class" must be accessible. This requirement is not part of the public interface of a class loader. Read the Sun Java documentation, which states: "A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code." Although, this approach works by coincidence since most class loaders in fact return this resource - at least class loaders that don't do anything fancy to bytecode before defining classes, a more principled solution would separate the classpath used by the runtime engine from the classpath used by the compiler. (This is, for instance, what javac or practically all command-line compilers do.) My suggestion is to either document this dependency on this particular class loader behavior, or, better, introduce a specific type resolver for the compilation process that is separated from the class loader's resource loading mechanism. -- 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

1
1
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 October 2007