Иерархическая Контекст приложений и стандарт-Прицелы и заказ Прицелы

Question

мой вопрос немного сложнее :) Я попытаюсь объяснить мою установку ...

• У меня есть веб-приложение, один веб-весенне контекст с некоторыми компонентами singleton-, session-scoped, иногда aop-proxies и т. д. normal stuff :)
• внутри приложения Я создаю некоторую инфраструктуру, чтобы иметь возможность «запускать» некоторые подконтексты, я делаю это вручную, отдельно заданное spring-configuration-classes, эти классы исключаются из основного/контекстного контекста-bean-scan, у меня есть неопределенное количество таких подконтекстов в приложении ...
• функция с субконтекстами не является обязательной, поэтому приложение также может работать только с основным контекстом
• внутри основного контекста и подконтекста Я использую некоторые классы/интерфейсы - чтобы отделить «верхний уровень» от «Бобы субкомпонентного уровня» я создал две дополнительные аннотации классификатора ... с помощью этих аннотаций я укусил материал для автоуслуг, так что я думаю, что правильный компонент используется в нужном месте :)
• Представьте, что существует FooBarService на верхнем уровне и N FooBarService в каждом подконтексте, каждая служба должна иметь свое «собственное» состояние, поэтому N + 1 экземпляров, запущенных во всей программе
• Некоторые субконтекстные компоненты используют (вводят) компоненты верхнего уровня и т. Д.

• это, кажется, работает до сих пор

• но теперь я исследовал БОЛЬШУЮ утечка памяти :(Я думаю, что я нашел проблему ...

• для субкомпонентами я создал свой собственный «контекст сеанса» (хеш-карта, нет реальной очистки и т. д. настоятельно призывает), и я зарегистрировал этот раздел через «CustomScopeConfigurer» как «СЕССИЯ» для каждого из моих (вручную запущенных) субконтекстов ... с этим я все еще могу использовать " normal "@Scope (значение = WebApplicationContext.SCOPE_SESSION) в моих подконтекстных классах весенней конфигурации

Q1: Этот «ручной» прицел - хорошая идея? : D Q2: эта область «ручной работы» должна быть своего рода «областью преобразования» внутри «области сеанса», но имейте в виду, что эта область существует N раз в «сеансе», поэтому позволяет называть ее «разговор-1» -scope "," chat-2-scope "..." conversation-N-scope " Q3: когда и как я могу очистить такую« область разговора »?

• Я ожидал от иерархического весеннего контекста, что bean, который не найден в «подконтексте», будет запрашиваться (попробуйте) из родительского контекста - это правильно?

Q4: нужно зарегистрировать все известные областей от «родительского контекста» в «суб-контекст», как это:

final ConfigurableListableBeanFactory parentBeanFactory = ((AbstractApplicationContext) parentSpringContext).getBeanFactory(); 
    final ConfigurableListableBeanFactory beanFactory = springApplicationContext.getBeanFactory(); 
    final String[] scopeNames = parentBeanFactory.getRegisteredScopeNames(); 
    for (final String scopeName : scopeNames) { 
    final Scope scope = parentBeanFactory.getRegisteredScope(scopeName); 
    beanFactory.registerScope(scopeName, scope); 
    } 

Вот визуализация моей «структуры»:

 
TOP-LEVEL-Context 
|-* session-scoped beans 
|-* singleton beans (HelloWorldService) 
| 
|->SUB1-Context 
| |-* session-scoped beans (FooBarService - depends on HelloWorldService) 
| |-* singleton beans 
| 
|->SUB2-Context 
| |-* session-scoped beans (FooBarService - depends on HelloWorldService) 
| |-* singleton beans 
| 
|->... 

Любой намек будет обалденно :)

Сердечные приветы Andreas

Answer 1

Вы ищете WeakHashMap на случай ...?

Я не имею представления обо всем весеннем дерьме :) - но вышеупомянутая вещь пригодится, когда мне нужно создать, а затем автоматически освобождать подграфы при использовании Dagger2.