- 21 11月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10005
-
由 Rossen Stoyanchev 提交于
Tiles 3 has modified packages and classes as well as additional dependencies, notably "tiles-request-api", which is a request/response abstraction independent of Servlet and JSP APIs. In order to have both Tiles 2 and Tiles 3 integrations, the source for the Tiles 3 integration is in a separate project spring-webmvc-tiles3. The build process merges the compiled Tiles 3 integration classes into the spring-webmvc module so in effect it contains both the Tiles 2 and the Tiles 3 integrations. This change originated as a pull request at spring-framework-issues: https://github.com/SpringSource/spring-framework-issues/pull/30 And was additionally updated: https://github.com/SpringSource/spring-framework-issues/commit/1f64be4aa59b4766f9cc5fc6ead621d29f92a0d6 Issue: SPR-8825
-
- 09 11月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 04 11月, 2012 2 次提交
-
-
由 Chris Beams 提交于
-
由 Phillip Webb 提交于
-
- 03 11月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This is more specific exception raised instead of RestClientException when the raw HTTP status code received from the server is not one of the HttpStatus enum values. Issue: SPR-9406
-
- 01 11月, 2012 3 次提交
-
-
由 Sam Brannen 提交于
-
由 Phillip Webb 提交于
-
由 Sam Brannen 提交于
Added missing JIRA issue IDs.
-
- 31 10月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 29 10月, 2012 1 次提交
-
-
由 Phillip Webb 提交于
-
- 28 10月, 2012 2 次提交
-
-
由 Sam Brannen 提交于
Issue: SPR-9593
-
由 Sam Brannen 提交于
Issue: SPR-9724
-
- 27 10月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
The MVC namespace and the MVC Java config now allow configuring CallableProcessingInterceptor and DeferredResultProcessingInterceptor instances. Issue: SPR-9914
-
- 23 10月, 2012 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Before this change View implementations set the response content type to the fixed value they were configured with. This change makes it possible to configure a View implementation with a more general media type, e.g. "application/*+xml", and then set the response type to the more specific requested media type, e.g. "application/vnd.example-v1+xml". Issue: SPR-9807.
-
由 Rossen Stoyanchev 提交于
-
- 17 10月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
-
- 11 10月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 10 10月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 25 9月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 11 9月, 2012 1 次提交
-
-
由 Chris Beams 提交于
-
- 05 9月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 10 8月, 2012 5 次提交
-
-
由 Chris Beams 提交于
CGLIB 3 has been released in order to depend on ASM 4, which Spring now depends on internally (see previous commit). This commit eliminates spring-beans' optional dependency on cglib-nodep v2.2 and instead repackages net.sf.cglib => org.springframework.cglib much in the same way we have historically done with ASM. This change is beneficial to users in several ways: - Eliminates the need to manually add CGLIB to the application classpath; especially important for the growing number of @Configuration class users. Java-based configuration functionality, along with proxy-target-class and method injection features now work 'out of the box' in Spring 3.2. - Eliminates the possibility of conflicts with other libraries that may dependend on differing versions of CGLIB, e.g. Hibernate 3.3.1.ga and its dependency on CGLIB 2.1.3 would easily cause a conflict if the application were depending on CGLIB 3 for Spring-related purposes. - Picks up CGLIB 3's changes to support ASM 4, meaning that CGLIB is that much less likely to work well in a Java 7 environment due to ASM 4's support for transforming classes with invokedynamic bytecode instructions. On CGLIB and ASM: CGLIB's own dependency on ASM is also transformed along the way to depend on Spring's repackaged org.springframework.asm, primarily to eliminate unnecessary duplication of ASM classfiles in spring-core and in the process save around 100K in the final spring-core JAR file size. It is coincidental that spring-core and CGLIB currently depend on the exact same version of ASM (4.0), but it is also unlikely to change any time soon. If this change does occur and versions of ASM drift, then the size optimization mentioned above will have to be abandoned. This would have no compatibility impact, however, so this is a reasonable solution now and for the forseeable future. On a mysterious NoClassDefFoundError: During the upgrade to CGLIB 3.0, Spring test cases began failing due to NoClassDefFoundErrors being thrown from CGLIB's DebuggingClassWriter regarding its use of asm-util's TraceClassVisitor type. previous versions of cglib-nodep, particularly 2.2, did not cause this behavior, even though cglib-nodep has never actually repackaged and bundled asm-util classes. The reason for these NoClassDefFoundErrors occurring now is still not fully understood, but appears to be due to subtle JVM bytecode preverification rules. The hypothesis is that due to minor changes in DebuggingClassWriter such as additional casts, access to instance variables declared in the superclass, and indeed a change in the superclass hierarchy, preverification may be kicking in on the toByteArray method body, at which point the reference to the missing TraceClassVisitor type is noticed and the NCDFE is thrown. For this reason, a dummy implementation of TraceClassVisitor has been added to spring-core in the org.springframework.asm.util package. This class simply ensures that Spring's own tests never result in the NCDFE described above, and more importantly that Spring's users never encounter the same. Other changes include: - rename package-private Cglib2AopProxy => CglibAopProxy - eliminate all 'cglibAvailable' checks, warnings and errors - eliminate all 'CGLIB2' language in favor of 'CGLIB' - eliminate all mention in reference and java docs of needing to add cglib(-nodep) to one's application classpath Issue: SPR-9669
-
由 Chris Beams 提交于
ASM 4.0 is generally compatibile with Java 7 classfiles, particularly including 'invokedynamic' instructions. This is important when considering that Spring's component-scanning support is internally ASM-based and it is increasingly likely that component classes having invokedynamic instructions may be encountered and read by ASM. This upgrade, then, is primarily preventive in nature. Changes include: - upgrade from ASM 2.2.3 to ASM 4.0 - adapt to ASM API changes as necessary throughout spring-core, resulting in no impact to the public Spring API. - remove dedicated spring-asm module - use new :spring-core:asmRepackJar task to repackage org.objectweb.asm => org.springframework.asm as per usual and write repackaged classes directly into spring-core jar The choice to eliminate the spring-asm module altogether and instead inline the repackaged classes directly into spring-core is first to eliminate an otherwise unnecessary second jar. spring-core has a non-optional dependency on spring-asm meaning it is always on the application classpath. This change simplifies that situation by consoliding two jars into one. The second reason for this choice is in anticipation of upgrading CGLIB to version 3 and inlining it into spring-core as well. See subsequent commit for details. Issue: SPR-9669
-
由 Andy Clement 提交于
Attempting to register a custom MethodFilter with a StandardEvaluationContext after invoking setMethodResolvers() with a custom list of MethodResolver instances results in a NullPointerException. Based on the current documentation in StandardEvaluationContext it is unclear what the expected behavior should be, but either the implementation is broken, or the use case is unsupported. In either case, allowing a NullPointerException to be thrown is inappropriate. This commit documents the fact that the SpEL MethodFilter is intended to be used with the ReflectiveMethodResolver. Furthermore, StandardEvaluationContext.registerMethodFilter() now throws an IllegalStateException if the user attempts to set a filter after having registered a custom set of resolvers. Issue: SPR-9621
-
由 Andy Clement 提交于
The Spring Expression Language currently supports nested single quotes within expressions but not nested double quotes. The SpEL tokenizer has been modified to support nested double quotes in the same way it supports single quotes. A sequence of two double quotes will now be replaced by one when evaluated. Extra error handling has also been added to report when invalid escaping is encountered, since SpEL does not support escaping with backslash. Issue: SPR-9620
-
由 Andy Clement 提交于
SpEL typically supports logical operators for boolean expressions consistent with standard Java language syntax. However, the operators for logical AND and logical OR are currently only supported as textual operators. In other words, SpEL does not support the use of && and || as logical operators. The SpEL tokenizer has now been modified to recognize && and || as symbolic boolean operators. The parser has been modified to allow the use of either the textual or symbolic operators. Issue: SPR-9614
-
- 06 8月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
- renamed resolveParameterizedReturnType() to resolveReturnTypeForGenericMethod() - fleshed out Javadoc for resolveReturnType() and resolveReturnTypeForGenericMethod() regarding declaration of formal type variables - improved wording in log statements and naming of local variables within resolveReturnTypeForGenericMethod() Issue: SPR-9493
-
- 04 8月, 2012 5 次提交
-
-
由 Andy Clement 提交于
Prior to this commit null literals in SpEL expressions had to be specified as "null" (i.e., all lowercase). With this commit null literals in SpEL expressions are interpreted in a case-insensitive manner, analogous to the current support for boolean literals. Issue: SPR-9613
-
由 Andy Clement 提交于
When attempting to parse an Integer literal expression such as 42.toString(), SpEL currently throws a SpelParseException with a message similar to: "EL1041E:(pos 3): After parsing a valid expression, there is still more data in the expression: 'toString'". The problem here is that '3.' is currently considered a valid number (including the dot). However, SpEL succeeds at parsing an equivalent expression for a Double literal such as 3.14.isInfinite(). To address this issue, the SpEL Tokenizer no longer consumes the trailing '.' on an integer as part of the integer. So '3.foo()' will now be parsed as '3' '.' 'foo()' and not '3.' 'foo()' -- which was what prevented parsing of method invocations on integers. To keep the change simple, the parser will no longer handle real numbers of the form '3.e4'. From now on they must include the extra 0 (i.e., '3.0e4'). Issue: SPR-9612
-
由 Sam Brannen 提交于
Recently new utility methods were added to JdbcTestUtils, and a JdbcTemplate was introduced in abstract transactional base classes in the TestContext framework. This presents an easy opportunity to make these new utility methods available as convenience methods in the base test classes. This commit introduces new countRowsInTableWhere() and dropTables() convenience methods in the abstract transactional base classes in the TestContext framework. These new methods internally delegate to methods of the same names in JdbcTestUtils. Issue: SPR-9665
-
由 Sam Brannen 提交于
Since Spring 2.5, the abstract transactional base classes in the TestContext framework have defined and delegated to a protected SimpleJdbcTemplate instance variable; however, SimpleJdbcTemplate has deprecated since Spring 3.1. Consequently, subclasses of AbstractTransactionalJUnit4SpringContextTests and AbstractTransactionalTestNGSpringContextTests that use this instance variable suffer from seemingly unnecessary deprecation warnings. This commit addresses this issue by introducing a protected JdbcTemplate instance variable in abstract transactional base classes to replace the use of the existing SimpleJdbcTemplate. Furthermore, the existing simpleJdbcTemplate instance variable has been deprecated, and utility methods in the affected base classes now delegate to JdbcTestUtils instead of the now deprecated SimpleJdbcTestUtils. Issue: SPR-8990
-
由 Ian Brandt 提交于
Several static utility methods in SimpleJdbcTestUtils accept an instance of SimpleJdbcTemplate as an argument; however, SimpleJdbcTemplate has been deprecated since Spring 3.1 in favor of simply using JdbcTemplate which now also supports Java 5 language constructs such as var-args. Consequently, use of such methods from SimpleJdbcTestUtils results in deprecation warnings without an equivalent API to migrate to. This commit addresses this issue by migrating all existing methods in SimpleJdbcTestUtils to JdbcTestUtils. The migrated methods now accept an instance of JdbcTemplate as an argument, thereby avoiding the deprecation warnings but maintaining semantic compatibility with the functionality previous available in SimpleJdbcTestUtils. In addition, this commit also introduces two new methods: - countRowsInTableWhere(): counts the rows in a given table, using a provided `WHERE` clause - dropTables(): drops the tables with the specified names Issue: SPR-9235
-
- 29 7月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
For legacy reasons, a MockEnvironment implementation already exists in multiple places within Spring's test suite; however, it is not available to the general public. This commit promotes MockEnvironment to a first-class citizen in the spring-test module, alongside the existing MockPropertySource. In addition, the following house cleaning has been performed. - deleted MockPropertySource from the spring-expression module - deleted MockEnvironment from the "spring" integration testing module - updated test copies of MockPropertySource and MockEnvironment - documented MockEnvironment and MockPropertySource in the testing chapter of the reference manual Issue: SPR-9492
-
- 28 7月, 2012 2 次提交
-
-
由 Sam Brannen 提交于
Currently the Spring TestContext Framework looks up a PlatformTransactionManager bean named "transactionManager". The exact name of the bean can be overridden via @TransactionConfiguration or @Transactional; however, the bean will always be looked up 'by name'. The TransactionManagementConfigurer interface that was introduced in Spring 3.1 provides a programmatic approach to specifying the PlatformTransactionManager bean to be used for annotation-driven transaction management, and that bean is not required to be named "transactionManager". However, as of Spring 3.1.2, using the TransactionManagementConfigurer on a @Configuration class has no effect on how the TestContext framework looks up the transaction manager. Consequently, if an explicit name or qualifier has not been specified, the bean must be named "transactionManager" in order for a transactional integration test to work. This commit addresses this issue by refactoring the TransactionalTestExecutionListener so that it looks up and delegates to a single TransactionManagementConfigurer as part of the algorithm for determining the transaction manager. Issue: SPR-9604
-
由 Sam Brannen 提交于
TransactionalTestExecutionListener currently requires that the PlatformTransactionManager bean be named "transactionManager" by default. Otherwise, the bean name can only be overridden via the transactionManager attribute of @TransactionConfiguration or the value attribute of @Transactional. However, if there is only a single PlatformTransactionManager in the test's ApplicationContext, then the requirement to specify the exact name of that bean (or to name it exactly "transactionManager") is often superfluous. This commit addresses this issue by refactoring the TransactionalTestExecutionListener so that it is comparable to the algorithm for determining the transaction manager used in TransactionAspectSupport for "production" code. Specifically, the TTEL now uses the following algorithm to retrieve the transaction manager. - look up by type and qualifier from @Transactional - else, look up by type and explicit name from @TransactionConfiguration - else, look up single bean by type - else, look up by type and default name from @TransactionConfiguration Issue: SPR-9645
-
- 26 7月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
Currently the getNamedDispatcher(String) method of MockServletContext always returns null. This poses a problem in certain testing scenarios since one would always expect at least a default Servlet to be present. This is specifically important for web application tests that involve the DefaultServletHttpRequestHandler which attempts to forward to the default Servlet after retrieving it by name. Furthermore, there is no way to register a named RequestDispatcher with the MockServletContext. This commit addresses these issues by introducing the following in MockServletContext. - a new defaultServletName property for configuring the name of the default Servlet, which defaults to "default" - named RequestDispatchers can be registered and unregistered - a MockRequestDispatcher is registered for the "default" Servlet automatically in the constructor - when the defaultServletName property is set to a new value the the current default RequestDispatcher is unregistered and replaced with a MockRequestDispatcher for the new defaultServletName Issue: SPR-9587
-
- 21 7月, 2012 3 次提交
-
-
由 Rossen Stoyanchev 提交于
The MVC Java config and the MVC namespace now support options to configure content negotiation. By default both support checking path extensions first and the "Accept" header second. For path extensions .json, .xml, .atom, and .rss are recognized out of the box if the Jackson, JAXB2, or Rome libraries are available. The ServletContext and the Java Activation Framework may be used as fallback options for path extension lookups. Issue: SPR-8420
-
由 Rossen Stoyanchev 提交于
Add the ability provide exclude patterns for mapped interceptors in the MVC namespace and in the MVC Java config. Issue: SPR-6570
-
由 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
-