Пользовательские пружинные объемы?
Рассматривая argcomplete и как это работает. Вы можете разместить его после parser.parse_known_args() и до parser.parse_args(), но это не принесет вам особой пользы, поскольку он запускает ваш скрипт и проверяет parser, предоставленный для определения параметров автозаполнения. Он не передает аргументы (то есть то, что уже было напечатано в командной строке) скрипту.
Что при вызове argcomplete ваш скрипт не будет иметь представления о том, что было передано filename и какие другие аргументы должны быть добавлены динамически.
Кроме того, если бы у вас были какие-либо required=True аргументы, уже добавленные в анализатор до запуска parser.parse_known_args(), вы действительно никогда бы не запустили argcomplete.autocomplete(parser), потому что выполнение скрипта было бы неудачным на первом до достижения последнего (опять же, для Сценарий автозаполнения запускается без каких-либо параметров, передаваемых ему).
5 ответов
В моей компании мы создали два пользовательских объема, тот, который будет использовать Поток или Запрос и другого, который будет использовать или Поток или Сессию. Идея состоит в том, что единственный объем может использоваться для ограниченных по объему бобов, не имея необходимость изменять конфигурацию на основе среды выполнения (JUnit или контейнер Сервлета). Это также действительно пригождается для того, когда Вы выполняете объекты в Кварце и больше не имеете объем Запроса или Сессии в наличии.
Мы реализовали наш собственный объем Spring. Много нашего кода работает на относительно низком уровне, близко к базе данных, и мы поддерживаем концептуальный уровень к тому же с его собственной объектной моделью источников данных, ссылок, атрибуты и т.д.
Так или иначе много бобов требует, чтобы так называемый StorageDictionary (инкапсуляция этого графа объектов) сделал их работу. Когда мы вносим нетривиальные изменения в граф объектов, словарь иногда должен сдуваться и воссоздаваться. Следовательно, мы реализовали пользовательский объем для объектов, которые были словарем, ограниченным по объему, и часть аннулирования данного словаря включает очистку этого пользовательского объема. Это позволяет Spring обработать хорошую форму автоматического кэширования для этих объектов. Вы добираетесь, тот же объект отступают, каждый раз вплоть до словаря делается недействительным, в которой точке Вы получаете новый объект.
Это помогает не только с непротиворечивостью, но также и позволяет сами объекты ссылкам кэша на объекты в рамках словаря, безопасного в знании, что кэш будет допустим столько, сколько они сами восстановимы Spring. Это в свою очередь позволяет нам создать их как неизменные объекты (пока они могут быть соединены проводом через инжекцию конструктора), который является очень хорошей вещью сделать так или иначе по мере возможности.
Эта техника не будет работать везде и действительно зависит в большой степени от характеристик программного обеспечения (например, если бы словарь регулярно изменялся, то это было бы ужасно неэффективно, и если бы это никогда не обновлялось, то это было бы ненужным и немного менее эффективным, чем прямой доступ). Однако это определенно помогло нам выдать это управление жизненного цикла к Spring способом, который концептуально прост и по-моему довольно изящен.
Когерентность Oracle реализовала объем datagrid для бобов Spring. Подвести итог его:
Боб Сетки Данных является прокси к java.io. Сериализуемый Бобовый экземпляр, который хранится в не истекающей Когерентности Распределенный Кэш (названный почти-datagridbeans).
Никогда не использовал их самостоятельно, но они кажутся прохладными.
Фон:
Я работаю над одним веб-приложением, которое запускает 4 разных веб-сайта в одном контексте сервлета. У каждого сайта есть свое собственное доменное имя, например www.examplesite1.com, www.examplesite2.com и т. Д.
Проблема:
Сайтам иногда требуется собственный настроенный экземпляр компонента из контекста приложения (обычно для настраиваемого отображения сообщений или форматирование объектов).
Например, сайты 1 и 2 используют bean-компонент "standardDateFormatter", сайт 3 использует bean-компонент "usDateFormatter", а сайт 4 использует bean-компонент "ukDateFormatter".
Решение:
Я планирую использовать с использованием области "site".
У нас есть перечисление Site вроде этого:
enum Site {
SITE1, SITE2, SITE3, SITE4;
}
Затем у нас есть фильтр, который сохраняет одно из этих значений Site в потоке запроса с помощью ThreadLocal. Это «идентификатор разговора» области сайта.
Тогда в контексте приложения должен быть bean-компонент с именем «dateFormatter» с 'scope = "site"'. Затем, где бы мы ни хотели использовать средство форматирования даты, будет использоваться правильный формат для текущего сайта пользователя.
Добавлено позже:
Пример кода здесь:
Apache Orchestra предоставляет SpringConversationScope .