Comment injecter un non-classe sérialisable (comme java.util.ResourceBundle) avec Soudure

Je veux créer un Producteur qui le rend possible d'injecter un java.util.ResourceBundle dans l'une des classes afin d'obtenir les Chaînes localisées facilement. Mon ResourceBundle-Producteur ressemble à ceci:

public class ResourceBundleProducer {
  @Inject       
  public Locale locale;

  @Inject       
  public FacesContext facesContext;

  @Produces
  public ResourceBundle getResourceBundle() {
    return ResourceBundle.getBundle("/messages", locale )
  }
}

L'Injection de paramètres Régionaux et FacesContext fonctionne (j'ai pris le correspondant pour les producteurs de la Couture 3 Source Alpha). Mais malheureusement, ResourceBundle n'est pas Sérialisable et, par conséquent, ne peuvent pas être produites de cette façon. J'obtiens l'Erreur suivante à partir de Soudure lorsque vous essayez d'accéder à un JSF-page qui appelle un haricot qui utilise mon ResourceBundle:


Caused by: org.jboss.weld.IllegalProductException: WELD-000054 Producers cannot produce non-serializable instances for injection into non-transient fields of passivating beans\\n\\nProducer\: org.jboss.weld.bean-/D:/Program Files (x86)/GlassFish-Tools-Bundle-For-Eclipse-1.2/glassfishv3/glassfish/domains/teachernews/applications/teachernews/-ProducerMethod-services.producers.ResourceBundleProducer.getResourceBundle()\\nInjection Point\: field web.PersonHome.bundle

Est-il possible d'obtenir mon ResourceBundleResolver de travail? Ou existe-il d'autres mécanismes pour obtenir une fonctionnalité similaire?
Merci à l'avance!

EDIT:

Bon, je vais passé une partie de ma peine le nombre de points gagnés 😉
Acceptera également une bonne solution de contournement pour ce problème!

J'ai reçu un autre exemple où la création d'un Producteur ne fonctionne pas: un FlashProducer. Un FacesContext-Flash ne peut pas être produit parce que Flash n'est pas sérialisable.

InformationsquelleAutor ifischer | 2010-06-08
  1. 25

    Bien, tout d'Abord ResourceBundle n'est pas Sérialisable. Voir ici. Et Le message est clair

    ne peut pas produire non sérialisable cas pour l'injection dans non transitoires champs de la passivation de haricots

    la passivation de haricots ??? Je Pense que web.PersonHome est un Stateful Session Bean ou un @ConversationScoped bean. Suis-je le droit ??? Si donc vous devriez marque de votre bundle propriété transitoire

    private transient @Inject ResourceBundle bundle;
    • avertissement: je n'utilise pas de Soudure encore. J'utilise pour la Couture. Donc, je ne suis pas sûr de savoir si annotation @Inject peut être utilisée avec la transitoire
    • Congratz, vous venez de gagner vous-même 50 points 😉 Enfin une solution! Me demande pourquoi il a fallu cette longue + une Prime, comme c'est un peu facile (me demande aussi pourquoi je n'ai pas trouvé par moi-même...). Juste testé, fonctionne aussi avec CDI/Soudure. Maintenant, je peux enfin injecter des regroupements resourcebundle et des Contextes.
    • BTW, PersonHome est un @ConversationScoped CDI/Soudure-Haricot (@Nom)
    • Vous êtes de droite. Parce que ConversationScoped doivent être sérialisables entre les demandes, tous les champs doivent implémente l'interface Serializable à moins que vous marquez comme transitoire. Elle explique pourquoi vous obtenez Le message d'erreur. Le même problème se produit avec Stateful Session beans.
    • Mais avec le bundle marqué comme transient, comment pouvez-vous être sûr qu'il est disponible lorsque vous en avez besoin? En cas de passivation/activation de la fève, la ResourceBundle est parti et l'accès à il serait rais une exception.
    • Belle prise. Je me demande même!
    • Après une seconde bien,, ResourceBundle n'est jamais autorisé à rester Null en tant que serveur d'application sera ré-injecter de nouveau une fois détecté comme Null. C'est une fonctionnalité de base de n'importe quel conteneur de mise en œuvre du Cio
    • mais CDI-injection est effectuée qu'une seule fois au moment de la création de la fève. Donc, le "contenant" (c'est à dire de Soudure) ne sera pas vérifiez les valeurs de ses champs après la passivation/activation. L'accès au terrain après passivation/activation entraînera une NullPointerException.
    • s'il vous plaît vérifier la réponse que j'ai ajouté
    • transient résout l'exception encore, mais je suis arriver un triangle d'avertissement sur les dépendances non satisfaites. Mon beans.xml a bean-discovery-mode="all" dans les deux projets (où le @Cached annotation et producteur de la classe et où le @Cached est @Inject), mais encore sur les deux côtés, je suis, comme pour @Inject private CacheManager manager;. Des idées?

    InformationsquelleAutor Arthur Ronald
  2. 3

    Que par les commentaires de thread dans la accepté de répondre à d'Arthur. J'ai suivi ce blog ainsi que cette une de réaliser une passivation/activation de l'expérience. L'expérience a prouvé MrD commentaire que le passage de la propriété sera NULLE au moment de l'activation. Ainsi, pour faire face à la non-sérialisable membre propriétés de passivation capable de haricots (à savoir, sessionscoped, conversationscoped et stateful session beans), je propose la solution suivante: 

    private ResourceBundle bundle;

@PostConstruct
@PostActivate
public void getResourceBundle() {
    bundle = ResourceBundle.getBundle("/messages", locale );
}

    Cette solution permet de s'assurer que la non-sérialisable les membres de la propriété sont réinitialisés à chaque fois qu'il entre dans l'état PRÊT.

    Un dernier problème à résoudre

    Un dernier point à aborder est l'injection d'un SLF4j Enregistreur qui était non sérialisable avant de slf4j 1.5.3, et Je cite:

    De SLF4J version 1.5.3, enregistreur instances de survivre à la sérialisation.
    Ainsi, la sérialisation de la classe d'accueil n'est plus spécial
    action, même lorsque les bûcherons sont déclarées comme variables d'instance.

    Ainsi, aussi longtemps que votre slf4j dépendance est 1.5.3 ou tard, vous pouvez en toute sécurité injecter un SLF4j Enregistreur comme suit:

    @Produces
@LogbackLogger
public Logger produceLogger(InjectionPoint injectionPoint){
    return LoggerFactory.getLogger(injectionPoint.getMember().getDeclaringClass().getName());
}

    En supposant que vous avez déclaré le qualifier:

    @Qualifier
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
public @interface LogbackLogger {
}

    Puis dans une passivation capable de haricot, injecter comme suit:

    @Inject
@LogbackLogger
private Logger logger;
    • Concernant le "producteur" pour ResourceBundle: si je comprends bien, vous êtes pas à l'aide d'un producteur pour la ResourceBundle plus - perdre le charme de CDI. Au lieu de cela, vous obtenez la ResourceBundle manuellement sur PostConstruct et -Activer les événements (btw: le PostConstruct et Activer des méthodes ne DOIT PAS retourner de valeur). Donc, c'est complètement non-CDI solution qui pourrait avoir été utilisé dans JEE5 trop, n'est-ce pas?
    • Absolument vrai!
    • J'ai édité la méthode d'initialisation de retour void. Merci pour votre oeil aiguisé.
    • Je suppose que l'annotation @PostConstruct doit être supprimée de sorte que vous pouvez toujours faire usage de CDI
    • J'aime votre suggestion. Je n'ai pas essayé mais... je me demande ce MrD va dire à ce sujet, il a été la bonne.
    • que pensez-vous de Armando suggestion?

    InformationsquelleAutor Sym-Sym