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
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,
> 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
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
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
> > >
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
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:
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> >
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
> 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:
>
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
> 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.
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
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
>
>
> 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
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
>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
>
>
> 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
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,
>
>
> 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,
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
>
>
> 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
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
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
23 matches
Mail list logo