Author: cziegeler
Date: Tue Jul 23 07:58:25 2013
New Revision: 1505925
URL: http://svn.apache.org/r1505925
Log:
Update job handling docs
Removed:
sling/site/trunk/content/site/apache-sling-eventing-and-job-handling.html
Modified:
sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext
sling/site/trunk/content/site/.htaccess
Modified:
sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext
URL:
http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext?rev=1505925&r1=1505924&r2=1505925&view=diff
==============================================================================
---
sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext
(original)
+++
sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext
Tue Jul 23 07:58:25 2013
@@ -1,32 +1,84 @@
-translation_pending: true
Title: Apache Sling Eventing and Job Handling
-*NOTE: This documentation is work in progress!*
## Overview
-The Apache Sling Event Support bundle provides interesting services for
advanced event handling and job processing. While this bundle leverages the
OSGi EventAdmin, it provides a very powerful support for so called jobs: a job
is a task which has to be performed by a component - the Sling job handling
ensures that exactly one component performs this task.
+The Apache Sling Event Support bundle adds additional features to the OSGi
Event Admin and for distributed event processing.
-To get some hands on code, you can refer to the following tutorials:
-* [How to Manage Events in Sling]({{ refs.how-to-manage-events-in-sling.path
}})
-* [Scheduler Service (commons scheduler)]({{
refs.scheduler-service-commons-scheduler.path }})
+The bundle provides the following features
-The Sling Event Supports adds the following services:
* [Jobs](#jobs-guarantee-of-processing)
* [Distributed Events](#distributed-events)
* [Scheduled Events](#sending-scheduled-events)
+To get some hands on code, you can refer to the following tutorials:
+* [How to Manage Events in Sling]({{ refs.how-to-manage-events-in-sling.path
}})
+* [Scheduler Service (commons scheduler)]({{
refs.scheduler-service-commons-scheduler.path }})
+
## Jobs (Guarantee of Processing)
In general, the eventing mechanism (OSGi EventAdmin) has no knowledge about
the contents of an event. Therefore, it can't decide if an event is important
and should be processed by someone. As the event mechanism is a "fire event and
forget about it" algorithm, there is no way for an event admin to tell if
someone has really processed the event. Processing of an event could fail, the
server or bundle could be stopped etc.
-On the other hand, there are use cases where the guarantee of processing a job
is a must and usually this comes with the requirement of processing this job
exactly once. Typical examples are sending notification emails (or sms) or post
processing of content (like thumbnail generation of images or documents).
+On the other hand, there are use cases where the guarantee of processing is a
must and usually this comes with the requirement of processing exactly once.
Typical examples are sending notification emails (or sms), post processing of
content (like thumbnail generation of images or documents), workflow steps etc.
-The Sling Event Support adds the notion of a job to the OSGi EventAdmin. A job
is a special OSGi event that someone has to process (do the job). The job event
has a special topic *org/apache/sling/event/job* to indicate that the event
contains a job. These job events are consumed by the Sling Job Handler - it
ensures that someone does the job! To support different jobs and different
processors of such jobs, the real topic of the event is stored in the
*event.job.topic* property of the original event. When a job event (event with
the topic *org/apache/sling/event/job*) is received, a new event with the topic
from the property *event.job.topic* is fired (Firing this event comes of course
with a set of rules and constraints explained below).
+The Sling Event Support adds the notion of a job. A job is a special event
that has to be processed exactly once. While older versions of the job handling
were based on sending and receiving events through the OSGi event admin, newer
versions provide enhanced support through special Java interface. This approach
is preferred over the still supported but deprecated event admin way.
-In order to distinguish a job which occured twice and a job which is generated
"at the same time" on several nodes, each job can be uniquely identified by its
topic (property *event.job.topic*) and an optional job name, the *event.job.id*
property. It is up to the client creating the event to ensure that the
*event.job.id* property is unqiue *and* identical on all application nodes. If
the job name is not provided for the job, then it is up to the client to ensure
that the job event is only fired once. Usually for jobs generated based on user
interaction, a unique job name is not required as the job is only created
through the user interaction.
+A job consists of two parts, the job topic describing the nature of the job
and the payload which is a key value map of serializable objects. A client can
initiate a job by calling the *JobManager.addJob* method:
+
+ import org.apache.sling.jobs.JobManager;
+ import org.apache.felix.scr.annotations.Component;
+ import org.apache.felix.scr.annotations.Reference;
+ import java.util.Map;
+ import java.util.HashMap;
+
+ @Component
+ public class MyComponent {
+
+ @Reference
+ private JobManager jobManager;
+
+ public void startJob() {
+ final Map<String, Object> props = new HashMap<String,
Object>();
+ props.put("item1", "/something");
+ props.put("count", 5);
+
+ jobManager.addJob("my/special/jobtopic", null, props);
+ }
+ }
+
+The job topic follows the conventions for the topic of an OSGi event. All
objects in the payload must be serializable and publically available (exported
by a bundle). This is required as the job is persisted and unmarshalled before
processing.
+
+As soon as the method returns from the job manager, the job is persisted and
the job manager ensures that this job will be processed exactly once.
+
+### Job Consumers
+
+A job consumer is a service consuming and processing a job. It registers
itself as an OSGi service together with a property defining which topics this
consumer can process:
+
+ import org.apache.felix.scr.annotations.Component;
+ import org.apache.felix.scr.annotations.Service;
+ import org.apache.sling.event.jobs.Job;
+ import org.apache.sling.event.jobs.consumer.JobConsumer;
+
+ @Component
+ @Service(value={JobConsumer.class})
+ @Property(name=JobConsumer.PROPERTY_TOPICS,
value="my/special/jobtopic",)
+ public class MyJobConsumer implements JobConsumer {
+
+ public JobResult process(final Job job) {
+ // process the job and return the result
+ return JobResult.OK;
+ }
+ }
-### Job Processors
+The *Job* interface allows to query the topic, the payload and additional
information about the current job. The consumer can either return
*JobResult.OK* indicating that the job has been processed, *JobResult.FAILED*
indicating the processing failed, but can be retried or *JobResult.CANCEL* the
processing has failed permanently.
+
+### Deprecated EventAdmin based Solution
+
+In previous versions starting and processing of jobs was based on the OSGi
EventAdmin. While this approach is still supported for compatibility, it's
deprecated and should be replaced with the above mentioned usage of interfaces
and services.
+
+However, if you want to use the old way, starting a job means sending an OSGi
event to the OSGi EventAdmin. The job event has a special topic
*org/apache/sling/event/job* to indicate that the event contains a job. These
job events are consumed by the Sling Job Handler - it ensures that someone does
the job. The real topic of the job is stored in the *event.job.topic* property
of the original event. When a job event (event with the topic
*org/apache/sling/event/job*) is received, a new event with the topic from the
property *event.job.topic* is fired (Firing this event comes of course with a
set of rules and constraints explained below).
+
+In order to distinguish a job which occured twice and a job which is generated
"at the same time" on several nodes, each job can be uniquely identified by its
topic (property *event.job.topic*) and an optional job name, the *event.job.id*
property. It is up to the client creating the event to ensure that the
*event.job.id* property is unqiue *and* identical on all application nodes. If
the job name is not provided for the job, then it is up to the client to ensure
that the job event is only fired once. Usually for jobs generated based on user
interaction, a unique job name is not required as the job is only created
through the user interaction.
A job processor is a service consuming and processing a job. It listens for
OSGi events with the job topic. The OSGi EventAdmin usually comes with a
timeout for event handlers. An event handler must consume an OSGi event as fast
as possible otherwise the handler might get a timeout and get blacklisted.
Therefore a job processor should never directly process the job in the event
handler method, but do this async.
@@ -36,9 +88,9 @@ To make implementing such a job processo
If the job processor wants to do the background processing by itself or does
not need background processing at all, it must signal starting and completition
of the job by call *JobUtil.acknowledgeJob(Event), *JobUtil.finishedJob(event)*
or *JobUtil.rescheduleJob(Event).
-### Processing of Jobs
+### Job Handling
-Incoming jobs are first persisted in the repository (for failover etc.) and
then a job is put into a processing queue. There are different types of queues
defining how the jobs are processed (one after the other, in parallel etc.).
+New jobs are first persisted in the resource tree (for failover etc.), then
the job is distributed to an instance responsible for processing the job and on
that instance the job is put into a processing queue. There are different types
of queues defining how the jobs are processed (one after the other, in parallel
etc.).
For managing queues, the Sling Job Handler uses the OSGi ConfigAdmin - it is
possible to configure one or more queue configurations through the ConfigAdmin.
One way of creating and configuring such configurations is the Apache Felix
WebConsole.
@@ -54,8 +106,6 @@ A queue configuration can have the follo
| *queue.retries* | How often should the job be retried. -1 for endless
retries. |
| *queue.retrydelay* | The waiting time in milliseconds between job
retries. |
| *queue.priority* | The thread priority: NORM, MIN, or MAX |
-| *queue.runlocal* | Should the jobs only be processed on the cluster
node they have been created? |
-| *queue.applicationids* | Optional list of application (cluster node)
ids. If configured, these jobs are only processed on this application node.|
| *service.ranking* | A ranking for this configuration.|
The configurations are processed in order of their service ranking. The first
matching queue configuration is used for the job.
@@ -74,131 +124,46 @@ The jobs are processed in parallel. Sche
#### Ignoring Queues
-A queue of type *ignoring* ignores this job. The job is persisted but not
processed. This can be used to delay processing of some jobs. With a changed
configuration and a restart of the Sling Job Handler the ignored jobs can be
processed at a later time.
+A queue of type *ignoring* ignores this job. The job is persisted but not
processed. This can be used to delay processing of some jobs. With a changed
configuration, the ignored jobs can be processed at a later time.
#### Dropping Queues
A queue of type *drop* is dropping a job - which means it is not processed at
all and directly discarded.
+### Job Distributing
-### Persistence
-
-The job event handler listens for all job events (all events with the topic
*org/apache/sling/event/job*) and will as a first step persist those events in
the JCR repository. All job events are stored in a tree under the job root node
*/var/eventing/jobs*. Persisting the job ensures proper handling in a clustered
environment and allows failover handling after a bundle stop or server restart.
Once a job has been processed by someone, the job will be removed from the
repository.
-
-When the job event listener tries to write a job into the repository it will
check if the repository already contains a job with the given topic
*event.job.topic* and job name (property *event.job.id*). If the event has
already been written by some other application node, it's not written again.
-
-Each job is stored as a separate node with the following properties:
-| *Property Name* | *Description* |
-| *event:topic* | The topic of the job |
-| *event:id* | The unique identifier of this job (optional).
-| *event:created* | The date and time when the event has been created
(stored in the repository)
-| *event:application* | The identifier of the node where the job was created |
-| *event:properties* | Serialized properties |
-| *event:finished* | The date and time when the job has been finished |
-| *event:processor* | The identifier of the node which processed the job
(after successful processing) |
-
-The failover of an application node is accomplished by locking. If a job is
locked in the repository a session scoped lock is used. If this application
node dies, the lock dies as well. Each application node observes the JCR
locking properties and therefore gets aware of unlocked event nodes with the
active flag set to true. If an application node finds such a node, it locks it,
updates the *event:application* information and processes it accordingly. In
this case the event gets the additional property *org/apache/sling/job/retry*.
-
-Each application is periodically removing old jobs from the repository (using
the scheduler).
-
-
-
-### Distribution of Jobs
-
-A job event is an event like any other. Therefore it is up to the client
generating the event to decide if the event should be distributed. If the event
is distributed, it will be distributed with a set *event.application* on the
remote nodes. If the job event handler receives a job with the
*event.application* property set, it will not try to write it into the
repository. It will just broadcast this event asynchronously as a ~FYI event.
-
-If a job event is created simultanously on all application nodes, the event
will not be distributed. The application node that actually has the lock on the
stored job in the repository will clear the *event.application* when sending
the event locally. All other application nodes will use the *event.application*
stored in the repository when broadcasting the event locally.
-
-## Usage Patterns
-
-Based on some usage patterns, we discuss the functionality of the eventing
mechanism.
-
-### Sending User Generated Events
-
-If a user action results in an event, the event is only created on one single
node in the cluster. The event object is generated and delivered to the OSGi
event admin. If the *event.distribute* is not explicitly set, the event is only
distributed localled.
-
-If the *event.distribute* is the, the cluster event handler will write the
event into the repository. All nodes in the cluster observe the repository area
where all events are stored. If a new event is written into that area, each
application node will get notified. It will create the event based on the
information in the repository, clear the *event.distribute* and publish the
event.
-
-The flow can be described as follows:
-1. Client code generates event using OSGi API, if the *event.distribute*
should be set, it is using the ~EventUtil.
-1. Client code sends the event to the (local) event admin.
-1. Event admin delivers the event locally.
-1. Clustering event handler receives the event if *event.distribute* is present
-1. # Event handler adds *event.application* and writes the event to the
repository
-1. # Remote repository observers get notified through JCR observation about
the new event. They distribute the event locally with the *event.application*
(from the node where the event occured first) and cleared *event.distribute*.
-
-### Processing JCR Events
-
-JCR events are environment generated events and therefore are sent by the
repository to each node in the cluster. In general, it is advisable to not
built the application on the low level repository events but to use application
events. Therefore the observer of the JCR event should create an OSGi event
based on the changes in the repository. A decision has to be made if the event
should be a job or a plain event.
+For job distribution (= distributing the processing in a cluster), the job
handling uses the topology feature from Sling - each instance in the topology
announces the set of topics (consumers) it currently has - and this defines the
job capabilities, a mapping from an instance to the topics it can process.
-The flow can be described as follows:
-1. Client registers for JCR observation
-1. JCR notifies the client for changes
-1. Client generates OSGi event based on the JCR events (the *event.distribute*
will not be set), it decides if it sends this event as a job.
-1. Client code sends the event to the (local) event admin
-1. Event admin publishes the event locally
-1. The distribution event handler does not set see the event as the
*event.distribute* is not set.
-1. The job event handler gets the event if it has the job topic
-1. # The job event handler adds the *event.application* property and tries to
write the job to the repository
-1. ## If no job with the topic and *id* property is in the repository, the
event will be written and locked.
-1. ## If an event with the topic and *id* property is in the repository then:
-1. ### If the *event.application* equals the current application node, the
event is set to active (*event:active*) in the repository again and locked
-1. ### If the *event.application* does not equal the current application node,
the event is not distributed locally.
-1. ## If the job could be locked in the repository, the job event handler
delivers the job locally and synchronously and it unlocks the job and sets
*event:active* to false afterwards.
+When a job is scheduled, the job manager uses these capabilities to find out
the set of instances which is able to process the request. If the queue type is
*ordered* then all jobs are processed by the leader of this set. For parallel
queues, the jobs are distributed equally amongst those instance.
-### Sending Scheduled Events
+Failover is handled by the leader: if an instance dies, the leader will detect
this through the topology framework and then redistribute jobs from the dead
instance to the available instances. Of course this takes a leader change into
account as well. In addition if the job capabilities change and this require a
reschedule of jobs, that's done by the leader as well.
-Scheduled events are OSGi events that have been created by the environemnt.
They are generated on each application node of the cluster through an own
scheduler instance. Sending these events works the same as sending events based
on JCR events (see above).
+### Job Creation Patterns
-In most use cases a scheduler will send job events to ensure that exactly one
application node is processing the event.
+The job manager ensures that a job is processed exactly once. However, the
client code has to take care that a job is created exactly once. We'll discuss
this based on some general usage patterns:
-### Receiving OSGi Events
+#### Jobs based on user action
-If you want to receive OSGi events, you can just follow the specification:
receive it via a custom event handler which is registered on bundle start - a
filter can be specified as a configuration property of the handler.
+If a user action results in the creation of a job, the thread processing the
user action can directly create the job. This ensures that even in a clustered
scenario the job is created only once.
-As we follow the principle of distributing each event to every registered
handler, the handler has to decide if it will process the event. In order to
avoid multiple processing of this event in a clustered environment, the event
handler should check the *event.application* property. If it is not set, it's a
local event and the handler should process the event. If the
*event.application* is set, it's a remote event and the handler should not
process the event. This is a general rule of thumb - however, it's up to the
handler to make its decision either on *event.application* or any other
information.
+#### Jobs based on observation / events
-It is advisable to perform the local event check even in a non clustered
environment as it makes the migration to a cluster later on much easier and
there is nearly no performance overhead caused by the check.
+If an observation event or any other OSGi event results in the creation of a
job, special care needs to be taken in a clustered installation to avoid the
job is created on all cluster instances. The easiest way to avoid this, is to
use the topology api and make sure the job is only created on the leader
instance.
-The ~EventUtil class provides an utility method *isLocalEvent(Event)* which
checks the existance of the *event.application* property and returns *true* if
it is absend.
+If that's not doable, the job handling provides the support of a unique job
name - if all instances in a cluster use the same unique job name to create the
job, the job handling detects this and will start this job just once.
Additional jobs arriving with the same name are discarded. The
*JobManager.addJob* method can be provided with this name as the second
argument.
+However as processing of a job name comes with some overhead, it should only
be used if there is no other way. Using the topology api with the leader
detection is the preferred way.
+
## Distributed Events
In addition to the job handling, the Sling Event support adds handling for
distributed events. A distributed event is an OSGi event which is sent across
JVM boundaries to a different VM. A potential use case is to broadcast
information in a clustered environment.
-### Sources of Events
-
-When it comes to application based on Sling, there is a variety of sources
from which OSGi events can be send:
-* JCR observation events
-* Application generated events
-* Events from messaging systems (~JMS)
-* "External events"
-
-The events can either be generated inside a current user context, e.g. when
the user performs an action through the UI, or they can be out of a user
context, e.g. for schedulded events. This leads to different weights of events.
-
-### Weights of Events
-
-We can distinguish two different weights of events, depending how they are
distributed in a clustered environment:
-
- * User generated events - these events are generated directly by some user
action and are therefore started on one single node.
- * Environment generated events (JCR events, scheduler events etc.) - these
events are generated "simultanously" on all nodes.
-
-External events, like incoming JMS events etc. might fall either into the
first or the second category. The receiver of such events must have the
knowledge about the weight of the event.
-
### Basic Principles
-The foundation of the distributed event mechanism is to distribute each event
to every node in a clustered environment. The event distribution mechanism has
no knowledge about the intent of the event and therefore is not able to make
delivery decisions by itself. It is up to the sender to decide what should
happen, however the sender must explicitly declare an event to be distributed.
There are exceptions to "distributing everything to everywhere" as for example
framework related events (bundle stopped, installed etc.) should not be
distributed.
+The foundation of the distributed event mechanism is to distribute each event
to every node in a clustered environment. The event distribution mechanism has
no knowledge about the intent of the event and therefore is not able to make
delivery decisions by itself. It is up to the sender to decide what should
happen. The sender must explicitly declare an event to be distributed as for
example framework related events (bundle stopped, installed etc.) should not be
distributed.
The event mechanism will provide additional functionality making it easier for
event receivers to decide if they should process an event. The event receiver
can determine if the event is a local event or comming from a remote
application node. Therefore a general rule of thumb is to process events only
if they're local and just regard remote events as a FYI.
-The event mechanism is an *event* mechanism which should not be confused with
a *messaging* mechanism. Events are received by the event mechanism and
distributed to registered listeners. Concepts like durable listeners, guarantee
of processing etc. are not part of the event mechanism itself. However, there
is additional support for such things, like job handling.
-
-The application should try to use application events instead of low level JCR
events whereever possible. Therefore a bridging between JCR events and the
event mechanism is required. However, a general "automatic" mapping will not be
provided. It is up to the application to develop such a mapping on a per use
case base. There might be some support to make the mapping easier.
-
-The event handling should be made as transparent to the developer as possible.
Therefore the additional code for a developer to make the eventing working in a
clustered environment etc. should be kept to a minimum (which will hopefully
reduce possible user errors).
-
-### Distributed Events
-
For distributed events two properties are defined (check the *EventUtil*
class):
* *event.distribute* - this flag is set by the sender of an event to give a
hint if the event should be distributed across instances. For example JCR
observation based events are already distributed on all instances, so there is
no further need to distribute them. If the flag is present, the event will be
distributed. The value has currently no meaning, however the EventUtil method
should be used to add this property. If the flag is absent the event is
distributed locally only.
* *event.application* - An identifier for the current application node in the
cluster. This information will be used to detect if an event has been created
on different nodes. If the event has been created on the same node, the
*event.application* is missing, if it is a remote event, the
*event.application* contains the ID of the node, the event has been initially
created. Use the *EventUtil.isLocal(Event)* method to detect if the event is a
local or a distributed event.
@@ -207,54 +172,10 @@ While the *event.distribute* must be set
### Event Distribution Across Application Nodes (Cluster)
-The (local) event admin is the service distributing events locally. The Sling
Distributing Event Handler is a registered event handler that is listening for
events to be distributed. It distributes the events to remote application
notes, the JCR repository is used for distribution. The distributing event
handler writes the events into the repository, the distributing event handlers
on other application nodes get notified through observation and then distribute
the read events locally.
+The (local) event admin is the service distributing events locally. The Sling
Distributing Event Handler is a registered event handler that is listening for
events to be distributed. It distributes the events to remote application
notes, Sling's resource tree is used for distribution. The distributing event
handler writes the events into the resource tree, the distributing event
handlers on other application nodes get notified through observation and then
distribute the read events locally.
As mentioned above, the client sending an event has to mark an event to be
distributed in a cluster by setting the *event.distribute* in the event
properties (through *EventUtil*). This distribution mechanism has the advantage
that the application nodes do not need to know each other and the distribution
mechanism is independent from the used event admin implementation.
-### Storing Events in the Repository
-
-Distributable events are stored in the repository, the repository will have a
specific area (path) where all events are stored.
-
-Each event is stored as a separate node with the following properties:
-| *Property Name* | *Description* |
-| *event:topic* | The topic of the event |
-| *event:application* | The identifier of the application node where the event
was created |
-| *event:created* | The date and time when the event has been created
(stored in the repository)
-| *event:properties* | Serialized properties (except the *event.distribute*,
but including the *event.application*) |
-
-Each application is periodically removing old events from the repository
(using the scheduler).
-
-
-### Sending Scheduled Events
+## Sending Scheduled Events
Scheduled events are OSGi events that have been created by the environemnt.
They are generated on each application node of the cluster through an own
scheduler instance. Sending these events works the same as sending events based
on JCR events (see above).
-
-In most use cases a scheduler will send job events to ensure that exactly one
application node is processing the event.
-
-### Receiving OSGi Events
-
-If you want to receive OSGi events, you can just follow the specification:
receive it via a custom event handler which is registered on bundle start - a
filter can be specified as a configuration property of the handler.
-
-As we follow the principle of distributing each event to every registered
handler, the handler has to decide if it will process the event. In order to
avoid multiple processing of this event in a clustered environment, the event
handler should check the *event.application* property. If it is not set, it's a
local event and the handler should process the event. If the
*event.application* is set, it's a remote event and the handler should not
process the event. This is a general rule of thumb - however, it's up to the
handler to make its decision either on *event.application* or any other
information.
-
-It is advisable to perform the local event check even in a non clustered
environment as it makes the migration to a cluster later on much easier and
there is nearly no performance overhead caused by the check.
-
-The ~EventUtil class provides an utility method *isLocalEvent(Event)* which
checks the existance of the *event.application* property and returns *true* if
it is absend.
-
-## Scheduler
-
-Each Sling based application will contain a scheduler service (which is based
on the Quartz open source project).
-
-## Use Cases
-
-### Post Processing (Business Processes)
-
-A typical example for post processing (or running a business process) is
sending an email or creating thumbnails and extracting meta data from the
content (like we do in DAM), which we will discuss here.
-
-An appropriate JCR observer will be registered. This observer detects when new
content is put into the repository or when content is changed. In these cases
it creates appropriate *CONTENT*ADDED*, *CONTENT*UPDATED* OSGi events from the
JCR events. In order to ensure that these actions get processed accordingly,
the event is send as a job (with the special job topic, the *topic* and *id*
property).
-
-The event admin now delivers these jobs to the registered handlers. The job
event handler gets notified and (simplified version) sends the contained event
synchronously. One of the handlers for these events is the post processing
service in DAM. The job mechanism ensures that exactly one application node is
post processing and that the process has to be finished even if the application
node dies during execution.
-
-## Scheduling
-
-The scheduler is a service which uses the open source Quartz library. The
scheduler has methods to start jobs periodically or with a cron definition. In
addition, a service either implementing *java.lang.Runnable* or
*org.quartz.job* is started through the whiteboard pattern *if* it either
contains a configuration property *scheduler.expression* or *scheduler.period*.
The job is started with the ~PID of the service - if the service has no PID,
the configuration property *scheduler.name* must be set.
\ No newline at end of file
Modified: sling/site/trunk/content/site/.htaccess
URL:
http://svn.apache.org/viewvc/sling/site/trunk/content/site/.htaccess?rev=1505925&r1=1505924&r2=1505925&view=diff
==============================================================================
--- sling/site/trunk/content/site/.htaccess (original)
+++ sling/site/trunk/content/site/.htaccess Tue Jul 23 07:58:25 2013
@@ -5,6 +5,7 @@ Redirect Permanent /site/architecture.ht
Redirect Permanent /site/adapters.html
/documentation/the-sling-engine/adapters.html
Redirect Permanent /site/apache-sling-commons-thread-pool.html
/documentation/bundles/apache-sling-commons-thread-pool.html
Redirect Permanent /site/apache-sling-community-roles-and-processes.html
/project-information/apache-sling-community-roles-and-processes.html
+Redirect Permanent /site/apache-sling-eventing-and-job-handling.html
/documentation/bundles/apache-sling-eventing-and-job-handling.html
Redirect Permanent /site/authentication.html
/documentation/the-sling-engine/authentication.html
Redirect Permanent /site/authentication-actors.html
/documentation/the-sling-engine/authentication/authentication-actors.html
Redirect Permanent /site/authentication-authenticationhandler.html
/documentation/the-sling-engine/authentication/authentication-authenticationhandler.html
