It is a bit confusing... anyway, I think my bigger question of persisting a job to the database still remains unanswered... I know quartz has it's own persistence mechanism (and seems to work better with clustering environments than the old way), but for now I am giving up on it.
For this project, I really just need one job to start and so I can pre-configure it through the quartz.xml file for now. It actually may be better to separate it out as it's own project and just let it run continuously outside of the webapp, but I am trying to make it easy to deploy the final solution as one component rather than multiple. I will have to think about it :-/ Thanks for your thoughts Georg. I am still not sure the best way to address it other than to note in user docs for now :-) - Jeff On 10/15/2018 11:19 AM, Georg Kallidis wrote: > This root path seems to be the classes folder! In a servlet context it may > be easiest to use class loading to avoid some servlet realpath mapping in > configuration files. Why not put the quartz.xml into the classes folder? > If you want to have a test case just use build>testResources declaration > in pom.xml, e.g. folder src/resources/test, and put it there. Then > org.quartz.plugin.jobInitializer.fileNames" value="./quartz.xml" should > work.., this is not an issue with Fulcrum, but Quartz + Web Context, > though IMO. > Best regards, Georg > > > Von: Jeffery Painter <[email protected]> > An: Turbine Developers List <[email protected]> > Datum: 15.10.2018 15:16 > Betreff: Re: Persisting jobs with the Quartz scheduler > > > > Hi guys, > > I found the old wiki entry on migrating to Quartz scheduler from Turbine > 2.3 scheduler service (I admit that was the last time I was using it and > had not tried it in Turbine 4/5 until now). So far the documentation is > pretty easy to follow. But I am getting the following exception being > thrown though when trying to use the quartz.xml file on startup. > > > Caused by: org.quartz.SchedulerException: File named './quartz.xml' does > not exist. > at > org.quartz.plugins.xml.XMLSchedulingDataProcessorPlugin$JobFile.initialize(XMLSchedulingDataProcessorPlugin.java:401) > at > org.quartz.plugins.xml.XMLSchedulingDataProcessorPlugin$JobFile.<init>(XMLSchedulingDataProcessorPlugin.java:351) > at > org.quartz.plugins.xml.XMLSchedulingDataProcessorPlugin.initialize(XMLSchedulingDataProcessorPlugin.java:206) > at > org.quartz.impl.StdSchedulerFactory.instantiate(StdSchedulerFactory.java:1334) > at > org.quartz.impl.StdSchedulerFactory.getScheduler(StdSchedulerFactory.java:1559) > at > org.apache.fulcrum.quartz.impl.QuartzSchedulerImpl.initialize(QuartzSchedulerImpl.java:143) > at > org.apache.fulcrum.yaafi.framework.component.AvalonServiceComponentImpl.initialize(AvalonServiceComponentImpl.java:409) > at > org.apache.fulcrum.yaafi.framework.component.AvalonServiceComponentImpl.incarnateInstance(AvalonServiceComponentImpl.java:106) > at > org.apache.fulcrum.yaafi.framework.component.ServiceComponentImpl.getInstance(ServiceComponentImpl.java:139) > at > org.apache.fulcrum.yaafi.framework.component.ServiceComponentImpl.incarnate(ServiceComponentImpl.java:154) > ... 32 more > > > I played with path names in the quartz section of my component config > and the debugger until I finally found a setup that works. But it does > not make sense why the other does not work. > > This setup works: > <parameter name="org.quartz.plugin.jobInitializer.fileNames" > value="../../WEB-INF/conf/quartz.xml"/> > > All of these fail: > > 1. <parameter name="org.quartz.plugin.jobInitializer.fileNames" > value="quartz.xml"/> > 2. <parameter name="org.quartz.plugin.jobInitializer.fileNames" > value="./quartz.xml"/> > 3. <parameter name="org.quartz.plugin.jobInitializer.fileNames" > value="/quartz.xml"/> > > > I tried many more variations including, but finally tried the one that > works after about 12 other tries :-) > > Any ideas on why this one works and the other does not? > > > -- > Jeff > > > > On 10/11/2018 08:32 PM, Jeffery Painter wrote: >> Hi Thomas, >> >> I am starting a new project with turbine-5.0-SNAPSHOT and I already >> updated the web archetype to get the Quartz configuration in place (I >> found most of it from the test cases you had in svn). So far so good... >> >> I added the simplejob test and started it up, however I tried to set it >> to run every 10 seconds, but it was only running once per minute - I >> don't really need a job to run every 10 seconds, but I thought that was >> a little strange. I will have to debug that further. But the real >> reason I am writing is I am trying to understand how to persist the jobs >> in the database so they come back on restart. I first just manually >> entered a job in the TURBINE_SCHEDULED_JOB table, but it is not reading >> anything from there. >> >> Looking at the startup logs, it says it is using a RAMJobStore store >> which is not persistent. Does the new Quartz scheduler not support >> persisting job entries? The log tells me no user-supplied config was >> found, so I guess there is some way to configure it further :-) >> >> Once I figure it all out, I was going to put together a simple Job >> Manager UI in the flux package similar to the way we have the user >> manager. I think it would be a nice addition (provide basic >> functionality, start/stop scheduler, add/remove jobs, check current job >> status). Let me know what you think. >> >> I need this myself - my new contract I am putting together a system that >> allows users to manage a set of keywords and then schedule automated web >> crawling to gather relevant data before sending it through some data >> mining, text classification processes ;-) >> >> Also, I would be happy to write this all up when I get it working and >> add to the site docs (the schedule docs there now only apply to T-2.3.x >> version I believe). >> >> >> Thanks! >> >> Startup is looking good! >> >> 2018-10-11 20:15:43,109 [localhost-startStop-1] INFO avalon.quartz - >> Using Quartz default configuration since no user-supplied configuration >> was found >> 2018-10-11 20:15:43,124 [localhost-startStop-1] INFO >> org.quartz.impl.StdSchedulerFactory - Using default implementation for >> ThreadExecutor >> 2018-10-11 20:15:43,127 [localhost-startStop-1] INFO >> org.quartz.simpl.SimpleThreadPool - Job execution threads will use class >> loader of thread: localhost-startStop-1 >> 2018-10-11 20:15:43,135 [localhost-startStop-1] INFO >> org.quartz.core.SchedulerSignalerImpl - Initialized Scheduler Signaller >> of type: class org.quartz.core.SchedulerSignalerImpl >> 2018-10-11 20:15:43,136 [localhost-startStop-1] INFO >> org.quartz.core.QuartzScheduler - Quartz Scheduler v.2.3.0 created. >> 2018-10-11 20:15:43,136 [localhost-startStop-1] INFO >> org.quartz.simpl.RAMJobStore - RAMJobStore initialized. >> 2018-10-11 20:15:43,137 [localhost-startStop-1] INFO >> org.quartz.core.QuartzScheduler - Scheduler meta-data: Quartz Scheduler >> (v2.3.0) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED' >> Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally. >> NOT STARTED. >> Currently in standby mode. >> Number of jobs executed: 0 >> Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 10 > threads. >> Using job-store 'org.quartz.simpl.RAMJobStore' - which does not >> support persistence. and is not clustered. >> >> 2018-10-11 20:15:43,137 [localhost-startStop-1] INFO >> org.quartz.impl.StdSchedulerFactory - Quartz scheduler >> 'DefaultQuartzScheduler' initialized from default resource file in >> Quartz package: 'quartz.properties' >> 2018-10-11 20:15:43,137 [localhost-startStop-1] INFO >> org.quartz.impl.StdSchedulerFactory - Quartz scheduler version: 2.3.0 >> 2018-10-11 20:15:43,137 [localhost-startStop-1] DEBUG avalon - >> Startable.start() for quartz >> 2018-10-11 20:15:43,137 [localhost-startStop-1] INFO >> org.quartz.core.QuartzScheduler - Scheduler >> DefaultQuartzScheduler_$_NON_CLUSTERED started. >> 2018-10-11 20:15:43,138 [localhost-startStop-1] DEBUG avalon - YAAFI >> Avalon Service Container is up and running >> . >> . >> . >> 2018-10-11 20:15:43,217 [localhost-startStop-1] DEBUG avalon - Located >> the service 'org.apache.fulcrum.quartz.QuartzScheduler' in the local >> container >> 2018-10-11 20:15:43,217 [localhost-startStop-1] INFO scheduler - >> Starting job scheduler >> >> >> >> -- >> Jeff >> >> > > [Anhang "signature.asc" gelöscht von Georg Kallidis/CeDiS/FU-Berlin/DE] >
signature.asc
Description: OpenPGP digital signature
