Believe it or not, I started writing a RabbitMQ component on Friday as well ;) Small world.
In defense of Michael, I can totally understand why one would want to build a component based on the RabbitMQ client libraries. I've been trying to work with the Qpid libraries talking to a RabbitMQ broker for a while now, and I agree that the two don't necessarily mesh given both the volatility of the AMQP spec as well as the different audiences each tries to reach. Qpid is fantastic for those who were working with JMS and need to migrate to AMQP - it offers very familiar semantics and makes moving from JMS a fairly straightforward affair. The actual AMQP Camel component is only a very few lines, mostly bridging the connection pool back to the JMS component. However, if you want to have more granular control over exchange types, routing keys and queuing discovery then there is a need to do away with the JMS archtypes and move directly into AMQP. As far as other RabbitMQ components there are currently three versions on GitHub: the original LShift prototype, an updated version from abashev and a version from me that hit a brick wall on. Both LShift and abashev's use an abandoned EIP library that has not even been ported to the most recent AMQP client spec, so its use is fairly limited. I attempted to remove this dependency but had significant issues in trying to keep with the code style and design patterns while not re-writing everything. There is enough coding re-work to be done in either branch that it makes more sense just to begin from scratch. The component I started on Friday is almost in working order, but I need to ensure I can release it with an Apache License v2. Once I get that figured out I'll make sure to circulate it for wider use and editing. Should the release under the Apache License be cleared, if Camel would like the component I'd be happy to donate it to the project or just toss it into GitHub for others to use. I've spoken to a few other local engineers who have been working with the AMQP component and they have expressed interest in helping out as well. As far as your original question, usually the best way to set properties specified as part of the parameter string is to call setProperties(endpoint, parameters) from inside your Endpoint class. That will automagically set properties on the target bean based on the properties from your URL string. Michael Prieß wrote: > > Hello, > > the reason why I started to build a own component for RabbitMQ is that > the actual AMQP Component is based on the QPID Client Library which is not > full > compatible with RabbitMQ. > > For my component I used auto discovery and it all works well without > parameters. > > But with the param I got this error that I described above. > > Regards, > > Michael > > 2011/11/6 Jason Whaley <jasonwhaley@>: >> Also, if you are intent on writing a custom component, did you either add >> your component to the CamelContext with the name of "rabbitmq" or use the >> auto discovery by creating a file in META-INF as described here >> http://camel.apache.org/writing-components.html ? >> >> On Sun, Nov 6, 2011 at 4:07 PM, Michael Prieß < >> mailinglisteprm@> wrote: >> >>> Hello, >>> >>> I started today to write a new Camel Component for RabbitMQ to Consume >>> and Produce Messages from the message broker. >>> >>> At the moment I not understand how to put in parameters. >>> >>> When I try to append the parameter hostname >>> >>> Exam: >>> .to("rabbitmq:foo?hostname=localhost") >>> >>> I get the following exception: >>> Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to >>> resolve endpoint: rabbitmq://foo?hostname=localhost due to: null >>> >>> Cheers, >>> >>> Michael >>> >> > -- View this message in context: http://camel.465427.n5.nabble.com/Writing-own-Camel-Components-tp4969523p4970048.html Sent from the Camel - Users mailing list archive at Nabble.com.
