Re: Observation with the ResourceChangeListener

the paths to listen for configurable and do the property name filtering in the listener. Carsten > Hi, > > as you know we're currently in the process of moving away from the OSGi > event based observation to the ResourceChangeListener interfaces. Main > reason is moving to a more

Re: Observation with the ResourceChangeListener

On 21/09/16 14:28, "Carsten Ziegeler" wrote: >> On 21/09/16 14:14, "Robert Munteanu" wrote: >> >>> On Wed, 2016-09-21 at 14:11 +0200, Stefan Egli wrote: On 21/09/16 11:26, "Robert Munteanu" wrote: > > On Wed,

Re: Observation with the ResourceChangeListener

> On 21/09/16 14:14, "Robert Munteanu" wrote: > >> On Wed, 2016-09-21 at 14:11 +0200, Stefan Egli wrote: >>> On 21/09/16 11:26, "Robert Munteanu" wrote: >>> On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote: > > So we a) need to

Re: Observation with the ResourceChangeListener

On 21/09/16 14:14, "Robert Munteanu" wrote: >On Wed, 2016-09-21 at 14:11 +0200, Stefan Egli wrote: >> On 21/09/16 11:26, "Robert Munteanu" wrote: >> >> > >> > On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote: >> > > >> > > So we a) need to

Re: Observation with the ResourceChangeListener

On Wed, 2016-09-21 at 14:11 +0200, Stefan Egli wrote: > On 21/09/16 11:26, "Robert Munteanu" wrote: > > > > > On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote: > > > > > > So we a) need to clarify the contract and b) think about what we > > > do > > > if > > >

Re: Observation with the ResourceChangeListener

On 21/09/16 11:26, "Robert Munteanu" wrote: >On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote: >>So we a) need to clarify the contract and b) think about what we do >> if >> someone registers for a glob pattern. Do we send removal of parents >> automatically or do we

Re: Observation with the ResourceChangeListener

On Wed, 2016-09-21 at 11:18 +0200, Carsten Ziegeler wrote: > > > > On Wed, 2016-09-21 at 10:21 +0200, Carsten Ziegeler wrote: > > > > > > > > > > > > > > > > > > > > > > > On 21.9.16 9:14 , Carsten Ziegeler wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Re: Observation with the ResourceChangeListener

On 21/09/16 11:18, "Carsten Ziegeler" wrote: >So we a) need to clarify the contract and b) think about what we do if >someone registers for a glob pattern. Do we send removal of parents >automatically or do we expect to listener to register at /? I'd say clarifying the

Re: Observation with the ResourceChangeListener

> On Wed, 2016-09-21 at 10:21 +0200, Carsten Ziegeler wrote: >>> >>> >>> >>> On 21.9.16 9:14 , Carsten Ziegeler wrote: > > > > On 21.9.16 8:50 , Carsten Ziegeler wrote: >> >>> >>> >>> >>> On 21.9.16 8:33 , Carsten Ziegeler wrote: >

Re: Observation with the ResourceChangeListener

On 21/09/16 11:12, "Carsten Ziegeler" wrote: >> Hi, >> >> On 21/09/16 08:13, "Carsten Ziegeler" wrote: >> >>> Finally, recently some people suggested that we support all of Oaks >>> filtering possibilities for the ResourceChangeListener. I'm not a

Re: Observation with the ResourceChangeListener

> Hi, > > On 21/09/16 08:13, "Carsten Ziegeler" wrote: > >> Finally, recently some people suggested that we support all of Oaks >> filtering possibilities for the ResourceChangeListener. I'm not a fan of >> that - first of all, we should only support what is really needed.

Re: Observation with the ResourceChangeListener

On Wed, 2016-09-21 at 10:21 +0200, Carsten Ziegeler wrote: > > > > > > > > On 21.9.16 9:14 , Carsten Ziegeler wrote: > > > > > > > > > > > > > > > > > > > On 21.9.16 8:50 , Carsten Ziegeler wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 21.9.16 8:33 , Carsten

Re: Observation with the ResourceChangeListener

Hi, On 21/09/16 08:13, "Carsten Ziegeler" wrote: >Finally, recently some people suggested that we support all of Oaks >filtering possibilities for the ResourceChangeListener. I'm not a fan of >that - first of all, we should only support what is really needed. >Second, as

Re: Observation with the ResourceChangeListener

> > > On 21.9.16 9:14 , Carsten Ziegeler wrote: >>> >>> >>> On 21.9.16 8:50 , Carsten Ziegeler wrote: > > > On 21.9.16 8:33 , Carsten Ziegeler wrote: >>> Pushing filters as much into Oak has many performance advantages >>> though compared to filter messages after

Re: Observation with the ResourceChangeListener

On 21.9.16 9:14 , Carsten Ziegeler wrote: On 21.9.16 8:50 , Carsten Ziegeler wrote: On 21.9.16 8:33 , Carsten Ziegeler wrote: Pushing filters as much into Oak has many performance advantages though compared to filter messages after delivery. Also Oak would easily able to support the

RE: Observation with the ResourceChangeListener

>But we have to think about other providers as well, what if I use the >mongo resource provider? Can we make the same guarantees? We have an >abstraction and have to come up with a solution that always works >without exceptions. when speaking oft he nosql resource providers based on the generic

Re: Observation with the ResourceChangeListener

> > > On 21.9.16 8:50 , Carsten Ziegeler wrote: >>> >>> >>> On 21.9.16 8:33 , Carsten Ziegeler wrote: > Pushing filters as much into Oak has many performance advantages > though >> compared to filter messages after delivery. Also Oak would easily >> able >> to support the

Re: Observation with the ResourceChangeListener

On 21.9.16 8:50 , Carsten Ziegeler wrote: On 21.9.16 8:33 , Carsten Ziegeler wrote: Pushing filters as much into Oak has many performance advantages though compared to filter messages after delivery. Also Oak would easily able to support the delete use case described above. In all cases,

Re: Observation with the ResourceChangeListener

> > > On 21.9.16 8:33 , Carsten Ziegeler wrote: >>> Pushing filters as much into Oak has many performance advantages though >>> > compared to filter messages after delivery. Also Oak would easily able >>> > to support the delete use case described above. >>> > >> In all cases, always,

Re: Observation with the ResourceChangeListener

On 21.9.16 8:33 , Carsten Ziegeler wrote: Pushing filters as much into Oak has many performance advantages though > compared to filter messages after delivery. Also Oak would easily able > to support the delete use case described above. > In all cases, always, guaranteed? For some

Re: Observation with the ResourceChangeListener

> > > On 21.9.16 8:13 , Carsten Ziegeler wrote: >> Finally, recently some people suggested that we support all of Oaks >> filtering possibilities for the ResourceChangeListener. I'm not a fan of >> that - first of all, we should only support what is really needed. >> Second, as soon as we

Re: Observation with the ResourceChangeListener

On 21.9.16 8:13 , Carsten Ziegeler wrote: Finally, recently some people suggested that we support all of Oaks filtering possibilities for the ResourceChangeListener. I'm not a fan of that - first of all, we should only support what is really needed. Second, as soon as we support it, it means

Observation with the ResourceChangeListener

Hi, as you know we're currently in the process of moving away from the OSGi event based observation to the ResourceChangeListener interfaces. Main reason is moving to a more scalable/better performing solution. We started very simple with the ResourceChangeListener: listeners register themselves