views:

1435

answers:

2

Is there a recommended way to upgrade Quartz in JBoss 4.2.x?

JBoss bundles quartz 1.5.2, but I have encountered issues (QUARTZ-399, QUARTZ-520) that I want to avoid.

I would not want to patch quartz.jar in JBoss just to resolve the errors, but instead provide a new quartz.jar (plus associated configuration artifacts). The Quartz 1.6 migration notes only contain information specific to Quartz, and I could not find any additional information during my search.

It does not seem to work to just put the new quartz.jar into the EAR file, because the old version is loaded at the server level (in the server's lib directory).

I am quite sure somebody has already tried that, and hope that this person could share or provide some links.

+1  A: 

You could include Quartz 1.6 in your WAR or EAR, and your application will use that instead. However, only the application components within that WAR or EAR will use the new JAR, which may be a problem or an advantage, depending on how you've set up your deployments.

skaffman
Thank you for the quick answer. Just tried it and put quartz-1.6.jar in the ear/lib directory. When I try to set the trigger's priority (feature of 1.6) I get a NoSuchMethodError.Quartz schedulers are instantiated using Spring's SchedulerFactoryBean, which might be a reason why it does not work.
Kariem
Did you also put a reference to the JAR in META-INF/application.xml? Without that, the classloader will ignore it.
skaffman
No, I did not. All referenced libraries are in that folder and picked up automatically by the class loader. The point is that quartz.jar is in the server's class path which is loaded before the application.
Kariem
Found a comparable problem with log4j with a nice solution:http://www.jboss.org/feeds/post/how_do_i_use_my_own_log4j_properties_or_xml_file_in_jboss. The problem is that changing the class loading results in problems related to dependency injection via @EJB via Spring/JNDI.
Kariem
Other config options that might affect this are the "Isolated" attribute in deploy/ear-deployer.xml. I have this set to true, and I think this makes JBoss use the EAR's libs in preference to JBoss' own ones. Give that a try.
skaffman
Thank you for your suggestion and patience. I just tried it with this setting and receive the same error. I believe this has something to do with how the application is laid out, and it certainly would have worked with a normal application.
Kariem
+1  A: 

After trying around following skaffman's comments, I have found a very simple solution that does not involve changing JBoss' class loading behavior. Simply replacing the quartz.jar in ${jboss.server.dir}/lib with quartz 1.6 does the job, and I haven't had any problems yet.

Restarting shows the following output:

[QuartzScheduler] Quartz Scheduler v.1.6.0 created.
[RAMJobStore] RAMJobStore initialized.
[StdSchedulerFactory] Quartz scheduler 'QuartzScheduler' initialized from an externally provided properties instance.
[StdSchedulerFactory] Quartz scheduler version: 1.6.0
Kariem