https://issues.apache.org/bugzilla/show_bug.cgi?id=52444
Guillaume Smet <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #10 from Guillaume Smet <[email protected]> 2012-01-31 23:05:41 UTC --- Hi Mark, As we also had this problem with our application, we have built a Tomcat from svn tip and when starting the application, we had the following stacktrace: Caused by: java.lang.NullPointerException at org.apache.tomcat.util.bcel.classfile.ClassParser.<init>(ClassParser.java:72) at org.apache.catalina.startup.ContextConfig.populateJavaClassCache(ContextConfig.java:2132) at org.apache.catalina.startup.ContextConfig.populateJavaClassCache(ContextConfig.java:2123) at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:2058) at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2015) at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1904) at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1872) at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1858) This is due to the fact that classes present in the jar files may implement interfaces not present in the classpath (in our case, it's the optional commonj support in Spring's scheduling classes which rises this problem). We solved this problem by checking that the inputStream "is" is different from null in populateJavaClassCache(String className). With this fix, our application starts and the initialization is faster than with 7.0.25. HTH. -- Guillaume -- 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: [email protected] For additional commands, e-mail: [email protected]
