Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warnings thrown while using SpringFramework 3.1.RC2 with Quartz 2.1.1 [SPR-8894] #13535

spring-issuemaster opened this issue Dec 3, 2011 · 3 comments


Copy link

@spring-issuemaster spring-issuemaster commented Dec 3, 2011

Greg Lively opened SPR-8894 and commented

Updated my local dev environment to Spring Framework 3.1.RC2 and Quartz 2.1.1. My job are running fine, however, I get a number of these warnings in my logs while the app is starting up:

WARNING: Unable to load class [org.springframework.scheduling.quartz.CronTriggerBean] to check against the @HandlesTypes annotation of one or more ServletContentInitializers.
java.lang.IncompatibleClassChangeError: class org.springframework.scheduling.quartz.CronTriggerBean has interface org.quartz.CronTrigger as super class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(
at java.lang.ClassLoader.defineClass(
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(
at org.apache.catalina.loader.WebappClassLoader.findClass(
at org.apache.catalina.loader.WebappClassLoader.loadClass(
at org.apache.catalina.loader.WebappClassLoader.loadClass(
at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(
at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(
at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(
at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(
at org.apache.catalina.startup.ContextConfig.processAnnotations(
at org.apache.catalina.startup.ContextConfig.webConfig(
at org.apache.catalina.startup.ContextConfig.configureStart(
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
at org.apache.catalina.core.StandardContext.startInternal(
at org.apache.catalina.util.LifecycleBase.start(
at org.apache.catalina.core.ContainerBase$
at org.apache.catalina.core.ContainerBase$
at java.util.concurrent.FutureTask$Sync.innerRun(
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
at java.util.concurrent.ThreadPoolExecutor$

Affects: 3.1 RC2


Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Dec 5, 2011

Chris Beams commented

Hi Greg,

I'm resolving this as invalid simply because it's not something we can fix from a Spring perspective. What's at issue here is that Quartz changed CronTrigger from a class to an interface(!) in 2.x. Spring's CronTriggerBean has historically declared CronTrigger as a base class, and will continue to for 1.x compatibility reasons. CronTriggerFactoryBean is a Quartz 2.x-compatible alternative, and all this has been documented, by the way in the Javadoc for CronTriggerBean.

So it makes sense why an attempt to classload CronTriggerBean would fail when Quartz 2.x is on the classpath. The trouble is, that even if you as a user are doing everything right and using CronTriggerFactoryBean in your application, Tomcat will still try to classload the old CronTriggerBean when it processes Spring 3.1's new SpringServletContainerInitializer. This class is an implementation of Servlet 3.0's ServletContainerInitializer SPI, and it is marked with a @HandlesTypes annotation that causes Tomcat to do a search for classes that implement Spring's WebApplicationInitializer interface. Tomcat classloads CronTrigger in an attempt to see if it implements this interface, and that's where everything goes wrong.

I've asked the Tomcat team to consider (a) ignoring errors like this, or reporting them at a lower log level such as DEBUG; or (b) considering the use of ASM or similar libraries to avoid classloading altogether. Option (b) should be both faster and safer all around, though I cannot speak to the feasibility of such a refactoring in the Tomcat codebase.

In the meantime, I'm afraid your only real option is to suppress Tomcat's internal logging.

In any case, thanks for bringing this to our attention.


Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jan 30, 2012

Chris Beams commented

See resolution comments on -- As of 7.0.26, Tomcat no longer uses classloading for @HandlesTypes processing, so this issue should be taken care of.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.