+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 <mudokon...@gmail.com
<mailto:mudokon...@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
<gal...@redhat.com <mailto:gal...@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
<https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation>
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
<https://lists.jboss.org/mailman/listinfo/infinispan-dev>
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
<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
