Prior to this commit, one could only match exact URLs in redirectedUrl
and forwardedUrl ResultMatchers. When creating a resource with
a REST service, URLs often contain the id the new resource,
like "/resource/12".
This commit updates those ResultMatchers to support both
exact matches and AntPath matches, using new methods.
The former URL then can be tested against "/resource/*" in MVC tests.
Issue: SPR-10789
This change reverts recent commits made to expand the resource handling
mechanism in Spring MVC. The changes will move into a separate branch
and likely into a separate project allowing it to mature and evolve
without being tied to the main framework release schedule.
Issue: SPR-10933, SPR-10310
Prior to this commit, one could not test for the absence of
a specific HTTP header in a response.
Using header("X-Custom-Header", Matchers.nullValue()) would not
work because it tests for an empty value of an existing header.
This commit adds a doesNotExist method on the
HeaderResultMatcher.
Issue: SPR-10771
Prior to this commit, one could call the setStatus method on
this Mock object and update the response's status,
even though the sendError method had already been called.
According to the HttpServletResponse Javadoc, sendError() methods
commit the response; so the response can't be written after that.
This commit fixes MockHttpServletResponse's behavior; setStatus
methods do not update the status once the response has been
committed.
Issue: SPR-10414
A few noteworthy minor changes: LocaleContext.getLocale() may return null in special cases (not by default), which our own accessing classes are able to handle now. If there is a non-null TimeZone user setting, we're exposing it to all collaborating libraries, in particular to JSTL, Velocity and JasperReports. Our JSR-310 and Joda-Time support falls back to checking the general LocaleContext TimeZone now, adapting it to their time zone types, if no more specific setting has been provided. Our DefaultConversionService has TimeZone<->ZoneId converters registered. And finally, we're using a custom parseTimeZoneString method now that doesn't accept the TimeZone.getTimeZone(String) GMT fallback for an invalid time zone id anymore.
Issue: SPR-1528
At the same time, dropped GlassFish 1/2 support from GlassFishLoadTimeWeaver and redesigned it to be as analogous to TomcatLoadTimeWeaver as possible.
Issue: SPR-10788
Prior to this commit, one couldn't configure Jackson's ObjectMapper
with (De)SerializerModifiers or advanced configuration features
using XML configuration.
This commit updates the FactoryBean and adds a setModule method
that will register Modules with the ObjectMapper.
Note that this commit is only about XML configuration, since
this feature was already available with JavaConfig.
Issue: SPR-10429
Prior to this commit, Multipart databinding would only support
MultiPartFile databinding using commons-multipart.
Now the WebRequestDataBinder supports Part and List<Part>
databinding for Servlet 3.0 compliant containers.
Issue: SPR-10591
Previously, there was no generic concept of a message that represents
a heartbeat and the STOMP-specific code used a null STOMP command to
represent a heartbeat.
This commit introduces HEARTBEAT as a new SimpMessageType. The STOMP
support has been updated to create HEARTBEAT messages to represent
heartbeats, and to use the new message type as the mechanism by which
heartbeats are identified.
Prior to this commit, the intervals at which the broker relay's system
session would send heartbeats to the STOMP broker and expect to
receive heartbeats from the STOMP broker were hard-coded at 10
seconds.
This commit makes the intervals configurable, with 10 seconds being
the default value.
Previously, when the broker relay was shut down, the TCP client was
closed and the relay sessions were left to find out about the
shutdown as a result of their TCP connections being closed. This led
to problems where an attempt could be made to use a session that was,
in fact, in the process of being shut down.
This commit updates the broker relay to explicitly close each of its
relay sessions as part of its stop processing.
As part of the broker relay being shut down explicitly close each of
its relay sessions. It does so before closing the TCP client so that
the relay sessions know that they are disconnected before their TCP
connections are closed.
The broker relay's publishing of availability events has also been
improved. Prior to this commit, availability events were published
based on the availability of any relay session. For example, this
meant that a successfully established client relay session would
result in an event being published indicating that the broker's
available even if the system relay session was yet to be established.
This commit updates the relay so that broker availability events are
only published by the system relay session. This allows application
code the use these events as an accurate indication of the
availability of the broker. Clients that are interested in the
broker's availability can find out through the use of heart beats or
through the receipt of an ERROR frame in response to an attempt to
communnicate with the broker.
Fix error in te code that handles the result of sending a heartbeat
Fix error in processing DISCONNECTED frames that closed the TCP
connection before the message was sent.
Previously, handling of a STOMP CONNECT message and sending of a
CONNECTED response was performed by StompProtocolHandler if it was
backed by SimpleBrokerMessageHandler, or left up to the real message
broker if it was backed by StompBrokerRelayMessageHandler. This
wasn't ideal as it should be StompProtocolHandler's job to simply map
messages to and from the STOMP protocol, not to do part of the
broker's job and respond directly to CONNECT.
This commit introduces a new message type, CONNECT_ACK. When it
receives a CONNECT message, SimpleBrokerMessageHandler will now
respond with a CONNECT_ACK message that StompProtocolHandler can map
into a STOMP CONNECTED message. The CONNECT_ACK message contains the
CONNECT message as a header so that StompProtocolHandler has access to
its accept-version header.
StompProtocolHandler has been simplified so that a CONNECT message
is always passed to the output channel, irrespective of whether it's
backed by a simple broker or a real broker. The handleConnect flag,
and the code that would set it correctly depending on the app's
configuration, has been removed.
Prior to this commit, a failure to send a heartbeat was ignored and a
failure to forward a message to the broker would result in an error
frame being sent but nothing more.
Following this commit, a failure to send a heartbeat to the broker
is treated as a TCP client failure. Furthermore, if the system relay
session fails to forward a message to the broker an exception is
thrown. Typically, the system relay session will be forwarding
messages on behalf of local application code, rather than a remote
WebSocket client. Throwing an exception allows the application code
to be notified of the problem directly, rather than via a broker
availability event.
Renamed ResourceUrlMapper to ResourceUrlGenerator and refactored it
to be configured with Resource-serving HandlerMappings as opposed to
having them detected in the ApplicationContext through the
BeanPostProcessor contact.
Renamed and polished ResourceUrlEncodingFilter to ResourceUrlFilter
and added tests.
This change splits out resource transformation out from the
ResourceResolverChain so that chain is focused entirely on resource
resolution (as its name suggests). The invocation of transformers
is left as a separate step, it uses a different (recursive)
algorithm in any case and iterates over a different set of objects.
Also ResourceResolverChain is now limited strictly to methods that
a ResourceResolver should be able to use to delegate to remaining
resolvers.
Furthermore, ResourceResolverChain now maintains an internal index
of the "current" resolver so that resolvers don't have to pass the
chain when invoking it much like a (Servlet API) FilterChain works.
If the last resolver calls the chain again, a null value is returned.
Commit 2397b21096 changed websocket
support to use GlassFish 4.0.1 nightlies, but broke support for 4.0. In
GlassFish 4.0.1, the package that TyrusEndpoint is located in changed.
This commit provides an abstract handler that does all required
GlassFish setup, but delegates to version specific upgrade handlers to
create the final TyrusEndpoint.
GlassFish 4.0 handler uses reflection to create its endpoint to prevent
dependency issues of depending on different versions of
tyrus-websocket-core and tyrus-container-servlet
Previously, when a broker heartbeat was mnissed, the STOMP connection
would be left in a semi-disconnected state such that, for example, the
read and write idle callbacks would still be active, even though
the underlying TCP connection had been nulled out.
As part of disconnecting the STOMP connection, this commit closes the
underlying TCP connection when a heartbeat's missed which cancels the
read and write idle callbacks. It also now copes with the underlying
TCP connection being null when sending a heartbeat to the broker. This
protects again a race condition between the write idle callback being
fired, such that a heartbeat needs to be sent, and the connection
being nulled out due to it being closed.
Previously, the STOMP broker relay did not support heart-beats. It sent
0,0 in the heart-beats header for its own CONNECTED message, and set the
heart-beats header to 0,0 when it was forwarding a CONNECTED from from a
client to the broker.
The broker relay now supports heart-beats for the system relay session.
It will send heart-beats at the send interval that's been negotiated
with the broker and will also expect to receive heart-beats at the
receive interval that's been negotiated with the broker. The receive
interval is multiplied by a factor of three to satisfy the STOMP spec's
suggestion of lenience and ActiveMQ 5.8.0's heart-beat behaviour (see
AMQ-4710).
The broker relay also supports heart-beats between clients and the
broker. For any given client's relay session, any heart-beats received
from the client are forwarded on to the broker and any heart-beats
received from the broker are sent back to the client.
Internally, a heart-beat is represented as a Message with a byte array
payload containing the single byte of new line ('\n') character and
'empty' headers. SubscriptionMethodReturnValueHandler has been updated
to default the message type to SimpMessageType.MESSAGE. This eases
the distinction between a heartbeat and a message that's been created
from a return value from application code.
Before this change, the StompProtocolHandler always responded to
clients with a CONNECTED frame, while the STOMP broker relay
independantly forwarded the client CONNECT to the broker and waited
for the CONNECTED frame back. That meant the relay had to buffer
client messages until it received the CONNECTED response from
the message broker.
This change ensures that clients wait for a CONNECTED frame from
the message broker. The broker relay forwards the CONNECT frame to
the broker. The broker responds with a CONNECTED frame, which the
relay then forwards to the client. As a result, a (well-written)
client will not send any messages to the relay until the connection
to the broker is fully established.
The StompProtcolHandler can now be configured whether to send CONNECTED
frame back. By default that is off. So when using the simple broker,
the StompProtocolHandler can still respond with CONNECTED frames.
The relay's handling of a connection being dropped has also been
improved. When a connection for a client relay session is dropped
an ERROR frame will be sent back to the client. If a connection is
closed as part of a DISCONNECT frame being sent, no ERROR frame
is sent back to the client. When the connection for the system relay
session is dropped, an event is published indicating that the broker
is unavailable. Reactor's TcpClient will then attempt to re-restablish
the connection.
Rossen Stoyanchev
Brian Clozel
Juergen Hoeller
Andy Wilkinson
Jeremy Grelle
Phillip Webb
Michael Irwin