Java Blog

Контейнер выполняет разрешение зависимостей бина следующим образом: ApplicationContext создается и инициализируется с метаданными конфигурации, которые описывают все компоненты. Метаданные конфигурации могут быть указаны с помощью XML, кода Java или аннотаций. Для каждого компонента его зависимости выражаются в форме свойств, аргументов конструктора или аргументов метода статичной фабрики (если вы используете его вместо обычного конструктора). Эти зависимости предоставляются компоненту, когда компонент фактически создается. Каждый аргумент свойства или конструктора является фактическим определением значения, которое нужно установить, или ссылкой на другой компонент в контейнере. Каждый аргумент свойства или конструктора, являющийся значением, преобразуется из указанного формата в фактический тип аргумента этого свойства или конструктора. По умолчанию Spring может преобразовать значение, предоставленное в строковом формате, во все встроенные типы, такие как int, long, String, bool...

Поскольку вы можете смешивать DI на основе конструктора и сеттера, рекомендуется использовать конструкторы для обязательных зависимостей, а также методы сеттеры или методы настройки для необязательных зависимостей. Обратите внимание, что использование аннотации @Required в методе сеттере может быть использовано для того, чтобы сделать свойство обязательной зависимостью; однако внедрение в конструктор с программной проверкой аргументов предпочтительнее. Команда Spring, как правило, выступает за внедрение конструктора, поскольку она позволяет реализовывать компоненты приложения как неизменяемые объекты и гарантирует, что требуемые зависимости не равны null. Более того, внедренные конструктором компоненты всегда возвращаются клиентскому (вызывающему) коду в полностью инициализированном состоянии. В качестве примечания следует отметить, что большое количество аргументов конструктора является нежелательным кодом, подразумевая, что класс, вероятно, имеет слишком много обязанностей и должен ...

DI на основе сеттера выполняется контейнером, вызывающим методы setter для ваших bean-компонентов после вызова конструктора без аргументов или статического метода фабрики без аргументов для создания экземпляра вашего bean-компонента. В следующем примере показан класс, который может быть внедрен зависимостью только при использовании setter внедрения. Этот класс является обычным Java классом. Это POJO, который не зависит от конкретных интерфейсов контейнера, базовых классов или аннотаций. Java public class SimpleMovieLister { // SimpleMovieLister зависит от MovieFinder private MovieFinder movieFinder; // метод сеттер, чтобы контейнер Spring мог внедрить MovieFinder public void setMovieFinder(MovieFinder movieFinder) { this.movieFinder = movieFinder; } // бизнес-логика, которая фактически использует внедренный MovieFinder, опущена... } Kotlin class SimpleMovieLister { // свойство с поздней инициализацией, чтобы контейнер Spring мог внед...

Соответствие разрешения аргумента конструктора происходит с использованием типа аргумента. Если в аргументах конструктора определения компонента не существует потенциальной неоднозначности, порядок, в котором аргументы конструктора определяются в определении компонента, является порядком, в котором эти аргументы передаются соответствующему конструктору при создании экземпляра компонента. Рассмотрим следующий класс: Java package x.y; public class ThingOne { public ThingOne(ThingTwo thingTwo, ThingThree thingThree) { // ... } } Kotlin package x.y class ThingOne(thingTwo: ThingTwo, thingThree: ThingThree) Предполагая, что классы ThingTwo и ThingThree не связаны наследованием, потенциальной двусмысленности не существует. Таким образом, следующая конфигурация работает нормально, и вам не нужно явно указывать индексы или типы аргументов конструктора в элементе <constructor-arg/>. <beans> <bean id="beanOne" class="x.y.Thi...

DI на основе конструктора выполняется контейнером, вызывающим конструктор с несколькими аргументами, каждый из которых представляет зависимость. Вызов статического метода фабрики со специфическими аргументами для создания компонента почти эквивалентен, и в этом обсуждении аргументы конструктора и статического метода фабрики аналогичны. В следующем примере показан класс, который может быть внедрен только в зависимости с помощью конструктора: Java public class SimpleMovieLister { // SimpleMovieLister имеет зависимость от MovieFinder private MovieFinder movieFinder; // конструктор, чтобы контейнер Spring мог внедрить MovieFinder public SimpleMovieLister(MovieFinder movieFinder) { this.movieFinder = movieFinder; } // бизнес-логика, которая фактически использует внедренный MovieFinder, опущена ... } Kotlin // конструктор, чтобы контейнер Spring мог внедрить MovieFinder class SimpleMovieLister(private val movieFinder: MovieFinder) { // бизне...

Типичное корпоративное приложение не состоит из одного объекта (или bean-компонента в Spring). Даже в самом простом приложении есть несколько объектов, которые работают вместе, чтобы представить то, что конечный пользователь видит как связное приложение. В следующих постах объясняется, как перейти от определения отдельных определений bean-компонентов к полностью реализованному приложению, в котором объекты взаимодействуют для достижения цели. Внедрение зависимостей Внедрение зависимостей (DI, Dependency injection) - это процесс, при котором объекты определяют свои зависимости (то есть другие объекты, с которыми они работают) только через аргументы конструктора, аргументы метода фабрики или свойства, которые устанавливаются в экземпляре объекта после его создания или возвращения из фабричного метода. Затем контейнер внедряет эти зависимости при создании компонента. Этот процесс по своей сути является инверсией (отсюда и название, инверсия контроля) самого компонента, самостоятельно к...

Тип среды выполнения определенного компонента не является тривиальным для определения. Указанный класс в определении метаданных компонента - это просто начальная ссылка на класс, потенциально объединенная с объявленным методом фабрики или являющаяся классом FactoryBean, которая может привести к другому типу среды выполнения компонента или не устанавливаемая вообще в случае метод фабрики уровня экземпляра (который разрешается через указанное имя фабричного компонента). Кроме того, проксирование AOP может обернуть экземпляр компонента с помощью посредника на основе интерфейса с ограниченным представлением фактического типа целевого компонента (только его реализованные интерфейсы). Рекомендуемый способ узнать о фактическом типе времени выполнения конкретного компонента - это вызов BeanFactory.getType для указанного имени компонента. Это учитывает все вышеупомянутые случаи и возвращает тип объекта, который вызов BeanFactory.getBean собирается вернуть для того же имени компонента. Читайт...

Подобно реализации через статический метод фабрики, создание экземпляра методом фабрики экземпляра вызывает нестатический метод существующего компонента из контейнера для создания нового компонента. Чтобы использовать этот механизм, оставьте атрибут class пустым и в атрибуте factory-bean укажите имя компонента в текущем (или родительском) контейнере, который содержит метод экземпляра, который должен быть вызван для создания объекта. Задайте имя самого фабричного метода с помощью атрибута factory-method. В следующем примере показано, как настроить такой компонент: <!-- фабричный компонент, содержащий метод с именем createInstance() --> <bean id="serviceLocator" class="examples.DefaultServiceLocator"> <!-- внедрить любые зависимости, требуемые этим bean-компонентом локатора --> </bean> <!-- компонент, создаваемый с помощью фабричного компонента --> <bean id="clientService" factory-bean="serviceLocator" ...

При определении bean-компонента, создаваемого с помощью статического метода фабрики, используйте атрибут class, чтобы указать класс, содержащий статический метод фабрики, и атрибут с именем factory-method, чтобы указать имя самого метода фабрики. Вы должны иметь возможность вызывать этот метод (с необязательными аргументами, как описано ниже) и возвращать живой объект, который впоследствии обрабатывается, как если бы он был создан с помощью конструктора. Одним из применений такого определения компонента является вызов статических фабрик в унаследованном коде. Следующее определение bean-компонента указывает, что bean-компонент создается путем вызова метода фабрики. Определение не указывает тип (класс) возвращаемого объекта, только класс, содержащий фабричный метод. В этом примере метод createInstance() должен быть статическим методом. В следующем примере показано, как указать фабричный метод: <bean id="clientService" class="examples.ClientService" fac...

Когда вы создаете компонент (bean) с помощью конструктора, все нормальные классы могут использоваться и совместимы со Spring. То есть разрабатываемый класс не должен реализовывать какие-либо конкретные интерфейсы или кодироваться определенным образом. Достаточно просто указать класс бина. Однако, в зависимости от того, какой тип IoC вы используете для этого конкретного компонента, вам может понадобиться конструктор по умолчанию (пустой). Контейнер Spring IoC может управлять практически любым классом, которым вы хотите управлять. Это не ограничено управлением истинными JavaBeans. Большинство пользователей Spring предпочитают реальные JavaBeans только с конструктором по умолчанию (без аргументов) и соответствующими сеттерами и геттерами, смоделированными по свойствам в контейнере. В вашем контейнере также могут быть более экзотические классы не в стиле бинов. Если, например, вам нужно использовать устаревший пул соединений, который абсолютно не соответствует спецификации JavaBean, Sprin...

Определение бина (bean definition) - это, по сути, рецепт создания одного или нескольких объектов. Контейнер просматривает рецепт для именованного компонента при запросе и использует метаданные конфигурации, инкапсулированные этим определением компонента, для создания (или получения) реального объекта. Если вы используете метаданные конфигурации на основе XML, вы указываете тип (или класс) объекта, для которого создается экземпляр, в атрибуте класса элемента <bean/>. Этот атрибут класса (который внутри является свойством Class в экземпляре BeanDefinition) обычно является обязательным. Свойство Class можно использовать одним из двух способов: Как правило, чтобы указать класс bean-компонента, который будет создан в случае, когда сам контейнер непосредственно создает bean-компонент, вызывая его конструктор рефлексивно, что несколько эквивалентно коду Java с оператором new. Чтобы указать фактический класс, содержащий метод статической фабрики, который вызывается для создания объе...

В самом определении компонента (bean) вы можете указать более одного имени для компонента, используя комбинацию из одного имени, указанного в атрибуте id, и любого количества других имен в атрибуте name. Эти имена могут быть эквивалентными псевдонимами одного и того же компонента и могут быть полезны в некоторых ситуациях, например, позволяя каждому компоненту в приложении ссылаться на общую зависимость, используя имя компонента, специфичное для самого компонента. Однако указание всех псевдонимов, в которых фактически определен компонент, не всегда адекватно. Иногда желательно ввести псевдоним для компонента, который определен в другом месте. Это обычно имеет место в больших системах, где конфигурация разделена между каждой подсистемой, где каждая подсистема имеет свой собственный набор определений объектов. В метаданных конфигурации на основе XML для этого можно использовать элемент <alias/>. В следующем примере показано, как это сделать: <alias name="fromName"...

Каждый компонент (bean) имеет один или несколько идентификаторов. Эти идентификаторы должны быть уникальными в контейнере, в котором размещается bean. Bean обычно имеет только один идентификатор. Однако если требуется более одного, дополнительные могут рассматриваться как псевдонимы. В метаданных конфигурации на основе XML вы используете атрибут id, атрибут name или оба для указания идентификаторов компонента. Атрибут id позволяет указать ровно один идентификатор. Обычно эти имена являются буквенно-цифровыми ('myBean', 'someService' и т. д.), но они также могут содержать специальные символы. Если вы хотите ввести другие псевдонимы для компонента, вы также можете указать их в атрибуте name, разделяя их запятой (,), точкой с запятой (;) или пробелом. Как историческое примечание, в версиях до Spring 3.1 атрибут id был определен как тип xsd:ID, который ограничивал возможные символы. Начиная с версии 3.1 он определяется как тип xsd:string. Обратите внимание, что уникальност...

Контейнер Spring IoC управляет одним или несколькими компонентами (beans) . Эти компоненты создаются с помощью метаданных конфигурации, которые вы предоставляете контейнеру (например, в форме определений XML <bean/>). В самом контейнере эти определения bean-компонентов представлены в виде объектов BeanDefinition, которые содержат (среди прочего) следующие метаданные: Имя класса с указанием пакета: обычно это фактический класс реализации определяемого компонента. Элементы поведенческой конфигурации бина, которые определяют, как бин должен вести себя в контейнере (область действия, обратные вызовы жизненного цикла и т. д.). Ссылки на другие bean-компоненты, которые необходимы для его работы. Эти ссылки также называются соавторами (collaborators) или зависимостями (dependencies). Другие параметры конфигурации, устанавливаемые во вновь созданном объекте - например, ограничение размера пула или количество соединений, используемых в бине, который управляет пулом соединений. Эт...

ApplicationContext - это интерфейс для продвинутой фабрики, способной поддерживать реестр различных bean-компонентов и их зависимостей. Используя метод T getBean(String name, Class<T> requiredType), вы можете получить экземпляры ваших bean-компонентов. ApplicationContext позволяет читать определения бинов и получать к ним доступ, как показано в следующем примере: Java // создаем и настраиваем bean-компоненты ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml"); // получить настроенный экземпляр PetStoreService service = context.getBean("petStore", PetStoreService.class); // использовать настроенный экземпляр List<String> userList = service.getUsernameList(); Kotlin import org.springframework.beans.factory.getBean // создаем и настраиваем bean-компоненты val context = ClassPathXmlApplicationContext("services.xml", "daos.xml") // получить настроенный экземпляр val service...

В качестве дополнительного примера для метаданных внешней конфигурации, определения bean-компонентов также могут быть выражены в DSL Groovy Bean Definition, как это известно из среды Grails. Как правило, такая конфигурация находится в файле .groovy со структурой, показанной в следующем примере: beans { dataSource(BasicDataSource) { driverClassName = "org.hsqldb.jdbcDriver" url = "jdbc:hsqldb:mem:grailsDB" username = "sa" password = "" settings = [mynew:"setting"] } sessionFactory(SessionFactory) { dataSource = dataSource } myService(MyService) { nestedBean = { AnotherBean bean -> dataSource = dataSource } } } Этот стиль конфигурации в значительной степени эквивалентен определениям bean-компонентов XML и даже поддерживает пространства имен конфигурации XML Spring. Он также позволяет импортировать файлы определений XML-компонентов...

Иногда бывает полезно, чтобы определения бинов охватывали несколько файлов XML. Часто каждый отдельный файл конфигурации XML представляет логический уровень или модуль в вашей архитектуре. Вы можете использовать конструктор контекста приложения для загрузки определений бинов из всех этих фрагментов XML. Этот конструктор занимает несколько расположений ресурсов. Или используйте одно или несколько вхождений элемента <import/> для загрузки определений бина из другого файла или файлов. В следующем примере показано, как это сделать: <beans> <import resource="services.xml"/> <import resource="resources/messageSource.xml"/> <import resource="/resources/themeSource.xml"/> <bean id="bean1" class="..."/> <bean id="bean2" class="..."/> </beans> В предыдущем примере определения внешних компонентов загружаются из трех файлов: services.xml, messageSource....

Путь или пути расположения, предоставленные конструктору ApplicationContext, представляют собой строки ресурсов, которые позволяют контейнеру загружать метаданные конфигурации из различных внешних ресурсов, таких как локальная файловая система, Java CLASSPATH и т. д. Java ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml"); Kotlin val context = ClassPathXmlApplicationContext("services.xml", "daos.xml") После того, как вы узнаете о контейнере IoC Spring, вам может понадобиться больше узнать об абстракции ресурсов Spring, которая предоставляет удобный механизм для чтения InputStream из местоположений, определенных в синтаксисе URI. В частности, пути к ресурсам используются для создания контекстов приложений. В следующем примере показан файл конфигурации объектов уровня сервиса (services.xml): <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www....

Контейнер Spring IoC использует форму метаданных конфигурации. Эти метаданные конфигурации показывают, как вы, как разработчик приложения, указываете контейнеру Spring создавать экземпляры, настраивать и собирать объекты в вашем приложении. Метаданные конфигурации традиционно предоставляются в простом и интуитивно понятном формате XML, который используется в большей части этой главы для передачи ключевых концепций и функций контейнера IoC Spring. Метаданные на основе XML - не единственная разрешенная форма метаданных конфигурации. Сам контейнер Spring IoC полностью отделен от формата, в котором эти метаданные конфигурации фактически записаны. В наши дни многие разработчики выбирают конфигурацию на основе Java для своих приложений Spring. Использование других форм метаданных с контейнером Spring: Конфигурация на основе аннотаций: в Spring 2.5 появилась поддержка метаданных конфигурации на основе аннотаций. Конфигурация на основе Java. Начиная с Spring 3.0, многие функции, предоста...

Интерфейс org.springframework.context.ApplicationContext представляет контейнер IoC Spring и отвечает за создание, настройку и сборку bean-компонентов. Контейнер получает инструкции о том, какие объекты создавать, настраивать и собирать, читая метаданные конфигурации. Метаданные конфигурации представлены в виде XML, аннотаций Java или кода Java. Это позволяет вам выражать объекты, составляющие ваше приложение, и богатую взаимозависимость между этими объектами. Несколько реализаций интерфейса ApplicationContext поставляются с Spring. В автономных приложениях обычно создается экземпляр ClassPathXmlApplicationContext или FileSystemXmlApplicationContext. Хотя XML является традиционным форматом для определения метаданных конфигурации, вы можете указать контейнеру использовать аннотации Java или код в качестве формата метаданных, предоставив небольшой объем конфигурации XML для декларативного включения поддержки этих дополнительных форматов метаданных. В большинстве сценариев приложений яв...

В этом посте рассказывается о реализации в Spring Framework принципа инверсии контроля (IoC, Inversion of Control). IoC также известен как внедрение зависимостей (DI, dependency injection). Это процесс, при котором объекты определяют свои зависимости (то есть другие объекты, с которыми они работают) только через аргументы конструктора, аргументы метода фабрики или свойства, которые устанавливаются в экземпляре объекта после того, как он создан или возвращен из метода фабрики. Затем контейнер внедряет эти зависимости при создании компонента (bean). Этот процесс по своей сути является инверсией (отсюда и название, инверсия контроля) самого компонента, управляющего созданием экземпляров или расположением его зависимостей, с помощью прямого конструирования классов или механизма, такого как паттерн Service Locator. Пакеты org.springframework.beans и org.springframework.context являются основой для контейнера IoC Spring Framework. Интерфейс BeanFactory предоставляет расширенный механизм кон...

systemd является преемником системы инициализации System V и в настоящее время используется во многих современных дистрибутивах Linux. Хотя вы можете продолжать использовать сценарии init.d с systemd, также можно запускать приложения Spring Boot с помощью systemd ‘service’ сценариев. Предполагая, что у вас установлено приложение Spring Boot в /var/myapp, чтобы установить приложение Spring Boot в качестве службы systemd, создайте сценарий с именем myapp.service и поместите его в каталог /etc/systemd/system. Следующий скрипт предлагает пример: [Unit] Description=myapp After=syslog.target [Service] User=myapp ExecStart=/var/myapp/myapp.jar SuccessExitStatus=143 [Install] WantedBy=multi-user.target Не забудьте изменить поля Description, User и ExecStart для вашего приложения. Поле ExecStart не объявляет команду действия сценария, что означает, что команда запуска используется по умолчанию. Обратите внимание, что, в отличие от запуска в качестве службы init.d, пользователь, кото...

Приложение Spring Boot можно легко запустить как сервисы Unix/Linux с помощью init.d или systemd. Если вы сконфигурировали подключаемый модуль Spring Boot Maven или Gradle для создания полностью исполняемого jar-файла и не используете настраиваемый внедренный LaunchScript, ваше приложение можно использовать в качестве службы init.d. Для этого сделайте символическую ссылку на jar-файл с init.d для поддержки стандартных команд start, stop, restart и status. Скрипт поддерживает следующие функции: Запускает сервисы как пользователь, которому принадлежит файл jar Отслеживает PID приложения с помощью /var/run/<appname>/<appname>.pid Записывает журналы консоли в /var/log/<appname>.log Предполагая, что у вас установлено приложение Spring Boot в /var/myapp, чтобы установить приложение Spring Boot в качестве службы init.d, создайте символическую ссылку следующим образом: $ sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp После установки вы можете запускать и ост...

Помимо запуска приложений Spring Boot с использованием java -jar, также можно создавать полностью исполняемые приложения для систем Unix. Полностью исполняемый jar может быть выполнен как любой другой исполняемый двоичный файл или он может быть зарегистрирован в init.d или systemd. Это упрощает установку и управление приложениями Spring Boot в обычных производственных средах. Полностью исполняемые файлы jar работают путем встраивания дополнительного скрипта в начало файла. В настоящее время некоторые инструменты не принимают этот формат, поэтому вы не всегда сможете использовать эту технику. Например, jar -xf может молча не извлечь jar или war, которые были сделаны полностью исполняемыми. Рекомендуется сделать jar или war полностью исполняемым только в том случае, если вы намерены выполнять его напрямую, а не запускать его с помощью java -jar или развертывать его в контейнере сервлета. Файл jar в формате zip64 нельзя сделать полностью исполняемым. Попытка сделать это приведет к тому,...

В Google Cloud есть несколько опций, которые можно использовать для запуска приложений Spring Boot. Возможно, проще всего начать с App Engine, но вы также можете найти способы запуска Spring Boot в контейнере с Container Engine или на виртуальной машине с Compute Engine. Для запуска в App Engine вы можете сначала создать проект в пользовательском интерфейсе, который устанавливает для вас уникальный идентификатор, а также настраивает маршруты HTTP. Добавьте приложение Java в проект и оставьте его пустым, а затем используйте Google Cloud SDK, чтобы вставить приложение Spring Boot в этот слот из командной строки или сборки CI. Стандарт App Engine требует, чтобы вы использовали упаковку WAR. Выполните следующие действия , чтобы развернуть стандартное приложение App Engine в Google Cloud. Кроме того, App Engine Flex требует создания файла app.yaml для описания ресурсов, необходимых для вашего приложения. Обычно вы помещаете этот файл в src/main/appengine, и он должен выглядеть следующим ...

Boxfuse работает, превращая исполняемый jar или war Spring Boot в минимальный образ виртуальной машины, который можно развернуть без изменений либо в VirtualBox, либо в AWS. Boxfuse поставляется с глубокой интеграцией для Spring Boot и использует информацию из вашего файла конфигурации Spring Boot для автоматической настройки портов и URL-адресов проверки работоспособности (health check). Boxfuse использует эту информацию как для образов, которые он создает, так и для всех ресурсов, которые он предоставляет (экземпляры, группы безопасности, эластичные балансировщики нагрузки и т. д.). После того как вы создали учетную запись Boxfuse, подключили ее к своей учетной записи AWS, установили последнюю версию клиента Boxfuse и убедились, что приложение было создано Maven или Gradle (с помощью, например, mvn clean package), вы можете развернуть приложение Spring Boot в AWS с помощью команды, аналогичной следующей: $ boxfuse run myapp-1.0.jar -env=prod Если в текущем каталоге присутству...

Heroku - еще одна популярная PaaS платформа. Для настройки сборок Heroku вы предоставляете Procfile, который обеспечивает incantation, необходимое для развертывания приложения. Heroku назначает порт для использования приложением Java, а затем гарантирует, что маршрутизация на внешний URI работает. Вы должны настроить приложение для прослушивания на правильном порту. В следующем примере показан Procfile для нашего начального REST-приложения: web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar Spring Boot делает аргументы -D доступными в качестве свойств, доступных из экземпляра Spring Environment. Свойство конфигурации server.port передается встроенному экземпляру Tomcat, Jetty или Undertow, который затем использует порт при запуске. Переменная окружения $PORT присваивается нам Heroku PaaS. Это должно быть все, что вам нужно. Наиболее распространенный рабочий процесс развертывания для развертываний Heroku - это отправка (git push) кода в производственный режим, ка...