[
https://issues.apache.org/jira/browse/CAMEL-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15795084#comment-15795084
]
Claus Ibsen commented on CAMEL-10638:
-------------------------------------
Can you only configure this now using <bean> style?
That is not desireable. Using <bean> is hard and complex and people have to
remember class names and much more. Its okay you can do it as an alternative
way.
But the point is that you configure all your Camel stuff inside <camelContext>
like must of the stuff you can do with data formats, endpoints, hystrix etc.
This gives us type safe configuration, tooling support, documentation in the
xsd, dsl etc.
> Refactor ServiceCall EIP
> ------------------------
>
> Key: CAMEL-10638
> URL: https://issues.apache.org/jira/browse/CAMEL-10638
> Project: Camel
> Issue Type: Improvement
> Components: camel-consul, camel-core, camel-etcd, camel-kubernetes,
> camel-ribbon, camel-spring-cloud
> Reporter: Luca Burgazzoli
> Assignee: Luca Burgazzoli
> Fix For: 2.19.0
>
>
> As today the ServiceCall is implemented loading a ProcessorFactory using a
> ServiceLoader like system but this may cause issues as if you have multiple
> components providing an implementation of the ServiceCall SPI so i.e. if you
> have both consul and etcd components in the classpath, the following set-up
> will be initialized with the first ServiceCall SPI found in the classpath
> regardless of the consulConfiguration/etcdConfiguration:
> {code:java}
> from("timer:consul?period=1s")
> .serviceCall()
> .name("consul")
> .consulConfiguration()
> ...
> .end();
> from("timer:etcd?period=1s")
> .serviceCall()
> .name("etcd")
> .etcdConfiguration()
> ...
> .end();
> {code}
> It may be better to have a different way to set-up the ServiceCall so that
> each element (server discovery, load balancer, server chooser) is provided
> instead of created by the ServiceCall ProcessorFactory.
> A possible - high level - definition of the classes may look like:
> {code:java}
> interface ServiceCallLoadBalancer extends Processor {
> }
> interface ServiceCallServer {
> String getServiceId();
> String getHost();
> int getPort();
> Map<String, String> getMetadata();
> }
> interface ServiceCallServerDiscovery {
> List<ServiceCallServer> getInitialListOfServers(String serviceId);
> List<ServiceCallServer> getUpdatedListOfServers(String serviceId);
> }
> interface ServiceCallServerDiscoveryAware {
> void setServerDiscovery(ServiceCallServerDiscovery serverDiscovery);
> }
> interface ServiceCallServerChooser {
> ServiceCallServer choose(List<ServiceCallServer> serverList)
> }
> interface ServiceCallServerChooserAware {
> void setServerChooser(ServiceCallServerChooser serverDiscovery);
> }
> class ServiceCallConfiguration {
> public void setServiceId(String serviceid);
> public void setComponent(String component);
> public void setUri(String uri);
> public void setExpression(Expression expression);
> public void setLoadBalancer(String loadBalancerRef);
> public void setLoadBalancer(ServiceCallLoadBalancer<ServiceCallServer>
> loadBalancer);
> public void setServerDiscovery(String serverDiscoveryRef);
> public void
> setServerDiscovery(ServiceCallServerDiscovery<ServiceCallServer>
> serverDiscovery);
> public void setServerChooser(String serverChooserRef);
> public void setServerChooser(ServiceCallServerChooser<ServiceCallServer>
> serverChooser);
> }
> class ServiceCallDefinition extends ServiceCallConfiguration {
> public void setConfiguration(ServiceCallConfiguration configuration);
> public void setConfiguration(String configurationRef);
> }
> class DefaultServiceCallLoadBalancer implements CamelContextAware,
> ServiceCallServerDiscoveryAware, ServiceCallServerChooserAware,
> ServiceCallLoadBalancer {
> ...
> }
> {code}
> The configuration part will be similar to the one we have today except the
> etcdConfiguration/consulConfiguration/etc will be removed in favor of a
> generic one, like:
> {code:java}
> ServiceCallServerDiscovery sd = new EtcdServiceCallServerDiscovery(conf);
> from("timer:consul?period=1s")
> .serviceCall()
> .name("consul")
> .loadBalancer("my-load-balancer")
> .serverDiscovery(sd)
> .serverChooser(servers -> servers.get(0))
> .end();
> {code}
> There will be a default implementation of the load balancer so defining it
> may not be needed but environment like spring-cloud could provide a different
> implementation.
> [~davsclaus] what do you think ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
