Hey Guru, Nice ideas! Some thoughts inline.
Cheers, Raúl. On Thu, Mar 24, 2016 at 12:12 PM, Gnanaguru S <gnanagu...@gmail.com> wrote: > > Guys, > > These are some of the feature, I wish to see in upcoming camel versions. It > would be useful to have. > > 1. Timeout option in a internal synchronous endpoint - we very much use > camel for orchestration layer. In a use case where many downstream > routes/endpoints are called synchronously, I would like to have a direct: > endpoint which has a timeout. So that I can timeout a call to some > particular downstream route, handle the exception and proceed to the next > step. In fact this option is already there with seda: endpoint, but I wont > prefer to use seda: for synchronous flow. Also I can use internal JMS > endpoints between routes to achieve this, but sometimes using JMS for > internal transaction is heavy. > Yep. JMS can be a little heavy, but I tend to go in that direction for internal orchestration because it supports the async routing engine. For us, it is very important to not block the system while we're waiting for backend systems to respond. I think that camel-seda and camel-disruptor need to support the async routing engine. I might work on this in the next weeks. You can use camel-seda with waitForTaskToComplete=Always, or it'll work OOTB if your exchange is InOut (default value of the option is 'IfReplyExpected'). 2. Improved/Sophisticated xmljson component. > We depend on a 3rd party library for this. Do you know if there's a better 3rd party library for this? > 3. Improved/even Simpler exception handling. > Could you detail this point? I think we need to simplify the documentation for error handling. In most cases I've seen, 100% of the users requirements is satisfied by onException. A suggestion from my part is to find a way to use onExceptions defined at the context level without copying them to each single route (wasteful, imagine if you're using a recipientList with its corresponding producer cache, etc.). > 4. Native Camel transformation component, I am bit obsessed with XSLT. So I > was thinking, why dont camel incorporate something like xslt: internally. > like Camel transformer component ? Something better than XSLT component, > something very camelish. ;) > So am I ;-) If you come from a comercial ESB background, you're likely to find lots of potential in externally declared transformations vs. code transformations. What would be cool is to be able to inject, delete, modify XML nodes and attributes directly from a route, without dealing with XML APIs, with specific DSL particles. What exactly were you thinking of? > 5. Better CXF configurations, for example configuring timeout for a cxf > consumer and producer endpoint is not that straight forward like jetty / > http(4) components. > > 6. Better/Improved unit testing, Camel test support is great, like > AdviceWith & Mock endpoints. But some of their methods have issues, I am > seeing latest camel versions have lot of fixes, but I think some more > features can be introduced. For example, if I want send a sample XML as a > request, I dont want to use a IOUtil or a File reader to load the file and > then to a string and then pass it to a producer template, instead it will > be > easier if there is a something called as mockRequest. May be there are > better options already, please ignore my ignorance here ;) > > 7. JSON validator. XML XSD validation is nice and straight forward, but it > will be great if we have something similar for JSON as well. like > to:json-validator:classpath/response.json > Yep, we should create a component for JSON Schema validations. > > 8. Ability to load a route context directly to a unit test case > > These are some aspects I could think of at the moment, I will try to add > more. But please ignore if some of these ideas sounds silly ;) > > Happy long weekend ! > > Cheers > Guru > http://gnan.io > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/DISCUSS-Thoughts-on-Apache-Camel-2-18-and-towards-3-0-tp5779549p5779641.html > Sent from the Camel Development mailing list archive at Nabble.com. >
