Автоматическая конфигурация Spring против явного @ Enable * объявления конфигурации

Question

Spring 4 предоставляет отличную функцию с автоматической настройкой вместе с @Conditional API. Spring также имеет множество встроенных настроек @Enable *** (например, @EnableWebMvc, @EnableCaching, @EnableScheduling ...). Но я сбит с толку, когда мне нужно явно использовать конфигурацию @ Enable **, или мне просто нужна автоконфигурация и достаточно указать некоторые пользовательские компоненты для переопределения. Пожалуйста, объясните мне эту проблему.

Answer 1

@EnableWebMvc, @EnableCaching, @EnableScheduling - это способы включения различных возможностей, которые пружина предоставляет через некоторые из его модулей.

Они не являются частью весенней загрузки

. Эти функции включают в себя много тяжелой работы. И, следовательно, они не активируются по умолчанию.

Например, даже если вы используете @Scheduled, планировщик не будет включен, если вы не включите возможность планирования с помощью @EnableScheduling. Это позволяет весне делать необходимые вещи, необходимые для поддержки этой функции. Это может включать / не включать запуск нескольких AutoConfiguration классов

Классы автоконфигурации предоставляют способ настройки плагина, который необходимо выполнить во время запуска. Это расширяется. Это означает, что вы можете написать свои собственные классы автоконфигурации. И эти классы автоконфигурации являются частью springboot

Spring boot в основном самоуверен, что означает, что он принимает много решений, основанных на зависимостях, которые он видит в pom. Например, когда он видит зависимости mon go, он пытается подключиться к базе данных moon go на локальном хосте и порту 27017. Это делается с помощью классов AutoConfiguration. Что расширяемо, путем предоставления пользовательских значений через application.properties или предоставления пользовательских реализаций

Answer 2

Если вы используете Spring Boot, то автоконфигурация включается автоматически, и если вы можете обрабатывать их с помощью файла application.properties.

Если вы переопределяете / настраиваете некоторую конфигурацию, проверьте следующий код:

import java.util.concurrent.Executor;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.annotation.EnableAsync;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;

@Configuration
@EnableAsync
public class AsyncConfig 
{
    @Bean(name ="taskExecutor")
    public Executor taskExecutor()
    {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2);
        executor.setMaxPoolSize(2);
        executor.setQueueCapacity(100);
        executor.setThreadNamePrefix("Thread-");
        executor.initialize();
        return executor;
    }
}

Здесь мы можем настраивать асинхронную функциональность.