Lorsque vous utilisez plusieurs arguments dans un @mapper, il semble que les arguments @Context sont inaccessibles
public interface MyMapper { @Mapping(target="target1", source="arg1.arg") //works @Mapping(target="target2", source="arg2") //works @Mapping(target="target3", source="arg2.arg") //works @Mapping(target="target2", source="context.arg") //NOT WORKING public MyTarget convert(Object arg1, Object arg2, @Context Object context); }
3 Réponses :
Par définition A Voici un problème de GitHub associé avec réponse officielle: GitHub Issue P > @Context code> objet annoté n'est pas une source. C'est du contexte pour que vous ne puissiez pas l'utiliser comme
source code> dans le
@ Mapping (cible = "cible2", source = "context.arg") code> p> p>
Et comment atteindre le comportement souhaité alors?
Supprimer le @Context code> et montroptract le considérera comme un objet source. En marquant
@Context Code> Vous dites essentiellement à MODRUCTRUT d'ignorer le paramètre de mappage, mais transmettez-le dans les appels de méthode sous-jacents. De plus, bien que MapStructeur puisse gérer plusieurs arguments de source, il ne peut pas appeler plusieurs méthodes de paramètre source pour gérer les mappages imbriqués. L'API deviendrait imprévisible et le mécanisme de sélection serait venu à manifester.
Votre suggestion fonctionne si j'ai besoin de paramètre au même endroit. Mais si j'ai besoin de paramètre sur les deux couches, je devrai effectuer une carte (source source, param param, @Context paramam param) code> ce qui n'a aucun sens pour moi. Ce serait beaucoup plus facile de ne pas ignorer Paramètre de contexte pour la cartographie ..
La raison est indiquée dans mon commentaire ci-dessus. Cependant, vous pouvez coller à l'approche code> @context code> par délégation vers une deuxième méthode et un @AfterMapping code>.
Oui, j'ai vu cette approche quelque part dans la documentation officielle. Je ne comprends tout simplement pas pourquoi les créateurs ne veulent pas inclure le contexte dans la cartographie. Pourquoi ils l'excluent? Des idées?
Contexte == Par définition Contexte .. Pas un paramètre source. Son seul but est ignoré par la cartographie
Eh bien, c'est la définition de l'équipe de Mapstruit. Le contexte est quelque chose à utiliser comme contexte pour toutes les méthodes de la toute première méthode où elle est transmise. Pensez à un contexte de travail par lots ou à autre chose. La toute première classe qui a contemplé est passée comme argument est plus bienvenue pour lire ou mettre quelque chose au contexte. La question de MapStract est que l'argument de niveau supérieur ne peut pas être effectué de contexte dans le paramètre de contexte en aval et au contexte ne peut pas être utilisé comme source dans la première cartographie. Je comprends toutes les définitions et les contours de contournement, mais cela ne me convient pas. Merci pour une discussion précieuse, appréciez que
Pour répondre à votre deuxième question:
public interface MyMapper { @Mapping(target="target1", source="arg1.arg") @Mapping(target="target2", ignore = true ) // leave to after mapping MyTarget convert(Object arg1, @Context Object context); @AfterMapping default convert(Object arg1, @MappingTarget MyTarget target, @Context context) { target.setTarget2( convert ( context ) ); } // if you have multipe mappings, you could address them here @Mapping(target="target2", source="context.arg") MyInnerTarget convert(Object arg1, Object context); }
J'ai couru dans le même scénario que j'avais besoin d'un @Context code> param pour pouvoir passer à une fonction de mappage imbriquée, mais souhaitait également l'utiliser comme source dans un
@ Mapping code>. J'ai pu atteindre cet article en utilisant
expression code> comme suit:
Pourquoi avez-vous besoin de passer un
@Context code> et utilisez-le comme source? Pouvez-vous fournir un peu plus de contexte?