Printemps @Autocâblés - Instancier de nouveaux bean

Besoin de l'aide avec le Printemps, permettra à l'autowiring, et étendues.

Ici est l'application de base structure:

  1. J'ai un CustomHttpClient, avec l'annotation @Component, et également tirant quelques config liées à des propriétés de l'application.fichier de propriétés (via @Valeur de l'annotation).
  2. CustomHttpClient est utilisé par plusieurs services dans mon application. Chaque fois que je suis en utilisant le CustomHttpClient, je autowire une instance de cette via: 
    @Autowired
private CustomHttpClient httpClient;
  3. - Je utiliser de l'intercepteur à modifier certaines des variables à l'intérieur de CustomHttpClient, comme suit: 
    public class MyInterceptor extends HandlerInterceptorAdapter {
@Autowired CustomHttpClient httpClient;

@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
httpClient.setSomeProperty(newValue);
...

Maintenant, ici, est le problème. Si j'ai tout configuré comme décrit ci-dessus, alors à chaque fois que je changer les réglages de la CustomHttpClient par interceptor, que la nouvelle valeur est conservée pour tous les autres clients, tant que la machine virtuelle est en cours d'exécution. Donc, quand je lance httpClient.setSomeProperty() - ce paramètre est maintenant définitivement sauvé. Même si je me connecte à l'application à partir d'un autre client.

Fondamentalement, ce que j'ai besoin de deux choses:

  1. Toujours être en mesure de remplacer les paramètres par défaut de la CustomHttpClient via l'intercepteur (intercepteur de demande, configuré via ).
  2. Assurez-vous qu'une nouvelle instance de CustomHttpClient est créé pour chaque requête (après l'intercepteur ne de sa magie).

J'ai tenté de changer le champ d'application de CustomHttpClient à @Scope("prototype"), mais de cette façon je ne peux plus modifier les paramètres de CustomHttpClient avec un intercepteur.

J'ai peut-être tort, mais je pense que le design est probablement erronée si vous avez besoin pour l'injection de ce prototype de composant réutilisable dont les propriétés vous avez besoin de modifier, conformément à la demande. Peut-être, c'est meilleur si vous le contrôle de la création et de la destruction manuellement. Après tout, pas tous les objets sont censés être injecté.
Hmmm, qui pourrait être un bon point. Mais si je n'ai pas autowire et injecter le composant, aurais-je encore être en mesure d'ajuster ses propriétés avec un intercepteur? Disons que je n'ai pas de contrôle sur le service qui utilise le composant, et ne peut modifier certaines propriétés via les en-têtes HTTP et/ou de la chaîne de requête params. C'est la principale raison pour laquelle je suis allé avec permettra à l'autowiring.
Si vous avez juste besoin d'ajuster les en-têtes et/ou des paramètres, pourquoi ne pas vous venez de modifier le HttpServletRequest/HttpServletResponse ? C'est pourquoi ils sont à votre disposition dans un intercepteur.
La modification de la demande serait l'idéal, mais je ne pense pas que je peux accéder à la demande de la portée de la CustomHttpClient sans permettra à l'autowiring que la première. Si j'ai mis la nouvelle en-tête de l'objet HttpServletRequest puis il est là pour ça, mais j'ai besoin de faire plus de traitement avec le Composant sous-jacent, où la CustomHttpClient vie.
Je vous ai fourni une réponse. Veuillez fournir des commentaires après l'examen. Laissez-moi savoir si cela a fonctionné pour vous.

OriginalL'auteur isyndicate | 2013-09-24

  1. 7

    Par défaut lorsque vous utilisez @Autowired printemps bean champ d'application est un singleton. Que signifie le printemps injecte le même objet singleton où jamais vous utilisez @Autowired. En faisant de la portée prototype, vous demandez Printemps pour créer de nouveaux objets pour chaque @Autocâblés injection, et donc dans votre intercepteur devra avoir sa propre copie de HttpClient et ne peux pas voir les autres HttpClient objets.

    Donc une meilleure approche est d'utiliser la portée singleton, Utiliser les attributs de la requête ou threadlocal pour transporter vos propriétés personnalisées à la demande thread. ie au lieu de modifier HttpClient propriétés de l'intercepteur, il suffit de définir certains attributs de la requête ou threadlocals et gérer ces paramètres personnalisés dans CustomHttpClient les méthodes de la classe.

    OriginalL'auteur ssk

  2. 1

    Si votre intercepteur est seulement addding certaines propriétés, puis à l'aide de fil devrait être une meilleure option. Vous pouvez appeler ThreadLocal.set(Carte personnalisée) et l'utiliser partout où vous le souhaitez pour le thread en cours d'exécution et que votre programme va sortir de votre contrôleur, vous pouvez appeler ThreadLocal.Unset qui va effacer la valeur stockée.

    De cette façon, vous n'aurez pas besoin d'une nouvelle instance de HttpcLient à chaque fois, aussi une nouvelle instance à chaque fois serait un grave défaut. Et vous serez en mesure d'utiliser votre carte personnalisée n'importe où vous voulez dans le thread en cours d'exécution.

    ThreadLocal semble être une très maladroits à l'approche de ce problème. Si vous allez utiliser le thread habitants vous DEVEZ assurez-vous d'annuler les modifications (par doit, je veux dire, très soigneusement l'utilisation de enfin les blocs).
    Ya Un besoin pour être sûr d'annuler la valeur de la thread local qui peut être garanti facilement en faire un personnalisé Session Gardien qui ne peut être invoquée à l'entrée et à la sortie. Mais cela présente des avantages en termes de facilité d'accès

    OriginalL'auteur Vineet Kasat

  3. 1

    Tous les haricots a déclaré au Printemps conteneur enther par XML ou par l'annotation de soutien sont, par défaut, les singletons. Si vous injecter un haricot avec champ d'application de prototype dans un singleton par exemple, un contrôleur, il va injecter en une seule fois. Il y a un moyen pour atteindre cet objectif. Voici comment vous devez déclarer un bean étendue comme un prototype. Cela signifie que le conteneur toujours de vous donner une nouvelle instance à chaque fois ce bean est appelé à partir du conteneur.

    <bean id="shoppingCart" class="example.ShoppingCart" scope="request">
     <aop:scoped-proxy />
</bean>
    Comme je l'ai mentionné dans ma question, j'ai essayé d'utiliser le prototype de la portée, mais qui défait le but de permettra à l'autowiring et de l'injection de propriétés par l'intercepteur. Parce que, comme un prototype, une nouvelle instance est créée à chaque fois, donc de perdre toutes les modifications apportées à partir de l'intercepteur.

    OriginalL'auteur Khush