2010-02-24 2 views
23

Ich habe com.sun.xml.bind.marshaller.NamespacePrefixMapper in meinem Projekt verwendet, und ich hatte kein Problem damit in JDK 6u17. Jetzt habe ich nur auf 6u18 aktualisiert, und ich sah, dass es com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper ersetzt wurde. Allerdings, wenn ich diese Klasse importieren und versuche, meine Klassen zu kompilieren, erhalte ich die Fehlermeldung:Was ist passiert mit JAXB NamespacePrefixMapper in JDK6u18

 
package com.sun.xml.internal.bind.marshaller does not exist 
import com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper; 

ich dieses Paket durch die Vervollständigungsfunktion NetBeans Code zugreifen kann, und NetBeans den Code nicht für Fehler markieren.

Jede Hilfe wäre willkommen!

Antwort

17

Ich glaube nicht, dass die Klasse com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper Ersatz von com.sun.xml.bind.marshaller.NamespacePrefixMapper ist, ersteres ist es für eine lange Zeit und es NICHT DURCH SIE AUF ALLE (daher die internal Verpackung) VERWENDET WERDEN BESTIMMT. Das Problem hier ist, dass JavaSE 6 nicht die JAXB RI hat (es hat eine JAXB-Implementierung, aber nicht JAXB RI). Wenn Sie sich also auf RI-spezifische Funktionen verlassen wollen, sollten Sie JAXB RI in Ihrer Anwendung bündeln (und.) das würde Sie vor JAXB-Änderungen in Java SE schützen).

+0

das klingt logisch, aber dann - warum sind diese Pakete da? – Bozho

+0

@Bozho Wie ich geschrieben habe, enthält Java 6 eine JAXB-Implementierung, die ** nicht ** JAXB RI ist. Wenn Sie sich also auf eine JAXB RI-spezifische Funktion verlassen wollen, sollten Sie sie bündeln. Ja, der Blogpost ist falsch, da der Autor explizit ein RI-spezifisches Feature verwendet hat (weshalb er Probleme mit JavaSE-Änderungen hatte, wie das OP). –

+0

@Bozho Es ist in der Tat. Aber diese 'interne' Verpackung sollte Sie zum Laufen bringen und nach einer anderen Lösung suchen. Die Verwendung von "internal" ist bestenfalls eine vorübergehende Lösung, Sie wissen einfach nicht, wann es kaputt gehen wird. –

4

Sie sollten com.sun.** Klassen nicht direkt verwenden. Sie gelten als intern und können ohne Vorankündigung geändert werden. (Und schau, was gerade passiert ist !!) Die Tatsache, dass die neue Klasse internal im Paketnamen hat, ist ein noch größerer Hinweis!

Ich schlage vor, dass Sie nach einer besseren Art zu tun suchen, was Sie tun ... das die Klassen com.sun.** nicht verwendet.

BEARBEITEN - hmmm, sieht aus wie wer für die JAXB verantwortlich ist RI hat die Sun-Regeln über Paketnamen für diese Erweiterung gebrochen! Und es ist auch bedauerlich, dass Sun diese spezielle RI-Erweiterung in JDK 6.0 nicht implementiert hat.

+1

In diesem Fall handelt es sich tatsächlich um ein API-Problem, da diese Funktion zur Ermittlung von Namespacepräfixen "angekündigt" wird und eine benutzerdefinierte Providereigenschaft ist. siehe http://java.sun.com/webservices/docs/1.5/jaxb/vendorProperties.html und http://fisheye5.atlassian.com/browse/~raw,r=1.600/jaxb-architecture-document/www/ doc/com/sun/xml/bind/marshaller/NamespacePrefixMapper.html – Bozho

+1

(mein Punkt ist - es gibt keinen besseren Weg, dies zu tun, und das ist ein wesentliches Merkmal) – Bozho

4

Sun hatte in diesem Fall etwas nicht ganz angemessen gemacht. Der Namespace-Mapper ist nicht in der Spezifikation enthalten, wird jedoch als eine Möglichkeit zum Anpassen von Präfixen "beworben". So ist die allgemeine Beratung „nicht com.sun.* verwenden“ gilt hier nicht, und die javadoc dieser Klasse sagt:

Implemented by the user application to determine URI -> prefix mapping.

Check this article und sehen, ob es für Sie funktionieren würde.

+0

Ich stimme nicht mit der vorgeschlagenen Lösung. Hier muss das OP explizit die JAXB RI Gläser mit seiner Anwendung bündeln (wie ich in meiner Antwort erkläre), "interne" Sachen sollen Sie abschrecken. –

+0

Wenn Sie sich den Quelltext von Sun's NamespacePrefixMapper.java anschauen, hat der Autor geschrieben: "Seien Sie vorsichtig beim Ändern dieser Klasse. Diese Klasse sollte von Benutzern erweitert werden und daher dürfen wir diesen Benutzercode nicht brechen. " Also ja, Sun verwirrt die Leute wirklich, indem er eine Klasse, die "von Benutzern erweitert werden soll", in ein internes Paket stellt. – vocaro

+2

Der Link "Diesen Artikel prüfen" ist ungültig. – koppor

13

Die NamespacePrefixMapper ist nicht mehr verwendbar.

die Anmerkungen in package-info.java Verwendung:

@javax.xml.bind.annotation.XmlSchema(namespace = "http://nameSpaceUri" 
, xmlns = { 
    @XmlNs(prefix = "myPrefix", namespaceURI = "http://nameSpaceUri") 
} 
, elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED) 

package my.package.; 

Das mit dem JAXB arbeitet mit JDK7 gebündelt, für andere JAXB Versions-Update JDK 2.2.4.

+0

Was passiert, wenn Sie einen WSDL-First-Ansatz verwenden? Wird Ihr Paket-info.java nicht jedes Mal von wsimport überschrieben, wenn Sie Ihr Projekt säubern? – Catchwa

+0

Wenn ich mich damit auseinandersetzen muss, kopiere ich den automatisch generierten Code in den Quellordner eines anderen Projekts. –

+1

Dies sollte die akzeptierte Antwort sein. – Tilo

1

Ich habe vor kurzem bei der Portierung etwas älteren Code in ein neues Projekt ran. Das alte Projekt hat mit Ameisen gut funktioniert, aber das neue Projekt ist mit dem oben erwähnten Fehler gescheitert.

Nach einigem Graben fand ich, dass der alte Build.XML-Datei eine javac-Compiler-Option verwendet die Einschränkung oben zu umgehen:

<javac srcdir="${srcDir}" destdir="${outputDir}" classpathref="classpath" debug="on"> 
    <compilerarg value="-XDignore.symbol.file" /> 
</javac> 

Nach der Feststellung, ich suchte und fand diese andere Stackoverflow Frage: Using internal sun classes with javac