DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31908>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31908 hasPermission in SecurityImpl may be subject to same problem as defect 31907 Summary: hasPermission in SecurityImpl may be subject to same problem as defect 31907 Product: Slide Version: 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Security AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] As noted in defect 31907 the getUri(String) calls is inappropriate for places where the returned Uri object will be used to make store calls because the token in the uri is null and doesn't contain an indicator as to whether the store calls should be enlisted for the current transaction. There are some places in hasPermission() in the SecurityImpl class where getUri(String) is used to make store calls. hasPermission() makes calls to the store using three different Uris it constructs using just getUri(String). So for those using the access control and a jdbc store these calls may result in a deadlock just as happened for defect 31907. hasPermission() needs to be revised to determine whether the slide token for the current transaction needs to be passed to the getUri() calls so that a valid Uri is returned that can make store calls within another transaction. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
