- 21 10月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 01 9月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
This commit allows to use place holder definitions for JmsListener attributes, effectively allowing to externalize those settings from the code. Issue: SPR-12134
-
- 01 8月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
This commit moves JmsHandlerMethodFactory and its default implementation to the messaging abstraction. Working on a similar support for AMQP revealed that this factory has nothing that is JMS specific and is exactly identical in the case of AMQP. Issue: SPR-12053
-
- 24 4月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
Prior to this commit, the default JmsListenerContainerFactory to use must be explicitly set. Since having a single container factory is a fairly common use case, we look up the default one automatically using the bean name "jmsListenerContainerFactory". It is still possible to provide an explicit default but since it refers more to "the" container factory to use, the parameter has been renamed to "containerFactory" which is shorter and more explicit. The lookup strategy is lazy: if all endpoints are providing an explicit container factory and no container factory with the "jmsListenerContainerFactory" bean name exists, no exception will be thrown. Issue : SPR-11706
-
- 17 4月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
This commit adds the support of JMS annotated endpoint. Can be activated both by @EnableJms or <jms:annotation-driven/> and detects methods of managed beans annotated with @JmsListener, either directly or through a meta-annotation. Containers are created and managed under the cover by a registry at application startup time. Container creation is delegated to a JmsListenerContainerFactory that is identified by the containerFactory attribute of the JmsListener annotation. Containers can be retrieved from the registry using a custom id that can be specified directly on the annotation. A "factory-id" attribute is available on the container element of the XML namespace. When it is present, the configuration defined at the namespace level is used to build a JmsListenerContainerFactory that is exposed with the value of the "factory-id" attribute. This can be used as a smooth migration path for users having listener containers defined at the namespace level. It is also possible to migrate all listeners to annotated endpoints and yet keep the <jms:listener-container> or <jms:jca-listener-container> element to share the container configuration. The configuration can be fine-tuned by implementing the JmsListenerConfigurer interface which gives access to the registrar used to register endpoints. This includes a programmatic registration of endpoints in complement to the declarative approach. A default JmsListenerContainerFactory can also be specified to be used if no containerFactory has been set on the annotation. Annotated methods can have flexible method arguments that are similar to what @MessageMapping provides. In particular, jms listener endpoint methods can fully use the messaging abstraction, including convenient header accessors. It is also possible to inject the raw javax.jms.Message and the Session for more advanced use cases. The payload can be injected as long as the conversion service is able to convert it from the original type of the JMS payload. By default, a DefaultJmsHandlerMethodFactory is used but it can be configured further to support additional method arguments or to customize conversion and validation support. The return type of an annotated method can also be an instance of Spring's Message abstraction. Instead of just converting the payload, such response type allows to communicate standard and custom headers. The JmsHeaderMapper infrastructure from Spring integration has also been migrated to the Spring framework. SimpleJmsHeaderMapper is based on SI's DefaultJmsHeaderMapper. The simple implementation maps all JMS headers so that the generated Message abstraction has all the information stored in the protocol specific message. Issue: SPR-9882
-