+ 1 for this improvement from me. toD is very commonly used expression, and while it is an improvement over recipientList, it has a serious drawback - creating new endpoints for every changed option...
Only last week I had to use toD for querying Cassandra, and it quickly became obvious it is not practical as it was creating a new endpoint and a new connection to a Cassandra cluster of 5 even for a small query parameter change. You change would allow to reuse the connection (I understand this has to be added to Cassandra component first as well) and dynamically build queries..gr8. Bilgin On Mon, Apr 23, 2018 at 11:50 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > We have ticket > https://issues.apache.org/jira/browse/CAMEL-12462 > > Its an idea I had though about in the past, even before we had toD. > However I do think that the simplification toD gives Camel end users, > can warrant that we attempted to look at this again. > > In particular when you have HTTP endpoints that are dynamic (different > query parameters, context-path, etc) but calling to the same HTTP > server, then toD should ideally be optimised to deal with this > out-of-the-box. Today you end up with unique Camel endpoints per > unique combo computed from toD. > > So CAMEL-12462 optimised and resolved this. However it does this with > a little bit of complexity of parsing the computed endpoint uri to > resolve it into 3 parts > > - static base uri > - dynamic context-path > - dynamic query parameters > > Then it will use the static base url, as the Camel endpoint, and > therefore resolve into a single endpoint and Camel http producer. And > the dynamic parts are automatic provided in Camel headers that the > HTTP producer supports (HTTP_PATH and HTTP_QUERY). > > Anyway the PR has some docs and examples and more details in the > updated adoc file for toD, so take a look at that file. > > I implemented this with a way for components to support this by > providing a service locator file in the send-dynamic folder of > META-INF, eg same way we discover components. This way other > components can provide their own optimisation implementation in the > future. For example to other kinds of components like JMS, Kafka and > others. > > I wanted to give the community and other Camel committers a chance to > provide feedback, review, improve, etc - before we merged this into > the master branch. > > There is a GitHub PR that makes it easier to browse the code changes > https://github.com/apache/camel/pull/2302 > > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Bilgin Ibryam ASF Member | Architect at Red Hat http://ofbizian.com | @bibryam Kubernetes Patterns http://leanpub.com/k8spatterns (in progress) Camel Design Patterns https://leanpub.com/camel-design-patterns
