- 02 5月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
The fromUri method of UriComponentsBuilder used uri.getXxx() methods, which decode the URI parts causing URI parsing issues. The same method now uses uri.getRawXxx(). Issue: SPR-9317
-
- 01 5月, 2012 2 次提交
-
-
由 Chris Beams 提交于
* SPR-9176: Fix scoped-proxy memory leak w/ @resource injection
-
由 Dridi Boukelmoune 提交于
Prior to this change, request-scoped components having @Resource-injected dependencies caused a memory leak in DefaultListableBeanFactory#dependenciesForBeanMap. Consider the following example: @Component @Scope(value="request", proxyMode=ScopedProxyMode.TARGET_CLASS) public class MyComponent { @resource private HttpServletRequest request; // ... } The bean name for "MyComponent" will end up being 'scopedTarget.myComponent', which will become a key in the #dependenciesForBeanMap structure. On the first request, the injected HttpServletRequest bean will be a proxy and will internally have a bean name of the form "$Proxy10@1a3a2a52". This name will be added to the Set value associated with the 'scopedTarget.myComponent' entry in #dependenciesForBeanMap. On the second request, the process will repeat, but the injected HttpServletRequest will be a different proxy instance, thus having a different identity hex string, e.g. "$Proxy10@5eba06ff". This name will also be added to the Set value associated with the 'scopedTarget.myComponent' entry in #dependenciesForBeanMap, and this is the source of the leak: a new entry is added to the set on each request but should be added only once. This commit fixes the leak by introducing caching to CommonAnnotationBeanPostProcessor#ResourceElement similar to that already present in AutowiredAnnotationBeanPostProcessor#AutowiredFieldElement and #AutowiredMethodElement. Essentially, each ResourceElement instance now tracks whether it has been created, caches the ultimate value to be injected and returns it eagerly if necessary. Besides solving the memory leak, this has the side effect of avoiding unnecessary proxy creation. This fix also explains clearly why injection into request-scoped components using @Autowired never suffered this memory leak: because the correct caching was already in place. Because @resource is considerably less-frequently used than @Autowired, and given that this particular injection arrangement is relatively infrequent, it becomes understandable how this bug has been present without being reported since the introduction of @resource support in Spring 2.5: developers were unlikely to encounter it in the first place; and if they did, the leak was minor enough (adding strings to a Set), that it could potentially go unnoticed indefinitely depending on request volumes and available memory. Issue: SPR-9176
-
- 30 4月, 2012 6 次提交
-
-
由 Chris Beams 提交于
* SPR-8308: Convert SpEL plus operands using reg'd converters
-
由 Ivo Smid 提交于
Prior to this commit, SpEL's OpPlus ('+' operator) would convert its left and right operands to String directly via #toString calls. This change ensures that operand values are delegated to any registered converters, allowing for customization of the stringified output. Note that the OpPlus constructor now throws IllegalArgumentException if zero operands are supplied. Issue: SPR-8308
-
由 Chris Beams 提交于
* SPR-9113: Fix javadoc warnings
-
由 Stevo Slavic 提交于
Before this change there were numerous javadoc warnings being reported while building Spring framework API. This commit resolves most of the javadoc warnings, reducing the total number from 265 to 103. Issue: SPR-9113
-
由 Chris Beams 提交于
* SPR-9097: Fix encoding issues in javadoc
-
由 Stevo Slavic 提交于
Before this change javadoc in two classes had non-UTF-8 encoded characters. This caused building Spring API to fail in Java 1.7. Commit fixes this by replacing wrongly encoded characters with their UTF-8 equivalents. Issue: SPR-9097
-
- 27 4月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
When a controller returns a DeferredResult, the underlying async request will eventually time out. Until now the default behavior was to send a 503 (SERVICE_UNAVAILABLE). However, this is not desirable in all cases. For example if waiting on an event, a timeout simply means there is no new information to send. To handle those cases a DeferredResult now accespts a timeout result Object in its constructor. If the timeout occurs before the DeferredResult is set, the timeout result provided to the constructor is used instead. Issue: SPR-8617
-
- 24 4月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
* Clarify semantics and behavior of AsyncWebRequest methods in most cases making a best effort and not raising an exception if async processing has completed for example due to a timeout. The startAsync() method is still protected with various checks and will raise ISE under a number of conditions. * Return 503 (service unavailable) when requests time out. * Logging improvements. Issue: SPR-8517
-
- 21 4月, 2012 1 次提交
-
-
由 Chris Beams 提交于
- Fixes deprecation warnings associated with recent upgrade to Gradle 1.0-rc1
-
- 19 4月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-8517
-
由 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
-
- 17 4月, 2012 3 次提交
-
-
由 Chris Beams 提交于
Previously depending on 1.5.10 in certain locations, which caused NoClassDefFoundErrors in EhCacheCacheTests and other tests due to mismatches between slf4j -api and -log4j12 versions. With the exception of one transitive dependency via Hibernate 3.3.1.GA, all slf4j dependencies are now pegged at 1.6.1 (and all tests pass).
-
由 Chris Beams 提交于
* rstoyanchev/slf4j-dependency: Fix transitive dependency issue with slf4j-api
-
由 Rossen Stoyanchev 提交于
Before this change, IDE settings generated via import-into-eclipse.sh created a classpath dependency on slf4j-api version 1.6.1 and slf4j-log4j12 version 1.5.10. As a result running tests inside the IDE resulted in a NoSuchMethodException. build.gradle sets the variable slf4jLog4jVersion to '1.5.10'. However, the hibernate-validator dependency in spring-context pulls in slf4j-api version 1.6.1. The change ensures the version specified in the build script variable is used consistently. Whether it should be 1.5.10 or 1.6.1 is a separate concern.
-
- 16 4月, 2012 1 次提交
-
-
由 Chris Beams 提交于
-
- 15 4月, 2012 1 次提交
-
-
由 Chris Beams 提交于
- Spring remains compatible against AJ version 1.6.8, but is now compiling and testing against 1.6.12 - Encountered what appears to be an AJ bug introduced in 1.6.10: an assertion in org.aspectj.weaver.UnresolvedType causes a false negative failure when encountering org.springframework.io.Resource arrays, e.g. "[org.springframework.io.Resource@xxx". This problem has been reported to the AJ team and in the meantime, the recommended workaround is to disable assertions either completely, or at least selectively with -disableassertions:org.aspectj.weaver.UnresolvedType Issue: SPR-7989, SPR-9272
-
- 14 4月, 2012 2 次提交
-
-
由 Chris Beams 提交于
- Fix deprecation warnings about dynamic properties; favor use of "extra properties extensions" per [1] - Certain such deprecations are still issued due to violations within the docbook-reference plugin. These will be fixed in an upcoming revision of the plugin, at which point spring-framework will upgrade to depend on it and these warnings will be eliminated [1] http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html Issue: SPR-9327
-
由 Chris Beams 提交于
Issue: SPR-9321
-
- 07 4月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
The new @mvc support classes select a HandlerMethodArgumentResolver and a HandlerMethodReturnValueHandler statically, i.e. based on the signature of the method, which means that a controller method can't declare a more general return type like Object but actually return a more specific one, e.g. String vs RedirectView, and expect the right handler to be used. The fix ensures that a HandlerMethodReturnValueHandler is selected based on the actual return value type, which is something that was supported with the old @mvc support classes. One consequence of the change is the selected HandlerMethodReturnValueHandler can no longer be cached but that matches the behavior of the old @mvc support classes. Issues: SPR-9218
-
由 Rossen Stoyanchev 提交于
Moved a null check inside a protected method to give protected method a chance to override what happens in that case. Issues: SPR-9193
-
- 03 4月, 2012 5 次提交
-
-
由 Rossen Stoyanchev 提交于
Previously 'Content-Disposition' was passed to Part.getHeader(String). However the Javadoc for that method specifies the header should be case insensitive. Note that the JavaDoc in tomcat-servlet-api doesn't mention this. It can only be found in the official api JavaDoc: http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/ Issue: SPR-9149
-
由 Rossen Stoyanchev 提交于
Invalid Content-Type or Accept header values previously resulted in the IllegalArgumentException getting propagated. After this change such errors are detected and generally treated as a "no match", which may for example result in a 406 in the case of the Accept header. Issue: SPR-9148
-
由 Rossen Stoyanchev 提交于
Issues: SPR-9138
-
由 Rossen Stoyanchev 提交于
A custom RequestCondition which can be provided by overriding methods in RequestMappingHandlerMapping worked only for conditions that match and did not return null (as it should have) for conditions that don't match. Issues: SPR-9134
-
由 Rossen Stoyanchev 提交于
Issues: SPR-7970
-
- 27 3月, 2012 2 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-9260
-
由 Chris Beams 提交于
Copy spring-*-3.1.xsd => spring-*-3.2.xsd; this commit introduces no substantive changes, but rather prepares for them by creating a clean baseline. All internal references to 3.1 schemas (e.g. spring-tool) have also been updated.
-
- 20 3月, 2012 1 次提交
-
-
由 Arjen Poutsma 提交于
JibxUnmarshallerTests contained UTF-8 characters; this commit changes those to the \uXXX notation, as all Java source files should be in Latin-1.
-
- 15 3月, 2012 2 次提交
-
-
由 Chris Beams 提交于
* SPR-7865: Use configured encoding during JiBX unmarshalling
-
由 Stevo Slavic 提交于
Before this change JibxMarshaller did not use the configured encoding when unmarshalling XML. This caused issues when content being unmarshalled was not encoded using the default encoding. This commit fixes the issue by passing configured encoding to JiBX so it gets used when unmarshalling instead of the default encoding. Issue: SPR-7865
-
- 09 3月, 2012 3 次提交
-
-
由 Chris Beams 提交于
-
由 Chris Beams 提交于
Use the preferred SessionFactoryImplementor#getDialect call as opposed to the previous Dialect#getDialect approach which required explicitly setting the 'hibernate.dialect' property. Issue: SPR-7396
-
由 Chris Beams 提交于
With thanks to @abdull for pull request #55
-
- 08 3月, 2012 1 次提交
-
-
由 Chris Beams 提交于
This change fixes a mistake made during an earlier sync with the 3.1.x branch in which the new QueryTimeoutException class was accidentally placed in spring-transaction instead of spring-tx. Issue: SPR-7680
-
- 05 3月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Stevo Slavic 提交于
Before this change if FreeMarker Spring form macro was bound to a path which contains square brackets, those brackets would also appear in id of generated tag, making the id invalid. As of this fix all FreeMarker Spring form macros generate tag with id that does not contain square brackets. Issue: SPR-8732
-
- 03 3月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-