November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-1824) JACC: <role-name>*</role-name> in web.xml

by Roland R?z (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1824?page=comments#action_12346229 ] Roland R?z commented on JBAS-1824: ---------------------------------- Sadly, the new feature described in http://jira.jboss.com/jira/browse/JBAS-2926 is just about tomcat and not jacc. Providing such a feature prevents from ugly workarounds. For example writing a simple public web service (with an EJB3 stateless session bean) requires the developer to add for example the @RolesAllowed("friend") at the class level, else in the generated web deployment is not able to produce the jacc permissions. The proposed change at the JACC layer by using a WebResourcePermission("xyz", null) looks like a good solution. Until that is implemented JBoss could provide a feature similar as the following: org.jboss.web.WebPermissionMapping#createPermissions(): ... // Get the qualified url pattern PatternInfo info = (PatternInfo) patternMap.get(url); Iterator roles = wsmd.getRoles().iterator(); HashSet mappedRoles = new HashSet(); while( roles.hasNext() ) { String role = (String) roles.next(); if( role.equals("*") ) { if (Boolean.valueOf( System.getProperty("jboss.tomcat.jacc.allow-all.role.for.star", "false")).booleanValue()) { // add the "ALLOW-ALL" which could be handled // generically in jacc mappedRoles.add("ALLOW-ALL"); } // The wildcard ref maps to all declared security-role names Iterator allRoles = metaData.getSecurityRoleNames().iterator(); while( allRoles.hasNext() ) { role = (String) allRoles.next(); mappedRoles.add(role); } } else { mappedRoles.add(role); } } ... This feature would allow to handle the role * generically in the jacc provider. The developer just sets the jboss.tomcat.jacc.allow-all.role.for.star system property to true and uses then the role * as a role which any authenticated user has. > JACC: <role-name>*</role-name> in web.xml > ----------------------------------------- > > Key: JBAS-1824 > URL: http://jira.jboss.com/jira/browse/JBAS-1824 > Project: JBoss Application Server > Issue Type: Feature Request > Components: Security > Affects Versions: JBossAS-4.0.2 Final > Environment: - > Reporter: Roland R?z > Assigned To: Scott M Stark > Priority: Minor > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > In some cases I wish to do authentication without authorisation. For example everybody has access to my web-resource, but I want to know who she/he is. > Therefore the accessing user must login. > So my web.xml contains the following snippet: > ... > <security-constraint> > <web-resource-collection> > <web-resource-name>Protected Helloworld example</web-resource-name> > <description/> > <url-pattern>/servlet/HelloWorldExample</url-pattern> > <http-method>POST</http-method> > <http-method>GET</http-method> > </web-resource-collection> > <auth-constraint> > <role-name>*</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>public</realm-name> > </login-config> > ... > The web app runs with this configuration in Tomcat 5.5.8 standalone but not in Jboss. > To run it in Jboss I have to add the following element: > <security-role> > <role-name>aRole</role-name> > </security-role> > The JACC spec (section 3.1.3.1, paragraph 3)states : > " ?. When an auth-constraint names the reserved role-name, "*", all of the patterns in the containing security-constraint must be combined with all of the roles defined in the web application." > JBoss implemented this by combining all of the patterns with all roles defined in the web.xml and assumes that each role has to be defined in the web.xml. > But the web applications roles are probably defined in other files than the web.xml. In our case we use JACC with an external authentication provider. And each time, the roles changes, I also would have to modify the web.xml. > It is desirable if the auth-contraint with the role-name "*" acceppts "all" roles and not only those that are defined in the web.xml. > Or is this a JACC spec issue? > Regards, > Andrea -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-164) Update copyright notices to specify RedHat

by Kevin Conner (JIRA)

Update copyright notices to specify RedHat ------------------------------------------ Key: JBTM-164 URL: http://jira.jboss.com/jira/browse/JBTM-164 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Reporter: Kevin Conner Assigned To: Mark Little Copyright notices in files currently state 'Copyright 2006, JBoss Inc.' This should be changed to 'Copyright 2006, Red Hat Middleware LLC -- 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, 6 months

1
4
0 / 0

[JBoss JIRA] Commented: (JBAS-3183) Integration with WebSphere MQ 5.x

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3183?page=comments#action_12346225 ] Dimitris Andreadis commented on JBAS-3183: ------------------------------------------ Now, I'm not sure if this need fixing in both Branch_4_0 and Branch_4_2 ??? > Integration with WebSphere MQ 5.x > --------------------------------- > > Key: JBAS-3183 > URL: http://jira.jboss.com/jira/browse/JBAS-3183 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Environment: WebSphereMQ 5.3 with Extended TX client > Reporter: Luc Texier > Assigned To: Weston Price > Priority: Critical > Fix For: JBossAS-4.2.0.CR1 > > Attachments: mq-trace.jar, mq-xa.zip > > > http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingWebSphereMQSeriesWithJBossA... > we need to make some changes to StdServerSession and StdServerSessionPool to integrate two workarounds in order to properly integrate with WSMQ 5.x and support their XA resource implementation and transaction handling -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3819) Possible resource leak in SubDeployerSupport

by Roman Arkhangelskiy (JIRA)

Possible resource leak in SubDeployerSupport -------------------------------------------- Key: JBAS-3819 URL: http://jira.jboss.com/jira/browse/JBAS-3819 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.5.GA Reporter: Roman Arkhangelskiy Assigned To: Dimitris Andreadis I have been running Jtest's BugDetective feature on JBossAS source code and it reported a possible resource leak in org.jboss.deployment.SubDeployerSupport.java. There might be an IOException thrown at line 541 of this class's 'deployUrl' method. And this would consequently lead to a resource leak as the resource variable 'out' has already been initialized by the time the exception arises, and is never closed afterwards. I'm attaching a screenshot from BugDetective which describes the exact flow which may lead to the exception. Please let me know if this is a real problem or BugDetective is mistaken. Thank you! -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-147) Add in new EULA

by Mark Little (JIRA)

Add in new EULA --------------- Key: JBTM-147 URL: http://jira.jboss.com/jira/browse/JBTM-147 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Release Reporter: Mark Little Assigned To: Kevin Conner Fix For: 4.2.2 http://jira.jboss.com/jira/browse/JBAS-3652 -- 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, 6 months

3
6
0 / 0

[JBoss JIRA] Updated: (JBCACHE-327) Expose PojoCache management attribtues

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-327?page=all ] Ben Wang updated JBCACHE-327: ----------------------------- Fix Version/s: PojoCache 2.2.0 (was: PojoCache 2.1.0) > Expose PojoCache management attribtues > -------------------------------------- > > Key: JBCACHE-327 > URL: http://jira.jboss.com/jira/browse/JBCACHE-327 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache 2.2.0 > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > We need to expose JBossCacheAop management attributes. Here are some thoughts: > - # of pojos > - Pojo references > - pojo lifetime > - pojo evicted > - pojo life cycle listener (field access) -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-13) Lazy loading: PojoCache and CacheLoader

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-13?page=comments#action_12346212 ] Ben Wang commented on JBCACHE-13: --------------------------------- With the current flat-space POJO mapping, we should be doing this already. Just need to double check. > Lazy loading: PojoCache and CacheLoader > --------------------------------------- > > Key: JBCACHE-13 > URL: http://jira.jboss.com/jira/browse/JBCACHE-13 > Project: JBoss Cache > Issue Type: Task > Affects Versions: 1.2.4SP1 > Reporter: Bela Ban > Assigned To: Ben Wang > Fix For: 2.0.0.GA > > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > Idea is to have a configurable option that can be set either to eager or lazy loading. This can apply to whether it is with or without cache loader as well. For example, we may as well do the initial mapping lazily. > Example: > Person p = cache.getObject("/person"); > p.getName(); only primitive fields get loaded (not Address, e.g.) -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-13) Lazy loading: PojoCache and CacheLoader

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-13?page=all ] Ben Wang updated JBCACHE-13: ---------------------------- Fix Version/s: 2.0.0.GA (was: PojoCache 2.1.0) Priority: Major (was: Critical) > Lazy loading: PojoCache and CacheLoader > --------------------------------------- > > Key: JBCACHE-13 > URL: http://jira.jboss.com/jira/browse/JBCACHE-13 > Project: JBoss Cache > Issue Type: Task > Affects Versions: 1.2.4SP1 > Reporter: Bela Ban > Assigned To: Ben Wang > Fix For: 2.0.0.GA > > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > Idea is to have a configurable option that can be set either to eager or lazy loading. This can apply to whether it is with or without cache loader as well. For example, we may as well do the initial mapping lazily. > Example: > Person p = cache.getObject("/person"); > p.getName(); only primitive fields get loaded (not Address, e.g.) -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-97) ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-97?page=all ] Ben Wang updated JBCACHE-97: ---------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) > ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock > ------------------------------------------------------------------------------------------------- > > Key: JBCACHE-97 > URL: http://jira.jboss.com/jira/browse/JBCACHE-97 > Project: JBoss Cache > Issue Type: Bug > Reporter: Bela Ban > Assigned To: Ben Wang > Fix For: 2.1.0.GA > > > TxDeadlockUnitTestCase has 2 methods that show the following stack traces: > testMoreThanOneUpgrader: > Upgrader#0: get(/a/b/c) > Upgrader#1: get(/a/b/c) > main: locks: > /a (read owners=[<null>:2, <null>:1]) > /b (read owners=[<null>:2, <null>:1]) > /c (read owners=[<null>:2, <null>:1]) > Upgrader#0: put(/a/b/c) > Upgrader#1: put(/a/b/c) > Upgrader#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:2); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock) > Upgrader#0: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2] > Write lock owner: null > (caller=<null>:1) > org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2] > Write lock owner: null > (caller=<null>:1) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155) > at org.jboss.cache.Node.acquireWriteLock(Node.java:448) > at org.jboss.cache.Node.acquire(Node.java:417) > at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199) > at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998) > at org.jboss.cache.TreeCache.put(TreeCache.java:1657) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyUpgrader._run(TxDeadlockUnitTestCase.java:346) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > and > testConcurrentUpgrade(): > MyThread#1: get(/a/b/c) > MyThread#2: get(/a/b/c) > MyThread#2: done, locks: > /a (read owners=[<null>:2]) > /b (read owners=[<null>:2]) > /c (read owners=[<null>:2]) > MyThread#1: done, locks: > /a (read owners=[<null>:2, <null>:1]) > /b (read owners=[<null>:2, <null>:1]) > /c (read owners=[<null>:2, <null>:1]) > MyThread#2: put(/a/b/c) > MyThread#1: put(/a/b/c) > MyThread#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:1); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock) > MyThread#2: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1] > Write lock owner: null > (caller=<null>:2) > org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1] > Write lock owner: null > (caller=<null>:2) > at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155) > at org.jboss.cache.Node.acquireWriteLock(Node.java:448) > at org.jboss.cache.Node.acquire(Node.java:417) > at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199) > at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40) > at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998) > at org.jboss.cache.TreeCache.put(TreeCache.java:1657) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyThread._run(TxDeadlockUnitTestCase.java:317) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) > at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213) -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-452) Support @NonPersistent annotation in PojoCache

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-452?page=comments#action_12346210 ] Ben Wang commented on JBCACHE-452: ---------------------------------- Maybe @NonPassivate > Support @NonPersistent annotation in PojoCache > ---------------------------------------------- > > Key: JBCACHE-452 > URL: http://jira.jboss.com/jira/browse/JBCACHE-452 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache > > > We should support @NonPersistent annotation that if set, that particular field is stored in the cache but is not under persisency even when cache loader is configured. -- 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, 6 months

1
0
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 November 2006