Пользовательские весенние рамки?

Question

Кто-нибудь знает о любых других пользовательских областях пружины, кроме Область контекста сервлета и ThreadScope ?

Если вы создали какую-то настраиваемую область с закрытым исходным кодом, мне также было бы интересно услышать, что она делает и как она работает для вас. (Я полагаю, кто-то сделает WindowScope в настольном приложении?)

Я открыт для всех случаев использования, я хочу расширить свой кругозор здесь.

Answer 1

Мы реализовали нашу собственную область Spring. Большая часть нашего кода работает на относительно низком уровне, рядом с базой данных, и мы поддерживаем концептуальный уровень на его основе с собственной объектной моделью источников данных, ссылок, атрибутов и т. Д.

Во всяком случае, многие компоненты требуют для своей работы так называемый StorageDictionary (инкапсуляция этого графа объектов). Когда мы вносим нетривиальные изменения в граф объектов, словарь иногда нужно сдуть и воссоздать. Следовательно, мы реализовали пользовательскую область видимости для объектов, которые были область словаря , и часть аннулирования данного словаря включает очистку этой пользовательской области. Это позволяет Spring обрабатывать красивую форму автоматического кэширования для этих объектов. Вы возвращаете один и тот же объект каждый раз, пока словарь не станет недействительным, после чего вы получите новый объект.

Это помогает не только обеспечить согласованность, но и позволяет самим объектам кэшировать ссылки на объекты в словаре, будучи уверенными в том, что кэш будет действителен до тех пор, пока они сами будут извлечены Spring. Это, в свою очередь, позволяет нам создавать их как неизменяемые объекты (при условии, что они могут быть подключены через инжекцию конструктора), что очень полезно делать в любом случае, когда это возможно.

Этот метод не будет работать повсеместно и сильно зависит от характеристик программного обеспечения (например, если словарь изменялся регулярно, это было бы ужасно неэффективно, и если оно никогда не обновлялось, это было бы ненужным и немного менее эффективным, чем прямое доступ). Однако это определенно помогло нам передать это управление жизненным циклом Spring таким концептуально простым и, на мой взгляд, довольно элегантным способом.

Answer 2

Справочная информация:

Я работаю над одним веб-приложением, которое запускает 4 разных веб-сайта в одном и том же контексте сервлета. Каждый сайт имеет собственное доменное имя, например, www.examplesite1.com, www.examplesite2.com и т. д.

Проблема:

Иногда сайтам требуется собственный настроенный экземпляр компонента из контекста приложения (обычно для настраиваемого отображения сообщений или форматирования объектов).

Например, скажем, сайты 1 и 2 используют компонент bean «standardDateFormatter», сайт 3 использует компонент «usDateFormatter», а сайт 4 использует компонент «ukDateFormatter».

Решение:

Я планирую использовать область "site".

У нас есть Site enum:

enum Site {
    SITE1, SITE2, SITE3, SITE4;
}

Затем у нас есть фильтр, который сохраняет одно из этих значений Site в потоке запроса, используя ThreadLocal. Это «идентификатор разговора» области сайта.

Тогда в контексте приложения будет bean-компонент с именем dateFormatter, с областью видимости = site. Затем везде, где мы хотим использовать форматер даты, будет использоваться правильный для текущего сайта пользователя.

Добавлено позже:

Пример кода здесь:

http://github.com/eliotsykes/spring-site-scope

Answer 3

В моей компании мы создали две пользовательских области: одна, которая будет использовать Thread или Request, а другая - либо Thread, либо Session. Идея состоит в том, что для областей действия можно использовать одну область видимости без необходимости изменять конфигурацию в зависимости от среды выполнения (контейнера JUnit или сервлета). Это также очень удобно, когда вы запускаете элементы в Quartz и у вас больше нет области запросов или сеансов.

Answer 4

Apache Orchestra предоставляет SpringConversationScope .

Answer 5

В Oracle Coherence реализована область охвата для бинов Spring . Подводя итог:

A Data Grid Bean является прокси для java.io.Serializable Бин экземпляр который хранится в не истекающем Coherence Distributed Cache (называется почти datagridbeans).

Никогда не использовал их сам, но они кажутся крутыми.

Answer 6

В приложении Spring Batch мы реализовали область действия элемента .

Фон

У нас есть множество @Service компонентов, которые вычисляют что-то на основе текущего элемента пакета. Многие из них нуждаются в одном и том же рабочем процессе:

1. Определите соответствующие детали элемента.
2. Инициализация вещей, основанных на предмете.
3. Для каждой части предмета что-то вычислить (используя вещи).

Мы переместили рабочий процесс в метод шаблона базового класса, поэтому подклассы реализуют только findItemParts(Item) (выполнение 1 и 2) и computeSomething(ItemPart) (выполнение 3). Таким образом, они стали с состоянием (материал, инициализированный в findItemParts, необходим в computeSomething), и это состояние должно быть очищено перед следующим элементом.

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

Дизайн

Мы реализовали AbstractScopeRegisteringItemProcessor, который регистрирует элемент и позволяет подклассам регистрировать производные бины. В конце метода process он удаляет элемент из контекста своей области, а производные бины используют DefaultSingletonBeanRegistry.destroySingleton.

Как это получилось

Работает, но имеет следующие проблемы:

1. Нам не удалось очистить производные бины без регистрации (только на основании их @Scope). Конкретный процессор должен их создать и зарегистрировать.
2. AbstractScopeRegisteringItemProcessor было бы лучше использовать композицию и динамически реализовывать все интерфейсы базового процессора. Но тогда результирующий компонент @StepScope является прокси для объявленного возвращаемого типа (т. Е. AbstractScopeRegisteringItemProcessor или ItemProcessor) без необходимых интерфейсов обратного вызова.

* * РЕДАКТИРОВАТЬ тысячу сорок-девять

С помощью решения @Eliot Sykes и общего кода плюс регистрация BeanDefinition @ Cheetah я смог избавиться от регистрации в виде синглтон-бинов. Вместо этого ItemScopeContext (хранилище, используемое как процессором, так и реализацией Scope; Java-конфигурируется статическим методом @Bean) реализует BeanDefinitionRegistryPostProcessor. Он регистрирует FactoryBean, чей getObject() возвращает текущий элемент или выдает исключение, если его нет. Теперь @Component, помеченный @Scope(scopeName = "Item", proxyMode = ScopedProxyMode.TARGET_CLASS), может просто внедрить элемент, и его не нужно регистрировать для очистки конца области действия.

Итак, в конце концов, это сработало хорошо.

Answer 7

Однажды я использовал своего рода область разговора , чтобы сохранить некоторые объекты в области сеанса, чтобы сохранить их при повторном входе на ту же страницу, но ограничил одной страницей, чтобы избежать бесполезности объекты в сессии. Реализация просто сохранила URL-адрес страницы и очистила область диалога при каждом изменении страницы.

Answer 8

В моей компании мы также внедрили пружинный заказ. У нас есть мультитенантная система, в которой каждый клиент может настроить параметры. Экземпляр , основанный на нашей области, кэширует компоненты, которые зависят от клиента. Поэтому каждый раз, когда пользователь клиента входит в систему, эти параметры кэшируются и снова используются, когда другие пользователи того же клиента входят в систему.

Answer 9

Область видимости источника на основе языкового стандарта пользователя с веб-приложением

См. связанную страницу вики