Andy Wilkinson opened AMQP-29 and commented

spring-amqp's pom declare's a compile-time dependency upon spring-test so I'm currently having to manually exclude it. spring-rabbit has the same problem

Affects: 1.0.0.M1

Mark Fisher opened AMQP-9 and commented

We should clarify in the javadoc for methods that accept "exchangeName" or "queueName" that those override the corresponding properties of the template itself. This is different terminology than we use in JmsTemplate, etc. where instead we refer to the default properties ("defaultDestination" or "defaultDestinationName"). This apparent break with consistency is justified however since the AMQP specification describes "default exchange" as the no-name exchange that always exist, and that is actually the default exchange property for our template.

No further details from AMQP-9

Mark Fisher opened AMQP-3 and commented

We should upgrade to the RabbitMQ client JAR version to 1.8.0. Also, we should be testing against the 1.8.0 version of the RabbitMQ server.

No further details from AMQP-3

Mark Fisher opened AMQP-22 and commented

Provide links to the AMQP Specification, the RabbitMQ "Getting Started" page, and the Spring AMQP Forum.

No further details from AMQP-22

Mark Fisher opened AMQP-14 and commented

This should cover AmqpTemplate's send and receive methods as well as the usage of SimpleMessageListenerContainer for asynchronous message reception. That should also include MessageListenerAdapter.

No further details from AMQP-14

Mark Fisher opened AMQP-45 and commented

This would be similar to Spring's AbstractRoutingDataSource and could handle cases such as thread-bound "virtualHost" values.

6 votes, 7 watchers

Andrey Paramonov opened AMQP-38 and commented

I send a message using RabbitMQ Java client - com.rabbitmq.client.Channel#basicPublish(String, String, BasicProperties, byte[]) - with null BasicProperties, which seems to be a valid case. I get NPE when I try to print the message within the MessageListener implementation:

java.lang.NullPointerException
	at org.springframework.amqp.core.Message.getBodyContentAsString(Message.java:70)
	at org.springframework.amqp.core.Message.toString(Message.java:56)
	at java.lang.String.valueOf(String.java:2826)
	at java.lang.StringBuilder.append(StringBuilder.java:115)
	at com.ndpar.spring.rabbitmq.MessageHandler.onMessage(MessageHandler.java:14)
	at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:316)
	at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:254)
	at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:230)
	at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.executeListener(AbstractMessageListenerContainer.java:199)
	at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.processMessage(SimpleMessageListenerContainer.java:229)
	at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:288)
	at java.lang.Thread.run(Thread.java:637)

Affects: 1.0.0.M1

Mark Pollack opened AMQP-21 and commented

Affects: 1.0.0.M1

Mark Fisher opened AMQP-2 and commented

For the milestone 1 release, the SingleConnectionFactory should be the default implementation of the ConnectionFactory interface.

Although we had originally planned on using the CachingConnectionFactory as the default, further work is necessary to provide a correct and robust implementation that caches Channels. There are many factors to consider in terms of 1) state that is maintained on a Channel corresponding to its use for acknowledgment of received messages, etc. and 2) volatility of the Connection itself due to certain Channel-related errors cascading to Connection-closing situations. We will explore these in more detail for future milestones.

No further details from AMQP-2

Mark Fisher opened AMQP-10 and commented

No further details from AMQP-10

Mark Fisher opened AMQP-16 and commented

This should be modeled after the similar support in the Spring "jms" namespace.

No further details from AMQP-16

Mark Fisher opened AMQP-40 and commented

For example, the properties should be a simple Map rather than depending on the 'BasicProperties' object in Rabbit's client library.

This will require copying when converting to/from the "real" messages, but the tradeoff is probably worth it.

No further details from AMQP-40

Mark Fisher opened AMQP-41 and commented

e.g. send(Message m)

This will be easier once we have the MessageBuilder (see #1605)

No further details from AMQP-41

Mark Fisher opened AMQP-13 and commented

For example, a with(routingKey) method will not be available when to(someFanoutExchange) is invoked.

No further details from AMQP-13

Mark Fisher opened AMQP-34 and commented

The current workaround is to provide a targetConnectionFactory that has already been fully configured with the virtual host and other connection parameters.

Affects: 1.0.0.M1

Issue Links:

• #1596 Support for virtual hosts in RabbitMQ.
  ("duplicates")

1 votes, 2 watchers

Mark Fisher opened AMQP-42 and commented

This will be used by MessageConverters, RabbitTemplate, etc.

We should follow this fallback logic:

1. explicit 'messageFactory' property has been set (e.g. on a RabbitTemplate)
2. lookup by bean name (or possibly a single 'primary' bean even if others)

For #2, RabbitTemplate (and other users) would need to be BeanFactoryAware.

We need to decide what "default" properties make sense (e.g. persistent?)

Internally it might use MessageBuilder (see #1605).

Issue Links:

• #1605 Provide a MessageBuilder with "fluent API" methods

Mark Fisher opened AMQP-15 and commented

This should cover SimpleMessageConverter, JsonMessageConverter, and MarshallingMessageConverter.

No further details from AMQP-15

Mark Fisher opened AMQP-26 and commented

No further details from AMQP-26

Magnus Johansson opened AMQP-31 and commented

It seems there is no support for choosing virtual hosts on the rabbitMQ-server. So if the default virtual ( / ) is not used it is not possible to use Spring's support for amqp and RabbitMQ.

Reference URL: http://forum.springsource.org/showthread.php?t=92686

Issue Links:

• #1600 enable configuration of the virtual host on SingleConnectionFactory
  ("is duplicated by")

1 votes, 1 watchers

Mark Fisher opened AMQP-20 and commented

No further details from AMQP-20

Mark Fisher opened AMQP-19 and commented

No further details from AMQP-19

Mark Fisher opened AMQP-5 and commented

This should define all Queue and Exchange operations (declare, delete, etc). as well as Bindings in as much as they can be portable across implementations

Sub-tasks:

• #1570 Add AmqpAdmin interface in spring-amqp-core interface with RabbitAdmin implementation in spring-rabbit

• #1571 Implement RabbitBrokerAdmin

Mark Pollack opened AMQP-23 and commented

Add to ExchangeType enumeration and BindingBuilder

Affects: 1.0.0.M1

Mark Fisher opened AMQP-25 and commented

This should pass directly through to the target rabbitConnectionFactory.

No further details from AMQP-25

Mark Fisher opened AMQP-24 and commented

We should set the hostname directly on the target ConnectionFactory rather than storing it in an instance variable (it is currently never being used!).

Also, we should replace the constructor that takes both targetConnectionFactory and hostname so that it only takes the targetConnectionFactory. That target should already have its hostname set anyways.

Finally, the getHostName() method can simply return the targetConnectionFactory.getHost() value.

No further details from AMQP-24

Mark Fisher opened AMQP-50 and commented

No further details from AMQP-50

Mark Fisher opened AMQP-48 and commented

No further details from AMQP-48

Mark Fisher opened AMQP-43 and commented

Consider transactions vs. non-transactional channels (keep separate since TX will always apply once started)

Consider the role of the Channel for async consumers (esp. on "rollback"... do we call basicRecover() or close()?)

No further details from AMQP-43

Chris Beams opened AMQP-35 and commented

e.g.: no ${version} placeholders

Issue Links:

• INT-1317 Ensure manifest files are well-formed

Mark Fisher opened AMQP-18 and commented

This should cover the ConnectionFactory interface, the SingleConnectionFactory implementation and future support for failover of connections.

No further details from AMQP-18

Chris Beams opened AMQP-32 and commented

See attached.

Affects: 1.0.0.M1

Attachments:

• warnings.txt (7.51 kB)

Mark Fisher opened AMQP-47 and commented

This might simply require a txCommit call immediately after publish.

No further details from AMQP-47

Mark Fisher opened AMQP-39 and commented

Issue Links:

• #1609 Define a MessageFactory for configuration of common "default" MessageProperties values

Chris Beams opened AMQP-36 and commented

Sub-tasks:

• #1603 Update release documentation

Mark Pollack opened AMQP-11 and commented

Affects: 1.0.0.M1

Referenced from: pull request #812

Mark Fisher opened AMQP-7 and commented

This belongs in the rabbit-admin module.

This issue is a sub-task of #1569

Mark Fisher opened AMQP-27 and commented

No further details from AMQP-27

Mark Fisher opened AMQP-12 and commented

The base @Configuration classes can define "queue()" and "exchange()" rather than "declareQueue()" and "declareExchange()". The declarations should happen in a callback upon startup so that in case of a fail-fast configuration error, the Exchanges and Queues will not be declared.

The AbstractRabbitConfiguration class can define an inner class (and return it as a bean) that implements ApplicationListener<ContextRefreshedEvent> then grab the Exchange and Queue beans from the ApplicationContext then declare them. The Queues must be declared before the bindings are created.

No further details from AMQP-12

Mark Fisher opened AMQP-6 and commented

This will require generic return types as opposed to the implementation specific DeclareOk objects.

For example, when declaring a Queue with an explicit name, we can have a void return type (else throw an Exception), and when declaring a Queue with a generated name, we should return a String (the generated name).

This issue is a sub-task of #1569

Mark Fisher opened AMQP-8 and commented

Would be nice to configure RabbitBrokerAdmin using Spring's ConnectionFactory interface. The vhost from Rabbit's connection factory needs to be extracted and passed into the various jinterface API calls.

for example in RabbitBrokerAdmin

public Map<String, Map<String, String>> getQueueInfo() {
// TODO: pass virtual host... currently hardcoded to default ("/").. need to parse off connection string.
return (Map<String, Map<String, String>>) erlangTemplate.executeAndConvertRpc("rabbit_amqqueue", "info_all", "/".getBytes());
}

No further details from AMQP-8

Mark Fisher opened AMQP-44 and commented

5 votes, 6 watchers

Mark Fisher opened AMQP-49 and commented

This should implement PlatformTransactionManager. We likely need an AbstractAmqpTransactionManager and subclasses such as RabbitTransactionManager.

No further details from AMQP-49

Mark Fisher opened AMQP-1 and commented

No further details from AMQP-1

Mark Fisher opened AMQP-17 and commented

This should cover classes in the org.springframework.amqp.core package such as Queue, Binding, Message, MessageProperties etc.

No further details from AMQP-17

Chris Beams opened AMQP-37 and commented

Affects: 1.0.0.M1

This issue is a sub-task of #1602

Mark Fisher opened AMQP-28 and commented

The packages for each group (Spring AMQP, Spring Rabbit, Spring Rabbit Admin, and Spring Erlang) should be configured in the root pom.xml.

Affects: 1.0.0.M1

Chris Beams opened AMQP-33 and commented

Please mark this for 1.0.M2 resolution and assign to me.

Affects: 1.0.0.M1

Mark Fisher opened AMQP-30 and commented

Affects: 1.0.0.M1

Issue Links:

• #1615 Move the declaration of queues, exchanges, and bindings into AmqpAdmin
  ("is superseded by")

1 votes, 1 watchers

Mark Fisher opened AMQP-46 and commented

This code is currently in the abstract @Configuration support class.

We should be able to follow the same approach in AmqpAdmin: it can implement SmartLifecycle with autoStartup set to true... and perhaps determined by a boolean flag (which should be 'true' by default), it will declare all Exchange, Queue, and Binding instances that it finds in the context.

This will only work for the case that all these components are being defined within the same virtual host (basically, they are declared on a Channel returned from a Connection returned from the AmqpAdmin ConnectionFactory, so that is the limitation). Using AmqpAdmin directly (and setting the boolean flag to false) is a perfectly valid option for those cases. We might want to explore some other ideas in the future (like nesting the resources within an outer tag that provides the connection-factory to use for that set).

Issue Links:

• #1595 Add a boolean flag to SimpleMessageListenerContainer for declaring queues upon initialization
  ("supersedes")

Mark Fisher opened AMQP-4 and commented

This should ideally be handled as a boolean flag on the components that declare Queues. For example, the AmqpTemplate could have a 'shouldCreateQueueIfNotAvailable' flag. Of course, we might come up with a better, more succinct name than that (suggestions?), and/or we might decide to be negative instead of positive, such as 'shouldFailIfQueueDoesNotExist'.

For naming purposes, we should probably compare to some other similar create-if-not-existing scenarios in Spring.

No further details from AMQP-4