- 08 3月, 2019 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 20 1月, 2018 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 13 1月, 2018 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 19 7月, 2017 1 次提交
-
-
由 Sebastien Deleuze 提交于
This commit ensure that null-safety is consistent between getters and setters in order to be able to provide beans with properties with a common type when type safety is taken in account like with Kotlin. It also add a few missing property level @Nullable annotations. Issue: SPR-15792
-
- 30 6月, 2017 1 次提交
-
-
由 Juergen Hoeller 提交于
This commits extends nullability declarations to the field level, formalizing the interaction between methods and their underlying fields and therefore avoiding any nullability mismatch. Issue: SPR-15720
-
- 07 6月, 2017 1 次提交
-
-
由 Juergen Hoeller 提交于
Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments. Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit. Issue: SPR-15540
-
- 27 5月, 2017 1 次提交
-
-
由 Sebastien Deleuze 提交于
This commit introduces 2 new @Nullable and @NonNullApi annotations that leverage JSR 305 (dormant but available via Findbugs jsr305 dependency and already used by libraries like OkHttp) meta-annotations to specify explicitly null-safety of Spring Framework parameters and return values. In order to avoid adding too much annotations, the default is set at package level with @NonNullApi and @Nullable annotations are added when needed at parameter or return value level. These annotations are intended to be used on Spring Framework itself but also by other Spring projects. @Nullable annotations have been introduced based on Javadoc and search of patterns like "return null;". It is expected that nullability of Spring Framework API will be polished with complementary commits. In practice, this will make the whole Spring Framework API null-safe for Kotlin projects (when KT-10942 will be fixed) since Kotlin will be able to leverage these annotations to know if a parameter or a return value is nullable or not. But this is also useful for Java developers as well since IntelliJ IDEA, for example, also understands these annotations to generate warnings when unsafe nullable usages are detected. Issue: SPR-15540
-
- 18 4月, 2017 1 次提交
-
-
由 Stephane Nicoll 提交于
This commit introduces QosSettings that gather the Qualify of Service settings one can use when sending a message. Such object can now be associated to any JMS endpoint that allows to send a reply as part of the processing of an incoming message. Issue: SPR-15408
-
- 23 1月, 2017 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 24 3月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13440
-
- 18 2月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13625
-
- 16 1月, 2016 1 次提交
-
-
由 Stephane Nicoll 提交于
Issue: SPR-13578
-
- 09 12月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13774
-
- 09 11月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13576
-
- 20 4月, 2015 1 次提交
-
-
由 Stephane Nicoll 提交于
Previously, a custom `DestinationResolver` was not made available to the underlying `MessageListener`: if a reply needs to be sent, the default `DestinationResolver` was used. This commit ensures that if a custom `DestinationResolver` has been set, it is also configured accordingly for replies. Issue: SPR-12927
-
- 17 4月, 2015 1 次提交
-
-
由 Stephane Nicoll 提交于
The attributes of @JmsListener allows to specify the reference to a key in the Environment but @SendTo did not. This commit fixes this inconsistency so that response destinations are now also externally configurable. Issue: SPR-12899
-
- 16 4月, 2015 1 次提交
-
-
由 Stephane Nicoll 提交于
Previously, the "pubSubDomain" drove the resolution of both the destination of the listener and the default response destination. A new "replyPubSubDomain" attribute has been added on the base listener and can be used to listen on a topic and reply to a queue (or vice versa). The attribute is exposed via the "response-destination-type" XML attribute on the listener container element. It is also available on the JmsListenerContainerFactory for use with the @JmsListener infrastructure. Issue: SPR-12911
-
- 08 12月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
Previously, the default reply destination could not be discovered if the @JmsListener annotation was placed on a bean that is eligible for proxying as the proxy method is used internally and does not reveal an annotation placed on the implementation. This commit makes sure to resolve the most specific method when searching that annotation. Issue: SPR-12513
-
- 21 10月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 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
-
- 30 7月, 2014 1 次提交
-
-
由 Stephane Nicoll 提交于
-
- 18 7月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-9882 Issue: SPR-11969
-
- 24 4月, 2014 2 次提交
-
-
由 Stephane Nicoll 提交于
This commit removes the queue attribute of the JmsListener annotation as this information should be provided by the container factory and not by each individual listener endpoints. There was a side effect that an annotation value cannot be null, which was forcing the container to be a queue-based container by default. Issue: SPR-9882
-
由 Stephane Nicoll 提交于
This commit replaces the "responseDestination" attribute on the JmsListener annotation by a support of the standard SendTo annotation. Issue: SPR-11707
-
- 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
-