- 12 6月, 2019 1 次提交
-
-
由 Juergen Hoeller 提交于
Closes gh-22957
-
- 23 3月, 2019 1 次提交
-
-
由 Spring Operator 提交于
This commit updates URLs to prefer the https protocol. Redirects are not followed to avoid accidentally expanding intentionally shortened URLs (i.e. if using a URL shortener). # Fixed URLs ## Fixed Success These URLs were switched to an https URL with a 2xx status. While the status was successful, your review is still recommended. * [ ] http://www.apache.org/licenses/ with 1 occurrences migrated to: https://www.apache.org/licenses/ ([https](https://www.apache.org/licenses/) result 200). * [ ] http://www.apache.org/licenses/LICENSE-2.0 with 6515 occurrences migrated to: https://www.apache.org/licenses/LICENSE-2.0 ([https](https://www.apache.org/licenses/LICENSE-2.0) result 200).
-
- 19 11月, 2018 1 次提交
-
-
由 Hanope 提交于
See gh-2019
-
- 09 8月, 2018 1 次提交
-
-
由 Juergen Hoeller 提交于
Includes Java 8 getDeclaredAnnotation shortcut for lookup on Class. Issue: SPR-17146
-
- 13 6月, 2017 1 次提交
-
-
由 Stephane Nicoll 提交于
-
- 07 6月, 2017 1 次提交
-
-
由 Juergen Hoeller 提交于
Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments. Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit. Issue: SPR-15540
-
- 22 2月, 2017 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-15271
-
- 20 2月, 2017 1 次提交
-
-
由 Stephane Nicoll 提交于
-
- 01 9月, 2016 1 次提交
-
-
由 Stephane Nicoll 提交于
This commit adds a "spring-context-indexer" module that can be added to any project in order to generate an index of candidate components defined in the project. `CandidateComponentsIndexer` is a standard annotation processor that looks for source files with target annotations (typically `@Component`) and references them in a `META-INF/spring.components` generated file. Each entry in the index is the fully qualified name of a candidate component and the comma-separated list of stereotypes that apply to that candidate. A typical example of a stereotype is `@Component`. If a project has a `com.example.FooService` annotated with `@Component` the following `META-INF/spring.components` file is generated at compile time: ``` com.example.FooService=org.springframework.stereotype.Component ``` A new `@Indexed` annotation can be added on any annotation to instructs the scanner to include a source file that contains that annotation. For instance, `@Component` is meta-annotated with `@Indexed` now and adding `@Indexed` to more annotation types will transparently improve the index with additional information. This also works for interaces or parent classes: adding `@Indexed` on a `Repository` base interface means that the indexed can be queried for its implementation by using the fully qualified name of the `Repository` interface. The indexer also adds any class or interface that has a type-level annotation from the `javax` package. This includes obviously JPA (`@Entity` and related) but also CDI (`@Named`, `@ManagedBean`) and servlet annotations (i.e. `@WebFilter`). These are meant to handle cases where a component needs to identify candidates and use classpath scanning currently. If a `package-info.java` file exists, the package is registered using a "package-info" stereotype. Such files can later be reused by the `ApplicationContext` to avoid using component scan. A global `CandidateComponentsIndex` can be easily loaded from the current classpath using `CandidateComponentsIndexLoader`. The core framework uses such infrastructure in two areas: to retrieve the candidate `@Component`s and to build a default `PersistenceUnitInfo`. Rather than scanning the classpath and using ASM to identify candidates, the index is used if present. As long as the include filters refer to an annotation that is directly annotated with `@Indexed` or an assignable type that is directly annotated with `@Indexed`, the index can be used since a dedicated entry wil be present for that type. If any other unsupported include filter is specified, we fallback on classpath scanning. In case the index is incomplete or cannot be used, The `spring.index.ignore` system property can be set to `true` or, alternatively, in a "spring.properties" at the root of the classpath. Issue: SPR-11890
-
- 12 4月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 31 3月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
This commit documents the @Ignore'd test to explain that Spring does not support a hybrid approach for annotation attribute overrides with transitive implicit aliases. Issue: SPR-13554
-
- 25 3月, 2016 2 次提交
-
-
由 Sam Brannen 提交于
This commit introduces a boolean alwaysProcesses() method in the Processor API which allows for simplification across all search algorithms within AnnotatedElementUtils. Specifically, it is no longer necessary for process() methods to verify that the supplied annotation is actually the sought target annotation. In addition, duplicated code has been extracted into common methods (e.g., hasMetaAnnotationTypes()) and common Processor implementations (e.g., AlwaysTrueBooleanAnnotationProcessor).
-
由 Sam Brannen 提交于
This commit picks up where 25354690 left off with added support for "get" search semantics for merged repeatable annotations. Specifically, this commit introduces a new getMergedRepeatableAnnotations() method in AnnotatedElementUtils. Issue: SPR-13973
-
- 20 3月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
This commit introduces tests that verify the status quo for finding multiple merged composed annotations on a single annotated element. Issue: SPR-13486
-
- 19 3月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, it was possible that implicit aliases and transitive implicit aliases (configured via @AliasFor) might not be honored in certain circumstances, in particular if implicit aliases were declared to override different attributes within an alias pair in the target meta-annotation. This commit addresses this issue by ensuring that all aliased attributes in the target meta-annotation are overridden during the merge process in AnnotatedElementUtils. In addition, concrete default values for attributes in a meta-annotation declaration can now be effectively shadowed by transitive implicit aliases in composed annotations. Issue: SPR-14069
-
- 18 3月, 2016 2 次提交
-
-
由 Sam Brannen 提交于
Issue: SPR-14069
-
由 Sam Brannen 提交于
-
- 07 3月, 2016 1 次提交
-
-
由 Sam Brannen 提交于
This commit picks up where 8ff9e818 left off. Specifically, this commit introduces support that allows a single element attribute to override an array attribute with a matching component type when synthesizing annotations (e.g., in annotations synthesized from attributes that have been merged from the annotation hierarchy above a composed annotation). Issue: SPR-13972
-
- 23 2月, 2016 1 次提交
-
-
由 Juergen Hoeller 提交于
Includes refinements for consistent quoting of names in exception messages. Issue: SPR-13972
-
- 08 12月, 2015 1 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13696
-
- 05 11月, 2015 2 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-13621
-
由 Juergen Hoeller 提交于
-
- 14 10月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 10 10月, 2015 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
Issue: SPR-13554
-
- 31 8月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
This commit picks up where 3eacb837 (SPR-13345) left off by adding support for transitive implicit aliases configured via @AliasFor. Issue: SPR-13405
-
- 29 8月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Spring Framework 4.2 introduced support for aliases between annotation attributes that fall into the following two categories. 1) Alias pairs: two attributes in the same annotation that use @AliasFor to declare that they are explicit aliases for each other. 2) Meta-annotation attribute overrides: an attribute in one annotation uses @AliasFor to declare that it is an explicit override of an attribute in a meta-annotation. However, the existing functionality fails to support the case where two attributes in the same annotation both use @AliasFor to declare that they are both explicit overrides of the same attribute in the same meta-annotation. In such scenarios, one would intuitively assume that two such attributes would be treated as "implicit" aliases for each other, analogous to the existing support for explicit alias pairs. Furthermore, an annotation may potentially declare multiple aliases that are effectively a set of implicit aliases for each other. This commit introduces support for implicit aliases configured via @AliasFor through an extensive overhaul of the support for alias lookups, validation, etc. Specifically, this commit includes the following. - Introduced isAnnotationMetaPresent() in AnnotationUtils. - Introduced private AliasDescriptor class in AnnotationUtils in order to encapsulate the parsing, validation, and comparison of both explicit and implicit aliases configured via @AliasFor. - Switched from single values for alias names to lists of alias names. - Renamed getAliasedAttributeName() to getAliasedAttributeNames() in AnnotationUtils. - Converted alias map to contain lists of aliases in AnnotationUtils. - Refactored the following to support multiple implicit aliases: getRequiredAttributeWithAlias() in AnnotationAttributes, AbstractAliasAwareAnnotationAttributeExtractor, MapAnnotationAttributeExtractor, MergedAnnotationAttributesProcessor in AnnotatedElementUtils, and postProcessAnnotationAttributes() in AnnotationUtils. - Introduced numerous tests for implicit alias support, including AbstractAliasAwareAnnotationAttributeExtractorTestCase, DefaultAnnotationAttributeExtractorTests, and MapAnnotationAttributeExtractorTests. - Updated Javadoc in @AliasFor regarding implicit aliases and in AnnotationUtils regarding "meta-present". Issue: SPR-13345
-
- 12 8月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
This commit introduces an additional test case to ensure that explicit local attribute aliases (configured via @AliasFor) do not accidentally override attributes of the same names in meta-annotations (i.e., by convention). Issue: SPR-13325
-
- 07 8月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, an explicit override for an attribute in a meta-annotation configured via @AliasFor could potentially result in an incorrect override of an attribute of the same name but in the wrong meta-annotation. This commit fixes the algorithm in getAliasedAttributeName(Method, Class) in AnnotationUtils by ensuring that an explicit attribute override is only applied to the configured target meta-annotation (i.e., configured via the 'annotation' attribute in @AliasFor). Issue: SPR-13325
-
- 14 6月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
In AnnotatedElementUtils, all methods pertaining to merging annotation attributes have been renamed to "getMerged*()" and "findMerged*()" accordingly. Existing methods such as getAnnotationAttributes(..) have been deprecated in favor of the more descriptive "merged" variants. This aligns the naming conventions in AnnotatedElementUtils with those already present in AnnotationReadingVisitorUtils. The use of "annotationType" as a variable name for the fully qualified class name of an annotation type has been replaced with "annotationName" in order to improve the readability and intent of the code base. In MetaAnnotationUtils.AnnotationDescriptor, getMergedAnnotation() has been renamed to synthesizeAnnotation(), and the method is now overridden in UntypedAnnotationDescriptor to always throw an UnsupportedOperationException in order to avoid potential run-time ClassCastExceptions. Issue: SPR-11511
-
- 30 5月, 2015 2 次提交
-
-
由 Sam Brannen 提交于
This commit introduces a "synthesized annotation" alternative to getAnnotationAttributes() in AnnotatedElementUtils, analogous to the recently introduced findAnnotation() methods. Issue: SPR-13082
-
由 Sam Brannen 提交于
-
- 29 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Spring Framework 4.2 RC1 introduced support for synthesizing an annotation from an existing annotation in order to provide additional functionality above and beyond that provided by Java. Specifically, such synthesized annotations provide support for @AliasFor semantics. As luck would have it, the same principle can be used to synthesize an annotation from any map of attributes, and in particular, from an instance of AnnotationAttributes. The following highlight the major changes in this commit toward achieving this goal. - Introduced AnnotationAttributeExtractor abstraction and refactored SynthesizedAnnotationInvocationHandler to delegate to an AnnotationAttributeExtractor. - Extracted code from SynthesizedAnnotationInvocationHandler into new AbstractAliasAwareAnnotationAttributeExtractor and DefaultAnnotationAttributeExtractor implementation classes. - Introduced MapAnnotationAttributeExtractor for synthesizing an annotation that is backed by a map or AnnotationAttributes instance. - Introduced a variant of synthesizeAnnotation() in AnnotationUtils that accepts a map. - Introduced findAnnotation(*) methods in AnnotatedElementUtils that synthesize merged AnnotationAttributes back into an annotation of the target type. The following classes have been refactored to use the new support for synthesizing AnnotationAttributes back into an annotation. - ApplicationListenerMethodAdapter - TestAnnotationUtils - AbstractTestContextBootstrapper - ActiveProfilesUtils - ContextLoaderUtils - DefaultActiveProfilesResolver - DirtiesContextTestExecutionListener - TestPropertySourceAttributes - TestPropertySourceUtils - TransactionalTestExecutionListener - MetaAnnotationUtils - MvcUriComponentsBuilder - RequestMappingHandlerMapping In addition, this commit also includes changes to ensure that arrays returned by synthesized annotations are properly cloned first. Issue: SPR-13067
-
- 27 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Prior to this commit, when a nested array of annotations was synthesized while adapting values within an AnnotationAttributes map, the array was improperly replaced with an array of type Annotation[] instead of an array of the concrete annotation type, which can lead to unexpected run-time exceptions. This commit fixes this bug by replacing annotations in the existing array with synthesized versions of those annotations, thereby retaining the original array's component type. Issue: SPR-13077
-
- 23 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
-
- 22 5月, 2015 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
This commit introduces first-class support for aliases for annotation attributes. Specifically, this commit introduces a new @AliasFor annotation that can be used to declare a pair of aliased attributes within a single annotation or an alias from an attribute in a custom composed annotation to an attribute in a meta-annotation. To support @AliasFor within annotation instances, AnnotationUtils has been overhauled to "synthesize" any annotations returned by "get" and "find" searches. A SynthesizedAnnotation is an annotation that is wrapped in a JDK dynamic proxy which provides run-time support for @AliasFor semantics. SynthesizedAnnotationInvocationHandler is the actual handler behind the proxy. In addition, the contract for @AliasFor is fully validated, and an AnnotationConfigurationException is thrown in case invalid configuration is detected. For example, @ContextConfiguration from the spring-test module is now declared as follows: public @interface ContextConfiguration { @AliasFor(attribute = "locations") String[] value() default {}; @AliasFor(attribute = "value") String[] locations() default {}; // ... } The following annotations and their related support classes have been modified to use @AliasFor. - @ManagedResource - @ContextConfiguration - @ActiveProfiles - @TestExecutionListeners - @TestPropertySource - @Sql - @ControllerAdvice - @RequestMapping Similarly, support for AnnotationAttributes has been reworked to support @AliasFor as well. This allows for fine-grained control over exactly which attributes are overridden within an annotation hierarchy. In fact, it is now possible to declare an alias for the 'value' attribute of a meta-annotation. For example, given the revised declaration of @ContextConfiguration above, one can now develop a composed annotation with a custom attribute override as follows. @ContextConfiguration public @interface MyTestConfig { @AliasFor( annotation = ContextConfiguration.class, attribute = "locations" ) String[] xmlFiles(); // ... } Consequently, the following are functionally equivalent. - @MyTestConfig(xmlFiles = "test.xml") - @ContextConfiguration("test.xml") - @ContextConfiguration(locations = "test.xml"). Issue: SPR-11512, SPR-11513
-
- 13 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
This commit updates the "get semantics" search algorithm used in `AnnotatedElementUtils` so that locally declared 'composed annotations' are favored over inherited annotations. Specifically, the internal `searchWithGetSemantics()` method now searches locally declared annotations before searching inherited annotations. All TODOs in `AnnotatedElementUtilsTests` have been completed, and all ignored tests have been reinstated. Issue: SPR-11598
-
- 07 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Issue: SPR-11514
-
- 06 5月, 2015 1 次提交
-
-
由 Sam Brannen 提交于
Issue: SPR-11514
-