May 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-734) Ship bouncycastle.jar without IDEA code

by Bela Ban (JIRA)

Ship bouncycastle.jar without IDEA code --------------------------------------- Key: JGRP-734 URL: http://jira.jboss.com/jira/browse/JGRP-734 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.7 IDEA is a patented algorithm, we want to ship a stripped-down version of bouncycastle.jar. -- 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, 2 months

2
9
0 / 0

[JBoss JIRA] Created: (JGRP-756) FLUSH still needs work

by Bela Ban (JIRA)

FLUSH still needs work ---------------------- Key: JGRP-756 URL: http://jira.jboss.com/jira/browse/JGRP-756 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Vladimir Blagojevic Fix For: 2.6.3, 2.7 [Michael Newcomb] Still debugging concurrent starting issues... Now I'm running into a problem with FLUSH. So, there are 3 current members (A, B, C) and a new one joins (D)... 1. coord starts a flush on A,B,C 2. coord receives FLUSH_COMPLETED from A,B (misses C) 3. coord times out and sleeps a few seconds 4. coord starts a new flush on A,B,C Here is where the problems start. A,B (and possibly C) are already in a FLUSH situation. As far as they are concerned a flush is in progress because they sent FLUSH_COMPLETED to the coord. So, when they get a new flush, they determine who they are going to reject (either the currently flushing coordinator or the flush requestor). If the flush requestor is < than the current flush coordinator, then a reject flush is sent to the original flush coordinator and the flush is proceeded with the flush requestor. If the flush requestor is > than the current flush coordinator, then a reject flush is sent to the flush requestor and the flush is proceeded with the original flush coordinator. If the flush requestor is == the current flush coordinator, it behaves the same as if the flush requestor was > the flush coordinator. A reject flush is sent to the current coordinator and then a FLUSH_COMPLETED is sent to him... The problem is that the FLUSH_COMPLETED is basically ignored because the reject flush sets the promise to FALSE which immediately fails the flush. This causes another flush retry which results in the same thing again and again until all the retries are exhausted and the overall flush fails. Furthermore, the node that rejected the flush is left in the exact same state: he thinks he is in a flush and will reject any new flush requests by the current flush coordinator! Essentially, retrying flushes is a waste of time... I think that there are several ways to solve this problem. Since the flush is 'restarted' (onStartFlush is called after the reject is sent) even when the flush requestor == the current flush coordinator, there may be no need to reject the flush when the flush requestor == the current flush coordinator. Only send a reject flush if the abortFlushCoordinator != proceedFlushCoordinator... If that is not sufficient, then when the flush requestor == the current flush coordinator, the node that rejects a flush, should not 'restart' the flush by calling onStartFlush again (only call onStartFlush if abortFlushCoordinator != proceedFlushCoordinator). This basically sets the next flush attempt up for failure again and again because nothing has changed at the node: he still thinks a flush is on going and will reject any new flushes from the current flush coordinator. Again, these cases are for when the flush requestor is == the current flush coordinator. I have yet to attempt concurrent flush attempts by different nodes ;) -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-5538) JBossMessaging SecurityMetaDataStore should use SecurityManagement

by Anil Saldhana (JIRA)

JBossMessaging SecurityMetaDataStore should use SecurityManagement ------------------------------------------------------------------ Key: JBAS-5538 URL: http://jira.jboss.com/jira/browse/JBAS-5538 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JMS (JBoss Messaging) Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.CR1 Currently, the implementation of SecurityMetaDataStore in AS5 uses JNDI lookups on startup to get the security managers. Ideally, we need to inject the SecurtyManagement instance. This is a work in progress to convert the messaging-service.xml mbean services into the messaging-beans.xml -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5537) Default implementation of SubjectFactory

by Anil Saldhana (JIRA)

Default implementation of SubjectFactory ---------------------------------------- Key: JBAS-5537 URL: http://jira.jboss.com/jira/browse/JBAS-5537 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.CR1 JBossSecuritySubjectFactory. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2018) Duplicate e-mail on searchUsers page

by Keuller Magalh￣es (JIRA)

Duplicate e-mail on searchUsers page ------------------------------------ Key: JBPORTAL-2018 URL: http://jira.jboss.com/jira/browse/JBPORTAL-2018 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: Identity-1.0.3 Environment: JBoss Portal 2.6.5.GA Reporter: Keuller Magalh￣es Fix For: 2.6.6 Final The problem is in the page search users. At the column e-mail the value which is displayed is the same e-mail of the users logged in, but the value of e-mail into database is correct, this problem is only in XHTML page. In the prior version of JBoss Portal (2.6.4GA) this problem does not occurs. -- 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, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-5469) Bean to register an instance of PolicyRegistration in JNDI

by Anil Saldhana (JIRA)

Bean to register an instance of PolicyRegistration in JNDI ---------------------------------------------------------- Key: JBAS-5469 URL: http://jira.jboss.com/jira/browse/JBAS-5469 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.CR1 Security bean to register PolicyRegistration bean under java:/policyRegistration. The PR bean should be injectable into the containers (but that is for the future). -- 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, 2 months

1
4
0 / 0

[JBoss JIRA] Created: (JBCL-12) Add a cache of found resources by root to the VFSClassLoader

by Adrian Brock (JIRA)

Add a cache of found resources by root to the VFSClassLoader ------------------------------------------------------------ Key: JBCL-12 URL: http://jira.jboss.com/jira/browse/JBCL-12 Project: JBoss ClassLoader Issue Type: Task Components: VFS Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossCL.2.0.0.CR1 When defining a class in the VFSClassLoader we use findChild() a number of times; 1) In the search of the classloaders to see whether the classloader has the class 2) To open the byte stream of the class 3) To determine the protection domain of the class (i.e. the root of class) 4) To locate the manifest to determine package information Some of this already has a cache in various places. But this could be further optimised by caching of resource path -> vfs file/root during the defineClass() -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-379) Split large messages into fragments

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-379?page=comments#action_12... ] Tim Fox commented on JBMESSAGING-379: ------------------------------------- String64KLimitTest has tests commented out until this task is complete. Uncomment them then. > Split large messages into fragments > ----------------------------------- > > Key: JBMESSAGING-379 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-379 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Fix For: 2.0.0 Beta > > Original Estimate: 3 days > Remaining Estimate: 3 days > > An alternative way of dealing with very large messages than using a streamed body, is to automatically split large messages into many small fragments and send each in it's own message. These can be automatically re-assembled at the receiver. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5527) jboss_4_0.dtd should include support for SingletonStatelessSessionInstancePool

by Andrew Shcheglov (JIRA)

jboss_4_0.dtd should include support for SingletonStatelessSessionInstancePool ------------------------------------------------------------------------------ Key: JBAS-5527 URL: http://jira.jboss.com/jira/browse/JBAS-5527 Project: JBoss Application Server Issue Type: Patch Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.0.5.GA Environment: N/A Reporter: Andrew Shcheglov Assigned To: Alexey Loubyansky Priority: Minor Attachments: jboss_4_0.dtd.patch jboss_4_0.dtd should include support for SingletonStatelessSessionInstancePool; namely, allow <Synchronized/> element under <container-pool-conf/>. -- 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, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-4765) jboss_5_0.xsd from ejb3 is not included with the other dtds/schemas in the docs directory of the AS output build

by Dimitris Andreadis (JIRA)

jboss_5_0.xsd from ejb3 is not included with the other dtds/schemas in the docs directory of the AS output build ---------------------------------------------------------------------------------------------------------------- Key: JBAS-4765 URL: http://jira.jboss.com/jira/browse/JBAS-4765 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: XML services Reporter: Dimitris Andreadis Assigned To: Carlo de Wolf Fix For: JBossAS-5.0.0.Beta3 The output docs directory of the jboss AS build, should contain all exported dtds/schemas. We use those to update the www.jboss.org site. -- 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, 2 months

3
4
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 May 2008