qualifier spring что это
Что мы делаем не так со Спрингом
В этой заметке хочу поделится наблюдениями о некоторых антипаттернах, встречающихся в коде приложений, работающих на Спринге. Все из них так или иначе всплывали в живом коде: либо я натыкался на них в уже существующих классах, либо вылавливал во время вычитки творчества коллег.
Надеюсь, вам будет интересно, а если после прочтения вы осознаете свои «грехи» и встанете на путь исправления, то я буду доволен вдвойне. Также призываю вас поделится своими собственными примерами в комментария, наиболее любопытные и необычные добавим в запись.
Autowired
Великий и ужасный @Autowired — это целая эпоха в Спринге. Без него до сих пор не обойтись при написании тестов, но в основном коде он (ПМСМ) явно лишний. В нескольких моих последних проектах его не было вовсе. Долгое время мы писали вот так:
Причины, по которым внедрение зависимостей через поля и сеттеры подвергаются критике, уже подробно описывались, в частности здесь. Альтернатива — внедрение через конструктор. По приведённой ссылке, описан такой пример:
Он выглядит более-менее прилично, но представьте, что зависимостей у нас штук 10 (да-да, я знаю, что в этом случае их нужно группировать по отдельным классам, но сейчас речь не об этом). Картинка получается уже не столь привлекательной:
Код прямо скажем, выглядит монструозненько.
Статические методы в утилитных классах и enum-функции
В кровавом Э часто стоит задача преобразования объектов-носителей данных из одного слоя приложения, в подобные объекты другого слоя. Для этого до сих пор (напоминаю, на дворе 2019 год) используются утилитные классы со статическими методами вроде такого:
Более продвинутые пользователи, читавшие умные книги, знают про волшебные свойства перечислений:
Правда, и в этом случае обращение всё равно происходит к объекту-одиночке, а не к компоненту, управляемому Спрингом.
Ещё более продвинутые парни (и девушки) знают про MapStruct, позволяющий описать всё в виде одного-единственного интерфейса:
Вот теперь мы получает спринговый компонент. Вроде победа. Но дьявол в мелочах, и бывает, что победа становится перемогой. Во-первых, именования полей должны быть одинаковы (иначе начинается геморрой), что не всегда удобно, во-вторых, при наличии каких-либо сложных преобразований полей обрабатываемых объектов возникают дополнительные сложности. Ну и сам mapstruct нужно добавлять в зависимости.
И мало кто вспоминает дедовский, но тем не менее простой и рабочий способ получить управляемый спрингом преобразователь:
Преимущество здесь в том, что в другом классе мне достаточно написать
и Спринг самостоятельно всё разрулит!
Ненужный Qualifier
Случай из жизни: приложение работает с двумя БД. Соответственно, есть два источника данных ( java.sql.DataSource ), два менеджера транзакций, две группы репозиториев и т.д. Всё это удобно описать в двух отдельных настройках. Вот это для Постгре:
javax.inject.Provider
Как получить бин с областью действия prototype? Часто мне попадалось вот это
А ведь Спринг давным давно умеет делать то же самое без сторонних зависимостей! Достаточно заменить javax.inject.Provider::get на org.springframework.beans.factory.ObjectFactory::getObject и всё работает точно так же.
Теперь мы можем с чистой совестью выпилить javax.inject из списка зависимостей.
Использование строк вместо классов в настройках
Здесь мы явно прописываем пакет, который будет просматриваться Спрингом. Если мы допустим очепятку в именовании, то приложение упадёт при запуске. Хочется выявлять подобные глупые ошибки на ранних этапах, в пределе — прямо во время правки кода. Фреймворк идёт нам навстречу, поэтому код выше можно переписать:
Здесь AuditRepository — один из репозиториев пакета, который мы будем просматривать. Т. к. мы указали класс, то нам потребуется подключить этот класс к нашей конфигурации, и теперь опечатки будут выявляться прямо в редакторе или на худой конец при сборке проекта.
Этот подход можно применить во многих похожих случаях, например:
но лучше использовать явный тип:
А когда есть нечто вроде
то стоит обратить внимание, что метод packages() перегружен и использовать классы: 
Не кладите все бины в один пакет
Думаю, во многих проектах на Спринге/Спринг Буте вы видели подобную структуру:
Здесь Application.java — это корневой класс приложения:
Это классический код микросервиса: составляющие разложены по папочкам согласно назначению, в корне лежит класс с настройками. Пока проект небольшой, то всё хорошо. По мере разрастания проекта возникают жирненькие пакеты с десятками репозиториев/сервисов. И если проект так и останется монолитом, то б-г с ними. А вот если встанет задача разделить раскабаневшее приложение на части, тут-то и начинаются вопросы. Один раз испытав эту боль я решил применить другой подход, а именно группировать классы по их домену. В итоге получается что-то вроде
Здесь пакет user включает в себя подпакеты с классами, ответственными за логику пользователей:
Теперь в UserConfig можно описать все настройки, связанные с данным функционалом:
На этом всё, я надеюсь, моё творчество оказалось для вас полезным. Описывайте в комментариях ваши антипаттерны, будем разбираться вместе 🙂
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, @Qualifier и @Primary аннотации
1. Использование аннотации @Autowired
Продолжить вышеГлубокое понимание аннотации @ComponentScan аннотации SpringВ этом примере нам нужно вызвать связанные с UserDao операции в UserService, после чего мы можем добавить следующий код в UserService:
Код теста следующий:
Результаты приведены ниже:
По результатам бега мы можем найтиuserDao успешно внедрен в UserServiceбинго
Допустим, в бизнесе есть ситуация, в которой UserDaoУслуги третьих сторон, Мы не можем гарантировать, что он может быть успешно добавлен в контейнер пружины,Тогда мы не сможем сделать всю нашу службу UserService недоступной, потому что UserDao не удалось внедрить в контейнер Spring., Здесь мы продемонстрируем эту ситуацию, следующим образом закомментируя аннотацию @Repository для UserDao:
В это время вы сообщите о следующей ошибке при запуске тестового класса:
На самом деле это очень просто. Сейчас нам просто нужно@Autowired аннотацияДобавьте следующие атрибуты:
Запустите тестовый класс еще раз, и вы обнаружите, что ошибка исчезла, но на данный момент userDao имеет значение null, как показано ниже:
2. Использование аннотации @Qualifier
Измените код UserDao следующим образом:
В то же время добавьте конфигурацию @Bean UserDao в класс конфигурации следующим образом:
Результаты запуска тестового класса следующие:
Мы можем обнаружить, что в настоящее время используется отсканированный UserDao по умолчанию. В это время мы меняем UserDao, введенный в UserService, на следующее:
Продолжаем запускать тестовый класс, результаты будут следующими:
Из приведенных выше результатов работы мы можем обнаружить, что при наличии нескольких bean-компонентов одного типа значение по умолчаниюВвести согласно соответствующему имени bean-компонентаДа, если мы не хотим использовать метод внедрения Spring по умолчанию в настоящее время, но хотим указать фиксированный компонент в соответствии с потребностями нашего бизнеса, то естьАннотация @QualifierСпектакль выглядит следующим образом:
В настоящее время, независимо от того, какое имя определяет ваш UserDao, всегда будет внедряться только userDao.
3. Использование аннотации @Primary
Из-за чистоты или чего-то еще, некоторые студенты могут не особенно любить использовать аннотацию @Qualifier, тогда это не имеет значения, spring также предоставляет нам другую аннотацию @Primary, которая также может выполнять указанные выше функции.
В это время запустите тестовый класс, и вы обнаружите, что UserService внедрил userDao2
Примечание. В настоящее время UserDao в UserService больше не может добавлять аннотации, соответствующие @Qualifier.
Выбор бина для внедрения: @Qualifier, @Named, @Resource
В больших приложениях, основанных на Spring (или любом другом IoC фреймворке), может наступить такой день, когда при внедрении зависимостей образуется неоднозначность: одной зависимости удовлетворяет сразу несколько бинов, ведь выбор производится по совместимости типов внедряемого и запрашиваемого бинов. Что же тогда произойдёт?
Подготовка
Нам понадобится многомодульный пустой maven проект с Spring и JUnit:
В проекте создадим интерфейс и две его реализации:
Неоднозначные бины
Для начала я бы хотел посмотреть, что жё всё таки будет, если мы объявим конкурс «Два бина на одно место» 🙂 Поскольку Spring поддерживает несколько аннотаций для связывания зависимостей, я решил попробовать их все:
Код, который неоднозначен:
И тестовый класс к нему. Так как тесты отличаются только именем пакета и именем тестируемого класса, достаточно будет показать лишь один:
Результат исполнения немного предсказуем:
Неявный выбор бина по имени
Одно из самых простых решений, это намекнуть Spring’у, какой бин нам нужен, используя имена полей.
Каждый бин в Spring context имеет своё имя. Это име порождается либо из имени класса, либо явно задаётся в xml и grovvy конфигах, либо берётся из имени функции создания бина в java config.
Если мы назовём поле с неоднозначным типом бина по имени бина, Spring сможет самостоятельно сделать правильным выбор:
Неявное определение типа по имени работает со всеми аннотациями:
Явное указание бина по имени
Для тех, кто не любит ‘convention-over-configuration’, в Spring есть аннотация @Qualifier, позволяющая явно задать имя нужного бина:
Тесты остаются теми же самыми и точно так же проходят:
@Qualifier и задание бина по типу
Для использования этой аннотации вначале нужно определить собственную аннотацию, уникальную для каждого бина:
И применить эту аннотацию и к классу бина и к зависимости:
@Named как другой способ указания бина по имени
JSR-330 помимо нового @Qualifier принёс и аналог старого, который называется @Named и ведёт себя аналогичным образом:
@Resource и всё ещё указание бина по имени
Нужно…больше…бинов…
На случай, если нужны одновременно все бины заданного типа, например когда точное имя бина неизвестно, можно внедрить их в коллекцию:
Порядок внедрения бинов не определён. Внедрение коллекции бинов работает со всеми аннотациями.
Заключение и рекомендации
С другой стороны, выбор между специализацией бина по имени или по типу упирается в вопрос удобства и безопасности. Специализация по типу, с @Qualified из JSR-330 однозначно связывает требуемый бин с его реализацией, но требует достаточно много подготовительного кода. Специализация по имени не требует код вообще, но может привести к неожиданным результатам, если имя будет не то или не у того бина.
Код примера доступен на github. Тесты модуля fail специально оставлены проваливающимися.
Руководство по аннотациям Spring Framework
Язык программирования Java обеспечивал поддержку аннотаций с Java 5.0 и выше. Ведущие платформы Java быстро приняли аннотации, и Spring Framework начал использовать аннотации из версии 2.5. Благодаря тому, как они определены, аннотации предоставляют много контекста в их объявлении.
До аннотаций поведение Spring Framework в основном контролировалось с помощью конфигурации XML. Сегодня использование аннотаций предоставляет нам огромные возможности в настройке поведения Spring Framework.
В этой статье мы рассмотрим аннотации, доступные в Spring Framework.
Основные Spring Framework Аннотации
@Необходимые
@Autowired
Эта аннотация применяется к полям, методам установки и конструкторам. В @Autowired аннотации впрыскивает объект зависимости неявно.
Когда вы используете @Autowired поля и передаете значения для полей, используя имя свойства, Spring автоматически назначает поля с переданными значениями.
Вы даже можете использовать @Autowired частные объекты, как показано ниже. (Это очень плохая практика!)
Когда вы используете @Autowired методы установки, Spring пытается выполнить это, набрав autowiring для этого метода. Вы указываете Spring, что оно должно инициировать это свойство, используя метод установки, в котором вы можете добавить свой собственный код, например, инициализировать любое другое свойство этим свойством.
Рассмотрим сценарий, в котором вам нужен экземпляр класса A, но вы не храните A в поле класса. Вы просто используете A для получения экземпляра B и сохраняете B в этом поле. В этом случае сеттер методом автопроводки подойдет вам лучше. У вас не будет неиспользуемых полей на уровне класса.
Когда вы используете @Autowired конструктор, тогда внедрение конструктора происходит во время создания объекта. Он сообщает конструктору об автоматической передаче при использовании в качестве компонента. Здесь следует заметить, что только один конструктор из любого класса бинов может нести @Autowired аннотацию.
ПРИМЕЧАНИЕ. Начиная с весны 4.3, @Autowired стало необязательным для классов с одним конструктором. В приведенном выше примере Spring по-прежнему внедрит экземпляр класса Person, если вы опустите @Autowired аннотацию.
@Qualifier
Эта аннотация используется вместе с @Autowired аннотацией. Когда вам нужно больше контроля над процессом внедрения зависимости, @Qualifier можно использовать. @Qualifier может быть указано в отдельных аргументах конструктора или параметрах метода. Эта аннотация используется, чтобы избежать путаницы, которая возникает, когда вы создаете несколько бинов одного типа и хотите связать только один из них со свойством.
Рассмотрим пример, где интерфейс BeanInterface реализуется двумя bean-компонентами, BeanB1 и BeanB2.
Теперь, если BeanA автоматически подключит этот интерфейс, Spring не будет знать, какую из двух реализаций внедрить.
Одним из решений этой проблемы является использование @Qualifier аннотации.
С @Qualifier добавленной аннотацией Spring теперь будет знать, какой bean-компонент нужно связать автоматически, а где beanB2 имя BeanB2.
@Configuration
Эта аннотация используется для классов, которые определяют bean-компоненты. @Configuration является аналогом файла конфигурации XML — он настраивается с использованием классов Java. Класс Java с @Configuration пометкой сам по себе является конфигурацией и будет иметь методы для создания экземпляров и настройки зависимостей.
@ComponentScan
Эта аннотация используется вместе с @Configuration аннотацией, чтобы Spring мог узнать, какие пакеты сканируются для аннотированных компонентов. @ComponentScan также используется для указания использования базовых пакетов basePackageClasses или basePackage атрибутов для сканирования. Если конкретные пакеты не определены, сканирование будет выполняться из пакета класса, который объявляет эту аннотацию.
Эта аннотация используется для классов компонентов. По умолчанию все автосвязные зависимости создаются и настраиваются при запуске. Но если вы хотите лениво инициализировать бин, вы можете использовать @Lazy аннотацию над классом. Это означает, что bean-компонент будет создан и инициализирован только при первом запросе. Вы также можете использовать эту аннотацию на @Configuration занятиях. Это указывает на то, что все @Bean методы в пределах этого @Configuration должны быть лениво инициализированы.
@Значение
Spring Framework Аннотации стереотипов
@Компонент
@Controller
@Controller Аннотаций используется для указания класса является контроллером Спринг. Эта аннотация может использоваться для идентификации контроллеров для Spring MVC или Spring WebFlux.
@Обслуживание
Эта аннотация используется в классе. @Service помечает класс Java, который выполняет некоторую услугу, такую как выполнение бизнес-логики, выполнение вычислений и вызов внешних API. Эта аннотация является специализированной формой @Component аннотации, предназначенной для использования на сервисном уровне.
@Repository
Spring Boot Annotations
@EnableAutoConfiguration
Эта аннотация обычно помещается в основной класс приложения. @EnableAutoConfiguration Аннотацию неявно определяет базу «поиск пакетов». Эта аннотация говорит Spring Boot начинать добавление bean-компонентов на основе настроек пути к классам, других bean-компонентов и различных настроек свойств.
@SpringBootApplication
Эта аннотация используется в классе приложения при настройке проекта Spring Boot. Класс, помеченный знаком, @SpringBootApplication должен храниться в базовом пакете. Единственное, что @SpringBootApplication делает, — это компонентное сканирование. Но он будет сканировать только свои подпакеты. Например, если вы поместите аннотированный класс @SpringBootApplication в com.example, он @SpringBootApplication будет сканировать все его подпакеты, такие как com.example.a, com.example.b и com.example.ax.
Это @SpringBootApplication удобная аннотация, которая добавляет все следующее:
Spring MVC и REST Аннотации
@Controller
Эта аннотация используется в классах Java, которые играют роль контроллера в вашем приложении. @Controller Аннотаций позволяет автоопределение классов компонентов в пути к классам и автоматическим регистрации бин для них. Чтобы включить автоматическое обнаружение таких аннотированных контроллеров, вы можете добавить компонентное сканирование в вашу конфигурацию. Класс Java с комментариями @Controller способен обрабатывать несколько сопоставлений запросов.
Эта аннотация может использоваться с Spring MVC и Spring WebFlux.
@RequestMapping
Эта аннотация используется как на уровне класса, так и на уровне метода. @RequestMapping Аннотаций используется для отображения веб — запросов на конкретные классы обработчиков и обработчиков методов. Когда @RequestMapping используется на уровне класса, он создает базовый URI, для которого будет использоваться контроллер. Когда эта аннотация используется для методов, она выдаст вам URI, для которого будут выполняться методы-обработчики. Отсюда можно сделать вывод, что сопоставление запросов на уровне класса останется прежним, тогда как у каждого метода-обработчика будет свое сопоставление запросов.
Иногда вам может потребоваться выполнить различные операции в зависимости от используемого метода HTTP, даже если URI запроса может оставаться прежним. В таких ситуациях вы можете использовать атрибут @RequestMapping метода со значением метода HTTP, чтобы сузить методы HTTP для вызова методов вашего класса.
Вот базовый пример того, как работает контроллер вместе с отображениями запросов:
Эта аннотация также может использоваться с Spring MVC и Spring WebFlux.
@CookieValue
Чтобы получить значение cookie, используйте @CookieValue следующим образом:
@CrossOrigin
Эта аннотация используется как на уровне класса, так и на уровне метода для разрешения запросов между источниками. Во многих случаях хост, обслуживающий JavaScript, будет отличаться от хоста, обслуживающего данные. В таком случае кросс-ресурсное совместное использование ресурсов (CORS) обеспечивает междоменную связь. Чтобы включить эту связь, вам просто нужно добавить @CrossOrigin аннотацию.
По умолчанию @CrossOrigin аннотация допускает все происхождение, все заголовки, методы HTTP, указанные в @RequestMapping аннотации, и maxAge 30 мин. Вы можете настроить поведение, указав соответствующие значения атрибута.
Пример использования @CrossOrigin на уровне методов контроллера и обработчика приведен ниже:
В этом примере, как getExample() и getNote() методы будут иметь MaxAge 3600 секунд. Кроме того, getExample() будут разрешены только запросы о происхождении с сайта http://example.com, а getNote() запросы всех источников — со всех узлов.
Составленные варианты @RequestMapping
Эти аннотации могут использоваться с Spring MVC и Spring WebFlux.
@GetMapping
@PostMapping
@PutMapping
@PatchMapping
@DeleteMapping
@ExceptionHandler
@InitBinder
@Mappings и @Mapping
@MatrixVariable
@PathVariable
@RequestAttribute
@RequestBody
Эта аннотация используется для аннотирования аргументов метода обработчика запроса. @RequestBody Аннотации указывает на то, что параметр метод должен быть связан с величиной тела запроса HTTP. HttpMessageConveter Отвечает за преобразование из сообщения запроса HTTP на объект.
@RequestHeader
Эта аннотация используется для аннотирования аргументов метода обработчика запроса. @RequestHeader Аннотаций используется для отображения параметра контроллера к значению заголовка запроса. Когда Spring отображает запрос, @RequestHeader проверяет заголовок с именем, указанным в аннотации, и связывает его значение с параметром метода-обработчика. Эта аннотация поможет вам получить подробности заголовка в классе контроллера.
@RequestParam
Эта аннотация используется для аннотирования аргументов метода обработчика запроса. Иногда вы получаете параметры в URL запроса, в основном в запросах GET. В этом случае, наряду с @RequestMapping аннотацией, вы можете использовать @RequestParam аннотацию, чтобы получить параметр URL и сопоставить его с аргументом метода. @RequestParam Аннотаций используется для связывания параметров запроса с параметром метода в контроллере.
@RequestPart
@ResponseBody
@ResponseStatus
@ControllerAdvice
@RestController
@RestControllerAdvice
@SessionAttribute
Эта аннотация используется на уровне параметров метода. @SessionAttribute Аннотаций используется для связывания параметра метода в атрибут сеанса. Эта аннотация обеспечивает удобный доступ к существующим или постоянным атрибутам сеанса.
@SessionAttributes
Рассмотрим этот пример:
@ModelAttribute Имя присваивается в @SessionAttributes качестве значения. @SessionAttributes Состоит из двух элементов. Элемент value — это имя сеанса в модели, а элемент types — это тип атрибутов сеанса в модели.
Spring Cloud Аннотации
@EnableConfigServer
Эта аннотация используется на уровне класса. При разработке проекта с несколькими службами вам необходимо иметь централизованный и простой способ настройки и извлечения конфигураций всех служб, которые вы собираетесь разрабатывать. Одним из преимуществ использования централизованного сервера конфигурации является то, что вам не нужно нести бремя запоминания того, где каждая конфигурация распределена по нескольким и распределенным компонентам.
Вы можете использовать @EnableConfigServer аннотацию Spring Cloud для запуска сервера конфигурации, с которым могут общаться другие приложения.
@EnableEurekaServer
Эта аннотация применяется к классам Java. Одна из проблем, с которой вы можете столкнуться при декомпозиции вашего приложения на микросервисы, заключается в том, что каждому сервису становится трудно узнать адрес каждого другого сервиса, от которого он зависит. Приходит служба обнаружения, которая отвечает за отслеживание местоположения всех других микросервисов.
@EnableDiscoveryClient
Эта аннотация применяется к классам Java. Чтобы указать любому приложению регистрироваться в Eureka, вам просто нужно добавить @EnableDiscoveryClient аннотацию к точке входа приложения. Приложение, которое теперь зарегистрировано в Eureka, использует абстракцию клиента Spring Cloud Discovery для опроса реестра для своего собственного хоста и порта.
@EnableCircuitBreaker
Эта аннотация применяется к классам Java, которые могут действовать как прерыватель цепи. Схема автоматического выключателя может позволить микросервису продолжать работу при сбое связанной службы, предотвращая каскадный сбой. Это также дает сбойному сервису время для восстановления.
Класс с пометкой @EnableCircuitBreaker будет контролировать, размыкать и замыкать автоматический выключатель.
@HystrixCommand
Эта аннотация используется на уровне метода. Библиотека Hyfrix от Netflix обеспечивает реализацию шаблона прерывателя цепи. Когда вы применяете автоматический выключатель к методу, Hystrix отслеживает сбои метода. Как только сбои нарастают до порогового значения, Hystrix открывает канал, так что последующие вызовы также не срабатывают. Теперь Hystrix перенаправляет вызовы метода, и они передаются указанным резервным методам.
Hystrix ищет любой метод, аннотированный @HystrixCommand аннотацией, и помещает его в прокси-сервер, подключенный к автоматическому выключателю, чтобы Hystrix мог отслеживать его.
Рассмотрим следующий пример:
Spring Framework DataAccess Аннотации
@Transactional
Эта аннотация помещается перед определением интерфейса, методом на интерфейсе, определением класса или открытым методом на классе. Простого присутствия @Transactional недостаточно для активации транзакционного поведения. Это @Transactional просто метаданные, которые могут использоваться некоторой инфраструктурой времени выполнения. Эта инфраструктура использует метаданные для настройки соответствующих компонентов с поведением транзакций.
Аннотация также поддерживает конфигурацию, такую как:
Аннотации на основе кэша
@Cacheable
Эта аннотация используется для методов. Самый простой способ включить поведение кеша для метода — это пометить его @Cacheable и параметризировать его именем кеша, в котором будут храниться результаты.
В приведенном выше фрагменте метод getAddress связан с кешем с именами адресов. Каждый раз, когда вызывается метод, кэш проверяется, чтобы увидеть, был ли вызов уже выполнен и не должен повторяться.
@CachePut
Эта аннотация используется для методов. Всякий раз, когда вам нужно обновить кэш, не мешая выполнению метода, вы можете использовать @CachePut аннотацию. То есть метод всегда будет выполняться, а результат кэшируется.
Использование @CachePut и @Cacheable использование одного и того же метода категорически не рекомендуется, поскольку первый вызывает выполнение для выполнения обновления кэша, а последний вызывает пропуск метода с использованием кэша.
@CacheEvict
Эта аннотация используется для методов. Дело не в том, что вы всегда хотите заполнять кеш все большим количеством данных. Иногда вам может понадобиться удалить некоторые данные из кэша, чтобы вы могли заполнить кэш некоторыми новыми значениями. В таком случае используйте @CacheEvict аннотацию.
Здесь, дополнительный элемент, allEntries используется вместе с именем кэша, который должен быть очищен. Он имеет значение true, поэтому он очищает все значения и готовится к хранению новых данных.
@CacheConfig
Эта аннотация является аннотацией на уровне класса. @CacheConfig Аннотаций позволяет упростить некоторые сведения о кэш — памяти на одном месте. Размещение этой аннотации в классе не включает никаких операций кэширования. Это позволяет хранить конфигурацию кеша на уровне класса, чтобы вам не приходилось объявлять что-либо несколько раз.
Выполнение задач и планирование аннотаций
@Запланированное
Эта аннотация является аннотацией уровня метода. @Scheduled Аннотаций используется на методах наряду с метаданными запуска. Метод с @Scheduled должен иметь возвращаемый тип void и не должен принимать никаких параметров.
Существуют разные способы использования @Scheduled аннотации:
В этом случае продолжительность между окончанием последнего выполнения и началом следующего выполнения является фиксированной. Задачи всегда ждут окончания предыдущего.
В этом случае начало выполнения задачи не ожидает завершения предыдущего выполнения.
Задание сначала выполняется с задержкой, а затем продолжается с указанной фиксированной скоростью.
@Async
@Async может использоваться как с пустыми методами возвращаемого типа, так и с методами, возвращающими значение. Однако методы с возвращаемыми значениями должны иметь возвращаемое значение типа Future.
Spring Framework Аннотации для тестирования
@BootstrapWith
@ContextConfiguration
Эта аннотация представляет собой аннотацию на уровне класса, которая определяет метаданные, используемые для определения, какие файлы конфигурации использовать для загрузки ApplicationContext теста. Более конкретно, @ContextConfiguration объявляет аннотированные классы, которые будут использоваться для загрузки контекста. Вы также можете указать Spring, где найти файл.
@WebAppConfiguration
@Timed
Эта аннотация используется для методов. @Timed Аннотации указывает на то, что аннотированный метод испытания должен завершить свое выполнение в определенный период времени (в миллисекундах). Если выполнение превышает указанное время в аннотации, тест не пройден.
В этом примере тест не пройден, если он превышает 10 секунд выполнения.
@Повторение
Эта аннотация используется в методах испытаний. Если вы хотите запустить тестовый метод несколько раз подряд автоматически, вы можете использовать @Repeat аннотацию. Количество раз, которое метод испытания должен быть выполнен, указано в аннотации.
В этом примере тест будет выполнен 10 раз.
@Commit
Эту аннотацию можно использовать как аннотацию как на уровне класса, так и на уровне метода. После выполнения тестового метода транзакция транзакционного метода может быть зафиксирована с использованием @Commit аннотации. Эта аннотация явно передает цель кода. При использовании на уровне класса эта аннотация определяет фиксацию для всех методов тестирования в классе. Когда объявляется как аннотация уровня метода, @Commit указывает фиксацию для определенных методов тестирования, переопределяющих фиксацию уровня класса.
@RollBack
При использовании на уровне класса эта аннотация определяет откат для всех методов тестирования в классе.
Когда объявляется как аннотация уровня метода, @RollBack указывает откат для определенных методов тестирования, переопределяя семантику отката на уровне класса.
@DirtiesContext
Эта аннотация используется как аннотация как на уровне класса, так и на уровне метода. @DirtiesContext указывает на то, что пружина ApplicationContext была каким-либо образом изменена или повреждена и должна быть закрыта. Это вызовет перезагрузку контекста перед выполнением следующего теста. ApplicationContext помечается как грязный до или после любого такого аннотированного метода, а также до или после текущего класса тестирования.
@BeforeTransaction
@AfterTransaction
@SqlConfig
@SqlGroup
@SpringBootTest
Эта аннотация используется для запуска контекста Spring для интеграционных тестов. Это откроет полный контекст автоконфигурации.
@DataJpaTest
Эта аннотация используется вместо @SpringBootTest.
@DataMongoTest
Это @DataMongoTest обеспечит минимальную автоконфигурацию и встроенную MongoDB для запуска интеграционных тестов с Spring Data MongoDB.
@WebMVCTest
Это @WebMVCTest вызовет фиктивный контекст сервлета для тестирования уровня MVC. Сервисы и компоненты не загружаются в контекст. Чтобы предоставить эти зависимости для тестирования, @MockBean обычно используется аннотация.
@AutoConfigureMockMVC
@AutoConfigureMockMVC Аннотаций работает очень похоже на @WebMVCTest аннотацию, но запускается полная весна загрузки контекста.
@MockBean
Создает и внедряет Mockito Mock для данной зависимости.
@JsonTest
Ограничит автоматическую настройку Spring Boot компонентами, относящимися к обработке JSON.
@TestPropertySource
Аннотация на уровне класса, используемая для указания источников свойств для тестового класса.