Hi,
JAXB bildet die XML-Typen [c]date[/c] und [c]dateTime[/c] ja automatisch auf [c]XmlGregorianCalendar[/c] ab. Ich hätte stattdessen aber lieber ein [c]java.util.Date[/c]. Aus diesem Grund habe ich mir einen eigenen XmlAdapter geschrieben (angelehnt an diesen Blog):
Diesen (bzw. die beiden benötigten Methoden) binde ich über ein Binding-File in den xjc/wsimport-Aufruf ein:
[xml]
<jaxb:bindings version="1.0" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<jaxb:bindings>
<jaxb:globalBindings generateIsSetMethod="true">
<jaxb:javaType name="java.util.Date" xmlType="xs:date"
parseMethod="mein.pkg.DateAdapter.parseDate"
printMethod="mein.pkg.DateAdapter.printDate"/>
<jaxb:javaType name="java.util.Date" xmlType="xs:dateTime"
parseMethod="mein.pkg.DateAdapter.parseDate"
printMethod="mein.pkg.DateAdapter.printDate"/>
</jaxb:globalBindings>
</jaxb:bindings>
</jaxb:bindings>
[/xml]
Die generierten Java-Klassen enthalten nun nicht mehr [c]XmlGregorianCalendar[/c], dafür aber [c]java.util.Calendar[/c] und es werden zwei neue Adapter-Klassen erzeugt (je eine für date und dateTime) und verwendet, die eine Übersetzung zwischen String und Calendar vornehmen (à la [c]Adapter extends XmlAdapter<String, Calendar>[/c]). Mein binding-File wird also beachtet, aber nicht so interpretiert, wie ich mir das wünsche.
Wenn ich in der generierten Java-Klasse meinen eigenen Adapter manuell eintrage und die Typen entsprechend von Calendar zu Date ändere, funktioniert auch alles, wie es soll; der Adapter funktioniert also. Nur beim nächsten wsimport ist natürlich wieder alles kaputt. Weiterhin gibt es mehrere Stellen, an denen ich diese Änderung durchführen müsste.
Kennt jemand eine Lösung für dieses Problem? Im Netz habe ich auf die Schnelle leider keine Lösung gefunden.
Danke schonmal
mK
JAXB bildet die XML-Typen [c]date[/c] und [c]dateTime[/c] ja automatisch auf [c]XmlGregorianCalendar[/c] ab. Ich hätte stattdessen aber lieber ein [c]java.util.Date[/c]. Aus diesem Grund habe ich mir einen eigenen XmlAdapter geschrieben (angelehnt an diesen Blog):
Java:
public class DateAdapter extends XmlAdapter<String, Date> {
@Override
public Date unmarshal(String value) {
return parseDate(value);
}
@Override
public String marshal(Date value) {
return printDate(value);
}
public static String printDate(Date d) {
Calendar cal = new GregorianCalendar();
cal.setTime(d);
return DatatypeConverter.printDate(cal);
}
public static Date parseDate(String v) {
return DatatypeConverter.parseDate(v).getTime();
}
}
Diesen (bzw. die beiden benötigten Methoden) binde ich über ein Binding-File in den xjc/wsimport-Aufruf ein:
[xml]
<jaxb:bindings version="1.0" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<jaxb:bindings>
<jaxb:globalBindings generateIsSetMethod="true">
<jaxb:javaType name="java.util.Date" xmlType="xs:date"
parseMethod="mein.pkg.DateAdapter.parseDate"
printMethod="mein.pkg.DateAdapter.printDate"/>
<jaxb:javaType name="java.util.Date" xmlType="xs:dateTime"
parseMethod="mein.pkg.DateAdapter.parseDate"
printMethod="mein.pkg.DateAdapter.printDate"/>
</jaxb:globalBindings>
</jaxb:bindings>
</jaxb:bindings>
[/xml]
Die generierten Java-Klassen enthalten nun nicht mehr [c]XmlGregorianCalendar[/c], dafür aber [c]java.util.Calendar[/c] und es werden zwei neue Adapter-Klassen erzeugt (je eine für date und dateTime) und verwendet, die eine Übersetzung zwischen String und Calendar vornehmen (à la [c]Adapter extends XmlAdapter<String, Calendar>[/c]). Mein binding-File wird also beachtet, aber nicht so interpretiert, wie ich mir das wünsche.
Wenn ich in der generierten Java-Klasse meinen eigenen Adapter manuell eintrage und die Typen entsprechend von Calendar zu Date ändere, funktioniert auch alles, wie es soll; der Adapter funktioniert also. Nur beim nächsten wsimport ist natürlich wieder alles kaputt. Weiterhin gibt es mehrere Stellen, an denen ich diese Änderung durchführen müsste.
Kennt jemand eine Lösung für dieses Problem? Im Netz habe ich auf die Schnelle leider keine Lösung gefunden.
Danke schonmal
mK