- 24 3月, 2014 1 次提交
-
-
由 Brian Clozel 提交于
Prior to this commit, the ShallowEtagHeaderFilter did not use the content length given by the content generator to set the ByteArrayOutputStream's buffer size. This can lead to performance issues for large content since the buffer grows as the content is being written. This commit adds a new ByteArrayOutputStream variant called ResizableByteArrayOutputStream. This implementation has public methods for modifying the internal buffer size and does not synchronize on buffer access. This commit also make use of this new variant in ShallowEtagHeaderFilter. Issue: SPR-8271
-
- 14 3月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 14 2月, 2014 1 次提交
-
-
由 Brian Clozel 提交于
Prior to this commit, all 2xx HTTP responses were eligible for ETag generation in ShallowEtagHeaderFilter. In some cases, this would use CPU resources for no reason since HTTP clients would not use ETags. This commit is an optimization and restricts ETags generation in cases where (all conditions must be met): - response has a 2xx status - request is a GET - response does not contain "no-store" in its "Cache-Control" header Issue: SPR-11110
-
- 12 2月, 2014 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-11413
-
- 29 12月, 2012 2 次提交
-
-
由 Phillip Webb 提交于
-
由 Chris Beams 提交于
Issue: SPR-10128
-
- 29 10月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
OncePerRequestFilter now allows sub-classes to choose whether they should ever get involved in processing an error dispatch. Issue: SPR-9895
-
由 Rossen Stoyanchev 提交于
Issue: SPR-9895
-
- 18 8月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-9433
-
- 04 8月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
As a result of the refactoring, the AsyncContext dispatch mechanism is used much more centrally. Effectively every asynchronously processed request involves one initial (container) thread, a second thread to produce the handler return value asynchronously, and a third thread as a result of a dispatch back to the container to resume processing of the asynchronous resuilt. Other updates include the addition of a MockAsyncContext and support of related request method in the test packages of spring-web and spring-webmvc. Also an upgrade of a Jetty test dependency required to make tests pass. Issue: SPR-9433
-
- 21 7月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
After this change each call stack level pushes and pops an async Callable to ensure the AsyncExecutionChain is in sync with the call stack. Before this change, a controller returning a "forward:" prefixed string caused the AsyncExecutionChain to contain a extra Callables that did not match the actual call stack. Issue: SPR-9611
-
- 19 4月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
From a programming model perspective, @RequestMapping methods now support two new return value types: * java.util.concurrent.Callable - used by Spring MVC to obtain the return value asynchronously in a separate thread managed transparently by Spring MVC on behalf of the application. * org.springframework.web.context.request.async.DeferredResult - used by the application to produce the return value asynchronously in a separate thread of its own choosing. The high-level idea is that whatever value a controller normally returns, it can now provide it asynchronously, through a Callable or through a DeferredResult, with all remaining processing -- @ResponseBody, view resolution, etc, working just the same but completed outside the main request thread. From an SPI perspective, there are several new types: * AsyncExecutionChain - the central class for managing async request processing through a sequence of Callable instances each representing work required to complete request processing asynchronously. * AsyncWebRequest - provides methods for starting, completing, and configuring async request processing. * StandardServletAsyncWebRequest - Servlet 3 based implementation. * AsyncExecutionChainRunnable - the Runnable used for async request execution. All spring-web and spring-webmvc Filter implementations have been updated to participate in async request execution. The open-session-in-view Filter and interceptors implementations in spring-orm will be updated in a separate pull request. Issue: SPR-8517
-
- 31 1月, 2012 1 次提交
-
-
由 Chris Beams 提交于
This renaming more intuitively expresses the relationship between subprojects and the JAR artifacts they produce. Tracking history across these renames is possible, but it requires use of the --follow flag to `git log`, for example $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history up until the renaming event, where $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history for all changes to the file, before and after the renaming. See http://chrisbeams.com/git-diff-across-renamed-directories
-
- 23 12月, 2010 1 次提交
-
-
由 Chris Beams 提交于
In accordance with recommendations at http://www.apache.org/licenses/LICENSE-2.0.html. A number of classes had strayed from this format, now all are the same.
-
- 21 12月, 2010 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 16 8月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 03 5月, 2010 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 27 1月, 2010 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 06 11月, 2009 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 29 7月, 2009 2 次提交
-
-
由 Arjen Poutsma 提交于
No commit message
-
由 Arjen Poutsma 提交于
-
- 15 6月, 2009 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 25 2月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 30 10月, 2008 1 次提交
-
-
由 Arjen Poutsma 提交于
-