March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-2032) Investigate org.jboss.ejb3.test.bank.unit.BankDeploymentDescriptorTestCase.testStatefulBank21 failure

by jaikiran pai (JIRA)

Investigate org.jboss.ejb3.test.bank.unit.BankDeploymentDescriptorTestCase.testStatefulBank21 failure ----------------------------------------------------------------------------------------------------- Key: EJBTHREE-2032 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2032 Project: EJB 3.0 Issue Type: Task Components: testsuite Reporter: jaikiran pai Assignee: jaikiran pai It's related to the @Init change and needs a bit of investigation. The test case looks valid so might be an edge case which was missed out (the test deployment doesn't explicitly have a @Init marked for ejbCreate() for EJB2.x view). I'll take a detailed look some time later. -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1793) Non-atomic increment operation on volatile field lastReceivedCommandID in class ChannelImpl

by Daniel Luo (JIRA)

Non-atomic increment operation on volatile field lastReceivedCommandID in class ChannelImpl ------------------------------------------------------------------------------------------- Key: JBMESSAGING-1793 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1793 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 2.0.0.beta4 Environment: OS: Redhat-5 Linux 2.6.18-92.el5 JDK: java version "1.6.0" Java(TM) SE Runtime Environment (build pxi3260sr4-20090219_01(SR4)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20090215_29883 (JIT enabled, AOT enabled) J9VM - 20090215_029883_lHdSMr JIT - r9_20090213_2028 GC - 20090213_AA) JCL - 20090218_01 Reporter: Daniel Luo In class ChannelImpl, field "lastReceivedCommandID" is declared as volatile int, in method confirm(xxx), lastReceivedCommandID++; is seen, which is a three-step (read->modify->write) non-atomic operation. Volatile keyword only guarantees variable visibility, but not atomicity, so statement "lastReceivedCommandID++;" invoked by multiple threads can result to race condition and incorrect result. It's suggested to use synchronized block to protect "lastReceivedCommandID++;" or AtomicInteger class from java.util.concurrent package to do atomic increment operation. -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1792) Non-atomic increment operation on volatile field ackBytes in class ClientConsumerImpl

by Daniel Luo (JIRA)

Non-atomic increment operation on volatile field ackBytes in class ClientConsumerImpl ------------------------------------------------------------------------------------- Key: JBMESSAGING-1792 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1792 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 2.0.0.beta4 Environment: OS: Redhat-5 Linux 2.6.18-92.el5 JDK: java version "1.6.0" Java(TM) SE Runtime Environment (build pxi3260sr4-20090219_01(SR4)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20090215_29883 (JIT enabled, AOT enabled) J9VM - 20090215_029883_lHdSMr JIT - r9_20090213_2028 GC - 20090213_AA) JCL - 20090218_01 Reporter: Daniel Luo In class ClientConsumerImpl, field "ackBytes" is declared as volatile int, in method acknowledge(xxx), ackBytes += message.getEncodeSize(); is seen, which is a three-step (read->modify->write) non-atomic operation. Volatile keyword only guarantees variable visibility, but not atomicity, so statement "ackBytes += message.getEncodeSize();" invoked by multiple threads can result to race condition and incorrect result. It's suggested to use synchronized block to protect "ackBytes += message.getEncodeSize();" or AtomicInteger class from java.util.concurrent package to do atomic increment operation. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-7776) Sort system properties in boot.log

by David Lloyd (JIRA)

Sort system properties in boot.log ---------------------------------- Key: JBAS-7776 URL: https://jira.jboss.org/jira/browse/JBAS-7776 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: System service Reporter: David Lloyd Assignee: David Lloyd Priority: Trivial Fix For: JBossAS-6.0.0.M3 It's a bitch to find anything in the unsorted list. Sort it. -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-460) ACLProviderImpl getEntitlements and isAccessGranted methods don't have consistent behavior

by Stefan Guilhen (JIRA)

ACLProviderImpl getEntitlements and isAccessGranted methods don't have consistent behavior ------------------------------------------------------------------------------------------ Key: SECURITY-460 URL: https://jira.jboss.org/jira/browse/SECURITY-460 Project: JBoss Security and Identity Management Issue Type: Bug Security Level: Public (Everyone can see) Components: ACL Affects Versions: JBossSecurity_2.0.4.SP3 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: JBossSecurity_2.0.4.SP4 The getEntitlements method checks for parent resources ACLs when the ACL for an specific resource is not found. The isAccessGranted method throws and exception when an ACL can't be found which is inconsistent with the behaviour of the getEntitlements method. This method needs to be fixed to look for parent resources ACLs in this situation. -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6725) quotes around JAVA_OPTS in run.bat

by David Croft (JIRA)

quotes around JAVA_OPTS in run.bat ---------------------------------- Key: JBAS-6725 URL: https://jira.jboss.org/jira/browse/JBAS-6725 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.Beta1, JBossAS-5.0.1.GA Environment: Windows XP and JDK 6 Reporter: David Croft In JBoss 4.2.3, I was able to prepend to run.bat a JAVA_OPTS option with a pipe symbol (|) by escaping it using quote marks. Example: set JAVA_OPTS=-Dhttp.nonProxyHosts="localhost|*.ldms.ibm.com" In JBoss 5.0.1.GA and 5.1.0.Beta1, the run.bat script has been modified slightly so that this is no longer possible. This modification was to wrap JAVA_OPTS with quote marks which will not parse if JAVA_OPTS already has quote marks as in the above example. There are two places where this occurs. Here is the first place: if "x%JAVA_OPTS%" == "x" ( set "JAVA_OPTS=-Dprogram.name=%PROGNAME%" ) else ( set "JAVA_OPTS=%JAVA_OPTS% -Dprogram.name=%PROGNAME%" ) The first place where it occurs can be fixed by reverting to the version 4.2.3 run.bat code without quote marks: set JAVA_OPTS=%JAVA_OPTS% -Dprogram.name=%PROGNAME% The second place it occurs is as follows: if not errorlevel == 1 ( set "JAVA_OPTS=%JAVA_OPTS% -server" ) This second place can be fixed by removing the quote marks: if not errorlevel == 1 ( set JAVA_OPTS=%JAVA_OPTS% -server ) -- 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, 4 months

4
9
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-246) Update to VFS 3.0.0.CR2

by John Bailey (JIRA)

Update to VFS 3.0.0.CR2 ----------------------- Key: JBDEPLOY-246 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-246 Project: JBoss Deployers Issue Type: Thirdparty Change Affects Versions: JBDEPLOY-2.2.0.Alpha2 Reporter: John Bailey Assignee: John Bailey Fix For: JBDEPLOY-2.2.0.Alpha3 -- 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, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-242) Issue with DeclaredStructure Deployer not mounting archives

by John Bailey (JIRA)

Issue with DeclaredStructure Deployer not mounting archives ----------------------------------------------------------- Key: JBDEPLOY-242 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-242 Project: JBoss Deployers Issue Type: Bug Components: vfs Affects Versions: JBDEPLOY-2.2.0.Alpha2 Reporter: John Bailey Assignee: John Bailey Fix For: JBDEPLOY-2.2.x The DeclaredStructure structure deployer is not working correctly with Archives. In order for the META/jboss-structure.xml to be available the archive must be mounted. The fix is making the DeclaredStructure extend AbstractVFSArchiveStructureDeployer and provide a hasValidSuffix method. Then the set of valid jar suffixes should be injected to match the JARStructure 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-929) Secure remote classloading

by David Lloyd (JIRA)

Secure remote classloading -------------------------- Key: JBREM-929 URL: http://jira.jboss.com/jira/browse/JBREM-929 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Remote classloading should be allowed only if either (a) a security manager is installed (and thus the security manager would create the policy) or (b) a specific option is enabled (which would be disabled by default) to allow it. Also, the remote classloader needs to be able to work with the standard security manager policy - which is to say, that classes loaded from a remote service need to have a unique codeBase URL so that administrators can grant permission to remote classes based on the service from whence they came. -- 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, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1016) Increase Basic Protocol Version

by David Lloyd (JIRA)

Increase Basic Protocol Version ------------------------------- Key: JBREM-1016 URL: https://jira.jboss.org/jira/browse/JBREM-1016 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.1.0.GA Increase the protocol version by one. Clone this issue for every minor release. -- 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, 4 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 March 2010