- 08 10月, 2013 1 次提交
-
-
由 Brian Clozel 提交于
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
-
- 07 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 05 10月, 2013 4 次提交
-
-
由 Juergen Hoeller 提交于
Comprehensive update to the framework's TimeZone handling, including a new TimeZoneAwareLocaleContext and a LocaleContextResolver for Spring MVC 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
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 03 10月, 2013 7 次提交
-
-
由 Juergen Hoeller 提交于
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
-
由 Juergen Hoeller 提交于
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10950
-
由 Brian Clozel 提交于
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
-
由 Brian Clozel 提交于
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
-
由 Andy Wilkinson 提交于
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.
-
由 Andy Wilkinson 提交于
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.
-
- 02 10月, 2013 3 次提交
-
-
由 Andy Wilkinson 提交于
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.
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
- 01 10月, 2013 7 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10893
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10923
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10930
-
由 Rossen Stoyanchev 提交于
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.
-
由 Andy Wilkinson 提交于
- Polish javadoc for CONNECTED_USER_HEADER - Improve method ordering
-
由 Andy Wilkinson 提交于
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.
-
由 Andy Wilkinson 提交于
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.
-
- 30 9月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10854
-
- 28 9月, 2013 7 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10933, SPR-10310
-
由 Rossen Stoyanchev 提交于
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.
-
由 Rossen Stoyanchev 提交于
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.
-
由 Rossen Stoyanchev 提交于
-
由 Jeremy Grelle 提交于
-
由 Phillip Webb 提交于
Fix ASM AnnotationAttributesReadingVisitor to correctly deal with subclasses enums. Issue: SPR-10914
-
- 27 9月, 2013 9 次提交
-
-
由 Rossen Stoyanchev 提交于
* mikesir87-ws-glassfish4-support: Added websocket upgrade support for GlassFish 4.0
-
由 Michael Irwin 提交于
Commit 2397b210 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
-
由 Rossen Stoyanchev 提交于
-
由 Phillip Webb 提交于
-
由 Rossen Stoyanchev 提交于
* broker-relay: Polish Improve handling of missed heartbeats Upgrade to Reactor 1.0.0.M3 Add heart-beat support to STOMP broker relay Remove CONNECT-related message buffer from STOMP relay Add StompCodec
-
由 Rossen Stoyanchev 提交于
-
由 Andy Wilkinson 提交于
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.
-
由 Andy Wilkinson 提交于
-
由 Andy Wilkinson 提交于
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.
-