- 22 6月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Introduced ContentNeogtiationStrategy for resolving the requested media types from an incoming request. The available implementations are based on path extension, request parameter, 'Accept' header, and a fixed default content type. The logic for these implementations is based on equivalent options, previously available only in the ContentNegotiatingViewResolver. Also in this commit is ContentNegotiationManager, the central class to use when configuring content negotiation options. It accepts one or more ContentNeogtiationStrategy instances and delegates to them. The ContentNeogiationManager can now be used to configure the following classes: - RequestMappingHandlerMappingm - RequestMappingHandlerAdapter - ExceptionHandlerExceptionResolver - ContentNegotiatingViewResolver Issue: SPR-8410, SPR-8417, SPR-8418,SPR-8416, SPR-8419,SPR-7722
-
- 21 6月, 2012 1 次提交
-
-
由 Chris Beams 提交于
PropertySourcesPropertyResolver#containsProperty now calls #containsProperty on each underlying PropertySource instead of calling #getProperty and checking for null. Issue: SPR-9529
-
- 20 6月, 2012 6 次提交
-
-
由 Sam Brannen 提交于
The reference manual currently documents the wrong file name for the default data SQL script used by EmbeddedDatabaseBuilder. In addition, the testing chapter of the reference manual does not link to the testing section of the JDBC chapter. - Updated the "Testing data access logic with an embedded database" section of the reference manual appropriately. - Added a new paragraph to the "JDBC Testing Support" section of the testing chapter which cross references the "Testing data access logic with an embedded database" section. Issue: SPR-9467
-
由 Sam Brannen 提交于
Issue: SPR-9493
-
由 Sam Brannen 提交于
-
由 Chris Beams 提交于
Commit aa415d7c introduced JacksonObjectMapperFactoryBean and associated tests, but with Windows (CRLF) line endings instead of the conventional Unix (LF) line endings. This commit converts these files to LF endings using the handy `dos2unix` utility. Issue: SPR-9125
-
由 Sam Brannen 提交于
* SPR-9493: Infer return type of parametrized factory methods
-
由 Sam Brannen 提交于
Currently, if a factory method is parameterized and the corresponding variable types are declared on the method itself instead of on the enclosing class or interface, Spring always predicts the return type to be Object, even if the return type can be explicitly inferred from the method signature and supplied arguments (which are available in the bean definition). This commit introduces a new resolveParameterizedReturnType() method in GenericTypeResolver that attempts to infer the concrete type for the generic return type of a given parameterized method, falling back to the standard return type if necessary. Furthermore, AbstractAutowireCapableBeanFactory now delegates to resolveParameterizedReturnType() when predicting the return type for factory methods. resolveParameterizedReturnType() is capable of inferring the concrete type for return type T for method signatures similar to the following. Such methods may potentially be static. Also, the formal argument list for such methods is not limited to a single argument. - public <T> T foo(Class<T> clazz) - public <T> T foo(Object obj, Class<T> clazz) - public <V, T> T foo(V obj, Class<T> clazz) - public <T> T foo(T obj) Issue: SPR-9493
-
- 19 6月, 2012 6 次提交
-
-
由 Chris Beams 提交于
The readme is heavy on links and hard to read in source form when using typical inline Markdown links. The following changes have been made to increase readability. - Wrap lines at 80 characters - Use 'implicit link name' shortcut syntax as described at [1] - Add link to 'spring-mvc' Stack Overflow tag as well - Add link to new 'lifecycle of an issue' wiki doc [1]: http://daringfireball.net/projects/markdown/syntax
-
由 Chris Beams 提交于
Some Spring Framework users and teams cannot use transitive dependency management tools like Maven, Gradle and Ivy. For them, a `distZip` task has been added to allow for creating a Spring Framework distribution from source that includes all optional and required runtime dependencies for all modules of the framework. This 'dist-with-deps' zip is not published to the SpringSource repository nor to the SpringSource community download page. It is strictly an optional task introduced as a convenience to the users mentioned above. Detailed instructions for building this zip locally have been added to the wiki and the README has been updated with a link to that new doc. Issue: SPR-6575
-
由 Sam Brannen 提交于
Fixed outdated Javadoc regarding support for 'annotated classes' in the TestContext Framework.
-
由 Chris Beams 提交于
Issue: SPR-5022
-
由 Rossen Stoyanchev 提交于
* SPR-9125: BeanFactory for configuring a Jackson ObjectMapper
-
由 Dmitry Katsubo 提交于
The BeanFactory makes it easier to configure a customized Jackson ObjectMapper (for example enable/disable certain features). This bean factory is usually used with MappingJacksonHttpMessageConverter or MappingJacksonJsonView. See JavaDoc for examples. Issue: SPR-9125
-
- 18 6月, 2012 3 次提交
-
-
由 Rossen Stoyanchev 提交于
* DavidBiesack-master: Minor fix in Javadoc for RequestMapping
-
由 David J. Biesack 提交于
Issue: SPR-9483
-
由 Rossen Stoyanchev 提交于
Issue: SPR-9513
-
- 15 6月, 2012 2 次提交
-
-
由 Chris Beams 提交于
* rstoyanchev/SPR-4984: Add splitIndex Javadoc option to the root project
-
由 Rossen Stoyanchev 提交于
Splits the very large index page with all classes into individual pages organized by first letter. Issue: SPR-4984
-
- 14 6月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
* SPR-8917: Allow parsing of media types with single-quotes
-
由 Maxim Valyanskiy 提交于
Previously MediaType could only parse double-quoted parameters without raising an IllegalArgumentException. Now parameters can also be single-quoted. Issue: SPR-8917
-
- 13 6月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
HttpStatus cannot be created with an unknown status code. If a server returns a status code that's not in the HttpStatus enum values, an IllegalArgumentException is raised. Rather than allowing it to propagate as such, this change ensures the actual exception raised is a RestClientException. Issue: SPR-9406
-
由 Chris Beams 提交于
A recent commit made aopalliance optional for spring-aop, while continuing to require it for spring-tx. On review, this is probably overly aggressive, and for convenience aopalliance should remain required for spring-aop. There are use cases for which aopalliance is indeed optional, but core functionality such as <aop:scoped-proxy> should never result in a ClassNotFoundException. This commit returns the aopalliance dependency for spring-aop to required status, and also explicitly notes the same dependency in other modules that compile directly against aopalliance types. Issue: SPR-9501
-
- 12 6月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-9494
-
- 10 6月, 2012 2 次提交
-
-
由 Sam Brannen 提交于
The junit:junit Maven artifact includes a bundled version of hamcrest core. For projects that depend on later versions of hamcrest this causes significant issues in terms of dependency management. The spring-test module now depends on junit:junit-dep, thus allowing developers to better manage their test dependencies on a more fine grained level. Also tidied up dependency issues regarding hamcrest-core and hamcrest-all across the build. Issue: SPR-6966
-
由 Sam Brannen 提交于
This commit introduces a test suite (Spr8849Tests) that demonstrates the claims made in SPR-8849. Specifically, if <jdbc:embedded-database id="xyz" /> is used to create an embedded HSQL database in an XML configuration file and that configuration file is imported in different sets of configuration files that are used to load ApplicationContexts for different integration tests, the embedded database will be initialized multiple times using any nested <jdbc:script /> elements. If such a script is used to create a table, for example, subsequent attempts to initialize the database named "xyz" will fail since an embedded database named "xyz" already exists in the JVM. As a work-around, this test suite uses a SpEL expression to generate a random string for each embedded database instance: id="#{T(java.util.UUID).randomUUID().toString()}" See the Javadoc in Spr8849Tests for further information. Issue: SPR-8849
-
- 04 6月, 2012 2 次提交
-
-
由 Chris Beams 提交于
* SPR-9457: Use transactional connection during db population
-
由 Oliver Gierke 提交于
Previously, DatabasePopulatorUtils#execute looked up a Connection from the given DataSource directly which resulted in the executed statements not being executed against a transactional connection (if any) which in turn resulted in the statements executed by the populator potentially not being rolled back. Now DataSourceUtils#getConnection is used to transparently take part in any active transaction and #releaseConnection is used to ensure the connection is closed if appropriate. Issue: SPR-9457
-
- 01 6月, 2012 5 次提交
-
-
由 Chris Beams 提交于
* SPR-7938: Include response headers in RestTemplate exceptions Polish web.client exceptions and related classes
-
由 Scott Andrews 提交于
Default HTTP error exceptions thrown from RestTemplate now include response headers in addition to the response body. In particular, this enables inspection of the Content-Type header allowing manual deserialization of the response body without guessing as to the content type. - introduce HttpStatusCodeException#getResponseHeaders - add constructor with headers param for HttpStatusCodeException, HttpClientErrorException and HttpServerErrorException - preserve exsisting constructor signatures - mark HttpHeaders as Serializable - generate new serialVersionUID where needed Issue: SPR-7938
-
由 Chris Beams 提交于
The following style updates have been made in anticipation of substantive changes in subsequent commits: - organize imports - correct whitespace errors (leading spaces in code, tabs in Javadoc) - wrap Javadoc at 90 chars; make imperative ("Return" vs. "Returns") - use conventional constructor argument wrapping A serialVersionUID has also been added to RestClientException and its ResourceAccessException subclass for consistency with the rest of that same exception hierarchy. Issue: SPR-7938
-
由 Chris Beams 提交于
- Explicitly specify compile-time dependencies on other spring-* modules, primarily for accuracy in pom generation and ensuring minimal dependencies for users of spring-aspects. - Remove use of p: namespace from annotation-cache-aspectj.xml to avoid parser-related test failures under Eclipse (likely due to classpath differences between Gradle and Eclipse).
-
由 Chris Beams 提交于
The spring-intstrument jar should have a 'Premain-Class:' manifest entry in order to enable use as a Java agent. This entry was present in versions 3.1.1 and earlier, but due to build infrastructure changes starting in 3.2.x this entry was missed. It is now back in place as expected. Issue: SPR-9458
-
- 29 5月, 2012 2 次提交
-
-
由 Chris Beams 提交于
-
由 Spring Buildmaster 提交于
-
- 28 5月, 2012 5 次提交
-
-
由 Chris Beams 提交于
Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
-
由 Chris Beams 提交于
Avoid Eclipse classpath conflicts between test versions of @Qualified and @Autowired living in spring-core and actual versions living in spring-beans.
-
由 Chris Beams 提交于
-
由 Sam Brannen 提交于
In Spring 3.1 the spring-test Maven artifact did not have a required dependency on spring-core, but there is practically no part of spring-test that can be used without spring-core. Most test utilities that are intended to be stand-alone utilities in fact use utility classes from spring-core (e.g., ReflectionTestUtils). Even some of the web mocks/stubs use spring-core (e.g., DelegatingServletInputStream). In addition, the current Gradle build configuration for the spring-test module is very simplistic -- in that it does not explicitly list any optional dependencies such as the Servlet and Portlet APIs -- and it defines a 'compile' dependency on spring-webmvc-portlet. The resulting Maven dependencies in the generated POM are therefore not what a typical consumer of the spring-test artifact would reasonably expect. To address these issues, the Gradle build configuration for the spring-test module now explicitly defines the following 'compile' dependencies: - spring-core - spring-webmvc, optional - spring-webmvc-portlet, optional - junit, optional - testng, optional - servlet-api, optional - jsp-api, optional - portlet-api, optional - activation, provided The only required dependency is now spring-core; all other dependencies are 'optional'. Issue: SPR-8861
-
由 Juergen Hoeller 提交于
-