@@ -578,7 +578,7 @@ Java::
578
578
MultiValueMap<String, Object> attrs = metadata.getAllAnnotationAttributes(Profile.class.getName());
579
579
if (attrs != null) {
580
580
for (Object value : attrs.get("value")) {
581
- if (context.getEnvironment().acceptsProfiles((( String[]) value) )) {
581
+ if (context.getEnvironment().matchesProfiles(( String[]) value)) {
582
582
return true;
583
583
}
584
584
}
@@ -597,7 +597,7 @@ Kotlin::
597
597
val attrs = metadata.getAllAnnotationAttributes(Profile::class.java.name)
598
598
if (attrs != null) {
599
599
for (value in attrs["value"]!!) {
600
- if (context.environment.acceptsProfiles(Profiles.of( *value as Array<String>) )) {
600
+ if (context.environment.matchesProfiles( *value as Array<String>)) {
601
601
return true
602
602
}
603
603
}
@@ -636,14 +636,14 @@ options for using `@Configuration` classes in this kind of "`XML-centric`" situa
636
636
[[beans-java-combining-xml-centric-declare-as-bean]]
637
637
==== Declaring `@Configuration` classes as plain Spring `<bean/>` elements
638
638
639
- Remember that `@Configuration` classes are ultimately bean definitions in the
640
- container. In this series examples, we create a `@Configuration` class named `AppConfig` and
639
+ Remember that `@Configuration` classes are ultimately bean definitions in the container.
640
+ In this series of examples, we create a `@Configuration` class named `AppConfig` and
641
641
include it within `system-test-config.xml` as a `<bean/>` definition. Because
642
642
`<context:annotation-config/>` is switched on, the container recognizes the
643
643
`@Configuration` annotation and processes the `@Bean` methods declared in `AppConfig`
644
644
properly.
645
645
646
- The following example shows an ordinary configuration class in Java:
646
+ The following example shows the `AppConfig` configuration class in Java and Kotlin :
647
647
648
648
[tabs]
649
649
======
@@ -664,7 +664,7 @@ Java::
664
664
665
665
@Bean
666
666
public TransferService transferService() {
667
- return new TransferService (accountRepository());
667
+ return new TransferServiceImpl (accountRepository());
668
668
}
669
669
}
670
670
----
@@ -697,6 +697,7 @@ The following example shows part of a sample `system-test-config.xml` file:
697
697
<beans>
698
698
<!-- enable processing of annotations such as @Autowired and @Configuration -->
699
699
<context:annotation-config/>
700
+
700
701
<context:property-placeholder location="classpath:/com/acme/jdbc.properties"/>
701
702
702
703
<bean class="com.acme.AppConfig"/>
@@ -743,8 +744,8 @@ Kotlin::
743
744
----
744
745
======
745
746
746
- NOTE: In `system-test-config.xml` file, the `AppConfig` `<bean/>` does not declare an `id`
747
- element . While it would be acceptable to do so, it is unnecessary, given that no other bean
747
+ NOTE: In the `system-test-config.xml` file, the `AppConfig` `<bean/>` does not declare an `id`
748
+ attribute . While it would be acceptable to do so, it is unnecessary, given that no other bean
748
749
ever refers to it, and it is unlikely to be explicitly fetched from the container by name.
749
750
Similarly, the `DataSource` bean is only ever autowired by type, so an explicit bean `id`
750
751
is not strictly required.
@@ -755,8 +756,8 @@ is not strictly required.
755
756
756
757
Because `@Configuration` is meta-annotated with `@Component`, `@Configuration`-annotated
757
758
classes are automatically candidates for component scanning. Using the same scenario as
758
- described in the previous example, we can redefine `system-test-config.xml` to take advantage of component-scanning.
759
- Note that, in this case, we need not explicitly declare
759
+ described in the previous example, we can redefine `system-test-config.xml` to take
760
+ advantage of component-scanning. Note that, in this case, we need not explicitly declare
760
761
`<context:annotation-config/>`, because `<context:component-scan/>` enables the same
761
762
functionality.
762
763
@@ -767,6 +768,7 @@ The following example shows the modified `system-test-config.xml` file:
767
768
<beans>
768
769
<!-- picks up and registers AppConfig as a bean definition -->
769
770
<context:component-scan base-package="com.acme"/>
771
+
770
772
<context:property-placeholder location="classpath:/com/acme/jdbc.properties"/>
771
773
772
774
<bean class="org.springframework.jdbc.datasource.DriverManagerDataSource">
@@ -781,13 +783,12 @@ The following example shows the modified `system-test-config.xml` file:
781
783
=== `@Configuration` Class-centric Use of XML with `@ImportResource`
782
784
783
785
In applications where `@Configuration` classes are the primary mechanism for configuring
784
- the container, it is still likely necessary to use at least some XML. In these
785
- scenarios, you can use `@ImportResource` and define only as much XML as you need. Doing
786
- so achieves a "`Java-centric`" approach to configuring the container and keeps XML to a
787
- bare minimum. The following example (which includes a configuration class, an XML file
788
- that defines a bean, a properties file, and the `main` class) shows how to use
789
- the `@ImportResource` annotation to achieve "`Java-centric`" configuration that uses XML
790
- as needed:
786
+ the container, it may still be necessary to use at least some XML. In such scenarios, you
787
+ can use `@ImportResource` and define only as much XML as you need. Doing so achieves a
788
+ "`Java-centric`" approach to configuring the container and keeps XML to a bare minimum.
789
+ The following example (which includes a configuration class, an XML file that defines a
790
+ bean, a properties file, and the `main()` method) shows how to use the `@ImportResource`
791
+ annotation to achieve "`Java-centric`" configuration that uses XML as needed:
791
792
792
793
[tabs]
793
794
======
@@ -812,6 +813,17 @@ Java::
812
813
public DataSource dataSource() {
813
814
return new DriverManagerDataSource(url, username, password);
814
815
}
816
+
817
+ @Bean
818
+ public AccountRepository accountRepository(DataSource dataSource) {
819
+ return new JdbcAccountRepository(dataSource);
820
+ }
821
+
822
+ @Bean
823
+ public TransferService transferService(AccountRepository accountRepository) {
824
+ return new TransferServiceImpl(accountRepository);
825
+ }
826
+
815
827
}
816
828
----
817
829
@@ -836,21 +848,32 @@ Kotlin::
836
848
fun dataSource(): DataSource {
837
849
return DriverManagerDataSource(url, username, password)
838
850
}
851
+
852
+ @Bean
853
+ fun accountRepository(dataSource: DataSource): AccountRepository {
854
+ return JdbcAccountRepository(dataSource)
855
+ }
856
+
857
+ @Bean
858
+ fun transferService(accountRepository: AccountRepository): TransferService {
859
+ return TransferServiceImpl(accountRepository)
860
+ }
861
+
839
862
}
840
863
----
841
864
======
842
865
866
+ .properties-config.xml
843
867
[source,xml,indent=0,subs="verbatim,quotes"]
844
868
----
845
- properties-config.xml
846
869
<beans>
847
870
<context:property-placeholder location="classpath:/com/acme/jdbc.properties"/>
848
871
</beans>
849
872
----
850
873
874
+ .jdbc.properties
851
875
[literal,subs="verbatim,quotes"]
852
876
----
853
- jdbc.properties
854
877
jdbc.url=jdbc:hsqldb:hsql://localhost/xdb
855
878
jdbc.username=sa
856
879
jdbc.password=
@@ -883,5 +906,3 @@ Kotlin::
883
906
----
884
907
======
885
908
886
-
887
-
0 commit comments