On 07/07/2010 4:41 PM, David Savage wrote:
Hi there,
I've just run into a problem with using logback in a jvm where the security manager is enabled. The trace of the exception is as follows:
java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.Class.getClassLoader(Class.java:594) at ch.qos.logback.classic.spi.PackagingDataCalculator.populateFrames(PackagingDataCalculator.java:87) at ch.qos.logback.classic.spi.PackagingDataCalculator.calculate(PackagingDataCalculator.java:58) at ch.qos.logback.classic.spi.ThrowableProxy.calculatePackagingData(ThrowableProxy.java:100) at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:126) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:469) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:425) at ch.qos.logback.classic.Logger.info(Logger.java:645)
This is running with a logback-classic-0.9.23-SNAPSHOT that I pulled and built a couple of days ago.
Looking at the code it seems the PackagingDataCalculator should be calling getClassLoader in an AccessController.doPriviledged block - but potentially this could also happen higher up to avoid having to put micro checks in all over the place.
This leads me to a couple of questions:
* Is logback generally dealing with security related checks and this is just one that's slipped through?
No, logback does not do security checks.
* From the call stack it seems the ThrowableProxy is doing quite a lot of work in the user thread - is there any way to configure logback to do this asynchronously?
That work only done after an exception is thrown which is by definition exceptional, so performance should not be a real problem.
Thanks in advance,
Regards,
Dave