Hi Robert, Jobs are Events guaranteed to be processed. Therefore jobs are an extension of the event engine that takes care of persisting the eventinformation and predefines various attributes. The Job API is convenient way to create and consume jobs without the need to manually compose those events which was much more complicated in first place.
In short you do not need to migrate your old jobs - the old way of creating those still works, but for new job requirements you may want to use the new API for the sake of simplicity of code. The event API itself will anyways still play an important role because it is light weight and it is an easy way to losely wire logic together. The stability of jobs always come at a price (de/serializing data to persistence), so you might want to think twice if you really require guarrantee of processing or if losing the event on restart is acceptable. HTH Dominik On Mon, Jun 16, 2014 at 1:20 PM, Robert A. Decker <dec...@robdecker.com> wrote: > We have the new jobs system (JobConsumer, jobManager, etc). But we also > still use osgi’s events to, for example, handle > SlingConstants.TOPIC_RESOURCE_ADDED. > > Should we be thinking about jobs and events as separate behaviors? Should > we be using the old event system to announce events and then using the new > job system to do work? Is that a good strategy? Or does it not really > matter, and we should use the new jobs system for everything? > > Robert A. Decker > dec...@robdecker.com > http://robdecker.com/about > > >
