Что такое autowired в spring
Spring IoC Annotation-based configuration, часть 2
В предыдущей статье я рассказал об основных аннотациях Spring IoC, однако есть еще несколько интересных вещей, о которых хотелось бы поведать.
Для, тех, кто не в курсе, что такое Spring Framework предлагаю почитать вот эту статью.
Еще несколько слов об @Autowired
Аннотация @Autowired может применяться не только к полям бина чтобы заинъектить в них зависимости, но так же к сеттерам, конструкторам и методам. Рассмотрим, что же будет значить @Autowired в каждом из этих случаев.
1. @Autowired примененный к сеттеру
Пусть наш подопытный бин, который мы будет инъектить выглядит так:
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Service;
@Service( «testBean» )
@Scope( «singleton» )
public class TestBean <
private String data = «I am a singleton!!» ;
public String getData() <
return data;
>
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Service;
@Service( «lab1Bean» )
@Scope( «session» )
public class SimpleBean <
private TestBean bean;
он заинъектит в поле бина синглтон TestBean’a и в консоли мы увидим заветное «I am a singleton!!».
2. @Autowired примененный к конструктору
Ситуация аналогичная — если мы добавим вот такой конструктор:
то в консоли увидим долгожданное «I am a singleton!!».
3. @Autowired примененный к методу
Самая интересная ситуация, добавляем вот такой метод
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Service;
@Service( «lab1Bean» )
@Scope( «session» )
public class SimpleBean <
@Autowired(required= false )
private TestBean bean;
@PostConstruct
public void init() <
// System.out.println(bean.getData());
>
Аннотация Qualifier
@Autowired
@Qualifier( «specialTestBean» )
private TestBean bean;
Эта конструкция будет искать в контексте бин с именем specialTestBean и в нашем примере мы соответственно получим исключение, так как TestBean объявлен с именем ‘testBean’ (@Service(«testBean»)).
На основе Qualifier можно создавать свои признаки бинов, об этом достаточно хорошо написано (и, что немаловажно, с огромным количеством примеров) в Spring Reference Manual.
Аннотация Resource
// @Autowired
// аналогично
@Resource
private TestBean bean;
// @Autowired
// @Qualifier(«specialTestBean»)
@Resource(name= «specialTestBean» )
private TestBean bean;
Русские Блоги
Spring @Autowired и три способа запустить автоматическое сканирование
Предисловие:
@Autowired определение кода аннотации
Этот метод реализуется с использованием метода set соответствующего класса. Прежде чем использовать аннотацию @Autowired, сначала убедитесь, что вы можете использовать здесь аннотацию @Autowired.
1. Введение в сценарии использования аннотаций @Autowired
Во-вторых, основная часть аннотации @Autowired
Фактически, когда запускается Spring IoC, контейнер автоматически загружает постпроцессор AutowiredAnnotationBeanPostProcessor. Когда контейнер сканирует @Autowied, @Resource или @Inject, он автоматически находит требуемый bean-компонент в контейнере IoC и объединяет его со свойствами объекта.
При использовании @Autowired сначала запросите соответствующий тип bean-компонента в контейнере,
Вышеупомянутый процесс показывает, что аннотация @Autowired вводится в соответствии с типом сборки по умолчанию. По умолчанию она требует, чтобы зависимый объект существовал. Если ему разрешено иметь значение null, вы можете установить для его обязательного атрибута значение false. Если вы хотите передать инъекцию в соответствии с именем, вам необходимо объединить @ Квалификатор используется вместе;
3. Устраните неоднозначность автоматической сборки с помощью аннотации @Autowired.
Если в процессе использования аннотаций @Autowired возникает исключение NoUniqueBeanDefinitionException, это в основном связано с неоднозначностью, вызванной автоматической сборкой или другими методами сборки. То есть существует более двух классов реализации для интерфейса. То есть во время автоматической сборки может возникнуть тяжелая ситуация. NoUniqueBeanDefinitionException вызвано проблемой имени.
@Autowired собирается по типу, поэтому у меня есть интерфейс UserInterface с несколькими классами реализации
И так далее, эти классы реализации добавляются в контейнер Spring, когда в классе используется следующий оператор:
Ниже перечислены вышеупомянутые проблемы и аналогичные решения неоднозначности сборки.
Поскольку существует более двух классов реализации для интерфейса, проблема неоднозначности также может быть решена путем определения предпочтительного bean-компонента. Например:
В настоящее время, если имеется ссылка на внедрение класса реализации интерфейса IUserService, сначала внедряется класс аннотации @Promary, но на данный момент существует проблема. В классе реализации того же интерфейса вы можете использовать @Primary только один раз. Если для AImpl Используются как @primary, так и BImpl, и неоднозначность сборки по-прежнему будет возникать.В настоящее время рекомендуется использовать метод (1) для решения проблемы неоднозначности.
Метод третий
В последнем случае вы можете использовать специальные аннотации квалификаторов, но такая ситуация возникает редко, поэтому я не буду вводить ее снова, и вы можете использовать Baidu самостоятельно.
В-четвертых, какие функции Spring обеспечивает автоматическая сборка?
Spring реализует автоматизированную сборку с двух точек зрения:
Комбинация сканирования компонентов и автоматической сборки может быть мощной, и они могут свести к минимуму конфигурацию вашего дисплея.
В-пятых, разница между @Autowired и @Resource
В этой статье перечислены только общие поверхностные различия между @Autowired и @Resource.Что касается причины различия, вам необходимо проверить реализацию аннотации @Autowired в официальной документации Spring и реализацию аннотации @Resource в Java.
(1) @Autowired внедряется в соответствии со сборкой типа по умолчанию. По умолчанию для этого требуется, чтобы зависимый объект существовал. Если ему разрешено иметь значение null, вы можете установить для его обязательного атрибута значение false. Если вы хотите передать инъекцию в соответствии с именем, вам необходимо объединить @Qualifier использовать вместе;
(2) @Resource по умолчанию собирает инъекцию в соответствии с именем.Только когда не удается найти bean-компонент, соответствующий имени, инъекция собирается в соответствии с типом;
(3) аннотация @Resource предоставляется J2EE, а @Autowired предоставляется Spring, поэтому для уменьшения зависимости системы от Spring рекомендуется использовать @Resource;
(4) И @Resource, и @Autowired могут быть записаны и отмечены в поле или в методе установки поля.
(5) @Resource собирается в соответствии с именем по умолчанию. Когда bean-компонент, соответствующий имени, не найден, он будет собран в соответствии с типом, который можно указать с помощью атрибута name. Если атрибут имени не указан, когда аннотация отмечена в поле, поле берется по умолчанию Имя используется в качестве имени компонента для поиска зависимого объекта.Когда аннотация помечена в методе установки атрибута, имя атрибута используется в качестве имени компонента для поиска зависимого объекта по умолчанию. Примечание: если атрибут имени не указан, и зависимый объект не может быть найден в соответствии с именем по умолчанию В это время он вернется к сборке по типу, но как только атрибут name будет указан, его можно будет собрать только по имени.
В-шестых, как Spring запускает автоматическое сканирование
Вот три способа запустить автоматическое сканирование.
метод первый:В этом случае, для более особой ситуации, то есть в проекте используется SpringBoot, вы можете использовать аннотацию @SpringBootApplication для запуска функции автоматического сканирования.
Путь второй: В режиме конфигурации XML запустите функцию автоматического сканирования. Режим конфигурации XML.
Тег будет включать автоматическое сканирование Spring Beans и может установить атрибут base-package, что означает, что Spring будет сканировать все классы, оформленные @Component в этом каталоге и подкаталогах, и собирать их.
Путь третий: С помощью метода настройки Java запустите функцию автоматического сканирования.
Вот конкретный пример:
(2) @ComponentScan означает открытие сканирования Spring Beans, аналогично конфигурации XML, здесь вы также можете установить атрибут basePackages. Чтобы
Если аннотация @ComponentScan не показывает, чтобы присвоить значения другим атрибутам, например, присвоить значения базовым пакетам здесь, если нет, аннотация @ComponentScan будет сканировать пакеты с тем же классом конфигурации.
Что касается использования четырех аннотаций @Repository, @Service, @Controller и @Component
На уровне сохраняемости, бизнес-уровне и уровне управления @Repository, @Service и @Controller используются для аннотирования классов на уровне, а @Component используется для аннотирования более нейтральных классов. Это означает, что этот класс передан Spring для управления, а имя переименовано в userManager.Поскольку трудно сказать, к какому уровню принадлежит этот класс, используется @Component.
Семь, сколько методов сборки существует в Spring?
В настоящее время в Spring есть три метода сборки:
8. Использование @Autowired в @Configuration для аннотирования ошибок IDE.
заглавие
Введение в Spring, или что делать, если по всему проекту @Autowired и @Component, а вы не понимаете, что это
Приветствую тебя, Хабр!
Эта статья будет полезна тем, кто уже начал изучать Java и даже успел добиться некоторых успехов в понимании Java Core, и вот услышал слово Spring. И, возможно, даже не один раз: знание Spring Framework, как минимум, фигурирует в описаниях множества вакансий для джавистов. Эта статья поможет вам взобраться на самую первую ступеньку: понять общую идею столь популярного фреймворка.
Начнем издалека. Существует такое понятие как Inversion of Control, по-русски – Инверсия управления, сокращенно – IoC. IoC — один из принципов, приближающий наш код к слабосвязанности. IoC — это делегирование части наших обязанностей внешнему компоненту.
Существуют разные реализации IoC подхода, нас интересует одна из них — Dependency Injection, внедрение зависимостей. Что это такое, название говорит само за себя, так что раскрыть ее я постараюсь на примере. Мы пишем приложение, автоматизирующее работу сети магазинов. Есть классы Shop (магазин) и Seller (продавец). У класса Seller имеется поле типа Shop — магазин, в котором работает продавец. Вот мы и столкнулись с зависимостью: Seller зависит от Shop. Теперь задумаемся, как в объект Seller попадет объект Shop? Есть варианты:
Перечисленные два способа — это реализация Dependency Injection (но пока еще это не IoC). И, наконец, мы подобрались к спрингу: он предоставляет еще один способ внедрять зависимости (а тут уже IoC).
Вообще говоря, Spring — это очень широкий набор библиотек на многие случаи жизни. Существует и Spring MVC для быстрого создания веб-приложений, и Spring Security для реализации авторизации в приложении, и Spring Data для работы с базами данных и еще куча всего. Но отдельно стоит Spring IoC — это базовый вид спринга, который реализует изучаемую нами тему — внедрение зависимостей. Spring IoC заслуживает внимания в самом начале изучения библиотек спринга по еще одной причине. Как вы увидите в процессе практической работы с другими видами спринга, для всех остальных спрингов Spring IoC используется как каркас.
Знакомство со Spring IoC начнем с главного термина: бин (англ. — bean). Самыми простыми словами,
Бин — создаваемый Spring-ом объект класса, который можно внедрить в качестве значения поля в другой объект.
Бин — объект класса, представляющий собой завершенный программный элемент с определенной бизнес-функцией либо внутренней функцией Spring’а, жизненным циклом которого управляет контейнер бинов.
Как вы уже поняли, для того, чтобы в Seller можно было внедрить Shop, Shop должен стать бином. Существует несколько способов рассказать приложению, какие объекты имеют гордое право называться бинами, все они приводят нас к понятию ApplicationContext. ApplicationContext — это сердце спринга. Как правило, он создается в самом начале работы приложения («поднимается») и управляет жизненным циклом бинов. Поэтому его еще называют контейнером бинов.
Подбираемся к главному. Каким образом нам необходимо переписать наши классы, чтобы Spring IoC и его слуга ApplicationContext подставили значение поля Shop объекту Seller? Вот таким:
Просто? Куда уж проще! Элегантно? Вполне. Здесь произошло следующее: аннотация Component сказала спрингу, что класс, который ей аннотируем, это бин. Аннотация Autowired попросила Spring в поле, которое она аннотирует, подставить значение. Эта операция называется «инжектнуть» (inject). Какое именно значение будет подставлено? Об этом чуть позже, сначала разберемся, как вообще классы становятся бинами.
Мы уже знаем, что в начале работы приложения должен подняться хранитель всех бинов ApplicationContext. Он-то и создает сразу все бины. Почти все. Дело в том, что по умолчанию любой бин имеет внутриспринговое свойство scope в значении singleton. Внутриспринговое, так как синглтоном в прямом смысле слова он не является. Он является синглтоном для спринга: при поднятии контекста Spring создаст ровно один объект-бин из указанного класса. Если вы хотите изменить такое поведение — пожалуйста, Spring разрешает управлять временем создания бина и их количеством для одного класса, но сейчас не об этом.
Итак, при поднятии ApplicationContext создаются все бины. Давайте выясним, а собственно где живет контекст и самое главное: как он определяет, из каких классов необходимо создавать бины. Вариантов несколько, для простоты изложения мы поговорим про один из них: конфигурирование с помощью файла xml. Вот его пример:
В этом файле продемонстрирован запуск создания бинов двумя путями. Первый, скажем так, ручной. Видите, здесь есть тег bean с указанием класса. Это и есть бин. Из всего, что прописано в этом файле с тегом bean, будут созданы бины.
Второй путь менее многословен. Помните, над классами мы поставили аннотацию Component. Из всех классов, аннотированных этой аннотацией, будут созданы бины. Благодаря этой строке из xml-файла:
Она говорит спрингу: просканируй весь пакет main и из всего, над чем будет стоять аннотация Component (или другие аннотации, являющиеся наследниками Component), создай бины. Компактно, не правда ли? Просто говорим, в каких пакетах содержатся классы, из которых нужно создавать бины, и аннотируем эти классы.
Поднять контекст с использованием xml-файла можно следующей строчкой кода:
где beans.xml — путь к xml-нику, о котором шла речь выше.
С созданием бинов разобрались. Каким же образом Spring заполнит поле Shop при создании Seller’а? При поднятии контекста создается бин-объект класса Shop. Также создается бин-объект класса Seller, он же тоже аннотирован Component. У него есть поле типа Shop, аннотированное Autowired. Аннотация Autowired говорит спрингу: в это поле нужно инжектнуть бин. В нашем случае у нас есть всего один бин, подходящий на эту роль, то есть тип которого совпадает с типом поля: это бин — экземпляр класса Shop. Он и будет проинжектен в объект Seller, что и требовалось. Я понимаю, сейчас вопросики полезли как червячки: а что будет, если Spring не найдет нужный бин, или найдет несколько подходящих (особенно учитывая, что инжектить можно также по интерфейсу, а не по классу). Spring умен, но требует того же и от нас. Нам нужно либо иметь в системе ровно один бин, подходящий под каждый Autowired, либо обучать Spring действиям при таких конфликтах (об этом мы сейчас не будем, вы и так устали, крепитесь, статья подходит к концу).
Заметьте, что Seller – это тоже бин. Если бы он был не бином, а создавался через new, то автоматически бы ничего в него не проинжектнулось.
Возможно вы сейчас думаете, зачем все эти сложности. Но представьте, что у нас приложение не из 2 классов, а на несколько порядков больше и управление зависимостями уже становится не самой тривиальной задачей.
Возможно вы сейчас думаете, как красиво, просто и лаконично Spring позволяет внедрять зависимости. Но представьте, что что-то пошло не так и вам необходимо дебажить приложение. И все становится уже не так просто…
Парочка хинтов напоследок:
Это легальный способ получить бин, хотя в современных реалиях так обычно не делают. Но для учебного примера можно.
UPD (20.04.2021). Dependency Injection это не всегда IoC! В самом начале я как раз привожу примеры Dependency Injection, не являющиеся IoC.
Что такое autowired в spring
Autowired Fields
Fields are injected right after construction of a bean, before any config methods are invoked. Such a config field does not have to be public.
Autowired Methods
Config methods may have an arbitrary name and any number of arguments; each of those arguments will be autowired with a matching bean in the Spring container. Bean property setter methods are effectively just a special case of such a general config method. Such config methods do not have to be public.
Autowired Parameters
Although @Autowired can technically be declared on individual method or constructor parameters since Spring Framework 5.0, most parts of the framework ignore such declarations. The only part of the core Spring Framework that actively supports autowired parameters is the JUnit Jupiter support in the spring-test module (see the TestContext framework reference documentation for details).
Multiple Arguments and ‘required’ Semantics
In the case of a multi-arg constructor or method, the required() attribute is applicable to all arguments. Individual parameters may be declared as Java-8 style Optional or, as of Spring Framework 5.0, also as @Nullable or a not-null parameter type in Kotlin, overriding the base ‘required’ semantics.
Autowiring Arrays, Collections, and Maps
Not supported in BeanPostProcessor or BeanFactoryPostProcessor
Note that actual injection is performed through a BeanPostProcessor which in turn means that you cannot use @Autowired to inject references into BeanPostProcessor or BeanFactoryPostProcessor types. Please consult the javadoc for the AutowiredAnnotationBeanPostProcessor class (which, by default, checks for the presence of this annotation).
Java Blog
Spring IoC контейнер: конфигурация на основе аннотаций, использование @Autowired
Вы можете применить аннотацию @Autowired к конструкторам, как показано в следующем примере:
Начиная с Spring Framework 4.3, аннотация @Autowired для такого конструктора больше не требуется, если целевой бин для начала определяет только один конструктор. Однако, если доступно несколько конструкторов и нет основного/стандартного конструктора, по крайней мере один из конструкторов должен быть аннотирован @Autowired, чтобы указать контейнеру, какой из них использовать.
Вы также можете применить аннотацию @Autowired к традиционным методам установки, как показано в следующем примере:
Вы также можете применить аннотацию к методам с произвольными именами и несколькими аргументами, как показано в следующем примере:
Вы также можете применять @Autowired к полям и даже смешивать их с конструкторами, как показано в следующем примере:
Убедитесь, что ваши целевые компоненты (например, MovieCatalog или CustomerPreferenceDao) последовательно объявляются в соответствии с типом, который вы используете для точек внедрения, помеченных @Autowired. В противном случае внедрение может завершиться неудачей из-за ошибки «no type match found» («не найдено совпадение типов») во время выполнения.
Для определенных в XML компонентов или классов компонентов, найденных с помощью сканирования путей к классам, контейнер обычно заранее знает конкретный тип. Однако для фабричных методов @Bean необходимо убедиться, что объявленный тип возвращаемого значения достаточно выразителен. Для компонентов, которые реализуют несколько интерфейсов, или для компонентов, на которые потенциально может ссылаться их тип реализации, рассмотрите возможность объявления наиболее определенного типа возврата в фабричном методе (по крайней мере, настолько специфичном, как того требуют точки внедрения, ссылающиеся на ваш компонент).
Вы также можете указать Spring предоставить все компоненты определенного типа из ApplicationContext, добавив аннотацию @Autowired в поле или метод, который ожидает массив этого типа, как показано в следующем примере:
То же самое относится к типизированным коллекциям, как показано в следующем примере:
Ваши целевые bean-компоненты могут реализовать интерфейс org.springframework.core.Ordered или использовать аннотацию @Order или стандартную @Priority, если вы хотите, чтобы элементы в массиве или списке сортировались в определенном порядке. В противном случае их порядок следует порядку регистрации соответствующих определений целевого компонента в контейнере.
Вы можете объявить аннотацию @Order на уровне целевого класса и в методах @Bean, потенциально для отдельных определений бинов (в случае нескольких определений, использующих один и тот же класс бинов). Значения @Order могут влиять на приоритеты в точках внедрения, но имейте в виду, что они не влияют на порядок запуска синглтона, что является ортогональной проблемой, определяемой отношениями зависимостей и объявлениями @DependsOn.
Обратите внимание, что стандартная аннотация javax.annotation.Priority недоступна на уровне @Bean, поскольку она не может быть объявлена в методах. Ее семантика может быть смоделирована с помощью значений @Order в сочетании с @Primary для одного компонента для каждого типа.
По умолчанию автоматическое подключение завершается ошибкой, когда для данной точки внедрения отсутствуют подходящие подходящие компоненты. В случае объявленного массива, коллекции или карты ожидается, по крайней мере, один соответствующий элемент.
Поведение по умолчанию состоит в том, чтобы рассматривать аннотированные методы и поля как указывающие на необходимые зависимости. Вы можете изменить это поведение, как показано в следующем примере, позволяя платформе пропускать недопустимую точку внедрения, помечая ее как необязательную (т. е. устанавливая обязательный атрибут в @Autowired равным false):
Необязательный метод вообще не будет вызываться, если его зависимость (или одна из его зависимостей в случае нескольких аргументов) недоступна. В таких случаях необязательное поле не заполняется вообще, а его значение по умолчанию остается на месте.
Только один конструктор из любого заданного класса bean-компонента может объявить @Autowired с обязательным атрибутом, установленным в true, что указывает на конструктор для автоматической передачи при использовании в качестве Spring-компонента. Как следствие, если для обязательного атрибута оставлено значение по умолчанию true, только один конструктор может быть аннотирован @Autowired. Если несколько конструкторов объявляют аннотацию, все они должны будут объявить required=false, чтобы их можно было рассматривать в качестве кандидатов на автопривязку (аналог autowire=constructor в XML). Будет выбран конструктор с наибольшим количеством зависимостей, который может быть удовлетворен путем сопоставления bean-компонентов в контейнере Spring. Если ни один из кандидатов не может быть удовлетворен, то будет использоваться основной/заданный по умолчанию конструктор (если имеется). Точно так же, если класс объявляет несколько конструкторов, но ни один из них не аннотирован @Autowired, то будет использоваться основной/заданный по умолчанию конструктор (если имеется). Если класс для начала объявляет только один конструктор, он всегда будет использоваться, даже если он не аннотирован. Обратите внимание, что аннотированный конструктор не должен быть публичным.
Обязательный атрибут @Autowired рекомендуется использовать вместо устаревшей аннотации @Required в методах установки (сеттеры). Установка для обязательного атрибута значения false указывает, что свойство не требуется для целей автоматической привязки, и свойство игнорируется, если оно не может быть автоподключено. @Required, с другой стороны, сильнее в том смысле, что заставляет свойство устанавливать любые средства, поддерживаемые контейнером, и, если значение не определено, возникает соответствующее исключение.
Кроме того, вы можете выразить необязательный характер конкретной зависимости через java.util.Optional Java 8, как показано в следующем примере:
Вы также можете использовать @Autowired для интерфейсов, которые являются хорошо известными разрешаемыми зависимостями: BeanFactory, ApplicationContext, Environment, ResourceLoader, ApplicationEventPublisher и MessageSource. Эти интерфейсы и их расширенные интерфейсы, такие как ConfigurableApplicationContext или ResourcePatternResolver, автоматически разрешаются без специальной настройки. Следующий пример автоматически связывает объект ApplicationContext:
Аннотации @Autowired, @Inject, @Value и @Resource обрабатываются реализациями Spring BeanPostProcessor. Это означает, что вы не можете применять эти аннотации в ваших собственных типах BeanPostProcessor или BeanFactoryPostProcessor (если есть). Эти типы должны быть явно подключены с использованием XML или метода Spring @Bean.