https://issues.apache.org/bugzilla/show_bug.cgi?id=52326
Bug #: 52326 Summary: Lower log level for failed class loading Product: Tomcat 7 Version: 7.0.23 Platform: PC Status: NEW Severity: minor Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: fha...@apache.org Classification: Unclassified Reference: https://jira.springsource.org/browse/SPR-8894 Tomcat attempts to load classes when it searches for annotations. These class loading attempts when failed, should be silently ignored. If the application attempts to load the classes later, it will receive the actual error. However, when Tomcat prints out the stack trace of this class loading error, it gives the wrong signal. There is actually not anything wrong in the application itself, so a WARN as tomcat logs with a stack trace becomes misleading. The initial fix would be: ContextConfig.java to drop log level to debug in checkHandleTypes method Class<?> clazz = null; try { clazz = context.getLoader().getClassLoader().loadClass(className); } catch (NoClassDefFoundError e) { log.debug(sm.getString("contextConfig.invalidSciHandlesTypes", className), e); return; } catch (ClassNotFoundException e) { log.warn(sm.getString("contextConfig.invalidSciHandlesTypes", className), e); return; } catch (ClassFormatError e) { log.warn(sm.getString("contextConfig.invalidSciHandlesTypes", className), e); return; } catch (Throwable t) { ExceptionUtils.handleThrowable(t); log.warn(sm.getString("contextConfig.invalidSciHandlesTypes", className), t); return; } The better fix would be to achieve the same without classloading at all. Other containers do ignore any type of classloading errors during this sequence. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org