Re: [observation] more options in JackrabbitEventFilter

2016-09-13 Thread Stefan Egli 
On 13/09/16 15:27, "Davide Giannella"  wrote:

>On 12/09/2016 09:48, Stefan Egli wrote:
>> IIUC then EventListeners are registered via either JCR's
>> ObservationManager or Jackrabbit's extension at [0]. If you want to do
>> this in Oak (ie not in Jackrabbit) then would you extend Oak's
>> Observationmanager ([1]) directly?
>Didn't look at the code and didn't think all the implications.
>
>Would it be an option to expose,
>javax.jcr.oak.observation.OakObservationManager that extends
>javax.jcr.observation.ObservationManager in which we expose what need?

Right, there's probably two options:

# (oak) add another variant of addEventListener to OakObservationManager
([0])
# (jackrabbit) integrate that into the JackrabbitEventFilter ([1])

I guess it comes down to API design and cleanliness, I don't have any
preference.

Cheers,
Stefan
--
[0] - 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/o
rg/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java#L179
[1] - 
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-api/src/main/jav
a/org/apache/jackrabbit/api/observation/JackrabbitEventFilter.java

Re: [observation] more options in JackrabbitEventFilter

2016-09-13 Thread Davide Giannella 
On 12/09/2016 09:48, Stefan Egli wrote:
> IIUC then EventListeners are registered via either JCR's
> ObservationManager or Jackrabbit's extension at [0]. If you want to do
> this in Oak (ie not in Jackrabbit) then would you extend Oak's
> Observationmanager ([1]) directly?
Didn't look at the code and didn't think all the implications.

Would it be an option to expose,
javax.jcr.oak.observation.OakObservationManager that extends
javax.jcr.observation.ObservationManager in which we expose what need?
I'm not familiar at all with the observation thing.

Davide

Re: [observation] more options in JackrabbitEventFilter

2016-09-12 Thread Stefan Egli 
Hi Davide,

On 08/09/16 14:24, "Davide Giannella"  wrote:

>On 07/09/2016 14:04, Michael Dürig wrote:
>> No not open them. But make their functionality available through an
>> API. Since JCR is dead (hint hint) we probably have to come up with an
>> ad-hoc API here.
>FWIW, I'm for exposing this aspect as Oak API.

Would be fine for me, however, how would you do that?

IIUC then EventListeners are registered via either JCR's
ObservationManager or Jackrabbit's extension at [0]. If you want to do
this in Oak (ie not in Jackrabbit) then would you extend Oak's
Observationmanager ([1]) directly?


Cheers,
Stefan
--
[0] - 
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-api/src/main/jav
a/org/apache/jackrabbit/api/observation/JackrabbitObservationManager.java#L
26
[1] - 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/o
rg/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java

>
>Then in Oak we implement few Filters for the already existing mechanism,
>so that the jcr layer can map the JCR API as Oak api.
>
>An application that needs to have complex filtering, will have to
>leverage the Oak API.
>
>Don't know whether it will be possible for an application to leverage
>*both* JCR and Oak APIs but I'm sure there are ways around it.
>
>Cheers
>Davide
>
>

Re: [observation] more options in JackrabbitEventFilter

2016-09-08 Thread Davide Giannella 
On 07/09/2016 14:04, Michael Dürig wrote:
> No not open them. But make their functionality available through an
> API. Since JCR is dead (hint hint) we probably have to come up with an
> ad-hoc API here.
FWIW, I'm for exposing this aspect as Oak API.

Then in Oak we implement few Filters for the already existing mechanism,
so that the jcr layer can map the JCR API as Oak api.

An application that needs to have complex filtering, will have to
leverage the Oak API.

Don't know whether it will be possible for an application to leverage
*both* JCR and Oak APIs but I'm sure there are ways around it.

Cheers
Davide