Java Blog

После того, как вы напишете и протестируете одну или несколько пользовательских реализаций Scope , вам необходимо сообщить контейнеру Spring о ваших новых областях. Следующий метод является основным методом регистрации нового Scope в контейнере Spring: Java void registerScope(String scopeName, Scope scope); Kotlin fun registerScope(scopeName: String, scope: Scope) Этот метод объявлен в интерфейсе ConfigurableBeanFactory, который доступен через свойство BeanFactory в большинстве конкретных реализаций ApplicationContext, которые поставляются с Spring. Первый аргумент метода registerScope(..) - это уникальное имя, связанное с областью действия. Примерами таких имен в самом контейнере Spring являются singleton и prototype. Второй аргумент метода registerScope(..) - это фактический экземпляр пользовательской реализации Scope, которую вы хотите зарегистрировать и использовать. Предположим, что вы пишете свою собственную реализацию Scope, а затем регистрируете ее, как показан...

Механизм определения бинов расширяемый. Вы можете определить свои собственные области или даже переопределить существующие области, хотя последнее считается плохой практикой, и вы не можете переопределить встроенные области singleton и prototype. Создание пользовательской области применения бинов Чтобы интегрировать ваши пользовательские области в контейнер Spring, вам необходимо реализовать интерфейс org.springframework.beans.factory.config.Scope. Интерфейс Scope имеет четыре метода для получения объектов из области, удаления их из области и предоставления возможности их уничтожения. Например, реализация области действия session возвращает bean-объект в области session (если он не существует, метод возвращает новый экземпляр bean-компонента после привязки его к session для использования в будущем). Следующий метод возвращает объект из базовой области: Java Object get(String name, ObjectFactory<?> objectFactory) Kotlin fun get(name: String, objectFactory: ObjectFa...

По умолчанию, когда контейнер Spring создает прокси для компонента, размеченного с помощью элемента <aop:scoped-proxy/> , создается прокси класса на основе CGLIB. CGLIB-прокси перехватывает только публичные вызовы методов! Не вызывайте непубличные методы на таком прокси. Они не делегируются фактическому целевому объекту с областью действия. В качестве альтернативы вы можете настроить контейнер Spring для создания стандартных прокси на основе интерфейса JDK для таких bean-компонентов, указав значение false для значения атрибута proxy-target-class элемента <aop:scoped-proxy/>. Использование прокси на основе интерфейса JDK означает, что вам не нужны дополнительные библиотеки в пути к классам вашего приложения, чтобы повлиять на такое прокси. Тем не менее, это также означает, что класс объекта EJB должен реализовывать как минимум один интерфейс, и что все соавторы, в которые вводится объект EJB, должны ссылаться на компонент через один из его интерфейсов. В следующем примере ...

Контейнер Spring IoC управляет не только созданием ваших объектов (компонентов), но и подключением сотрудников (collaborators) (или зависимостей). Если вы хотите внедрить (например) компонент с областью действия HTTP-запроса в другой компонент с более длительным сроком действия, вы можете внедрить прокси AOP (AOP proxy) вместо этого компонента. То есть вам нужно внедрить прокси-объект, который предоставляет тот же открытый интерфейс, что и объект области действия, но который также может извлечь реальный целевой объект из соответствующей области (например, HTTP-запрос) и делегировать вызовы методов в реальный объект. Вы также можете использовать <aop:scoped-proxy/> между bean-компонентами, которые определены как одноэлементные (singleton), причем ссылка затем проходит через промежуточный прокси, который сериализуем и поэтому может повторно получить целевой одноэлементный компонент при десериализации. При объявлении <aop:scoped-proxy/> против bean-объекта области видимости ...

Рассмотрим следующую конфигурацию XML для определения компонента: <bean id="appPreferences" class="com.something.AppPreferences" scope="application"/> Контейнер Spring создает новый экземпляр компонента AppPreferences, используя определение компонента appPreferences один раз для всего веб-приложения. Таким образом, bean-компонент appPreferences находится на уровне ServletContext и сохраняется как обычный атрибут ServletContext. Это в некоторой степени похоже на одноэлементный компонент Spring (singleton), но отличается двумя важными фактами: это один компонент для ServletContext, а не для Spring 'ApplicationContext' (для которого может быть несколько в любом данном веб-приложении), и он фактически отображается и поэтому видимый как атрибут ServletContext. При использовании управляемых аннотациями компонентов или конфигурации Java вы можете использовать аннотацию @ApplicationScope, чтобы назначить компонент области приложения. В следую...

Рассмотрим следующую конфигурацию XML для определения компонента: <bean id="userPreferences" class="com.something.UserPreferences" scope="session"/> Контейнер Spring создает новый экземпляр компонента UserPreferences с помощью определения компонента userPreferences для времени жизни одного сеанса HTTP. Другими словами, bean-компонент userPreferences эффективно ограничен на уровне сеанса HTTP. Как и в случае bean-объектов в области запросов, вы можете изменять внутреннее состояние экземпляра, который создается столько раз, сколько вы хотите, зная, что другие экземпляры сеанса HTTP, которые также используют экземпляры, созданные из того же определения bean-компонента userPreferences, не видят эти изменения в состоянии, потому что они специфичны для отдельного сеанса HTTP. Когда сеанс HTTP в конечном итоге отбрасывается, компонент, который ограничен этим конкретным сеансом HTTP, также отбрасывается. При использовании управляемых аннотациями комп...

Рассмотрим следующую конфигурацию XML для определения компонента: <bean id="loginAction" class="com.something.LoginAction" scope="request"/> Контейнер Spring создает новый экземпляр bean-компонента LoginAction, используя определение bean-компонента loginAction для каждого HTTP-запроса. То есть bean-компонент loginAction находится на уровне HTTP-запроса. Вы можете изменять внутреннее состояние экземпляра, который создается столько раз, сколько вы хотите, потому что другие экземпляры, созданные из того же определения бина loginAction, не видят эти изменения в состоянии. Они относятся к индивидуальному запросу. Когда запрос завершает обработку, компонент, находящийся в области действия запроса, отбрасывается. При использовании компонентов, управляемых аннотациями, или конфигурации Java, аннотация @RequestScope может использоваться для назначения компонента области запроса. В следующем примере показано, как это сделать: Java @RequestScope @C...

Области Request, Session, Application и WebSocket доступны только при использовании веб-реализации Spring ApplicationContext (такой как XmlWebApplicationContext). Если вы используете эти области с обычными контейнерами Spring IoC, такими как ClassPathXmlApplicationContext, генерируется исключение IllegalStateException, которое жалуется на неизвестную область действия компонента. Начальная веб-конфигурация Чтобы поддерживать область действия bean-компонентов на уровнеrequest, session, application, и websocket (web-scoped beans), перед определением ваших bean-компонентов требуется небольшая начальная конфигурация. (Эта начальная настройка не требуется для стандартных областей применения: singleton и prototype.) То, как вы выполните эту начальную настройку, зависит от вашей конкретной среды сервлетов. Если вы обращаетесь к bean-объектам области действия в Spring Web MVC, то в действительности в рамках запроса, который обрабатывается Spring DispatcherServlet, никакой специальной настро...

Область применения не-синглтон прототипа (prototype) развертывания компонента приводит к созданию нового экземпляра компонента каждый раз, когда делается запрос на этот конкретный компонент. Таким образом, компонент вводится в другой компонент, или вы запрашиваете его с помощью вызова метода getBean() для контейнера. Как правило, вы должны использовать область действия прототипа для всех bean-компонентов с состоянием и единственную (singleton) область для bean-компонентов без состояния. В следующем примере бин определяется как прототип в XML: <bean id="accountService" class="com.something.DefaultAccountService" scope="prototype"/> В отличие от других областей, Spring не управляет полным жизненным циклом прототипа bean-компонента. Контейнер создает, настраивает и иным образом собирает объект-прототип и передает его клиенту без дальнейшей записи этого экземпляра-прототипа. Таким образом, хотя методы обратного вызова жизненного цикла инициализац...