Regarding Raul´s ideas: Change often frightens people and changing the engine of a work horse (err, I mean work camel) surely frightens me. Maybe I am a worrisome person. I really like to be able to at least look at the moving parts. If you move to Rx/Go/Scala/whatever (right now) you have surely lost me. That will change in the future. Maybe waiting for the new (ok, maybe not so new) ideas to trickle (a bit more) into the mainstream would be a good idea. The project is called Apache Camel not Apache Fighterjet for a reason :-)
If this is kind of a wish list and to add a bit of a user´s perspective: I have to deal with obscure data formats on a daily basis. Sometimes they are parseable with Beanio and the like but oftentimes they are not. Yes, one could roll his own, but I would really prefer not to. I would really love to have a universal parser (like the one that was included with Seebeyond/sun/oracle JCAPS/egate). I understand that smooks was there to solve this but to me it looks dead. But the discussion of this aspect should go to the users-list. I will start a separate thread there. Cheers, Thomas. PS: Ok, the reason for the name may have more to do with a certain habit of a certain guy. -----Ursprüngliche Nachricht----- Von: Raul Kripalani [mailto:ra...@apache.org] Gesendet: Donnerstag, 24. März 2016 22:40 An: dev@camel.apache.org Betreff: Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0 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-1 > 8-and-towards-3-0-tp5779549p5779641.html > Sent from the Camel Development mailing list archive at Nabble.com. >
