- 21 7月, 2011 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Juergen Hoeller 提交于
-
- 20 7月, 2011 1 次提交
-
-
由 Chris Beams 提交于
A <scheduled:task> element declared within a <beans default-lazy-init="true"> element represents a contradiction in terms: such a task will never be executed. For this reason, we now override any inherited lazy-init settings when parsing <scheduled:task> elements, forcing lazy-init to false for the underlying ScheduledTaskRegistrar bean. Thanks to Mike Youngstrom for contributing an initial patch. Issue: SPR-8498
-
- 19 7月, 2011 11 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
SPR-8532 Exclude Tiles transitive deps on 'com.springsource.javax.servlet' from 'com.springsource.org.apache.tiles.jsp' and 'com.springsource.org.apache.tiles.servlet' only.
-
由 Costin Leau 提交于
+ add LTW support for JBoss 7 (renamed existing classes to MC (JBoss 5&6) and introduced Modules (JBoss 7))
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Chris Beams 提交于
This change returns the invocation order of ConfigurationClassPostProcessor#enhanceConfigurationClasses to its pre-3.1 M2 state. An earlier (and now unnecessary) refactoring in service of @Feature method processing caused the change that this now reverts.
-
由 Chris Beams 提交于
-
由 Juergen Hoeller 提交于
-
- 18 7月, 2011 4 次提交
-
-
由 Rossen Stoyanchev 提交于
SPR-8001 Recognize case when MultipartRequest is null and argument is of type MultipartFile and raise helpful exception.
-
由 Rossen Stoyanchev 提交于
SPR-8532 Upgrade org.springframework.web.servlet to Servlet 3.0 (as provided dependency) and add support for javax.servlet.Part parameter
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
- 16 7月, 2011 5 次提交
-
-
由 Sam Brannen 提交于
[SPR-8387] Fixed logic errors in DelegatingSmartContextLoader.processContextConfiguration() and ContextConfigurationAttributes.hasResources().
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
[SPR-8387] Fleshing out the implementation of processContextConfiguration() in DelegatingSmartContextLoader.
-
由 Sam Brannen 提交于
-
- 15 7月, 2011 5 次提交
-
-
由 Juergen Hoeller 提交于
extended Servlet API mocks for Servlet 3.0 forward compatibility as far as possible; made MockHttpServletResponse compatible with Servlet 3.0 getHeader(s) method returning Strings (SPR-8529); added getHeaderValue(s) method to MockHttpServletResponse for raw value access
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
call setEnvironment before other awareness methods rather than after; fixed AccessControlContext applicability check
-
由 Juergen Hoeller 提交于
extended Servlet API mocks for Servlet 3.0 forward compatibility as far as possible; made MockHttpServletResponse compatible with Servlet 3.0 getHeader(s) method returning Strings (SPR-8529); added getHeaderValue(s) method to MockHttpServletResponse for raw value access
-
由 Costin Leau 提交于
-
- 14 7月, 2011 3 次提交
-
-
由 Chris Beams 提交于
Prior to this change, an instance of ConfigurationClassPostProcessor would throw IllegalStateException if its postProcessBeanDefinitionRegistry method were called more than once. This check is important to ensure that @Configuration classes are not proxied by CGLIB multiple times, and works for most normal use cases. However, if the same CCPP instance is used to process multiple registries/factories/contexts, this check creates a false negative because it does not distinguish between invocations of postProcessBeanDefinitionRegistry across different registries. A use case for this, though admittedly uncommon, would be creating a CCPP instance and registering it via ConfigurableApplicationContext#addBeanDefinitionPostProcessor against several ApplicationContexts. In such a case, the same CCPP instance will post-process multiple different registry instances, and throw the above mentioned exception. With this change, CCPP now performs lightweight tracking of the registries/beanFactories that it has already processed by recording the identity hashcodes of these objects. This is only slightly more complex than the previous boolean-based 'already processed' flags, and prevents this issue (however rare it may be) from occurring. Issue: SPR-8527
-
由 Chris Beams 提交于
Issue: SPR-8411, SPR-8494
-
由 Juergen Hoeller 提交于
-
- 13 7月, 2011 2 次提交
-
-
由 Costin Leau 提交于
-
由 Costin Leau 提交于
-
- 12 7月, 2011 1 次提交
-
-
由 Chris Beams 提交于
<emphasis role="bold"> blocks do not render properly, probably due to conflicting CSS used for syntax highlighting. For the moment, any mentions of bold text (e.g. "see bold text in the snippet below") have been removed to avoid confusion as reported in SPR-8520. SPR-8526 has been created to address the underlying issue of getting bold to work even with syntax highlighting. Issue: SPR-8520, SPR-8526
-
- 11 7月, 2011 3 次提交
-
-
由 Juergen Hoeller 提交于
an EntityManagerFactoryBean is only deserializable through a SerializedEntityManagerFactoryBeanReference
-
由 Juergen Hoeller 提交于
-
由 Chris Beams 提交于
Prior to this change, @EnableTransactionManagement (via the ProxyTransactionManagementConfiguration class) did not properly register its auto-proxy creator through the usual AopConfigUtils methods. It was trying to register the APC as a normal @Bean method, but this causes issues (SPR-8494) with the logic in AopConfigUtils#registerOrEscalateApcAsRequired, which expects the APC bean definition to have a beanClassName property. When the APC is registered via a @Bean definition, it is actually a factoryBean/factoryMethod situation with no directly resolvable beanClass/beanClassName. To solve this problem, ImportSelector#selectImports has been refactored to accept an ImportSelector.Context instance. This object contains the AnnotationMetadata of the importing class as well as the enclosing BeanDefinitionRegistry to allow for the kind of conditional bean registration necessary here. In this case, the bean definition that must be registered conditionally is that of the auto-proxy creator. It should only be registered if AdviceMode == PROXY, and thus the ImportSelector is an appropriate place to make this happen. It must happen as a BeanDefinition (rather than a @Bean method) for compatibility with AopConfigUtils, and working with the BeanDefinitionRegistry API allows for that. This change does mean that in certain cases like this one, #selectImports has container modifying side effects. Documentation has been updated to reflect. Issue: SPR-8411, SPR-8494
-
- 08 7月, 2011 3 次提交
-
-
由 Chris Beams 提交于
@PostConstruct added to ProxyTransactionManagementConfiguration cases ConcurrentModificationException (as detailed previously in SPR-8397. Backing out for now until a better solution can be devised. This reverts commit 235b729514d125aef79fc3fae4bcfb1893642212.
-
由 Chris Beams 提交于
Prior to this change, @EnableTransactionManagement (via the ProxyTransactionManagementConfiguration class) did not properly register its auto-proxy creator through the usual AopConfigUtils methods. It was trying to register the APC as a normal @Bean method, but this causes issues (SPR-8494) with the logic in AopConfigUtils#registerOrEscalateApcAsRequired, which expects the APC bean definition to have a beanClassName property. When the APC is registered via a @Bean definition, it is actually a factoryBean/factoryMethod situation with no directly resolvable beanClass/beanClassName. Rather than trying to rework how AopConfigUtils works, a @PostConstruct method has been added to ProxyTransactionManagementConfiguration to call the usual AopConfigUtils registration methods. Issue: SPR-8411, SPR-8494
-
由 Chris Beams 提交于
SessionFactoryBuilderSupport implementations create DisposableBean proxies for SessionFactory objects created using #buildSessionFactory. Prior to this change, these proxies create problems when working agaist SessionFactoryUtils.getDataSource(SessionFactory), because this method expects the given SessionFactory to implement Hibernate's SessionFactoryImplementor interface (which the stock SessionFactoryImpl does). With this change, the DisposableBean proxies created by SFBuilders now also implement SessionFactoryImplementor to satisfy this and probably other such cases. Issue: SPR-8469
-