December 2006 - jboss-jira - Jboss List Archives

by Phillip Arrington

19 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-807) Bean meta data does not include security role references

by Anil Saldhana (JIRA)

Bean meta data does not include security role references -------------------------------------------------------- Key: EJBTHREE-807 URL: http://jira.jboss.com/jira/browse/EJBTHREE-807 Project: EJB 3.0 Issue Type: Task Components: Security Affects Versions: EJB 3.0 RC9 - Patch 1 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: EJB 3.0 RC10 - FD ==================================== <session> <ejb-name>SecTestEJB</ejb-name> <business-local>xxx</business-local> <ejb-class>xxx</ejb-cla ss> <security-role-ref> <role-name>ADMIN</role-name> <role-link>Administrator</role-link> </security-role-ref> <security-role-ref> <role-name>MGR</role-name> <role-link>Manager</role-link> </security-role-ref> </session> ================================================== There can be security role references configured at the bean level in ejb-jar.xml The metadata that is parsed by the ejb3 metamodel does not recognize the security role references. The isCallerInRole checks on the EnterpriseContext needs to be aware of these security role references. -- 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

19 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-808) isCallerInRole should consider Security Role Refs

by Anil Saldhana (JIRA)

isCallerInRole should consider Security Role Refs ------------------------------------------------- Key: EJBTHREE-808 URL: http://jira.jboss.com/jira/browse/EJBTHREE-808 Project: EJB 3.0 Issue Type: Bug Components: Security Affects Versions: EJB 3.0 RC9 - Patch 1 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: EJB 3.0 RC10 - FD If there are security role refs configured at the bean level in ejb-jar.xml, the EnterpriseContext.isCallerInRole checks should consider the security role refs. -- 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

19 years, 7 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBTM-18) Use inhouse DTF for QA

by Richard Achmatowicz (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-18?page=comments#action_12348832 ] Richard Achmatowicz commented on JBTM-18: ----------------------------------------- I have movd the DTF to the QA Labs machines. A database called dtf has been set up on a MySQL server on dev02.qa.atl.jboss.com. I have installed a copy of Tomcat in my home directory on the labs machines, with the following node pool: dev04: runs the DTF executive (NameServer, Coordinator, ServiceManager, ProductRepository, ResultsCollator) and one TestNode dev02: runs one TestNode The DTFweb user interface starts up correctly using the URL http://dev04:8080/dtf. Initiation of test nodes, product deployment, work fine under the control of the DTFweb user interface. However test cases which work on my local machine fail to work correctly when run on the QA Labs machines. There seems to be a problem with (i) receiving output from tasks and (ii) the results of the tests. I am investigating these problems. > Use inhouse DTF for QA > ---------------------- > > Key: JBTM-18 > URL: http://jira.jboss.com/jira/browse/JBTM-18 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation, WS-T Implementation > Reporter: Mark Little > Assigned To: Richard Achmatowicz > > Get the QA up and running for refactored ATS. Require refactoring DTF too. -- 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

19 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-390) Verify that buffer sizes are not > max memory

by Bela Ban (JIRA)

Verify that buffer sizes are not > max memory --------------------------------------------- Key: JGRP-390 URL: http://jira.jboss.com/jira/browse/JGRP-390 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Priority: Optional Fix For: 2.5 Throw an exception if it is. However, we don't combine all buffers and check their aggregated value, but we check each individual buffer. -- 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

19 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3946) remove() called on home of a sfsb in tx must fail

by Alexey Loubyansky (JIRA)

remove() called on home of a sfsb in tx must fail ------------------------------------------------- Key: JBAS-3946 URL: http://jira.jboss.com/jira/browse/JBAS-3946 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-5.0.0.Beta1 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossAS-5.0.0.Beta2 Page 86 of the ejb-2_1-fr-spec.pdf: "An attempt to remove a session object while the object is in a transaction will cause the container to throw the javax.ejb.RemoveException to the client." There is a cts test that fails because of this. -- 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

19 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-896) Port JBCACHE-875 and JBCACHE-871 to HEAD

by Manik Surtani (JIRA)

Port JBCACHE-875 and JBCACHE-871 to HEAD ---------------------------------------- Key: JBCACHE-896 URL: http://jira.jboss.com/jira/browse/JBCACHE-896 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.GA port JBCACHE-875 and JBCACHE-871 to HEAD/2.0.0 -- 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

19 years, 7 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBAS-2172) BINARY and BLOB types are stored as org.jboss.invocation.MarshalledValue

by Bernd Eckenfels (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2172?page=comments#action_12348824 ] Bernd Eckenfels commented on JBAS-2172: --------------------------------------- Anybody working on that issue? The serializer can be changed trivially: obj = new MarshalledValue(obj); abyte0 = obj.toByteArray(); However on de-serialization, you might have to check for instanceof MarshalledValue. (And then this might unwrap a MarshalledValue unconditionally...) > BINARY and BLOB types are stored as org.jboss.invocation.MarshalledValue > ------------------------------------------------------------------------ > > Key: JBAS-2172 > URL: http://jira.jboss.com/jira/browse/JBAS-2172 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.3RC2 > Reporter: Alexey Loubyansky > Assigned To: Alexey Loubyansky > Priority: Minor > > Binary types have been serialized using JBoss-specific org.jboss.invocation.MarshalledValue. An alternative serialization is needed to not tie users to JBoss-specific classes. -- 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

19 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-813) BaseRpcInterceptor to call callRemoteMethod() instead of callRemoteMethods() when sending to a single recipient

by Manik Surtani (JIRA)

BaseRpcInterceptor to call callRemoteMethod() instead of callRemoteMethods() when sending to a single recipient --------------------------------------------------------------------------------------------------------------- Key: JBCACHE-813 URL: http://jira.jboss.com/jira/browse/JBCACHE-813 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1, 1.4.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 1.4.0.SP2, 2.0.0 Mainly used as a workaround until AnyCast (JGRP-338) is available. -- 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

19 years, 7 months

1
5
0 / 0

[JBoss JIRA] Created: (JGRP-374) Flow control should send new credits only *after* processing a message

by Bela Ban (JIRA)

Flow control should send new credits only *after* processing a message ---------------------------------------------------------------------- Key: JGRP-374 URL: http://jira.jboss.com/jira/browse/JGRP-374 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Currently, FC sends new credits (when the sender's credits drop below a threshold) *before* passing the message up. However, if the receiver takes a long time to process the message, we might queue up messages, possibly leading to OOMs. SOLUTION: in FC.up(), decrement the sender's credits by number of bytes received, but only send replenishment (if needed) *after* the message was passed up. This requires that passUp() includes delivery of the message to the receiver and we can be sure that, once passUp() returns, the message has been delivered. If we use a queue in Channel (e.g. using the pull model, Channel.receive()), this won't work. -- 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

19 years, 7 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 December 2006