I don't think we need to write a customer HTTP binding this time, writing a custom Data Format should be enough. If you have some special HTTP header need to deal with, you may consider to write that HTTP binding.
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Friday, May 24, 2013 at 1:03 AM, Raul Kripalani wrote: > Hi Frank, > > By no means do you need to write a custom component! Camel has a lot of > features to help you in processing and/or transforming the message. > > First of all, take a look at our Data Formats [1] and see any can help you > digest the message. Of special relevance in your case are Bindy, Flatpack, > BeanIO, etc. > > If none helps you, you need to think what "overcoming this mess" actually > means. Do you mean transforming the content into a POJO? Or into another > serialized format for which there are more processing options readily > available, e.g. XML, JSON? > > Your solution could be as simple as a Bean that transforms the message into > something higher-level, if this is just a one-off case in your integration > middleware platform (one service, one operation). If it's a recurring > scenario, you're seeking something reusable and pluggable: > > - If all your interactions are over HTTP, you can consider a custom HTTP > Binding for camel-jetty [2]. > - If you're targeting a variety of protocols, you want something more > higher-level, in which case you can create your own custom Data Format [3]. > > To sum up, with Camel you normally don't need to create custom components, > unless you're interfacing over/with a new protocol, technology or > communication channel for which a component doesn't already exist (somewhat > unlikely). > > Hope this helps, > > [1] http://camel.apache.org/data-format.html > [2] http://camel.apache.org/jetty.html#Jetty-CustomizingHttpBinding > [3] http://camel.apache.org/custom-dataformat.html > > *Raúl Kripalani* > Enterprise Architect, Open Source Integration specialist, Program > Manager | Apache > Camel Committer > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Thu, May 23, 2013 at 2:56 PM, Frank Ertl < > [email protected] (mailto:[email protected])> > wrote: > > > Hi everybody, > > > > we have to implement a route that listens on a defined http-port and > > receives a message with a very strange legacy format. Partly XML, partly > > TLV > > (tag-length-value). > > I wonder what would be the best option to overcome this mess. Writing a > > custom component that could work as a consumer endpoint (somehow using > > jetty, maybe by extending the jetty-component) or would it be better just > > to > > write a new TypeConverter and call convertToType after receiving the > > message > > via the jetty-component? > > What would you propose? > > > > Regards, > > Frank > > > > > > > > -- > > View this message in context: > > http://camel.465427.n5.nabble.com/Custom-component-for-weird-legacy-format-tp5733030.html > > Sent from the Camel - Users mailing list archive at Nabble.com > > (http://Nabble.com). >
