The main `build.gradle` file contains now only the common build
infrastructure; all module-specific build configurations have
been moved to their own build file.
Issue: SPR-15885
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
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
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
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
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
String with version 5 the name of Java Platform, Enterprise Edition
changed from J2EE to Java EE. However a lot of the documentation still
uses the term J2EE.
This commit includes the following changes:
* replace J2EE with Java EE where appropriate
This is not a blind search and replace. The following occurrences
remain unchanged:
* references to old J2EE releases, most notably 1.3 and 1.4.
* references to "Expert One-On-One J2EE Design and Development"
* references to "Core J2EE patterns"
* XML namespaces
* package names
Issue: SPR-14811
See gh-1206
This commit adds a test runtime dependency on log4j 2 for every project
and migrates all log4j.properties files to log4j2-test.xml files.
Issue: SPR-14431
This commit fixes MessagingMessageConverter to no longer expose the lazy
message resolution algorithm. This restores proper behaviour for
converters used outside of that context.
Instead, such arrangement is now private to
AbstractAdaptableMessageListener (as it should).
Issue: SPR-14389
The test failure was caused by the previous commit. The Message
resolver now supports payload conversion so it can raise a
MessageConversionException, not MethodArgumentTypeMismatchException.
Support of @JsonView on @JmsListener annotated method that uses the
jackson converter. Also update MappingJackson2MessageConverter to offer
a public API to set the JSON view to use to serialize a payload.
Issue: SPR-13237
Previously, any `javax.jms.Message` was converted eagerly to the Message
abstraction. This leads to unnecessary conversion if the Payload is not
requested by the underlying method (i.e. if the `javax.jms.Message` is
injected directly).
This commit returns a `Message` implementation that holds the
`javax.jms.Message` and lazily resolve the payload or the headers on
demand (that is the first time they are requested).
Issue: SPR-13777
This commit migrates all remaining tests from JUnit 3 to JUnit 4, with
the exception of Spring's legacy JUnit 3.8 based testing framework that
is still in use in the spring-orm module.
Issue: SPR-13514
Previously, a method could only declare one Jms endpoint so if several
destinations share the exact same business logic, you'd still need one
separate method declaration per destination.
We now make sure that JmsListener is a repeatable annotation, introducing
JmsListeners for pre Java8 use cases.
Issue: SPR-13147
Add JmsResponse that can be used as return type of any JMS listener
method to indicate not only the response but also the actual destination
to which the reply should be sent.
Issue: SPR-13133
If a custom MessageConverter is set, it is not used for replies defined
via the Message abstraction. This commit harmonizes the behaviour of the
`MessagingMessageConverter` so that the conversion of the payload can
be converted for both incoming and outgoing messages.
Issue: SPR-12912
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
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
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
The auto startup flag can now be set on a JmsListenerContainerFactory to
control if the created container should be started automatically when the
application context starts.
Issue: SPR-12824
Previously, adding `@EnableAsync` on a blank application would lead to an
info message stating that `ProxyAsyncConfiguration` is not eligible for
getting processed by all BeanPostProcessors. Concretely, this is ok as
such internal configuration is not meant to be a target of such post
processing.
Revisit the condition for non infrastructure bean only. Add the
infrastructure role to a set of internal configuration, including the
`ProxyAsyncConfiguration`.
Issue: SPR-12761
Support the creation and registration of message listener containers in
a lazy manner, that is after the container initialization has completed.
Such support brought an interesting brainstorming of the thread safety
if JmsListenerEndpointRegistrar and JmsListenerEndpointRegistry so those
have also been revisited as part of this commit.
Issue: SPR-12774
Reduce logging level when no target annotation is found a on bean. For
consistency, update ScheduledAnnotationBeanPostProcessor and
JmsListenerAnnotationBeanPostProcessor that define the same log
statement.
Issue: SPR-12574
JmsInvokerClientInterceptor defines a receiveTimeout field but does not
handle such timeout. This commit adds an additional callback that throws
an RemoteTimeoutException instead.
Sub-classes can override the onReceiveTimeout to throw a different
exception or return a fallback RemoteInvocationResult.
Issue: SPR-12731
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
With this commit, Jackson builder is now used in spring-websocket
to create the ObjectMapper instance.
It is not possible to use the builder for spring-messaging
and spring-jms since these modules don't have a dependency on
spring-web, thus they now just customize the same features:
- MapperFeature#DEFAULT_VIEW_INCLUSION is disabled
- DeserializationFeature#FAIL_ON_UNKNOWN_PROPERTIES is disabled
Issue: SPR-12293
Commit 6a04831 introduced a regression that lead to burst recovery
attempts when the broker is up but the listener is failing for some
reason (the most obvious one being that the destination does not
exist).
Since the sleep period between recovery attempts strategy is more
complex, we can't just sleep for a period of time. But we can create
an execution and apply it once which should work just fine for most
use cases.
Issue: SPR-12183
This commit allows to use place holder definitions for JmsListener
attributes, effectively allowing to externalize those settings from
the code.
Issue: SPR-12134
This commit also turns MessagingException into a NestedRuntimeException subclass which delivers a root message that has the cause message appended to it. That's a common expectation with the use of Spring exceptions since all of our exception hierarchies have historically been designed that way.
Issue: SPR-12064
Issue: SPR-12038
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