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? * 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? Thanks in advance, Regards, Dave