J'essaie de migrer une application Playframework de 2,4 à 2.5.3 et j'ai des problèmes pour obtenir des valeurs à partir de avant Obtenir une valeur de maintenant comme Quand je suive ces instructions sur mon contrôleur mais quand j'essaie de l'utiliser sur un autre objet de classe de Mon projet, l'injection de dépendance ne fonctionne pas et je reçois toujours un peut-il me donner un exemple sur la manière d'obtenir des valeurs à partir de Une partie de mon code Java où j'essaie d'utiliser le di: et j'ai toujours une exception de pointeur null , à la ligne avec Application.conf Fichier: Application.conf Ce que je fais était: play.application () est obsolète, je devrais utiliser l'injection de dépendance. Basé sur le Documentation de cadre J'utilise les instructions suivantes:
javax.inject. *; Importer la lecture.configuration;
@Inject configuration de configuration privée;
Application.java Il fonctionne parfaitement: nullpointerexception . Application.conf Utilisation d'une injection de dépendance? configuration.getstring ("ecipedfile.path")
5 Réponses :
Essayez avec l'injection de constructeur à la place:
import javax.inject.Inject;
import play.Configuration;
import play.Logger;
public class Zipper {
private Configuration configuration;
@Inject
public Zipper(Configuration config) {
this.configuration = config;
}
public void unZip(String zipFilePath) {
Logger.debug("Display : zipFilePath"+zipFilePath);
Logger.debug("before call parameter from application.conf");
Logger.debug("configuration.getString = "+configuration.getString("Unzipedfile.path"));
Logger.debug("aftercall parameter from application.conf");
}
}
J'ai vu de cette façon, mais cela ne semble pas correspondre à mon besoin.
J'ai vu de cette façon, mais cela ne semble pas correspondre à mon besoin. Parce que si je mettais à jour mon constructeur, cela signifie que sur ma classe Java appelante, je devrai initier ce nouveau paramètre, non? Avec une truc comme cette fermeture à glissière ZipTest = nouvelle fermeture à glissière (Conf) et Conf devront être initiées dans ma classe Java appelante, j'aimerais éviter cette situation et, dans ce cas, l'injection de classe à glissière n'est pas utile, non? Peut-être que je me trompe, pouvez-vous me montrer comment appeler la classe à glissière avec votre proposition?
De plus, comme je l'ai dit injecter des champs privés travaille avec l'application du contrôleur.java, j'ai ce numéro uniquement sur toutes les autres classes Java
Comment utilisez-vous la catégorie ZIPPER ? Pourriez-vous s'il vous plaît modifier votre question à la façon dont il est instancié et utilisé?
THX pour votre aide, j'ai enfin trouvé mon erreur et mettre des détails ci-dessous
Essayez d'annoter votre classe avec Singleton afin que la lecture puisse détecter votre haricot pour injecter vos ressources.
J'ai mis ici la réponse, afin d'aider n'importe qui avec le même problème
Mon erreur est venue de la façon dont j'ai l'habitude d'instancier ma classe Java à glissière de ma classe d'appel.
thx to igmar Palsenberg, il m'a fourni la réponse: https://groups.google.com/forum /? utm_medium = e-mail et utm_source = pied de page #! Topic / Play-Framework / ULFQTM9_IY4
J'ai utilisé
Votre appelant de classe est-il un test?
NOP, juste une classe d'assistance et une classe à glissière était une classe UTIL, ma compréhension est que lorsque j'utilise la fermeture à glissière Ziptest = nouvelle fermeture à glissière (), je perds le mécanisme d'injection de dépendance. afin de le garder, je dois utiliser l'injecteur.Instance au lieu de nouveaux
Alors, pourquoi ne pas injecter zipper dans cette classe à la place?
Parce que ma cible consistait à mettre à jour mon code de 2.4 à 2.5.3 et être en mesure d'atteindre des paramètres de l'application.conf de toutes mes classes où j'en ai besoin. De plus, l'injection de dépendance est un nouveau modèle pour moi .. Inconnu avant dimanche dernier ... Maintenant, mon code fonctionne, je dois le refroidir, pour correspondre vraiment au modèle DI.
L'utilisation d'une injection de dépendance uniquement à une partie du code rendra plus difficile. Je veux dire, vous aurez deux méthodes d'instancier des objets. Cela semble plus compliqué pour moi.
Je suis d'accord, :) Je sais que je devrai refacturer mon code.
Je demande parce qu'il y a deux manières possibles que vous obtenez l'objet d'application utilisé pour instancier fermeture à glissière . 1) Vous utilisez play.application.application () qui est obsolète ou 2) que vous injecte une application . Si vous faites 2, pourquoi ne pas injecter directement zipper à la place? ;-)
Je pense que vous pouvez initialiser la configuration comme ceci:
import javax.inject.Inject;
import play.Configuration;
import play.Logger;
public class Zipper {
private Configuration configuration = Play.current().injector().instanceOf(Configuration .class);
public void unZip(String zipFilePath) {
Logger.debug("Display : zipFilePath"+zipFilePath);
Logger.debug("before call parameter from application.conf");
Logger.debug("configuration.getString = "+configuration.getString("Unzipedfile.path"));
Logger.debug("aftercall parameter from application.conf");
}
}
Vous devriez essayer de supprimer au lieu de: privé .
Utilisation:
Postez le code qui ne fonctionne pas.
J'ai mis à jour comme demandé.
Le même type de code travaille sur mon application contrôleur.java, mais jamais sur mes autres classes Java.
Vous ne pouvez pas injecter dans des classes arbitraires qui n'ont pas été créées par DI eux-mêmes ou n'ont pas été introduites dans le contexte de Guice. Si votre fermeture à glissière de classe a été créée par Guice ou injectée quelque part, vous auriez le contexte à injecter. Voir Stackoverflow.com/a/32896354/1956540
Oui, tu es totalement correct, c'était mon erreur, je mets des détails ci-dessous