Spring IoC контейнер: абстракция Environment, профили определения компонентов

Профили определения bean-компонентов обеспечивают механизм в основном контейнере, который позволяет регистрировать различные bean-компоненты в разных средах. Слово "среда" может означать разные вещи для разных пользователей, и эта функция может помочь во многих случаях использования, в том числе:

• Работа с источником данных в памяти при разработке по сравнению с поиском того же источника данных из JNDI в процессе контроля качества или производства.
• Регистрация инфраструктуры мониторинга только при развертывании приложения в производственной среде.
• Регистрация настраиваемых реализаций bean-компонентов для развертываний клиента A и клиента B.

Рассмотрим первый вариант использования в практическом приложении, требующем DataSource. В тестовой среде конфигурация может выглядеть следующим образом:

Java

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

Kotlin

@Bean
fun dataSource(): DataSource {
    return EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("my-schema.sql")
            .addScript("my-test-data.sql")
            .build()
}

Теперь рассмотрим, как это приложение можно развернуть в среде контроля качества или в производственной среде, предполагая, что источник данных для приложения зарегистрирован в каталоге JNDI производственного сервера приложений. Теперь наш bean-компонент dataSource выглядит как следующий листинг:

Java

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

Kotlin

@Bean(destroyMethod = "")
fun dataSource(): DataSource {
    val ctx = InitialContext()
    return ctx.lookup("java:comp/env/jdbc/datasource") as DataSource
}

Проблема в том, как переключаться между этими двумя вариантами в зависимости от текущей среды. Со временем пользователи Spring придумали несколько способов сделать это, обычно полагаясь на комбинацию переменных системной среды и операторов XML <import/>, содержащих токены ${placeholder}, которые разрешают правильный путь к файлу конфигурации в зависимости от значения переменной среды. Профили определения компонентов - это основная функция контейнера, которая обеспечивает решение этой проблемы.

Если мы обобщим вариант использования, показанный в предыдущем примере определений компонентов для конкретной среды, то в конечном итоге мы получим необходимость регистрировать определенные определения компонентов в определенных контекстах, но не в других. Вы могли бы сказать, что хотите зарегистрировать определенный профиль определений bean-компонентов в ситуации A и другой профиль в ситуации B. Начнем с обновления нашей конфигурации, чтобы отразить эту потребность.

---

Читайте также:

• Spring IoC контейнер: абстракция Environment
• Spring IoC контейнер: Java конфигурация, объединение конфигурации Java и XML
• Spring IoC контейнер: Java конфигурация, объединение конфигурации Java и XML, @Configuration класс ориентированное использование XML с @ImportResource