Je ne l'ai pas encore testé, mais je crois que cela fonctionnera. Pour chaque portée personnalisée/contexte que vous voulez dans votre application, il vous suffit d'ajouter ce contexte via une extension lorsque le conteneur est initialisé:
public void afterBeanDiscovery(@Observes AfterBeanDiscover afterBeanDiscovery, BeanManager beanManager)
{
CustomContext customContext = new CustomContext();
afterBeanDiscovery.addContext(customContext);
beanManager ...
}
Maintenant, l'astuce est, vous devez tenir une référence à ce contexte alors quand vous voulez commencer ou arrêter, vous pouvez. Ce serait quelque chose comme:
@Inject
protected HttpRequestLifecycle httpRequestLifecycle;
public void doSomething()
{
startContext();
doStuff();
stopContext();
}
public void startContext()
{
httpRequestContextLifecycle.getHttpRequestContext().activate();
}
Cela devrait le faire, il n'y a pas une foule de documents là-bas, donc j'espère que cela aide.
Toute personne intéressée, consultez la source ici: http://github.com/walterjwhite/server.web.application
Walter
En fait, cela m'a vraiment proche. Même après avoir démarré le contexte en le mettant en activité, je reçois toujours le No Contexts Active pour la portée ... –
Une autre note ici - vous ne pouvez pas injecter le contexte sauf si vous en faites un singleton. Si la portée de l'application est définie, vous n'avez aucune garantie que vous obtiendrez le même contexte que celui de la carte des contextes. Cela signifie que le contexte que vous activez est un contexte fictif, il ne contrôle rien. Ce que j'ai fini par faire était de tenir une référence dans mes classes de gestion du cycle de vie, puis d'injecter ce cycle de vie et d'obtenir le contexte. –
Si c'était @Singleton, comment différencieriez-vous plusieurs demandes? Ne devriez-vous pas créer et activer le contexte quelque part dans l'écouteur de contexte? –