Hi Luca Yeah its good to get more eyes on this new set of code. When I created kubernetes and ribbon there was sure some overlap of code that could be shared, but I didn't push for much default/abstract code in camel-core because there its new code and I also wanted to see what consul, etcd, zookeeper and other distributed systems may need/require.
I like the idea of the impl.remote package to have some base implementation there. Your current branch [2] has a good set of reusable code although its tied to consul currently, so that would need to be made abstract so it can be reuse by kuernetes and maybe also ribbon as well (where it makes sense). An aspect we haven't added yet could be to find out if we can expose some JMX attributes and operations for thise service call EIP as well? And then maybe some Camel commands so you can manage/list it from karaf and other CLIs. But this part is more "nice to have" and a bit "eye candy" but still somewhat cool. On Thu, May 26, 2016 at 4:13 PM, Luca Burgazzoli <lburgazz...@gmail.com> wrote: > Hello, > > I'm playing a little bit with the new ServiceCall EIP by adding support for > consul service discovery and I've committed some code in my own branch [1]. > > I borrowed most of the code from camel-kubernetes and as it ended up being > almost a clone, I've tried to make some base/default classes as what really > make the difference is the implementation of ServiceCallServerListStrategy > and ServiceCallLoadBalancer so to add a simple discovery engine you only > need to implement your own ServiceCallServerListStrategy and eventually your > own ServiceCallLoadBalancer (i.e. for ribbon). > > Does it make sense ? > > [1] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-9989 > [2] > https://github.com/apache/camel/compare/master...lburgazzoli:CAMEL-9989?expand=1 > > --- > Luca Burgazzoli -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
