Hi, On Fri, Oct 25, 2013 at 4:54 PM, Alexander Klimetschek <aklim...@adobe.com> wrote: > On 24.10.2013, at 16:55, Justin Edelson <jus...@justinedelson.com> wrote: > >> Given that there's already an expression syntax defined in the >> EventAdmin specification, wouldn't it make more sense for Oak to just >> use OSGi Events? That's the only way I personally could forsee us >> being in a position to deprecate/remote the JCR Observation/OSGi >> EventAdmin bridge which we have in Sling today. > > I don't think Oak wants to be tied to OSGi, but the expression syntax could > maybe reused.
Better IMHO would be for Oak to use the event/messaging system provided by the platform. In an OSGi environment, this would be EventAdmin. In JavaEE, it would be JMS (for which message selectors can be used for filtering). > >> FWIW, I'm not sure it's a straight comparison between the bridge we >> have in Sling and the CQ Workflow engine. The CQ Workflow engine >> *could* be implemented by registering specific OSGi event listeners >> (one per launcher). It just isn't (or so your email implies :). > > Not really, because it has to make the decision on matching events *itself*. > Because of that, it is natural to only have one central listener (it quickly > forks off into separate jobs once a match for a certain entry has been found). Why does the workflow engine have to make that decision itself? Can't that decision be expressed declaratively? They are, after all, being defined declaratively by the administrator, so it should just be a matter of mapping the administrator's selections to a filter expression and then letting the EventAdmin implementation handle the filter. For example, you could have a workflow launcher expressed as a listener with a filter of "(&(resourceType=nt:file)(path=/content/dam/*/original))". NOTE - I'm not necessarily saying that everything in CQ's workflow engine is supported by Sling Resource events *today*; there might be a need to add new event properties, but that's far from impossible. My point is that it is in large part the lack of good filtering (which is available in EventAdmin and JMS) is what leads to having multiple dispatching systems in the same applicatio and that good filtering is already available in Sling applications *because* of the Observation/EventAdmin bridge. Justin > > What I am asking for is that Oak provides those options (match on property > values etc.) directly and it can handled as early as possible, without Oak > having to call an event listener in the first place (and start a new thread > etc.) in case there is no match. > > Cheers, > Alex >
