Аннотация value spring не работает

Spring Core — Аннотация @Value

Приветствую уважаемые форумчане.

У меня не работает Аннотация @Value. Вместо нужно строки показывает null.

В интернете все перерыл и не нашёл решения. Сразу хочу сказать, что placeholder мне не нужен, но и с placeholder-ом тоже не работает. Сначала просто хочу минимально сделать чтобы работало без всяких placeholder-ов.

Вот простейший код

Подскажиnе, что не так? В интернете все примеры которые есть, все их делал, и проблема не уходит. Капец.

Добавлено через 4 минуты
А как закрыть тему? Тема закрыта. Сделал. Все правильно я делал. Только нужно было не конструктор, а метод делать. На конструкторе не работает. А вот на методе работает.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Spring аннотация Autowired
Всем, добрый день. Изучаю Spring недавно и соответственно столкнулся с некоторыми трудностями. У.

задания по spring core и spring mvc для новичков
Какие задания можно предложить новичкам для выполнения после знакомства их с spring core и mvc ?

Spring Core
Приветствую уважаемые форумчане. Изучаю Spring Core. Дошел до раздела . и пытаюсь повторить.

[Spring Core в web-приложении] Dependency Injection vs Servlet Context
Использую из спринга только контейнер в своем веб-приложении, но недавно узнал, что можно просто в.

Источник

Spring: @Value aннотация

Основная цель этой статьи — помочь вам понять, как работает аннотация Spring @Value.

@Value является аннотацией Java, которая используется на уровне параметра поля или метода / конструктора и указывает значение по умолчанию для затронутого аргумента. Он обычно используется для ввода значений в конфигурационные переменные — что мы покажем и объясним в следующей части статьи.

Основное назначение

Для самых простых примеров мы назначим значения трем различным полям, используя аннотацию @Value , дав им явные значения:

Очень важно отметить, что аргумент, переданный аннотации @Value , может быть только String . Spring преобразует значение в указанный тип, и присвоение будет выполнено без проблем, даже если мы передаем переменным String значение int или boolean .

Spring Environment

Внедрение значений из файлов свойств с помощью аннотации @Value , вероятно, наиболее часто используется в реальных приложениях.

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

В этом примере значения переменных считываются из файла application.properties и присваиваются им во время создания компонента.

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

Значение по умолчанию

Значения по умолчанию используются как «запасной вариант», если свойство, которое мы хотим внедрить, не определено или отсутствует:

В приведенном выше примере, потому как мы не имеем никакого значения car.type в application.properties , Spring присвоит Sedan к переменной type в качестве значения по умолчанию.

Если свойство car.type вставляется в файл свойств, вместо него будет использоваться новое значение.

Системные переменные

Мы также можем получить доступ к системным переменным, которые хранятся в виде свойств приложения Spring при запуске:

Переменные могут вызываться с различными соглашениями об именах — Spring ищет нас и присваивает правильное значение.

Значение глобального метода

Поскольку @Value обрабатывается классом BeanPostProcessor , он будет вызываться, когда Spring создает контекст Spring, создавая экземпляры файлов конфигурации и компонентов.

Это означает, что при наличии метода @Value все аргументы будут сопоставлены со значением, указанным в аннотации:

Если мы печатаем, carData.getCarColor() и carData.getCarBrand() мы получим значение car.brand оба раза, потому что, как мы сказали, все аргументы будут сопоставлены с предоставленным значением.

Параметр метода Value

Мы можем исправить это, используя @Value непосредственно с параметр метода:

Теперь, если мы печатаем значения из объекта carData — поле цвета будет иметь значение car.color , потому что мы предоставили значение для параметра самого метода.

Spring Expression Language (SpEL)

Язык выражений Spring (SpEL) — это язык выражений, который служит основой для оценки выражений в портфолио Spring.

По сути, когда мы используем SpEL вместе с аннотацией @Value , мы просто меняем способ сказать Spring, что нам нужно. Давайте внимательнее посмотрим:

Это то, как вы вводите конкретное системное свойство. С другой стороны, мы можем добавить все свойства:

Теперь мы знаем, что мы можем использовать аннотацию @Value для методов как глобальное значение или как значение параметра.

Поскольку конструкторы по сути являются методами, мы можем использовать аннотацию и в конструкторах:

Инъекция в Map

С SpEL мы можем сделать некоторые другие довольно интересные вещи в сочетании с аннотацией @Value . Например, давайте сделаем Map, представляет что indoor и outdoor хобби студента. Каждый из них может иметь несколько значений:

Теперь, чтобы ввести это, нам понадобится Map > :

Внедрение в списки

Если свойство имеет значения, разделенные запятыми, например, простой список книг, мы можем использовать SpEL для его интерпретации и преобразования в список:

Используя метод split() и разделяя для каждой запятой ( , ), мы можем вставить эти значения в список:

Вывод

Как только вы заканчиваете работу над реальным приложением, вы понимаете, что конфигурация является важной темой, и если вы используете Spring. Существует большая вероятность того, что вы уже используете или вам придется широко использовать аннотацию @Value .

Понимание этой базовой функциональности очень важно, потому что если вы этого не сделаете, вы можете использовать ее совершенно неправильно.

Источник

@value( $<> ) в spring не работает

Пишу приложение на java с использованием Spring. Нужно передать значение ключа из файла app.properties в поле класса. Передает null. Выскакивает NullPointerException, уже не знаю что и делать, помогите кто чем может

2 ответа 2

@Value(«$«) в твоём случае работает. Другое дело, что ты вызываешь private Pattern PRICE_REGEX = Pattern.compile(price); до того, как отработает @Value . Тебе надо перенести логику инициализации PRICE_REGEX в post-конструктор. На выходе должно получиться примерно так:

Ну или можно похитрить и использовать всю мощь SpEL

P.S. Как правильно заметил @Qwertiy, у тебя очень странное регулярное выражение для цены, быть может тебе больше подойдёт 1*([.]1<1,2>)?

Добавь аннотацию @PropertySource(«classpath:app.properties») .

Всё ещё ищете ответ? Посмотрите другие вопросы с метками java xml spring или задайте свой вопрос.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.10.15.40479

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник

Аннотация @Value не работает должным образом в Spring Boot?

КОНТЕКСТ:

Я обрабатываю отчеты с аннотацией @Scheduled и когда вызывается свойство Component from Service не инициализируется аннотацией @Value даже если оно физически существует в .properties и распечатывается в @PostConstruct .

ОПИСАНИЕ:

Интерфейс ReportProcessor и реализация InventoryReportProcessor :

Я использую это из

Моя путаница связана с тем фактом, что @Value в Service работает нормально, но в @Component возвращает @Component если не вызывается в @PostConstruct . Кроме того, если вызов @PostConstruct значение все еще остается null в остальной части кода класса.

Я нашел похожие и я занимался исследованиями в документах Srping, но до сих пор не было единой идеи, почему это работает таким образом и что может быть решением?

Всего 3 ответа

Вам нужно автоматически связать компонент, чтобы приложение Spring узнало о нем.

Инъекция поля выполняется после того, как объекты построены, так как, очевидно, контейнер не может установить свойство чего-то, что не существует

в момент System.out.println (destinationFileToSave); значения триггеров не вводятся;

если вы хотите, чтобы это работало, попробуйте что-то вроде этого

@PostConstruct работает так, как его вызывают после создания объекта.

Spring будет анализировать @Value аннотации @Value на известных им bean-компонентах. Код, который вы используете, создает экземпляр класса вне области Spring, и поэтому Spring ничего с этим не сделает. Одна вещь, которую вы можете сделать, это создать экземпляр явно или использовать Autowire:

tl: dr. Если вы правильно настроили контекст приложения, то @Value не может быть нулевым, так как это остановит корректный запуск вашего приложения.

Источник

Урок 2: Введение в Spring IoC контейнер

Этот урок освещает работу с Spring Framework IoC контейнером и основан на оригинальной документации §5. The IoC container.

Что вы создадите

Вы создадите некоторое количество классов, в которых будет рассмотрена функциональность Spring Framework IoC контейнера.

Что вам потребуется

Настройка проекта

Прежде чем вы начнете изучать этот урок, вам необходимо внести некоторые изменения в проект. Для начала создайте структуру папок src/main/resources и переместите в него файл настроек логгирования log4j.properties , тем самым поместив его в classpath проекта. Теперь немного измените файл сборки pom.xml , добавив и изменив в нем следующее:

И наконец, создайте структуру папок src/main/java/lessons/starter/ . В данном пакете вы будете создавать классы с методами public static void main(String[] args) , которые вы будете запускать для того, чтобы можно было видеть результаты действий в процессе изучения данного материала.

Введение

Inversion of Control (IoC), также известное как Dependency Injection (DI), является процессом, согласно которому объекты определяют свои зависимости, т.е. объекты, с которыми они работают, через аргументы конструктора/фабричного метода или свойства, которые были установлены или возвращены фабричным методом. Затем контейнер inject(далее «внедряет») эти зависимости при создании бина. Этот процесс принципиально противоположен, поэтому и назван Inversion of Control, т.к. бин сам контролирует реализацию и расположение своих зависимостей, используя прямое создание классов или такой механизм, как шаблон Service Locator.

Основными пакетами Spring Framework IoC контейнера являются org.springframework.beans и org.springframework.context . Интерфейс BeanFactory предоставляет механизм конфигурации по управлению любым типом объектов. ApplicationContext — наследует нитерфейс BeanFactory и добавляет более специфичную функциональность. Ниже в таблице представлены различия между ними:

В большинстве случаев предпочтительно использовать ApplicationContext , поэтому в дальнейшем будет использоваться только он и его реализации. Поскольку он включает в себя всю функциональность BeanFactory , его можно и нужно использовать, за исключением случаев, когда приложение запускается на устройствах с ограниченными ресурсами, в которых объем потребляемой памяти может быть критичным, даже в пределах нескольких килобайт, либо когда вы разрабатываете приложение, в котором необходима поддержка совместимости со сторонними библиотеками, использующими JDK 1.4 или не поддерживают JSR-250. Spring Framework активно использует BeanPostProcessor для проксирования и др., поэтому, если вам необходима поддержка такой функциональности, как AOP и транзакций, то при использовании BeanFactory необходимо добавить вручную регистрацию BeanPostProcessor и BeanFactoryPostProcessor , как показано ниже:

Описание работы IoC контейнера

Ниже представлена диаграмма, отражающая, как работает Spring. Ваши классы приложения совмещаются с метаданными конфигурации, в результате чего будет создан и инициализирован ApplicationContext , а на выходе вы получите полностью настроенное и готовое к выполнению приложение.

ApplicationContext представляет собой Spring IoC контейнер и необходим для инициализации, настройки и сборки бинов для построения приложения.

В метаданных конфигурации разработчик описывает как инициализировать, настроить IoC контейнер и собрать объекты в вашем приложении. В данном и других уроках этого цикла везде, где возможно, будет использоваться подход на основе аннотаций и Java-конфигурации. Если вы сторонник XML-конфигурации, либо хотите посмотреть как делать тоже самое через XML, обратитесь к оригинальной документации по Spring Framework или соответствующего модуля/проекта.

Настройка IoC контейнера

Основными признаками и частями Java-конфигурации IoC контейнера являются классы с аннотацией @Configuration и методы с аннотацией @Bean . Аннотация @Bean используется для указания того, что метод создает, настраивает и инициализирует новый объект, управляемый Spring IoC контейнером. Такие методы можно использовать как в классах с аннотацией @Configuration , так и в классах с аннотацией @Component (или её наследниках). Класс с аннотацией @Configuration говорит о том, что он является источником определения бинов. Самая простейшая из возможных конфигураций выглядит следующим образом:

Для того, чтобы приступить к настройке и изучению Spring IoC контейнера, вы должны инициализировать ApplicationContext , который поможет также с разрешением зависимостей. Для обычной Java-конфигурации применяется AnnotationConfigApplicationContext , в качестве аргумента к которому передается класс, либо список классов с аннотацией @Configuration , либо с любой другой аннотацией JSR-330, в том числе и @Component :

Как вариант, можно инициализировать контекст(ы) таким образом:

Использование @Bean аннотации

Как упоминалось выше, для того, чтобы объявить Bean-объект(далее просто бин), достаточно указать аннотацию @Bean тому методу, который возвращает тип бина как в классах с аннотацией @Configuration , так и в классах с аннотацией @Component (или её наследниках). Например, определим интерфейс какого-нибудь сервиса и его реализацию:

Теперь, для того, чтобы объект с типом GreetingService был доступен для использования, необходимо описать его в конфигурации следующим образом:

А для того, чтобы использовать его, достаточно выполнить следующее:

Метод getBean() может принимать в качестве аргумента как класс(как показано выше), так и названия бина(подробнее будет рассмотрено ниже), либо другие варианты, с которыми вы можете ознакомится в документации. Однако такой подход не рекомендуется использовать в production-конфигурациях, т.к. для подобных целей существует механизм Dependency Injection (DI), собственно говоря, для чего и предназначен Spring IoC контейнер. Использование DI будет рассмотрено ниже в отдельной главе.

По умолчанию, так, как будет назван метод определения бина, по такому имени и нужно получать бин через метод getBean() или автоматическое связывание. Однако вы можете переопределить это имя или указать несколько псевдонимов, через параметр name аннотации @Bean . Выглядеть это будет примерно так:

Иногда полезно предоставить более подробное описание бина, например, в целях мониторинга. Для этого существует аннотация @Description :

Жизненный цикл бина

Для управления контейнером жизненным циклом бина, вы можете реализовать метод afterPropertiesSet() интерфейса InitializingBean и метод destroy() интерфейса DisposableBean . Метод afterPropertiesSet() позволяет выполнять какие-либо действий после инициализации всех свойств бина контейнером, метод destroy() выполняется при уничтожении бина контейнером. Однако их не рекомендуется использовать, поскольку они дублируют код Spring. Как вариант, предпочтительно использовать методы с JSR-250 аннотациями @PostConstruct и @PreDestroy . Также существует вариант определить аналогичные методы как параметры аннотации @Bean , например так: @Bean(initMethod = «initMethod», destroyMethod = «destroyMethod») .В качестве примера применения данных методов, интерфейсов и аннотаций вы можете ознакомиться в классе GreetingServiceImpl .

При совместном использовании методов, интерфейсов и аннотаций, описанных выше, учитывайте их порядок вызовов. Для методов инициализации порядок будет следующий:

• Методы с аннотациями @PostConstruct в порядке их определения в классе
• Метод afterPropertiesSet()
• Метод, указанный в параметре initMethod аннотации @Bean

Для методов разрушения порядок будет следующий:

• Методы с аннотациями @PreDestroy в порядке их определения в классе
• Метод destroy()
• Метод, указанный в параметре destroyMethod аннотации @Bean

Если вам необходимо реализовать свою собственную модель жизненного цикла бина, то в таком случае бин должен реализовывать один из интерфейсов, приведенных ниже:

SmartLifecycle интересен тем, что наследует интерфейс Phased , в котором есть метод int getPhase(); . Суть в том, что порядок создания бинов, реализующих этот интерфейс, зависит от возвращаемого методом значения и чем оно меньше, тем раньше всех будет создан бин и тем позже он будет разрушен.

Если вы на данном этапе запустите Starter.java , то в логах увидите, что методы разрушения не вызываются, однако программа завершает свою работу корректно. Дело в том, что для обычных приложений для этих целей стоит инициализировать контекст с типом AbstractApplicationContext , который также реализует ApplicationContext и имеет метод registerShutdownHook() . В итоге, у вас должно быть премерно следующее:

После этого у вас появятся результаты работы методов при разрушении бина. Однако стоит заметить ещё раз, что это относится к обычным приложения, не относящимся к web-приложения(поскольку для них применяется отдельный тип контекста и подобный метод в них уже есть).

В некоторых случаях необходимо производить манипуляции с ApplicationContext ‘ом, например, в самом бине. Для этого существуют интерфейсы *Aware , полный список которых приведен в таблице 5.4 документации. Поэтому когда ApplicationContext создает экземпляр бина, он учитывает соответствующий интерфейс и передает ссылку на соответствующий ресурс.

Как было описано выше, Spring IoC контейнеру требуются метаданные для конфигурации. Одну из таких аннотаций мы уже рассмотрели, это @Bean , рассмотрим теперь и другие.

Другой основной аннотацией является @Component , а также её наследники @Repository , @Service и @Controller . Все они являются общими шаблонами для любых компонентов, управляемыми контейнеером. @Repository , @Service и @Controller рекомендуется использовать в тех случаях, когда вы можете отнести аннотируемый класс к определенному слою, например DAO, либо когда вам необходима поддержка функциональности, которую предоставляет аннотация. Также эти аннотации могут иметь дополнительный смысл в будущих версиях Spring Framework. В остальных же случаях достаточно использовать аннотацию @Component .

Для того, чтобы ваша конфигурация могла знать о таких компонентах и вы могли бы их использовать, существует специальная аннотация для класса вашей конфигурации @ComponentScan .

По умолчанию, такая конфигурация сканирует на наличие классов с аннотацией @Component и его потомков в том пакете, в котором сама находится, а также в подпакетах. Однако, если вы хотите, чтобы сканирование было по определенным каталогам, то это можно настроить, просто добавив в аннотацию @ComponentScan параметр basePackages с указанием одного или нескольких пакетов. Выглядеть это будет примерно таким образом: @ComponentScan(basePackages = «lessons.services») , а классу GreetingServiceImpl при этом необходимо добавить аннотацию @Component .

Стоит упомянуть ещё одну мета-аннотацию @Required . Данная аннотация применяется к setter-методу бина и указывает на то, чтобы соответствующее свойство метода было установлено на момент конфигурирования значением из определения бина или автоматического связывания. Если же значение не будет установлено, будет выброшено исключение. Использование аннотации позволит избежать NullPointerException в процессе использования свойства бина. Пример использования:

Области видимости(scopes) бинов

Когда вы создаете определение бинов, вы вы создаете рецепт для создания экземпляров класса, который определяет бин. Важно понять, что определение бинов является рецептом, потому что он означает, какого класса вы можете создать множество экземпляров по этому рецепту.

Вы можете контролировать не только какие зависимости и значения конфигурации вы можете подключить в объекте, который создан из определения бина, но также область видимости из того же определения бина. Это мощный и гибкий подход, при котором вы можете выбрать область видимости создаваемых объектов. Изначально, Spring Framework поддерживает несколько вариантов, некоторые доступны, только если вы используете web-aware ApplicationContext . Также вы можете создать свою собственную облать видимости. Ниже приведен список областей видимостей, описанных в документации на момент написания урока:

• singleton — По умолчанию. Spring IoC контейнер создает единственный экземпляр бина. Как правило, используется для бинов без сохранения состояния(stateless)
• prototype — Spring IoC контейнер создает любое количество экземпляров бина. Новый экземпляр бина создается каждый раз, когда бин необходим в качестве зависимости, либо через вызов getBean() . Как правило, используется для бинов с сохранением состояния(stateful)
• request — Жизненный цикл экземпляра ограничен единственным HTTP запросом; для каждого нового HTTP запроса создается новый экземпляр бина. Действует, только если вы используете web-aware ApplicationContext
• session — Жизненный цикл экземпляра ограничен в пределах одной и той же HTTP Session . Действует, только если вы используете web-aware ApplicationContext
• global session — Жизненный цикл экземпляра ограничен в пределах глобальной HTTP Session (обычно при использовании portlet контекста). Действует, только если вы используете web-aware ApplicationContext
• application — Жизненный цикл экземпляра ограничен в пределах ServletContext . Действует, только если вы используете web-aware ApplicationContext

С более подробной информацией о настройке приложения для применения областей видимости request , session , global session и application вы можете ознакомиться в документации. Пример реализации собственной области видимости будет рассмотрено в отдельном уроке.

Для того, чтобы указать область видимости бина, отличный от singleton , необходимо добавить аннотацию @Scope(«область_видимости») методу объявления бина или классу с аннотацией @Component :

Использование @Configuration аннотации

Как упоминалось выше, классы с аннотацией @Configuration указывают на то, что они являются источниками определения бинов, public-методов с аннотацией @Bean .

Кода бин имеет зависимость от другого бина, то зависимость выражается просто как вызов метода:

Однако работает такое взаимодействие только в @Configuration -классах, в @Component -классах такое не работает.

Представим теперь ситуацию, когда у вас есть бин с областью видимости singleton , который имеет зависимость от бина с областью видимости prototype .

Большая часть приложений строится по модульной архитектуре, разделенная по слоям, например DAO, сервисы, контроллеры и др. Создавая конфигурацию, можно также её разбивать на составные части, что также улучшит читабельность и панимание архитектуры вашего приложения. Для этого в конфигурацию необходимо добавить аннотацию @Import , в параметрах которой указываются другие классы с аннотацией @Configuration , например:

Таким образом, при инициализации контекста вам не нужно дополнительно указывать загрузку из конфигурации AnotherConfiguration , все останется так, как и было:

В большинстве случаев, имеются такие случаи, когда бин в одной конфигурации имеет зависимость от бина в другой конфигурации. Поскольку конфигурация является источником определения бинов, то разрешить такую зависимость не является проблемой, достаточно объявить поле класса конфигурации с аннотацией @Autowired (более подробно оисано в отдельной главе):

При этом LessonsConfiguration остается без изменений:

Классы с аннотацией @Configuration не стремятся на 100% заменить конфигурации на XML, при этом, если вам удобно или имеется какая-то необходимость в использовании XML конфигурации, то к вашей Java-конфигурации необходимо добавить аннотацию @ImportResource , в параметрах которой необходимо указать нужное вам количество XML-конфигураций. Выглядит это следующим способом:

Процесс разрешения зависимостей

IoC контейнер выполняет разрешение зависимостей бинов в следующем порядке:

• Создается и инициализируется ApplicationContext с метаданными конфигурации, которые описывают все бины. Эти метаданные могут быть описаны через XML, Java-код или аннотации
• Для каждого бина и его зависимостей вычисляются свойства, аргументы конструктора или аргументы статического фабричного метода, либо обычного(без аргументов) конструктора. Эти зависимости предоставляются бину, когда он(бин) уже создан. Сами зависимости инициализируются рекурсивно, в зависимости от вложенности в себе других бинов. Например, при инициализации бина А, котый имеет зависимость В, а В зависит от С, сначала инициализируется бин С, потом В, а уже потом А
• Каждому свойству или аргументу конструктора устанавливается значение или ссылка на другой бин в контейнере
• Для каждого свойства или аргумента конструктора подставляемое значение конвертируется в тот формат, который указан для свойства или аргумента. По умолчанию Spring может конвертировать значения из строкового формата во все встроенные типы, такие как int , long , String , boolean и др.

Spring каждый раз при создании контейнера проверяет конфигурацию каждого бина. И только бины с областью видимости(scope) singleton создаются сразу вместе со своими зависимостями, в отличие от остальных, которые создаются по запросу и в соответствии со своей областью видимости. В случае цикличной зависимости(когда класс А требует экземпляр В, а классу В требуется экземпляр А) Spring IoC контейнер обнаруживает её и выбрасывает исключение BeanCurrentlyInCreationException .

Spring контейнер может разрешать зависимости между бинами через autowiring(далее, автоматическое связывание). Данный механизм основан на просмотре содержимого в ApplicationContext и имеет следующие преимущества:

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

Для того, чтобы воспользоваться механизмом автоматического связывания, Spring Framework предоставляет аннотацию @Autowired . Примеры применения приведены ниже:

Т.к. кандидатов для автоматического связывания может быть несколько, то для установки конкретного экземпляра необходимо использовать аннотацию @Qualifier , как показано ниже. Данная аннотация может быть применена как к отдельному полю класса, так и к отдельному аргументу метода или конструктора:

Соответственно, у одной из реализации GreetingService должна быть установлена соответствующая аннотация @Qualifier :

Spring также поддерживает использование JSR-250 @Resource аннотации автоматического связывания для полей класса или параметров setter-методов:

Использование стандартных JSR-330 аннотаций

Spring Framework поддерживает JSR-330 аннотации. Эти аннотации работают таким же способом, как и Spring аннотации. Для того, чтобы работать с ними, необходимо добавить в pom.xml следующую зависимость:

Ниже приведена таблица сравнения JSR-330 и Spring аннотаций для DI:

Источник