1. Inicio
  2. Pregunta y respuesta
  3. ¿Qué pasó con JAXB NamespacePrefixMapper en JDK6u18

¿Qué pasó con JAXB NamespacePrefixMapper en JDK6u18

2010-02-24 20 views
23

He estado usando com.sun.xml.bind.marshaller.NamespacePrefixMapper en mi proyecto, y no tuve ningún problema con él en JDK 6u17. Ahora acabo de actualizar a 6u18, y vi que se ha reemplazado a com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper. Sin embargo, si puedo importar esta clase y intento compilar mis clases, me sale el error:¿Qué pasó con JAXB NamespacePrefixMapper en JDK6u18

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

puedo acceder a este paquete a través de la función de finalización de código de NetBeans, y NetBeans no resalta el código de errores.

¡Cualquier ayuda sería apreciada!

Fuente

2010-02-24 Daniel Szalay

Respuesta

17

no creo que la clase com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper es un reemplazo de com.sun.xml.bind.marshaller.NamespacePrefixMapper, el primero es allí durante mucho tiempo y que NO destinado a ser utilizado por usted en TODO (de ahí el internal embalaje).

El problema aquí es que JavaSE 6 no tiene JAXB RI (tiene una implementación JAXB pero no JAXB RI) así que si desea confiar en la función específica de RI, debe agrupar JAXB RI en su aplicación (y eso lo protegería de los cambios de JAXB en Java SE).

Fuente

2010-02-24 14:01:17

+0

que suena lógico, pero entonces - ¿por qué están estos paquetes allí? – Bozho

+0

@Bozho Como escribí, Java 6 incluye una implementación JAXB que ** no es ** JAXB RI, por lo que si desea confiar en una función específica de JAXB RI, debe agruparla. Así que sí, la publicación del blog es incorrecta ya que el autor estaba usando explícitamente una función específica de RI (razón por la cual se enfrentó a problemas con los cambios de JavaSE, como el OP). –

+0

@Bozho Es de hecho. Pero ese embalaje "interno" debe hacer que corras y busques otra solución. Usar 'internal' es, en el mejor de los casos, una solución temporal, simplemente no sabes cuándo se romperá. –

4

Se supone que usted no debe usar las clases com.sun.** directamente. Se consideran internos y están sujetos a cambios sin previo aviso. (¡¡Y mira lo que acaba de pasar !!) ¡El hecho de que la nueva clase tenga internal en el nombre del paquete es una pista aún más grande!

Sugiero que busque una forma mejor de hacer lo que está haciendo ... que no utiliza las clases com.sun.**.

EDIT - hmmm, parece que quienquiera que sea el responsable de JAXB RI ha infringido las reglas de Sun sobre los nombres de los paquetes para esa extensión. Y también es desafortunado que Sun no haya implementado esta extensión de RI en particular en JDK 6.0.

Fuente

2010-02-24 13:08:38

+1

en este caso se trata de un problema API en realidad, porque esta característica se "anuncia" como una forma de determinar prefijos de espacio de nombres, y también es una propiedad de proveedor personalizado. ver http://java.sun.com/webservices/docs/1.5/jaxb/vendorProperties.html y http://fisheye5.atlassian.com/browse/~raw,r=1.600/jaxb-architecture-document/www/ doc/com/sun/xml/bind/marshaller/NamespacePrefixMapper.html – Bozho

+1

(mi punto es que no hay mejor manera de hacerlo, y esta es una característica esencial) – Bozho

4

Sun hizo algo no muy apropiado en este caso. El asignador de espacios de nombres no está incluido en la especificación, pero se "anuncia" como una forma de personalizar prefijos. Por lo que el consejo general "no utilice com.sun.*" no se aplica aquí, y el javadoc de esta clase dice:

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

Check this article y ver si funcionaría para usted.

Fuente

2010-02-24 13:20:48 Bozho

+0

No estoy de acuerdo con la solución sugerida. Aquí, el OP explícitamente necesita agrupar los jarros JAXB RI con su aplicación (como explico en mi respuesta), las cosas "internas" están destinadas a asustarlo. –

+0

Además, si observa el código fuente en Sun's NamespacePrefixMapper.java, el autor ha escrito: "tenga cuidado con el cambio de esta clase. Se supone que los usuarios deben extender esta clase y, por lo tanto, no podemos romper ese código de usuario. " Así que sí, Sun realmente está confundiendo a las personas al colocar una clase que "los usuarios deben extender" en un paquete interno. – vocaro

+2

El enlace "Comprobar este artículo" está muerto. – koppor

13

El NamespacePrefixMapper ya no se puede usar.

Use las anotaciones en package-info.java:

@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.;

Esto funciona con la JAXB incluido con JDK7, por otra JAXB versión de actualización del JDK 2.2.4.

Fuente

2011-10-05 13:45:53

+0

¿Qué sucede si está utilizando un enfoque WSDL primero? ¿No va a anular su 'package-info.java' por wsimport cada vez que limpie su proyecto? – Catchwa

+0

Cuando tengo que enfrentar eso, solo copio el código autogenerado a la carpeta fuente de otro proyecto. –

+1

Esta debería ser la respuesta aceptada. – Tilo

1

Me encontré con esto recientemente cuando transfiero un código anterior a un nuevo proyecto. El viejo proyecto compiló muy bien usando hormiga, sin embargo, el nuevo falló con el error mencionado anteriormente.

Después de algunas excavaciones, encontré que la construcción anterior.archivo XML utiliza una opción del compilador javac para eludir la restricción anterior:

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

Después de encontrarlo, busqué y encontré esta otra pregunta StackOverflow: Using internal sun classes with javac

Fuente

2012-05-21 13:58:31 Travis

Cuestiones relacionadas

 Cuestiones relacionadas