Trick sur les interférences wsimport/wsgen et JAXB

[Sylvain RICHET]

Bonjour à Tous,

J'ai un WebService, avec une WSDL qui ne doit plus varier dans sa version
actuelle.
("ne doit plus varier" ? ==> les signatures de méthodes de ma SEI)

Or je viens de prendre conscience que sur une List d'une de mes classes, il
fallait que j'ajoute une annotation *@XmlElementWrapper* pour satisfaire un
mapping XML ==> JAVA via JAXB.

# Voici la classe annotée JAXB :

@XmlRootElement
public class DbiLayoutItem {

@XmlElement(required = true)
protected String label;

@XmlElementWrapper(name="items") <== ma personnalisation
@XmlElement(name="dbiLayoutItem") <== " "
//@XmlElement(name="items") <== version initiale
protected List<DbiLayoutItem> items;

[...]
}

*# WSIMPORT/WSGEN, qui s'appuie sur JAXB, est sensible aux annotations JAXB.
*
Du coup, lors de la génération des classes clientes via ces tools, une
nouvelle inner class "Items" apparait, dans la classe cliente/proxy
"DbiLayoutItem" :

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "dbiLayoutItem", namespace =
"urn:NETIA:schema:SEARCH_LAYOUT", propOrder = {
"label",
"items",
[...]
})
public class DbiLayoutItem {

@XmlElement(required = true)
protected String label;

protected DbiLayoutItem.Items items; <== !
[...]


@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
"dbiLayoutItem"
})
public static class Items {

protected List<DbiLayoutItem> dbiLayoutItem;
[...]
}
}

*# Ze problème :*
*ça vient péter mon contrat de WSDL, par rapport à ce qu'il y avait
auparavant sans l'annotation @XmlElementWrapper.*

# D'où ma question :
*comment faire pour éviter la génération de cette inner class supplémentaire
?*

En effet, je voudrais que WSIMPORT/WSGEN me garde la définition initiale de
la liste dans ma classe cliente "DbiLayoutItem" :
public class DbiLayoutItem {

@XmlElement(required = true)
protected String label;

protected List<DbiLayoutItem> items; <== pas d'inner class
[...]
}


Dès à présent, je vais fouiller un peu du côté de la "customisation JAXB"...
mais ça n'est pas dit du tout que cela soit possible.

Si l'un d'entre Vous est interpellé (ou a une idée, ou a été confronté à une
problèmatique similaire)
merci d'avance

[Sylvain RICHET]

Quand je dis* WSIMPORT/WSGEN*, ... en fait il s'agit surtout de
*WSIMPORT*(une task ANT fournit dans le fichierjaxws-tools.jarde la
library JAX-WS)

;-)

---------- Message transféré ----------
De : Sylvain RICHET <***@gmail.com>
Date : 27 septembre 2011 14:45
Objet : Trick sur les interférences wsimport/wsgen et JAXB
À : JAVA_ML_USTRASBG <***@u-strasbg.fr>


Bonjour à Tous,

J'ai un WebService, avec une WSDL qui ne doit plus varier dans sa version
actuelle.
("ne doit plus varier" ? ==> les signatures de méthodes de ma SEI)

Or je viens de prendre conscience que sur une List d'une de mes classes, il
fallait que j'ajoute une annotation *@XmlElementWrapper* pour satisfaire un
mapping XML ==> JAVA via JAXB.

# Voici la classe annotée JAXB :

@XmlRootElement
public class DbiLayoutItem {

@XmlElement(required = true)
protected String label;

@XmlElementWrapper(name="items") <== ma personnalisation
@XmlElement(name="dbiLayoutItem") <== " "
//@XmlElement(name="items") <== version initiale
protected List<DbiLayoutItem> items;

[...]
}

*# WSIMPORT/WSGEN, qui s'appuie sur JAXB, est sensible aux annotations JAXB.
*
Du coup, lors de la génération des classes clientes via ces tools, une
nouvelle inner class "Items" apparait, dans la classe cliente/proxy
"DbiLayoutItem" :

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "dbiLayoutItem", namespace =
"urn:NETIA:schema:SEARCH_LAYOUT", propOrder = {
"label",
"items",
[...]
})
public class DbiLayoutItem {

@XmlElement(required = true)
protected String label;

protected DbiLayoutItem.Items items; <== !
[...]


@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
"dbiLayoutItem"
})
public static class Items {

protected List<DbiLayoutItem> dbiLayoutItem;
[...]
}
}

*# Ze problème :*
*ça vient péter mon contrat de WSDL, par rapport à ce qu'il y avait
auparavant sans l'annotation @XmlElementWrapper.*

# D'où ma question :
*comment faire pour éviter la génération de cette inner class supplémentaire
?*

En effet, je voudrais que WSIMPORT/WSGEN me garde la définition initiale de
la liste dans ma classe cliente "DbiLayoutItem" :
public class DbiLayoutItem {

@XmlElement(required = true)
protected String label;

protected List<DbiLayoutItem> items; <== pas d'inner class
[...]
}


Dès à présent, je vais fouiller un peu du côté de la "customisation JAXB"...
mais ça n'est pas dit du tout que cela soit possible.

Si l'un d'entre Vous est interpellé (ou a une idée, ou a été confronté à une
problèmatique similaire)
merci d'avance

[Laurent Forêt]

Excuse j'ai lu en diagonale, mais ça me fait penser à du bindings JAXB, qui
te permet faire coïncider un élément à ta propre classe et squizz celle qui
t'a été généré automatiquement.

My quarter cent.

Laurent Forêt
http://www.devcoop.fr,
http://laurentforet.org
IvyBeans Creator
Membre du JUG Bordeaux

Post by Sylvain RICHET
Bonjour à Tous,
J'ai un WebService, avec une WSDL qui ne doit plus varier dans sa version
actuelle.
("ne doit plus varier" ? ==> les signatures de méthodes de ma SEI)
Or je viens de prendre conscience que sur une List d'une de mes classes, il
un mapping XML ==> JAVA via JAXB.
@XmlRootElement
public class DbiLayoutItem {
@XmlElement(required = true)
protected String label;
@XmlElementWrapper(name="items") <== ma personnalisation
@XmlElement(name="dbiLayoutItem") <== " "
protected List<DbiLayoutItem> items;
[...]
}
*# WSIMPORT/WSGEN, qui s'appuie sur JAXB, est sensible aux annotations
JAXB.*
Du coup, lors de la génération des classes clientes via ces tools, une
nouvelle inner class "Items" apparait, dans la classe cliente/proxy
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "dbiLayoutItem", namespace =
"urn:NETIA:schema:SEARCH_LAYOUT", propOrder = {
"label",
"items",
[...]
})
public class DbiLayoutItem {
@XmlElement(required = true)
protected String label;
protected DbiLayoutItem.Items items; <== !
[...]
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
"dbiLayoutItem"
})
public static class Items {
protected List<DbiLayoutItem> dbiLayoutItem;
[...]
}
}
*# Ze problème :*
*ça vient péter mon contrat de WSDL, par rapport à ce qu'il y avait
*comment faire pour éviter la génération de cette inner class
supplémentaire ?*
En effet, je voudrais que WSIMPORT/WSGEN me garde la définition initiale de
public class DbiLayoutItem {
@XmlElement(required = true)
protected String label;
protected List<DbiLayoutItem> items; <== pas d'inner class
[...]
}
Dès à présent, je vais fouiller un peu du côté de la "customisation
JAXB"... mais ça n'est pas dit du tout que cela soit possible.
Si l'un d'entre Vous est interpellé (ou a une idée, ou a été confronté à
une problèmatique similaire)
merci d'avance

[Sylvain RICHET]

---------- Message transféré ----------
De : Sylvain RICHET <***@gmail.com>
Date : 28 septembre 2011 11:07
Objet : Re: Trick sur les interférences wsimport/wsgen et JAXB
À : Laurent Forêt <***@gmail.com>


Salut Laurent,

Les JAXB Bindings, c'est effectivement de cela dont je parlais quand je
disais que j'allais chercher du côté Customization JAXB...
;-)

Le 27 septembre 2011 16:18, Laurent Forêt <***@gmail.com> a écrit
:

Excuse j'ai lu en diagonale, mais ça me fait penser à du bindings JAXB, qui

Post by Laurent Forêt
te permet faire coïncider un élément à ta propre classe et squizz celle qui
t'a été généré automatiquement.
My quarter cent.
Laurent Forêt
http://www.devcoop.fr,
http://laurentforet.org
IvyBeans Creator
Membre du JUG Bordeaux

Post by Sylvain RICHET
Bonjour à Tous,
J'ai un WebService, avec une WSDL qui ne doit plus varier dans sa version
actuelle.
("ne doit plus varier" ? ==> les signatures de méthodes de ma SEI)
Or je viens de prendre conscience que sur une List d'une de mes classes,
satisfaire un mapping XML ==> JAVA via JAXB.
@XmlRootElement
public class DbiLayoutItem {
@XmlElement(required = true)
protected String label;
@XmlElementWrapper(name="items") <== ma personnalisation
@XmlElement(name="dbiLayoutItem") <== " "
protected List<DbiLayoutItem> items;
[...]
}
*# WSIMPORT/WSGEN, qui s'appuie sur JAXB, est sensible aux annotations
JAXB.*
Du coup, lors de la génération des classes clientes via ces tools, une
nouvelle inner class "Items" apparait, dans la classe cliente/proxy
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "dbiLayoutItem", namespace =
"urn:NETIA:schema:SEARCH_LAYOUT", propOrder = {
"label",
"items",
[...]
})
public class DbiLayoutItem {
@XmlElement(required = true)
protected String label;
protected DbiLayoutItem.Items items; <== !
[...]
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
"dbiLayoutItem"
})
public static class Items {
protected List<DbiLayoutItem> dbiLayoutItem;
[...]
}
}
*# Ze problème :*
*ça vient péter mon contrat de WSDL, par rapport à ce qu'il y avait
*comment faire pour éviter la génération de cette inner class
supplémentaire ?*
En effet, je voudrais que WSIMPORT/WSGEN me garde la définition initiale
public class DbiLayoutItem {
@XmlElement(required = true)
protected String label;
protected List<DbiLayoutItem> items; <== pas d'inner class
[...]
}
Dès à présent, je vais fouiller un peu du côté de la "customisation
JAXB"... mais ça n'est pas dit du tout que cela soit possible.
Si l'un d'entre Vous est interpellé (ou a une idée, ou a été confronté à
une problèmatique similaire)
merci d'avance