The WebSocketMessageBroker config now allows wrapping the
SubProtocolWebSocketHandler to enable advanced use cases that may
require access to the underlying WebSocketSession.
Issue: SPR-12314
This change adds a new XhrTransport for the SockJs client
implementation. This transport is based on `UndertowClient`,
Undertow's HTTP client.
Note that this transport can be customized with an OptionMap that is
used by the Xnio worker backing the I/O communications (see
http://xnio.jboss.org).
Implementation tested with undertow 1.0.36, 1.1.0.RC3, 1.2.0.Beta1.
Issue: SPR-12008
This change adds a "Vary: Origin" HTTP response header for /info and
/iframe SockJS endpoints.
This is preventing proxies and browsers from caching a response and
reusing it for an invalid Origin.
Reference: https://groups.google.com/forum/#!topic/sockjs/svsLWRorSis
Issue: SPR-12310
This commit adds support for direct Jackson mix-in annotations registration in
Jackson2ObjectMapperFactoryBean and Jackson2ObjectMapperBuilder.
Issue: SPR-12144
Prior to this commit, the getter methods in MockServletContext threw an
UnsupportedOperationException when trying to retrieve Servlet and
Filter registrations.
This commit improves the behavior of these methods by returning null
when a single registration is requested and an empty map when all
registrations are requested. This is now in line with the Javadoc for
ServletContext. Note, however, that the corresponding setter methods
still throw UnsupportedOperationExceptions which is suitable behavior
for a mock.
Issue: SPR-12290
The ternary expression node was failing to generate the
necessary unboxing bytecode when the condition part
of the expression returned a boxed Boolean rather than
a primitive boolean.
Also fixed here is an IllegalAccessError that was
seen in the same expression due to generating a
CHECKCAST bytecode for a private type.
Issue: SPR-12271
Prior to this commit, the ResolvableType static cache was holding a lot
of duplicates for simple types. We are using too much metadata to compute
the key when the class has no generic information. so setFoo(String foo)
and setBar(String bar) would result in two entries in the cache because
the TypeProvider is different. On a very simple application 65% of the
entries in the cache were duplicate.
When the type is a Class with no generic information, the ResolvableType
instance is a simple wrapper around it so we might just as well not cache
it at all as the cost of finding it back from the cache is higher than
creating that simple wrapper.
This commit adds an explicit check; if the type is a simple Class we just
return a "resolved" ResolvableType instance for it. On a few test cases,
this reduces the size of the cache by 85%
Issue: SPR-12275
Rossen Stoyanchev
Brian Clozel
Sebastien Deleuze
Tadaya Tsuyukubo
Juergen Hoeller
Oleg Lomaka
Sam Brannen
Stephane Nicoll
unpush
Andy Clement
Janning Vygen
Spring Buildmaster