Hi I dont think its a good idea to create a 2nd component. Instead improve/fix make the the existing component better.
We love contributions http://camel.apache.org/contributing.html On Fri, Nov 15, 2013 at 7:49 PM, Christian Posta <christian.po...@gmail.com> wrote: > not sure what the rest of the community thinks... but i would say at > least put it on github :) > would it be possible to just auto-default to the "opinionated" config > settings in the current component? > > On Fri, Nov 15, 2013 at 10:28 AM, Alex Sherwin <alex.sher...@gmail.com> wrote: >> I found the RabbitMQ support shipped in 2.12 to be pretty sub-par for a >> bunch of reasons: >> >> - host/port must be configured in the URI >> - vhost must be configured in the URI >> - autoDelete cannot be specified separately for the Exchange/Queue >> - durability cannot be specified separately for the Exchange/Queue >> - poor options around ack/nack (autoAck is the only exposed option, >> which seems dangerous to me and >> CAMEL-6767<https://issues.apache.org/jira/browse/CAMEL-6767> only >> addresses a current bug... which isn't taking exchange.isFailed() into >> account) >> - no options around redelivery on exchange failures >> >> I would think that all of those should probably be addressed in the current >> RabbitMQComponent/RabbitMQEndpoint/RabbitMQConsumer classes >> >> However, to make using RabbitMQ as a viable option for a classic queue use >> case, which is all I wanted to do, even fixing all of the above still left >> the URI's feeling quite heavy.. mainly because the standard AMQP practices >> around routing keys and anonymous queue bindings make perfect sense, >> unless, you just want durable non-autodeleted named queues >> >> So I created RabbitMQQueueComponent/Consumer/Endpoint implementations which >> make it behave like one may expect for regular queueing. You configure the >> one-time settings (host/port, defaults for durability etc on the component) >> and then you can just create routes like this: >> >> from(rabbitmq:exchange?queue=from queue).to(rabbitmq:exchange?queue=to >> queue) >> >> The component/endpoints/consumers take care of the creating matching >> routing keys, creating appropriate exchanges/queues/bindings using the AMQP >> client etc to make it act like classic queues >> >> I implemented everything mentioned above, but it would be competing with >> the existing RabbitMQ components (because, rightfully so, the default >> implementation would want to have AMQP semantics) >> >> So my question is just... is there any interest to have contributed >> components for RabbitMQ that have very opinionated default AMQP settings >> and behaviors >> >> -- >> Alexander Sherwin > > > > -- > Christian Posta > http://www.christianposta.com/blog > twitter: @christianposta -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
