Page Operations
Browse Space
The Hippo CMS instance can be configured to run cronjobs; they can be used to run tasks like content imports etc.
Hereby is a brief introduction on the configuration files to add in your customized CMS project.
<xconf xpath="/cocoon" remove="/cocoon/component[@role='org.apache.cocoon.components.cron.JobScheduler']"> <component role="org.apache.cocoon.components.cron.JobScheduler" class="org.apache.cocoon.components.cron.CocoonQuartzJobScheduler" logger="cron"> <store type="ram"/> <!-- Definitions for a thread pool used to schedule jobs --> <thread-pool> <!-- Should we queue up execution requests if the pool is busy? Defaults to false --> <use-queueing>false</use-queueing> <!-- How big should the queue be. Defaults to unlimited size (<0 == default) --> <queue-size>-1</queue-size> <!-- The maximum size of the pool. Defaults to Integer.MAX_VALUE (<0 == default) --> <max-pool-size>-1</max-pool-size> <!-- The minimum size of the pool. Defaults to 1 (<0 == default) --> <min-pool-size>1</min-pool-size> <!-- How long will an idle thread be kept before it will be discarded. Defaults to 60000ms (<0 == default) --> <keep-alive-time-ms>60000</keep-alive-time-ms> <!-- Which blocking policy should be used if the maximum poolsize and queue size is bounded: Run: (default) The thread making the execute request runs the task itself. This policy helps guard against lockup. Wait: Wait until a thread becomes available. Abort: Throw a RuntimeException Discard: Throw away the current request and return. DiscardOldest: Throw away the oldest request and return. --> <block-policy>RUN</block-policy> <!-- Should queued and running jobs be given a chance to finished on system shutdown. Defaults to true --> <shutdown-graceful>true</shutdown-graceful> <!-- The maximum time to wait for running jobs to complete.Defaults to unlimited time (<0 == default) --> <shutdown-wait-time-ms>5000</shutdown-wait-time-ms> </thread-pool> <!-- Definitions of triggers --> <triggers> <trigger name="mycronjob1" target="org.apache.cocoon.components.cron.CronJob/mycronjob1" concurrent-runs="false"> <cron>${cms.cron.mycronjob1.time}</cron> </trigger> <trigger name="mycronjob2" target="org.apache.cocoon.components.cron.CronJob/mycronjob2" concurrent-runs="false"> <cron>${cms.cron.mycronjob2.time}</cron> </trigger> </triggers> </component> </xconf>
This file defines the cronjob triggers; the time interval is defined in the project.properties file as follows
cms.cron.mycronjob1.time=0 0 0 * * ? * cms.cron.mycronjob2.time=0 0 0 * * ? *
and can be overridden in the build.properties file
For each trigger defined there must be a Cronjob definition; in this case we use a CocoonPipelineCronJob, that basically calls a Cocoon URI (the cocoon:// prefix is implicit)
<xconf xpath="/cocoon" unless="component[@role='org.apache.cocoon.components.cron.CronJob/mycronjob2']"> <component role="org.apache.cocoon.components.cron.CronJob/mycronjob2" class="org.apache.cocoon.components.cron.CocoonPipelineCronJob" logger="cron.pipeline"> <pipeline>executeCronPipe?uri=http://${maven.cocoon.site.domain}:${maven.jetty.port}/extensions/mycronjob2</pipeline> </component> </xconf>
Note that the pipeline doesn't call directly the URI that triggers the related operation; it calls executeCronPipe, passing the target URI as request param. In order to use the further step, we need to add a pipeline to the root sitemap, using the following configuration file
<?xml version="1.0"?> <xmap xpath="/sitemap/pipelines" unless="/sitemap/pipelines/pipeline[@internal-only='false']" replace-properties="true" insert-before="/sitemap/pipelines/pipeline[@internal-only='true']" xmlns:map="http://apache.org/cocoon/sitemap/1.0"> <map:pipeline internal-only="false"> <map:match pattern="executeCronPipe"> <map:read src="{request-param:uri}"/> </map:match> </map:pipeline> </xmap>
 |
Thanks to Maurizio Pillitu for contributing this documentation! |