Re: [infinispan-dev] Passing client listener parameters programmatically

[Galder Zamarreno]

I've created a JIRA to track this:
https://issues.jboss.org/browse/ISPN-9151

On Mon, Apr 16, 2018 at 10:21 AM Adrian Nistor  wrote:

> +1 for both points.
>
> And I absolutely have to add that I never liked the annotation based
> listeners, both the embedded and the remote ones.
>
> On 04/16/2018 10:48 AM, Dan Berindei wrote:
>
> +1 to not require annotations, but -100 to ignore the annotations if
> present, we should throw an exception instead.
>
> Dan
>
> On Fri, Apr 13, 2018 at 9:57 PM, William Burns 
> wrote:
>
>> I personally have never been a fan of the whole annotation thing to
>> configure your listener, unfortunately it just has been this way.
>>
>> If you are just proposing to adding a new addClientListener method that
>> takes those arguments, I don't have a problem with it.
>>
>> void addClientListener(Object listener, String filterFactoryName,
>> Object[] filterFactoryParams, String converterFactoryName, Object[]
>> converterFactoryParams);
>>
>> I would think we would use these values only and ignore any defined on
>> the annotation.
>>
>>
>> Also similar to this but I have some API ideas I would love to explore
>> for ISPN 10 surrounding events and the consumption of them.
>>
>>  - Will
>>
>> On Fri, Apr 13, 2018 at 11:12 AM Galder Zamarreno 
>> wrote:
>>
>>> Hi,
>>>
>>> We're working with the OpenWhisk team to create a generic Feed that
>>> allows Infinispan remote events to be exposed in an OpenWhisk way.
>>>
>>> So, you'd pass in Hot Rod endpoint information, name of cache and other
>>> details and you'd establish a feed of data from that cache for
>>> create/updated/removed data.
>>>
>>> However, making this generic is tricky when you want to pass in
>>> filter/converter factory names since these are defined at the annotation
>>> level.
>>>
>>> Ideally we should have a way to pass in filter/converter factory names
>>> programmatically. To avoid limiting ourselves, you could potentially pass
>>> in an instance of the annotation in an overloaded method or as optional
>>> parameter [1].
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Galder
>>>
>>> [1]
>>> https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
> ___
> infinispan-dev mailing 
> listinfinispan-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Passing client listener parameters programmatically

[Adrian Nistor]

+1 for both points.

And I absolutely have to add that I never liked the annotation based 
listeners, both the embedded and the remote ones.


On 04/16/2018 10:48 AM, Dan Berindei wrote:
+1 to not require annotations, but -100 to ignore the annotations if 
present, we should throw an exception instead.


Dan

On Fri, Apr 13, 2018 at 9:57 PM, William Burns > wrote:


I personally have never been a fan of the whole annotation thing
to configure your listener, unfortunately it just has been this way.

If you are just proposing to adding a new addClientListener method
that takes those arguments, I don't have a problem with it.

void addClientListener(Object listener, String filterFactoryName,
Object[] filterFactoryParams, String converterFactoryName,
Object[] converterFactoryParams);

I would think we would use these values only and ignore any
defined on the annotation.


Also similar to this but I have some API ideas I would love to
explore for ISPN 10 surrounding events and the consumption of them.

 - Will

On Fri, Apr 13, 2018 at 11:12 AM Galder Zamarreno
> wrote:

Hi,

We're working with the OpenWhisk team to create a generic Feed
that allows Infinispan remote events to be exposed in an
OpenWhisk way.

So, you'd pass in Hot Rod endpoint information, name of cache
and other details and you'd establish a feed of data from that
cache for create/updated/removed data.

However, making this generic is tricky when you want to pass
in filter/converter factory names since these are defined at
the annotation level.

Ideally we should have a way to pass in filter/converter
factory names programmatically. To avoid limiting ourselves,
you could potentially pass in an instance of the annotation in
an overloaded method or as optional parameter [1].

Thoughts?

Cheers,
Galder

[1]

https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/infinispan-dev



___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org 
https://lists.jboss.org/mailman/listinfo/infinispan-dev





___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev



___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Passing client listener parameters programmatically

[William Burns]

I personally have never been a fan of the whole annotation thing to
configure your listener, unfortunately it just has been this way.

If you are just proposing to adding a new addClientListener method that
takes those arguments, I don't have a problem with it.

void addClientListener(Object listener, String filterFactoryName, Object[]
filterFactoryParams, String converterFactoryName, Object[]
converterFactoryParams);

I would think we would use these values only and ignore any defined on the
annotation.


Also similar to this but I have some API ideas I would love to explore for
ISPN 10 surrounding events and the consumption of them.

 - Will

On Fri, Apr 13, 2018 at 11:12 AM Galder Zamarreno  wrote:

> Hi,
>
> We're working with the OpenWhisk team to create a generic Feed that allows
> Infinispan remote events to be exposed in an OpenWhisk way.
>
> So, you'd pass in Hot Rod endpoint information, name of cache and other
> details and you'd establish a feed of data from that cache for
> create/updated/removed data.
>
> However, making this generic is tricky when you want to pass in
> filter/converter factory names since these are defined at the annotation
> level.
>
> Ideally we should have a way to pass in filter/converter factory names
> programmatically. To avoid limiting ourselves, you could potentially pass
> in an instance of the annotation in an overloaded method or as optional
> parameter [1].
>
> Thoughts?
>
> Cheers,
> Galder
>
> [1]
> https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] Passing client listener parameters programmatically

[Galder Zamarreno]

Hi,

We're working with the OpenWhisk team to create a generic Feed that allows
Infinispan remote events to be exposed in an OpenWhisk way.

So, you'd pass in Hot Rod endpoint information, name of cache and other
details and you'd establish a feed of data from that cache for
create/updated/removed data.

However, making this generic is tricky when you want to pass in
filter/converter factory names since these are defined at the annotation
level.

Ideally we should have a way to pass in filter/converter factory names
programmatically. To avoid limiting ourselves, you could potentially pass
in an instance of the annotation in an overloaded method or as optional
parameter [1].

Thoughts?

Cheers,
Galder

[1]
https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev