Сообщения

Spring IoC контейнер: конфигурация на основе аннотаций, точная настройка автопривязки на основе аннотаций с @Primary

Изображение
Поскольку автоматическое подключение по типу может привести к нескольким кандидатам, часто необходимо иметь больший контроль над процессом выбора. Одним из способов добиться этого является аннотация Spring @Primary . @Primary указывает, что конкретному bean-компоненту следует отдавать предпочтение, когда несколько bean-компонентов являются кандидатами на автоматическое подключение к однозначной зависимости. Если среди кандидатов существует ровно один основной компонент, он становится значением автопривязки. Рассмотрим следующую конфигурацию, которая определяет firstMovieCatalog в качестве основного MovieCatalog: Java @Configuration public class MovieConfiguration { @Bean @Primary public MovieCatalog firstMovieCatalog() { ... } @Bean public MovieCatalog secondMovieCatalog() { ... } // ... } Kotlin @Configuration class MovieConfiguration { @Bean @Primary fun firstMovieCatalog(): MovieCatalog { ... } @Bean fun secondMovieCatalo...

Spring IoC контейнер: конфигурация на основе аннотаций, использование @Autowired

Изображение
Вы можете применить аннотацию @Autowired к конструкторам, как показано в следующем примере: Java public class MovieRecommender { private final CustomerPreferenceDao customerPreferenceDao; @Autowired public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) { this.customerPreferenceDao = customerPreferenceDao; } // ... } Kotlin class MovieRecommender @Autowired constructor( private val customerPreferenceDao: CustomerPreferenceDao) Начиная с Spring Framework 4.3, аннотация @Autowired для такого конструктора больше не требуется, если целевой бин для начала определяет только один конструктор. Однако, если доступно несколько конструкторов и нет основного/стандартного конструктора, по крайней мере один из конструкторов должен быть аннотирован @Autowired, чтобы указать контейнеру, какой из них использовать. Вы также можете применить аннотацию @Autowired к традиционным методам установки, как показано в следующем примере: Java ...

Spring IoC контейнер: конфигурация на основе аннотаций, @Required

Изображение
Аннотация @Required применяется к методам установки (сеттерам) свойств бина, как в следующем примере: Java public class SimpleMovieLister { private MovieFinder movieFinder; @Required public void setMovieFinder(MovieFinder movieFinder) { this.movieFinder = movieFinder; } // ... } Kotlin class SimpleMovieLister { @Required lateinit var movieFinder: MovieFinder // ... } Эта аннотация указывает, что затронутое свойство компонента должно быть заполнено во время конфигурации, через явное значение свойства в определении компонента или через автоматическую привязку (autowiring). Контейнер генерирует исключение, если затронутое свойство компонента не было заполнено. Это учитывает нетерпеливый (eager) и явный сбой, избегая экземпляров NullPointerException и т.п. позже. Рекомендуется помещать утверждения в сам класс компонента (например, в метод init). Это обеспечивает выполнение этих обязательных ссылок и значений, даже если вы использ...

Spring IoC контейнер: конфигурация контейнера на основе аннотаций

Изображение
Аннотации лучше, чем XML для настройки Spring? Введение конфигурации на основе аннотаций поставило вопрос о том, является ли этот подход "лучше", чем XML. Краткий ответ: "Это зависит". Длинный ответ заключается в том, что у каждого подхода есть свои плюсы и минусы, и, как правило, разработчик сам решает, какая стратегия ему больше подходит. Благодаря тому, как они определены, аннотации обеспечивают много контекста в их объявлении, что приводит к более короткой и более краткой конфигурации. Однако XML отлично справляется с подключением компонентов, не затрагивая их исходный код и не перекомпилируя их. Некоторые разработчики предпочитают, чтобы привязка была ближе к источнику, в то время как другие утверждают, что аннотированные классы больше не являются POJO, и, кроме того, что конфигурация становится децентрализованной и более сложной для управления. Независимо от выбора, Spring может совместить оба стиля и даже смешать их вместе. Стоит отметить, что с помощью опц...

Spring IoC контейнер: точки расширения контейнера, настройка логики реализации с помощью FactoryBean

Изображение
Вы можете реализовать интерфейс org.springframework.beans.factory.FactoryBean для объектов, которые сами являются фабриками. Интерфейс FactoryBean - это точка подключения к логике создания контейнера Spring IoC. Если у вас есть сложный код инициализации, который лучше выражен в Java, в отличие от (возможно) многословного объема XML, вы можете создать свой собственный FactoryBean, записать сложную инициализацию внутри этого класса, а затем вставить свой собственный FactoryBean в контейнер. Интерфейс FactoryBean предоставляет три метода: Object getObject(): возвращает экземпляр объекта, который создает эта фабрика. Экземпляр может быть общим, в зависимости от того, возвращает ли эта фабрика синглтоны или прототипы. boolean isSingleton(): возвращает true, если этот FactoryBean возвращает синглтоны или false в противном случае. Class getObjectType(): возвращает тип объекта, возвращаемый методом getObject(), или значение null, если тип заранее не известен. Концепция и интерфейс Fac...

Spring IoC контейнер: точки расширения контейнера, PropertyOverrideConfigurer

Изображение
PropertyOverrideConfigurer, другой постпроцессор фабрики бинов, напоминает PropertySourcesPlaceholderConfigurer , но в отличие от последнего, исходные определения могут иметь значения по умолчанию или вообще не иметь значений для свойств бина. Если в файле переопределенных свойств нет записи для определенного свойства компонента, используется определение контекста по умолчанию. Обратите внимание, что определение компонента не знает о переопределении, поэтому из файла определения XML не сразу видно, что используется конфигуратор переопределения. В случае нескольких экземпляров PropertyOverrideConfigurer, которые определяют разные значения для одного и того же свойства компонента, выигрывает последний из-за механизма переопределения. Строки конфигурации файла свойств имеют следующий формат: beanName.property=value Следующий листинг показывает пример формата: dataSource.driverClassName=com.mysql.jdbc.Driver dataSource.url=jdbc:mysql:mydb Этот файл примера можно использоват...

Spring IoC контейнер: точки расширения контейнера, подстановка имени класса PropertySourcesPlaceholderConfigurer

Изображение
Вы можете использовать PropertySourcesPlaceholderConfigurer для вывода значений свойств из определения компонента в отдельный файл, используя стандартный формат свойств Java. Это позволяет человеку, развертывающему приложение, настраивать свойства среды, такие как URL-адреса и пароли базы данных, без сложности или риска изменения основного файла определения XML или файлов для контейнера. Рассмотрим следующий фрагмент метаданных конфигурации на основе XML, в котором определен источник данных со значениями-заполнителями: <bean class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer"> <property name="locations" value="classpath:com/something/jdbc.properties"/> </bean> <bean id="dataSource" destroy-method="close" class="org.apache.commons.dbcp.BasicDataSource"> <property name="driverClassName" value="${jdbc.driverClassName}"/> <p...