- 11 8月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Prior to this change, the repackaged spring-asm and spring-cglib jars were being included wholesale in the spring-core jar, whereas the intention was to include the unzipped classfiles. This change ensures that spring-asm and spring-cglib jars are unzipped on the fly when creating the spring-core jar. Issue: SPR-9669
-
- 10 8月, 2012 13 次提交
-
-
由 Sam Brannen 提交于
ReflectionTestUtils.setField() implicitly calls toString() on the target object when arguments for a call to Assert.notNull() are built. This can have undesirable side effects, for example if the toString() invocation results in a thrown exception or access to an external system (e.g., a database). This commit addresses this issue by inlining the Assert.notNull() code, thereby avoiding accidental invocation of toString() on a non-null target. Issue: SPR-9571
-
由 Sam Brannen 提交于
The default set of TestExecutionListeners is sufficient in most integration testing scenarios; however, the TestContextManager nonetheless logs an INFO message if the @TestExecutionListeners annotation is not present on an integration test class. In order to avoid flooding the logs with messages about the absence of @TestExecutionListeners, this commit reduces the log level for such messages from INFO to DEBUG. Issue: SPR-8645
-
由 Chris Beams 提交于
Issue: SPR-9669
-
由 Chris Beams 提交于
* SPR-9669: Upgrade to CGLIB 3 and inline into spring-core Remove spring-asm and inline ASM 4 into spring-core Upgrade JarJar to version 1.3
-
由 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
-
由 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
-
由 Sam Brannen 提交于
* SPR-9621: Avoid NPE when registering a SpEL MethodFilter
-
由 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
-
由 Sam Brannen 提交于
* SPR-9620: Support nested double quotes in SpEL expressions
-
由 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
-
由 Sam Brannen 提交于
* SPR-9614: Support symbolic boolean operators for OR and AND
-
由 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
-
- 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 3 次提交
-
-
由 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
-