Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to use @ Profile". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how to use @ Profile.

1.13 Environment abstraction

The Environment interface is an abstract integration in the container, and the application environment includes two important aspects: profiles and properties. A profile is a named bean definition logic group that is registered in the container only if a given profile is active. Bean can be assigned to a configuration file, whether it is defined with XML or annotated. The role of environment objects associated with profile files is to determine which profile files, if any, are currently active and which profile files, if any, should be active by default.

Properties plays an important role in almost all applications and may come from multiple sources: properties files, JVM system properties, system environment variables, JNDI, servlet context parameters, Properties objects, Map objects, and so on. The role of the Environment object is associated with properties to provide the user with a convenient service interface to configure the attribute source and resolve the property.

1.13.1 Bean definition Profiles

The bean definition properties file provides a mechanism in the core container that allows different bean to be registered in different environments. The word environment may mean different things to different users, and this feature can help many usage scenarios, including:

Work on in-memory data sources in development, rather than looking for the same data sources from JNDI during QA or production.

Use the registered health infrastructure when deploying the application to the execution environment

Deploy a customized bean implementation for customer An and customer B to register.

Consider the first usage scenario in the practical application, which needs to obtain a DataSource. In the test environment, the configuration assumptions are as follows:

@ Beanpublic DataSource dataSource () {return new EmbeddedDatabaseBuilder () .setType (EmbeddedDatabaseType.HSQL) .addScript ("my-schema.sql") .addScript ("my-test-data.sql") .build ();}

Now consider how the application is deployed to a QA or production environment, assuming that the application data source is registered in the generated application service JNDI directory. Our dataSource bean looks like the following list:

@ Bean (destroyMethod= ") public DataSource dataSource () throws Exception {Context ctx = new InitialContext (); return (DataSource) ctx.lookup (" java:comp/env/jdbc/datasource ");}

The question is how to switch between using these two variants according to the current environment. Over time, Spring users have devised a variety of ways to accomplish this task, usually relying on a combination of system environment variables and XML statements containing ${placeholder} placeholders that resolve to the correct profile path environment variables based on values. The Bean definition profile is a core container feature that addresses this issue.

If we summarize the use cases shown in the previous context-specific bean definition example, we eventually need to register a specific bean definition in a particular context rather than in another context. It can be said that you want to register one profile defined by bean in scenario An and another profile in scenario B. We began to update the configuration to reflect this requirement.

Use @ Profile

The @ Profile annotation allows you to indicate which components are suitable to register when one or more specified profile is active. Using our previous example, we can rewrite the dataSource configuration as follows:

@ Configuration@Profile ("development") public class StandaloneDataConfig {@ Bean public DataSource dataSource () {return new EmbeddedDatabaseBuilder () .setType (EmbeddedDatabaseType.HSQL) .addScrip t ("classpath:com/bank/config/sql/schema.sql") .addScript ("classpath:com/bank/config/sql/test-data.sql") .build () } @ Configuration@Profile ("production") public class JndiDataConfig {@ Bean (destroyMethod= ") public DataSource dataSource () throws Exception {Context ctx = new InitialContext (); return (DataSource) ctx.lookup (" java:comp/env/jdbc/datasource ");}}

As mentioned earlier, for the @ Bean method, you typically choose to use a programmatic JNDI lookup, either by using Spring's JndiTemplate/JndiLocatorDelegate helper class or directly using the JNDI InitialContext shown earlier, rather than using the JndiObjectFactoryBean variant, which forces you to declare the return type as a FactoryBean type.

The profile string may contain a simple configuration name (for example, production) or a configuration expression. A configuration expression allows more complex configuration logic to be expressed (for example, production & us-east), and the following operators are supported in profile expressions:

!: logic not

&: logic and

|: logic or

You can't mix & and! Operator without using parentheses. For example, production & us-east | eu-central is an invalid expression. It must be expressed like production & (us-east | eu-central).

You can use @ Profile as a metadata annotation to create your custom annotations. The following example defines a custom @ Production annotation that you can use as an alternative to @ Profile ("production").

Target (ElementType.TYPE) @ Retention (RetentionPolicy.RUNTIME) @ Profile ("production") public @ interface Production {}

If the @ configuration class is marked @ Profile, all @ Bean methods and classes associated with the @ Import annotation will be bypassed unless one or more specified configuration files are activated. If the @ Component or @ configuration class is marked @ Profile ({"p1", "p2"}), the class will not be registered or processed unless the configuration file p1 or p2 is activated. If the configuration prefix given is the NOT operator (!), the annotation element is registered only when the configuration file is not activated. For example, @ Profile ({"p1", "! p2"}), registration occurs if configuration p1 is activated or configuration p2 is not activated.

@ Profile can also be declared to include a specific configuration bean class at the method level (for example, an alternative to a specific bean), similar to the following example:

@ Configurationpublic class AppConfig {@ Bean ("dataSource") @ Profile ("development") / / 1 public DataSource standaloneDataSource () {return new EmbeddedDatabaseBuilder () .setType (EmbeddedDatabaseType.HSQL) .addScript ("classpath:com/bank/config/sql/schema.sql") .addScript ("classpath:com/bank/config/sql/test-data.sql") .build () @ Bean ("dataSource") @ Profile ("production") / / 2 public DataSource jndiDataSource () throws Exception {Context ctx = new InitialContext (); return (DataSource) ctx.lookup ("java:comp/env/jdbc/datasource");}}

The standaloneDataSource method is only valid in the development configuration

The jndiDataSource method is only valid in the production configuration

For @ Profile on @ Bean methods, you can apply a special scenario: in the case of overloading @ Bean methods with the same Java method name (similar to constructor overloading), the @ Profile condition needs to be declared consistently on all overloaded methods. If the conditions are inconsistent, only the first declared condition in the overloaded method is important. Therefore, @ Profile cannot be used to select a signature overloading method with a specific parameter. At creation time, parsing between all factory methods of the same bean follows Spring's constructor parsing method.

If you want to define bean for different configuration conditions, use different Java method names by using the @ Bean name attribute to point to the bean with the same name, similar to the previous example. If the parameters are all the same before (for example, all variants have a parameter constructor), this is the only way to represent this arrangement in a valid Java class (because there can only be one method with a specific name and parameter signature).

XML bean definition profile

The XML counterpart is the profile attribute of the element. Our previous same configuration can be rewritten in two XML files, similar to the following:

You can also avoid splitting and nesting elements in the same file, as shown in the following example:

Spring-bean.xsd has been limited to allowing only these elements as the last in the file. This should help provide flexibility without causing confusion in the XML file.

The XML counterpart does not support the profile expression described earlier: however, it may pass! Operator negates a configuration file. It may also apply logical and by embedding configuration files, as shown in the following example of the type:

In the previous example, if both production and us-east configurations are activated, dataSource bean is exposed.

Activate profile

Now that we have updated the profile, we still need to tell Spring which profile is active. If we have started our application, we will see a NoSuchBeanDefinitionException throw because the container cannot find the bean named dataSource.

Configuration files can be activated in a number of ways, but the most direct way is to configure the Environment API available through ApplicationContext programmatically. The following example shows how to do this:

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext (); ctx.getEnvironment (). SetActiveProfiles ("development"); ctx.register (SomeConfig.class, StandaloneDataConfig.class, JndiDataConfig.class); ctx.refresh ()

In addition, you can also activate the configuration file declaratively through the spring.profiles.active property, through the system environment variable, the JVM property, the servlet context parameter in web.xml, or even as an entry in JNDI (see PropertySource abstraction). In integration testing, the activation profile can be declared in the spring-test module by using @ ActiveProfiles (see the context configuration through the environment configuration file).

Note that the profile is not an either-or proposition. You can activate multiple profiles at once. Programmatically, you can provide multiple configuration file names to the setActiveProfiles () method, which accepts String. Variable parameters. The following example activates multiple profiles:

Ctx.getEnvironment (. SetActiveProfiles ("profile1", "profile2")

Declaratively, spring.profiles.active can receive a comma-separated list of configuration names, similar to the following example:

-Dspring.profiles.active= "profile1,profile2"

Default profile

The default profile represents the profile that is enabled by default. Consider the following example:

@ Configuration@Profile ("default") public class DefaultDataConfig {@ Bean public DataSource dataSource () {return new EmbeddedDatabaseBuilder () .setType (EmbeddedDatabaseType.HSQL) .addScript ("classpath:com/bank/config/sql/schema.sql") .build ();}

If no profile is activated, the dataSource instance is created. You can see that this approach provides a default definition for one or more bean. If any profile is activated, this default profile is not used.

You can change the default profile name by using setDefaultProfiles () on Environment or, declaratively, by using the spring.profiles.default attribute.

1.13.2 PropertySource abstraction

Spring's Environment abstraction provides search operations on a configurable attribute source hierarchy. Consider the following list:

ApplicationContext ctx = new GenericApplicationContext (); Environment env = ctx.getEnvironment (); boolean containsMyProperty = env.containsProperty ("my-property"); System.out.println ("Does my environment contain the 'my-property' property?" + containsMyProperty)

In the previous snippet, we saw a high-level way to ask Spring whether the my-property property is defined in the current context: to answer this question, the Environment object performs a search for the PropertySource collection object. PropertySource is a simple key-value abstraction of the source, and the StandardEnvironment of Spring is configured with two PropertySource objects, one describing the set of attributes of the JVM system (System.getProperties ()) and the other describing the set of system environment variables (System.getenv ()).

These default attribute sources are suitable for StandardEnvironment and are used in stand-alone applications. StandardServletEnvironment is populated by attaching default attribute sources, including servlet configuration and servlet context parameters. It can optionally enable JndiPropertySource. View javadock details.

Specifically, when you use StandardEnvironment, if the my-property system property or my-property environment variable is described at run time, calling the env.containsProperty ("my-property") method will return true.

The search performed is hierarchical, and by default, system attributes take precedence over environment variables. Therefore, if the my-property property is set in two places, the system property value will be returned when env.getProperty ("my-property") is called. Note that the property values are not merged, but are completely overridden by the previous values.

For generic StandardServletEnvironment, the complete hierarchy is as follows, with the highest priority entry at the top:

1.ServletConfig parameter (if used-for example, if it is a DispatcherServlet context)

2.ServletContext parameter (web.xml context parameter)

3.JNDI environment variable (java:comp/env/)

4.JVM system parameter (- D command line argument)

5.JVM system variable (operating system environment variable)

Most importantly, the whole mechanism is configurable. Maybe you have a custom attribute source that you want to integrate into this search. To do so, implement and instantiate your PropertySource and add it to the current Environment PropertySources collection. The following example shows how to do this:

ConfigurableApplicationContext ctx = new GenericApplicationContext (); MutablePropertySources sources = ctx.getEnvironment (). GetPropertySources (); sources.addFirst (new MyPropertySource ())

In the previous code, MyPropertySource is added to the highest index priority. If it contains a my-property property, it is detected and returned, supporting the my-property property in any other PropertySource. MutablePropertySourcesAPI exposes methods that allow precise manipulation of attribute source collections.

1.13.3 use @ PropertySource

The @ PropertySource annotation provides a convenient and declarative mechanism to add PropertySource to Spring's Environment.

Given a file called app.properties that contains the healthy pair testbean.name=myTestBean, the following @ Configuration class uses @ PropertySource to call testBean.getName () and return myTestBean in this way:

Configuration@PropertySource ("classpath:/com/myco/app.properties") public class AppConfig {@ Autowired Environment env; @ Bean public TestBean testBean () {TestBean testBean = new TestBean (); testBean.setName (env.getProperty ("testbean.name")); return testBean;}}

Any ${} placeholders that appear in the @ PropertySource resource location will be resolved based on the attribute source set that has been registered in the environment, as shown in the following example:

@ Configuration@PropertySource ("classpath:/com/$ {my.placeholder:default/path} / app.properties") public class AppConfig {@ Autowired Environment env; @ Bean public TestBean testBean () {TestBean testBean = new TestBean (); testBean.setName (env.getProperty ("testbean.name")); return testBean;}}

Assuming that my.placeholder is described in an attribute source that has been registered (for example, system properties or environment variables), the placeholder is resolved to the corresponding value. If not, a default value of default/path is used. If no default value is specified and the property cannot be parsed, an IllegalArgumentException is thrown.

According to the Java8 convention, the @ PropertySource annotation is repeatable. However, all @ PropertySource annotations need to be declared at the same level, either directly on the configuration class or as metadata annotations in the same custom annotations. It is not recommended to mix direct comments with meta-comments because direct comments effectively override meta-comments.

Reference code: com.liyong.ioccontainer.starter.EnvironmentIocContainer

Analysis of placeholders in 1.13.4 statements

Previously, the values of placeholders in elements could only be resolved based on JVM system properties or environment variables. Things are different now. Because the Environment abstraction is integrated into the container, it is easy to route placeholder resolution through it. This means that you can configure the parsing process in any way you like. You can change the priority of the search system properties and environment variables, or you can delete them completely. You can also add your own attribute sources to the combination as appropriate.

Specifically, wherever the customer attribute is defined, the following statement works as long as it is available in the environment:

Thank you for your reading, the above is the content of "how to use @ Profile", after the study of this article, I believe you have a deeper understanding of how to use @ Profile, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.