Guice Scopes personnalisés et gérés par Spring haricots

Question

(x-posté à Guice liste de diffusion)

Je Guice sur une expérimentation nouvelle bibliothèque qui vivent dans une application existante. Toutes nos applications sont actuellement des applications de printemps et nous avons un code commun qui est lié au printemps, principalement à cause du modèle de fil que nous avons tendance à utiliser. Il nous donne fondamentalement (ce qui pourrait être vu comme) un fil logique .

Ainsi, nous pouvons lancer des tâches et garantir que les tâches avec une clé donnée aboutissent toujours sur le même canal dans l'ordre dans lequel elles ont été soumises. Généralement, il s'agit d'un thread unique pour la vie de l'application mais si de mauvaises choses se produisent, le thread de travail (qui supporte le tuyau) est jeté, le tuyau est désactivé, un nouveau worker est créé et le tuyau est réactivé. Tout le câblage ici est fourni par le printemps.

Mes nouveaux besoins lib de l'utiliser pour le modèle de fil & Je prévois d'utiliser Guice du côté de domaine logique & des choses, à savoir la construction du travail qui va sur le pipeline & et la logique qu'il représente. Cela me semble assez simple, sauf pour une chose qui semble très grossière, à savoir que je veux injecter certaines choses avec la portée "pipe" (alias thread logique). J'ai lu les champs personnalisés (et la mise en œuvre SimpleScope) page wiki mais certaines choses ne sont pas claires pour moi et des éclaircissements serait très apprécié ...

1. pipes survivre à la vie de la machine virtuelle Java donc il semble que je besoin d'entrer dans une portée, mais ne jamais sortir, des inconvénients à cela?
2. Quelles options ai-je pour déclencher l'entrée d'une portée dans un haricot géré par ressort? Est-ce juste un cas de créer le contexte du printemps et ensuite en utilisant le SpringIntegration pour aspirer les haricots de printemps dans un contexte de guice?
3. Est-ce que ça sonne vraiment floconneux et je devrais juste l'envelopper avec un singleton claveté par mon ID pipe à la place?

Vive Matt

Answer 1

J'ai mis en place quelque chose qui fonctionne, mais implique une configuration un peu moche ... toujours intéressé par des améliorations sur ce & il peut y avoir un peu trop de code pour poster vraiment si juste mettre quelques extraits dans ce qui illumine avec espoir

c'est une variation sur l'exemple SimpleScope qui implique;

• élever le ressort ctx
• saisissant un bean spécifique hors de lui (à savoir un registre de clés de pipeline)
• passant que le module Guice avec le BeanFactory
• donnant ce registre à les impl de portée de sorte que le champ est saisi lorsque la conduite est activée (ce qui arrive plus tard, lorsque certains grains de printemps sont init'ed)

il semble que je dois saisir le grain spécifique plutôt que d'y accéder par un Nam ed après avoir fait une bindAll sur le BeanFactory comme l'instance Scope vous est new'ed dans le module, à savoir

PipeScope<SecurityId> pipeScope = new PipeScope<SecurityId>(); 
    pipeScope.setPipeIdRegistry(pipeIdRegistry); 
    bindScope(Pipe.class, pipeScope); 
    bind(PipeScope.class) 
      .annotatedWith(Names.named("pipeScope")) 
      .toInstance(pipeScope); 
    SpringIntegration.bindAll(binder(), beanFactory); 

Le fait que je dois nouveau cela signifie que je dois fournir explicitement le registre au module, peut » t voir un moyen de contourner cela comme c'est un poulet & situation d'oeuf.

Le PipeScope stocke essentiellement des valeurs contre la clé de la conduite (en fait une liste des clés), par opposition à un ThreadLocal donc mon entrer est comme

public void enter(List<K> scopedKeys) { 
    checkState(values.get(scopedKeys) == null, "A scoping block is already in progress"); 
    values.put(scopedKeys, Maps.<Key<?>, Object>newHashMap()); 
} 

dans l'ensemble semble fonctionner parfaitement ... au moins dans mon harnais de test rapidement frappé de toute façon