[
http://jira.qos.ch/browse/LBCLASSIC-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12120#action_12120
]
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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
