[ http://jira.qos.ch/browse/LBCLASSIC-263?page=com.atlassian.jira.plugin.syste... ] NC commented on LBCLASSIC-263: ------------------------------ You're right, assuming a security manager would impose a performance penalty. Altering PackagingDataCalculator as follows would avoid the penalty: if(System.getSecurityManager() == null) lastExactClassLoader =callerClass.getClassLoader(); else lastExactClassLoader =Loader.getClassLoaderAsPrivileged(callerClass); When not running under a security manager the ClassLoader is obtained in the usual manner, yet everything still works, out of the box, if a security manager is in place. This provides the best of both worlds with only a simple check. System.getSecurityManager() is not expensive.
Logback Classic causes SecurityException ----------------------------------------
Key: LBCLASSIC-263 URL: http://jira.qos.ch/browse/LBCLASSIC-263 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: NC Assignee: Logback dev list Attachments: PackagingDataCalculator.diff
PackagingDataCalculator invokes Class.getClassLoader(). This method throws a SecurityException when running under a security manager and that manager denies access to the ClassLoader. I'm submitting a PackagingDataCalculator patch which wraps the getClassLoader() invocation in a doPrivileged block. This allows these calls to succeed when the getClassLoader RuntimePermission is granted to logback-classic.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira