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
