January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1053) Write a test for JBMESSAGING-1031

by Clebert Suconic (JIRA)

Write a test for JBMESSAGING-1031 --------------------------------- Key: JBMESSAGING-1053 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1053 Project: JBoss Messaging Issue Type: Task Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.4.0.GA I have fixed JBMESSAGING-1031 using a manual test.. we need to add a testcase. -- 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

15 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-478) Create indexes to improve performance

by Tim Fox (JIRA)

Create indexes to improve performance ------------------------------------- Key: JBMESSAGING-478 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-478 Project: JBoss Messaging Issue Type: Sub-task Affects Versions: 1.0.1.CR3 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 Create indexes in memory so that we don't have to iterate through all the messages in memory to find the ones that match. Also make sure it all works when messages are paged to storage. -- 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

15 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1109) Clustered proxy factories don't bind home proxies

by Brian Stansberry (JIRA)

Clustered proxy factories don't bind home proxies ------------------------------------------------- Key: EJBTHREE-1109 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1109 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: AS 4.2.2.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: AS 5.0.0.Beta3 StatefulClusterProxyFactory and StatelessClusterProxyFactory differ from the others in not binding home proxies. -- 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

15 years, 10 months

4
15
0 / 0

[JBoss JIRA] Created: (JBAS-3945) RunAs Causes Unexpected Principal Propagation Switch

by Stefan Schulze (JIRA)

RunAs Causes Unexpected Principal Propagation Switch ---------------------------------------------------- Key: JBAS-3945 URL: http://jira.jboss.com/jira/browse/JBAS-3945 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.5.GA Environment: JBoss 4.0.5.GA JSE 1.5.0_09 Reporter: Stefan Schulze Assigned To: Scott M Stark Attachments: runAsError.zip My application is using JAAS authentication on web and ejb side. An authenticated user calls a stateless session bean from the web application which uses 'runAs' to change security role and calls a second stateless session bean. The second bean recuperates an 'anonymous' principal but it should be the authenticated user. This does not happen on our production server (JBoss 3.2.7) but on JBoss 4.05.GA. Test case: I try to attach my test case (where can I attach it ???) which boils down the problem. To run it, please - unzip the file (runAsError.zip) - you can import the content as a project in Eclipse if you prefer - change the 'jboss.dist' property in the 'ant.properties' file to your jBoss 4.0.5.GA installation - run the 'install' target of 'build.xml' which creates a new jboss container called 'runAsError' - start the 'runAsError' container (run -c runAsError) - run the 'test' target of 'build.xml' What happens: Standalone client calls Session1.hello() with caller principal 'max' . Session1 calls Session2.hello2() using runAs 'internal'. Session2 should get caller principal 'max' but gets 'anonymous'. See Exception that is thrown in SessionBean2.hello2(). It seems to be a different bug than http://jira.jboss.com/jira/browse/JBAS-1852 since I run the JBAS-1852 test and it seemed to work (I had some troubles with the DatabaseServerLoginModule that were probably related to my incompetence ;-). -- 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

15 years, 10 months

5
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-987) support DeliveryActive MDB activation config property

by William DeCoste (JIRA)

support DeliveryActive MDB activation config property ----------------------------------------------------- Key: EJBTHREE-987 URL: http://jira.jboss.com/jira/browse/EJBTHREE-987 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.0 GA, EJB 3.0 RC9 - Patch 1 Reporter: William DeCoste Assigned To: William DeCoste -- 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

15 years, 10 months

3
12
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1013) Manual merge queue feature via JMX

by Evgueni Smoliar (JIRA)

Manual merge queue feature via JMX ---------------------------------- Key: JBMESSAGING-1013 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1013 Project: JBoss Messaging Issue Type: Feature Request Components: Configuration and Management, JMS Clustering Environment: Clustering/load balancing Reporter: Evgueni Smoliar Assigned To: Tim Fox In a case of disaster recovery you are obliged always to recover last running cluster node. Otherwise some messages will remain in the queue waiting for this node to startup. Idd there is a workaround for this, but it's not always easy to do. Would me much nicer to have a manual function to merge queues ( or reallocate messages) preferably available via JMX. For more detail please check forum. -- 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

15 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1127) Use SSL certificate for client authentication

by Brendan Sibre (JIRA)

Use SSL certificate for client authentication --------------------------------------------- Key: JBMESSAGING-1127 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1127 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Remoting, JMS Security Affects Versions: 1.4.0.GA Environment: JBAS 4.2.1 on Solaris 9 and 10, Sun JVM 1.5.0 Reporter: Brendan Sibre Assigned To: Tim Fox Clients connect to JBM using the sslbisocket connector. They should be able to use a client certificate to authenticate them via my custom loginmodule (which has been tested and works with EJBs, Tomcat, etc). Use the principal created by the SSL connection for the getConnection() so that I do not need to pass a username and password. It seems that the callback handler used by the JBoss Messaging and the remoting SSLBisocket connector needs to be able to handle an X509Callback. This probably means that it will need to be a HandshakeCompletedListener on the remoting connector. Ideally, this method of authentication would be configured with the connector and then JBoss Messaging would use a CallerIdentityLoginModule to accept the Subject that already exists so that JBoss Messaging will continue to work with EJBs (JmsXA) etc. Forum posts include links to other potentially related JIRA issues. Hopefully JBoss Messaging can address this issue as it fits in the junction between JBM and remoting. -- 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

15 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-752) Create safe mode where session concurrent access is checked

by Tim Fox (JIRA)

Create safe mode where session concurrent access is checked ----------------------------------------------------------- Key: JBMESSAGING-752 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-752 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 As per JMS spec, a JMS session is supposed to be only accessed from one thread at a time. This is so the implementor does not have to synchronize access which might degrade performance. However, users are often unaware of this and use the session concurrent by multiple threads, resulting in subtle or hard to identify bugs. We should create a "safeMode", where if enabled, concurrent access is checked. safeMode should be turned on for development and off for production, so no performance penalty is incurred in production. -- 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

15 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1002) Improve order preservation checking

by Tim Fox (JIRA)

Improve order preservation checking ----------------------------------- Key: JBMESSAGING-1002 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1002 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Priority: Minor Fix For: 2.0.0 Beta 1 The current version of order preservation involves preventing messages being sucked from one queue to another more than once. This could be improved by encoding the nodeid/counter for each node sucked from in a header. The counter would be reset every time all consumers are closed on a particular node. A message won't be sucked to a node if its node id is encoded in the header and the distributor's current counter value matches the value in the header. -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1173) Merge after lost of network connectivity between cluster members (handle the split-brain situation)

by Mike Clark (JIRA)

Merge after lost of network connectivity between cluster members (handle the split-brain situation) --------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1173 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1173 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Clustering Affects Versions: 1.4.0.SP2 Environment: Any clustered Reporter: Mike Clark Assigned To: Tim Fox JBM does not currently support the merging of cluster segments that have gotten into the "split-brain" situation. This occurs when network connectivity is lost between subsets of a cluster. Each subset assumes the other is gone and acts appropriately. When the network connectivity is restore, they do not merge back into a single cluster but remain as independent clusters (the spit-brain). This feature request is to add cluster merging to prevent the split-brain situation. -- 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

15 years, 10 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008