SPR-7679 - Qualified TransactionManager now also found if declared in parent context #5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Issue: SPR-5973 git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4970 50f2f4bb-b051-0410-bef5-90022cba6387
Previously, #containsBean Javadoc advertised that a true return value indicates that a call to #getBean for the same name would succeed. This is actually not the case, and has never been. The semantics of #containsBean have always been to indicate whether a bean definition with the given name is definied or a singleton instance with the given name has been registered. The Javadoc now reflects this accurately. Issue: SPR-8690 git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4971 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4972 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4973 50f2f4bb-b051-0410-bef5-90022cba6387
…ween string paths and path segment lists automatically. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4974 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4975 50f2f4bb-b051-0410-bef5-90022cba6387
…AndView containing a View git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4976 50f2f4bb-b051-0410-bef5-90022cba6387
… correctly. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4977 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4978 50f2f4bb-b051-0410-bef5-90022cba6387
…formation. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4979 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4980 50f2f4bb-b051-0410-bef5-90022cba6387
…SP form tags. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4981 50f2f4bb-b051-0410-bef5-90022cba6387
…rverHttpRequest. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4982 50f2f4bb-b051-0410-bef5-90022cba6387
…lerMapping. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4983 50f2f4bb-b051-0410-bef5-90022cba6387
1. Consider single-purpose return value types like HttpEntity, Model, View, and ModelAndView ahead of annotations like @responsebody and @ModelAttribute. And reversely consider multi-purpose return value types like Map, String, and void only after annotations like @rb and @ma. 2. Order custom argument resolvers and return value handlers after the built-in ones also clarifying the fact they cannot be used to override the built-in ones in Javadoc throughout. 3. Provide hooks in RequestMappingHandlerAdapter that subclasses can use to programmatically modify the list of argument resolvers and return value handlers, also adding new getters so subclasses can get access to what they need for the override. 4. Make SessionStatus available through ModelAndViewContainer and provide an argument resolver for it. 5. Init test and javadoc improvements. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4984 50f2f4bb-b051-0410-bef5-90022cba6387
RequestCondition types keep individual expression types (e.g. the discrete header or param expressions) package private. Although the implementation of these types should remain private, there is no reason not to provide access to the underlying expression data -- e.g. for creating a REST endpoint documentation tool, or if you want to know which of the "consumes"/"produces" media types are negated. This change ensures that all RequestCondition types have a public getter that makes available the basic expression data. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4985 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4986 50f2f4bb-b051-0410-bef5-90022cba6387
Make it possible to hook in custom ServletRequestDataBinderFactory by overriding RequestMappingHandlerAdapter. Create ExtendedServletRequestDataBinder to add URI template vars to the binding values taking advantage of a new extension hook in ServletRequestDataBinder to provide additional values to bind. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4987 50f2f4bb-b051-0410-bef5-90022cba6387
…nners.model.MultipleFailureException, which has been deprecated in JUnit 4.9. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4988 50f2f4bb-b051-0410-bef5-90022cba6387
… is a super-class of the actual target. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4989 50f2f4bb-b051-0410-bef5-90022cba6387
…rmined why changes to GenericConversionService broke this test. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4990 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4991 50f2f4bb-b051-0410-bef5-90022cba6387
…nges to GenericConversionService broke this test. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4992 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4993 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4994 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4995 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4996 50f2f4bb-b051-0410-bef5-90022cba6387
When a @ModelAttribute is instantiated from a URI variable with type conversion, if conversion fails allow the exception to propagate. This is consistent with what happens on type conversion failure with @PathVariable and other args that rely on type conversion. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4997 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4998 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4999 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5216 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5218 50f2f4bb-b051-0410-bef5-90022cba6387
The AbstractHttpMessageConverter was using the requested Content-Type rather than the actual response Content-Type to determine the length of the content. This can lead to a problem when a controller returns a ResponseEntity with a Content-Type header that ignores (overrides) the requested Content-Type. The fix ensures that actual response Content-Type is the one used both to write to the response and to determine the length of the content. git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5219 50f2f4bb-b051-0410-bef5-90022cba6387
…ers on any access (SPR-8844, SPR-8845) git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5220 50f2f4bb-b051-0410-bef5-90022cba6387
…ompletion (if necessary; SPR-8846) git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5222 50f2f4bb-b051-0410-bef5-90022cba6387
… 1.6 compatibility; SPR-7969) git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5224 50f2f4bb-b051-0410-bef5-90022cba6387
…-8812) git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5226 50f2f4bb-b051-0410-bef5-90022cba6387
…ons from setHint calls (SPR-7947) git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5227 50f2f4bb-b051-0410-bef5-90022cba6387
…e for 404 status (SPR-7881) git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5229 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5231 50f2f4bb-b051-0410-bef5-90022cba6387
Prior to this change, a @configuration classes that @componentscan themselves would result in a ConflictingBeanDefinitionException. For example: package com.foo.config; @configuration @componentscan("com.foo"); public class AppConfig { // ... } This resulted in a ConflictingBeanDefinitionException that users have typically worked around in the following fashion: package com.foo.config; @configuration @componentscan(basePackages="com.foo", excludeFilters=@filter(value=ANNOTATION_TYPE, type=Configuration.class); public class AppConfig { // ... } This is obviously more verbose and cumbersome than would be desirable, and furthermore potentially too constraining as it prohibits the ability to include other legitimate @configuration classes via scanning. The exception was being thrown because of a logic problem in ClassPathBeanDefinitionScanner. The bean definition for AppConfig gets registered once by the user (e.g. when constructing an AnnotationConfigApplicationContext), then again when performing the component scan for 'com.foo'. Prior to this change, ClassPathBeanDefinitionScanner's #isCompatible returned false if the new bean definition was anything other than an AnnotatedBeanDefinition. The intention of this check is really to see whether the new bean definition is a *scanned* bean definition, i.e. the result of a component-scanning operation. If so, then it becomes safe to assume that the original bean definition is the one that should be kept, as it is the one explicitly registered by the user. Therefore, the fix is as simple as narrowing the instanceof check from AnnotatedBeanDefinition to its ScannedGenericBeanDefinition subtype. Note that this commit partially reverts changes introduced in SPR-8307 that explicitly caught ConflictingBeanDefinitionExceptions when processing recursive @componentscan definitions, and rethrew as a "CircularComponentScanException. With the changes in this commit, such CBDEs will no longer occur, obviating the need for this check and for this custom exception type altogether. Issue: SPR-8808, SPR-8307 git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5233 50f2f4bb-b051-0410-bef5-90022cba6387
…"cacheUnresolved"=true; SPR-8173) git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5234 50f2f4bb-b051-0410-bef5-90022cba6387
…"cacheUnresolved"=true; SPR-8173) git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5236 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5237 50f2f4bb-b051-0410-bef5-90022cba6387
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@5238 50f2f4bb-b051-0410-bef5-90022cba6387
… parent context In case you have defined a transaction manager inside a parent application context and try to reference this from a bean inside a child context explicitly (through @transactional("txMgr") e.g.) it will be found now.
|
Closing, as SPR-7679 was resolved some time ago. |
bclozel
pushed a commit
that referenced
this pull request
Jun 19, 2014
Make the link to a project's forum optional
This was referenced Jan 10, 2019
drodriguezhdez
referenced
this pull request
in scope-demo/spring-framework
Oct 14, 2019
This was referenced May 12, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In case you have defined a transaction manager inside a parent application context and try to reference this from a bean inside a child context explicitly (through @transactional("txMgr") e.g.) it will be found now.