[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 <anistor at redhat.com> 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 <mudokonman at gmail.com>
> 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 <galder at redhat.com>
>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
> _______________________________________________
> infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20180516/6f6294a9/attachment.html