Hi,
On Fri, Oct 25, 2013 at 4:54 PM, Alexander Klimetschek
wrote:
> On 24.10.2013, at 16:55, Justin Edelson 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
>
