Si une requête en cascade se produit en hibernate, il peut y avoir des problèmes de chargement paresseux. Par exemple, j'ai maintenant une classe de compte (administrateur), une catégorie (catégorie de produit) et une classe de produit (produit). De gauche à droite, il s'agit d'une relation un à plusieurs, et de droite à gauche, @ManyToOne (fetch = fetchType.lazy) est définie. Je veux maintenant découvrir les informations du produit et les emballer au format JSON pour la transmettre à la réception. J'utilise l'instruction de requête en arrière-plan comme:
du produit p gauche jointer fetch p.category où p.name comme: nom
De cette façon, vous pouvez découvrir le produit, puis la catégorie du produit est également mise en place. Cependant, le compte dans la catégorie n'est pas un objet réel, mais un objet proxy temporaire. C'est facile à comprendre, car j'ai vérifié le produit et uniquement la catégorie en cascade. Quant à la catégorie et au compte, il est configuré en fonction du réel (paresseux).
Maintenant, mettez le produit de requête dans la carte, puis convertissez-le au format JSON et revenez à la réception, il y aura certainement un problème de chargement paresseux, car l'objet de compte sera pris pendant le processus de convertissage de JSON, mais la session a été fermée à ce moment, donc une erreur sera signalée. Une solution très directe mais pas très bonne consiste à changer la catégorie paresseuse en avide, afin que les informations du compte puissent être trouvées, mais ce n'est pas bon. Nous utilisons donc une autre méthode: définissez une liste noire dans strut.xml et utilisons des expressions régulières pour filtrer le compte en catégorie lors de la conversion au format JSON, nous ne vérifierons donc pas l'objet du compte, et il n'y aura pas de problème de chargement de paresse. comme suit:
À ce stade, il ne devrait y avoir aucun problème. Cependant, dans mon projet, je signale toujours des exceptions de chargement paresseux, ce qui signifie que cela ne fonctionne pas après avoir configuré de cette façon. Mais théoriquement, après la configuration, ce sera OK, et les données peuvent être emballées au format JSON et transmises normalement à la réception. Ce problème m'a dérangé pendant deux jours, donc j'ai simplement changé paresseux pour être impatient et j'ai commencé à faire le projet.
Aujourd'hui, j'ai contacté l'exception ici dans une autre exception en hibernate et je l'ai résolu! Aujourd'hui, dans Hibernate, je souhaite appeler la méthode GET pour obtenir les informations du produit, mais je ne peux pas l'obtenir. Il n'y a pas de message sur la console d'arrière-plan. Depuis que j'ai allumé le mode Dev, la réception a affiché le message d'erreur:
java.lang.classCastException: cn.it.shop.model.product _ $$ _ Javassist_0 ne peut pas être jeté sur javassist.util.proxy.proxy </span>
Vous ne pouvez pas être converti en proxy? ? Pourquoi passer à un agent? Généralement, les agents ne peuvent-ils pas être convertis en objets réels? J'ai donc fouillé sur Internet et j'ai constaté que ce problème peut être dû à un package Javassist dans le projet qui est en conflit. Je suis allé au projet pour le vérifier, et cela s'est avéré être vrai:
Il est vraiment en conflit ... donc je viens de supprimer le javassist-3.11.0.ga.jar dans le package Struts. Hibernate est correct et vous pouvez obtenir les informations du produit normalement. Ensuite, je me suis souvenu du problème de Struts2 passant à JSON il y a 2 jours, alors je suis retourné changer de retour à la paresse. Le problème avait disparu et je pouvais également me convertir à JSON normalement. J'étais déprimé. Il a été vraiment causé par le conflit entre les packages en pot. Parce qu'il n'y avait aucune erreur à ce moment-là, mais je n'ai pas trouvé les données JSON renvoyées sur la réception. Je savais seulement que les données JSON n'avaient pas été renvoyées. Ce doit être un problème avec le transfert d'arrière-plan vers JSON. Selon l'expérience existante, 90% de celle-ci était un chargement paresseux, mais je ne m'attendais pas à ce qu'elle soit causée par le conflit de paquets de pot.
Plus tard: si le package JAR ne se confond pas mais ne peut pas convertir JSON, c'est essentiellement un problème causé par le chargement paresseux. La méthode de filtrage des objets de chargement paresseux en configurant des listes noires dans struts.xml est très pratique. Il n'est pas nécessaire de modifier la configuration dans POJO. Je vais transférer les champs que je souhaite transférer à JSON, et si je ne veux pas, c'est très pratique.
Lien original: http://blog.csdn.net/eson_15/article/details/51394302
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.