clase java utilizando api jaxb que falla en jira con: proveedor com.sun.xml.bind.v2.ContextFactory no encontrado

Question

Estoy escribiendo un complemento para Jira que implica el análisis de documentos XML. Estoy usando JAXB para hacerlo (XML a pojos y viceversa) Así que tenga una clase que genere XML desde pojos usando JAXB. parece que ...

import javax.xml.bind.*; 

Class Parser { 
    public void m1() { 
    ... 
    // code which uses classes in javax.xml.bind.* 
    } 

    public static void main(String args[]){ 
    Parser p=new Parser(); 
    p.m1(); 

    } 
} 

Los paquetes mencionados vienen con la distribución de JDK (rt.jar). así que no he transmitido nada más para ejecutar la clase.

cuando lo ejecuto desde la línea de comando usando 'java' está funcionando correctamente. pero, cuando Empaqueto como un frasco y ponerlo como complemento en Jira está fallando con el error siguiente

javax.xml.bind.JAXBException: Provider com.sun.xml.bind.v2.ContextFactory not found 
- with linked exception: 
[java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory] 
     at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:152) 
     at javax.xml.bind.ContextFinder.find(ContextFinder.java:299) 
     at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372) 
     at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337) 

Ésta es en la misma máquina. La única diferencia que pude ver es diferente al lanzamiento desde la línea de comandos, cuando lo implementé en Jira, no está llamando al main() sino a m1() al crear instancias.

¡Me pregunto qué está pasando! está en la misma máquina. No sé cómo Jira lanza la aplicación (ya que estoy lanzando desde la línea de comandos).

Answer 1

El paquete com.sun.xml.bind es parte de JAXB RI (http://jaxb.dev.java.net/), por lo que probablemente tenga eso en su classpath en algún lado.

Java6 tiene su propia versión de JAXB incluida, en el paquete com.sun.xml.internal.bind, por lo que no suele necesitar el RI en Java6.

La RI puede hecha para funcionar con Java6, pero es una batalla cuesta arriba, y generalmente termina con este tipo de problema.

Answer 2

Finalmente pude averiguar el motivo.

Hay muchos ClassLoaders involucrados al cargar los complementos en JIRA (Felix). que no se delegará en 'bootstrap' ClassLoader. Y de ahí el problema.

para saber qué ClassLoader cargado la clase JAXBContext, utilice JAXBContext.class.getClassLoader() que imprimirá alguna Felix ClassLoader.

Cargó la clase desde jaxb-api.jar en lugar de confiar en rt.jar pero implementaron las clases ligeramente diferentes. rt.jar versión utiliza com.sun.xml.bind.internal.v2.ContextFactory donde jaxb-api versión utiliza com.sun.xml.bind.v2.ContextFactory.

Puedo resolver el problema utilizando el método superpuesto de JAXB que tomará otro parámetro como ClassLoader.

Me llevó bastante tiempo. Pero, estoy sorprendido por los detalles internos & mi ignorancia

Answer 3

Sé que esto es una especie de respuesta tardía, pero para las personas que aterrizan aquí hay algunas cosas que no se mencionan en las otras publicaciones que son importantes cuando se desarrollan plug-ups ins para JIRA (y otros productos Atlassian).

Primera JIRA, o más bien Atlassian, tiene dos tipos de plug-ins, ver Differences between Plugins1 and Plugins2

Ya que era un ClassNotFoundException (y v4.0.1 JIRA), I asumir el plug-in es un Plugin2, que puede ser utilizado en JIRA v4 y más tarde.

De JIRA v4, JIRA actúa como un contenedor OSGi, y por lo tanto, Plugin2 es un paquete OSGi. En OSGi cada paquete tiene su propio conjunto de cargadores de clases. Esto permite que diferentes paquetes tengan diferentes versiones de los mismos archivos jar, y que se implementen en caliente, entre otras cosas. Sin embargo, la trampa es que no todos los paquetes del JDK están disponibles por defecto para estos cargadores de clases. Esto se explica en Plugins, bundles and OSGi en el Atlassian Developers web page. Una descripción más detallada se puede encontrar en el blog Exposing the boot classpath in OSGi en Springsource. El segundo párrafo incluso tiene el título NoClassDefFoundError: com.sun ...

Tanto para la teoría.

Al desarrollar un plug-in para JIRA con el SDK de Atlassian, Maven se utiliza detrás de escena, ver Atlassian Plugin SDK Documentation. Por lo tanto, habrá un pom.xml en el proyecto del complemento. Para incluir paquetes de JDK en el plugin, se puede añadir una etiqueta <SystemProperties> a la experto-jira-plugin (para otros productos de Atlassian, hay un plugin Maven correspondiente), y establezca el propiedad bootdelegation (y usted posible que quiera establecer java a 1.6 para los experto-compilador-plugin):

... 
<build> 
    <plugins> 
     <plugin> 
      <groupId>com.atlassian.maven.plugins</groupId> 
      <artifactId>maven-jira-plugin</artifactId> 
      <version>3.7.3</version> 
      <extensions>true</extensions> 
      <configuration> 
       <productVersion>${jira.version}</productVersion> 
       <productDataVersion>${jira.data.version}</productDataVersion> 
       <systemProperties> 
        <property> 
         <name>atlassian.org.osgi.framework.bootdelegation</name> 
         <value>sun.*,com.sun.*</value> 
        </property> 
       </systemProperties> 
      </configuration> 
     </plugin> 
     <plugin> 
      <artifactId>maven-compiler-plugin</artifactId> 
      <configuration> 
       <source>1.6</source> 
       <target>1.6</target> 
      </configuration> 
     </plugin> 
     ... 
    </plugins> 
</build> 
... 

los paquetes listados estarán disponibles para el paquete. Tenga en cuenta, sin embargo, que la delegación de arranque no es una solución para solucionarlo, y solo debe usarse con restricciones. Obtenga más información en Boot Delegation y Avoid Classloader Hacks.

Bajo las dependencias, se puede establecer la versión jaxb-api necesario:

... 
<dependencies> 
    <dependency> 
     <groupId>com.atlassian.jira</groupId> 
     <artifactId>atlassian-jira</artifactId> 
     <version>${jira.version}</version> 
     <scope>provided</scope> 
    </dependency> 
    <dependency> 
     <groupId>com.atlassian.plugins.rest</groupId> 
     <artifactId>atlassian-rest-common</artifactId> 
     <version>2.5.0</version> 
    </dependency> 
    <dependency> 
     <groupId>javax.xml.bind</groupId> 
     <artifactId>jaxb-api</artifactId> 
     <version>2.2.4</version> 
     <scope>provided</scope> 
    </dependency> 
    ... 
</dependencies> 
... 

No siempre es necesario tener explícitamente una dependencia de jaxb-api. Por ejemplo, el complemento atlassian-rest-common anterior tiene una dependencia transitiva en jaxb-api. Importante es comprender la configuración de ámbito. Mire Setting OSGi Manifest Instructions in your Plugin (la misma página que Complementos, paquetes y OSGi pero más abajo).

El intrigado puede obtener más información en OSGi Alliance Specifications y OSGi Community Wiki.