- 10 8月, 2012 2 次提交
-
-
由 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
-
由 Chris Beams 提交于
JarJar 1.3 now uses ASM 4 in order to be compatible with Java 7 'invokedynamic' instructions. This is not an immediate concern for the classes that we use JarJar to repackage and transform, but is a timely upgrade in anticipation of the subsequent commits in which we upgrade Spring's own dependency on ASM from 2.2.3 to 4.0 and Spring's dependency on CGLIB from 2.2 to 3.0 (which in turn depends on ASM 4.0). See https://code.google.com/p/jarjar/wiki/ChangeLog Issue: SPR-9669
-
- 08 8月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-9660
-
- 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 9 次提交
-
-
由 Sam Brannen 提交于
* SPR-9613: Support case-insensitive null literals in SpEL
-
由 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
-
由 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
-
由 Sam Brannen 提交于
* SPR-9612: Modify SpEL Tokenizer to support methods on numbers
-
由 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
-
由 Sam Brannen 提交于
* SPR-9235: Deprecate SimpleJdbcTestUtils in favor of JdbcTestUtils
-
由 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
-
- 03 8月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
-
- 29 7月, 2012 4 次提交
-
-
由 Sam Brannen 提交于
Introduce MockEnvironment in the spring-test module
-
由 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
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
- 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
-
- 27 7月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
-
- 26 7月, 2012 3 次提交
-
-
由 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
-
由 Rossen Stoyanchev 提交于
Usually this request attribute is set for all sub-classes of AbstractUrlHandlerMapping and therefore whenever AnnotationMethodHandlerAdapter is used. However, having a default value to fall back on in AnnotationMethodHandlerAdapter is still appropriate in general and also considering the Javadoc of HandlerMapping.INTROSPECT_TYPE_LEVEL_MAPPING. Issue: SPR-9629
-
由 Rossen Stoyanchev 提交于
Issue: SPR-9601
-
- 25 7月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
-
- 21 7月, 2012 5 次提交
-
-
由 Rossen Stoyanchev 提交于
The new FactoryBean facilitates the creation of a ContentNegotiationManager in XML configuration. Issue: SPR-8420
-
由 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 提交于
Issue: SPR-9611
-
由 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 7月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
-
- 18 7月, 2012 3 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-9500
-
由 Rossen Stoyanchev 提交于
Issue: SPR-9579
-
由 Rossen Stoyanchev 提交于
-
- 17 7月, 2012 2 次提交
-
-
由 Sam Brannen 提交于
* SPR-9594: Fix minor issue in MockHttpServletRequest
-
由 Rob Winch 提交于
Previously MockHttpServletRequest#sendRedirect did not set the HTTP status or the Location header. This does not conform to the HttpServletRequest interface. MockHttpServletRequest will now: - Set the HTTP status to 302 on sendRedirect - Set the Location header on sendRedirect - Ensure the Location header and getRedirectedUrl are kept in synch Issue: SPR-9594
-
- 11 7月, 2012 3 次提交
-
-
由 Rossen Stoyanchev 提交于
Update section on exception handling in Spring MVC chapter to include more guidance on exception handling when implementing a REST API. Issue: SPR-9290
-
由 Rossen Stoyanchev 提交于
Previously DefaultHandlerExceptionResolver did not handle BindException but after this change it does. A BindException is raised when an @ModelAttribute annotated argument is not followed by a BindingResult argument. Hence this is unlikely to affect browser rendering. For programmatic clients however this change ensures an unhandled BindException is at least turned into a 400 error. Issue: SPR-9310
-
由 Rossen Stoyanchev 提交于
The Atom/RSS message converters are now registered ahead of the Jackson and the JAXB2 message converters by default. Since the Atom and RSS converters convert to and from very specific object types Feed and Channel respectively, that shouldn't introduce any regressions and will work more intuitively when the requested media type is "*/*". Issue: SPR-9054
-
- 10 7月, 2012 1 次提交
-
-
由 Chris Beams 提交于
* SPR-9576: Include **/*.aj files in *-sources.jar files
-