Get "Provider x not a subtype" when using JAXB extensions

I previously posted this, but I think it's best if I rephrase the issue, as I've gotten no useful response from this or any of the other places I've tried to ask about this.

I'm attempting to use a couple of existing JAXB extensions while generating classes from XJC. This processing has been working fine for a long time in a Maven build, using the "cxf-xjc-plugin". I'm attempting to convert this build to Gradle, but I'm finding that all the other strategies besides the Maven build are failing with the same error, which is something like this:

Caused by: java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Provider com.sun.tools.xjc.addon.xew.XmlElementWrapperPlugin not a subtype at com.sun.tools.xjc.Options.findServices(Options.java:957) at com.sun.tools.xjc.Options.getAllPlugins(Options.java:374) at com.sun.tools.xjc.Options.parseArgument(Options.java:688) at com.sun.tools.xjc.Options.parseArguments(Options.java:809) at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:474) at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:457) at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:380) at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)

I can demonstrate this with a single simple Gradle build script. It doesn't require any source code or schemas to compile, the error happens while setting up the classpath.

Note that although the error here references the "Element Wrapper" plugin, if I remove that jar from the classpath, I get the same error, but instead referencing the other JAXB extension, the "Fluent API" extension. As far as I know, I'm referencing recent versions of both of these extensions, and recent versions of the XJC and related jars.

My current simple test case Gradle script is this (I'm calling it "testxjc.gradle"):

apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'

sourceCompatibility = 1.7
targetCompatibility = 1.7

repositories {
     maven { url "http://repo1.maven.org/maven2/" }
}

configurations {
    jaxb
}

dependencies {
    jaxb 'com.sun.xml.bind:jaxb-xjc:2.2.7'
    jaxb "com.github.jaxb-xew-plugin:jaxb-xew-plugin:1.4"
    jaxb "net.java.dev.jaxb2-commons:jaxb-fluent-api:2.1.8"
}

task processXSDs() << {
    URLClassLoader loader = GroovyObject.class.classLoader;
    configurations.jaxb.each { File file -> println file; loader.addURL(file.toURI().toURL()) }

    ant.taskdef(name: 'xjc', classname: 'com.sun.tools.xjc.XJCTask',
                classpath: configurations.jaxb.asPath)

    ant.xjc(destdir: 'tmp', package: "com.att.sunlight.service.domain.serviceCallResults", extension: true) {
        schema(dir: "src/main/resources/schema", includes: "serviceCallResults.xsd")
        arg(value: "-Xxew")
        arg(value: "-summary target/xew-summary.txt")
        arg(value: "-instantiate lazy")
        arg(value: "-Xfluent-api")
    }
}

compileJava.dependsOn processXSDs

I run this with "gradle -b testxjc.gradle build --stacktrace"

I've also been able to demonstrate the same error by bypassing the Ant task and directly using the XJCFacade class. This requires having the required jars available to reference. Here is my current test script (change semicolons to colons in the classpath if you test this on Linux):

    #! /bin/bash
java -classpath "lib/commons-beanutils-1.7.0.jar;lib/commons-lang-2.2.jar;lib/commons-logging-1.1.1.jar;lib/istack-commons-runtime-2.16.jar;lib/jaxb2-basics-runtime-0.6.5.jar;lib/jaxb2-basics-tools-0.6.5.jar;lib/jaxb-api-2.2.7.jar;lib/jaxb-core-2.2.7.jar;lib/jaxb-fluent-api-2.1.8.jar;lib/jaxb-xew-plugin-1.4.jar;lib/jaxb-xjc-2.2.7.jar" com.sun.tools.xjc.XJCFacade -extension

I've tested this on both Win7 and CentOS.

Update:

I now have a clue or two.

First, when I said I tested this on both Win7 and CentOS, I was referring to the shell script. Up to that point, I hadn't run the minimal Gradle build script on CentOS. When I ran this minimal Gradle build script on CentOS, it succeeded (which means, it complained about the missing schema). Besides different OSes, I have different versions of Gradle and Java on each box. I'm in the process of swapping those versions around to see what other clues I can find.

I also got a reply to the post I made to the "jaxb-dev" mailing list, where someone said that they've seen this symptom, and they think it might happen when multiple JAXB jars are found on the classpath, and some JAXB classes are loaded by one classloader, and other JAXB classes by another.

From this input, I suppose I should try running my minimal test with verbose classloading and see how they differ, but I'm not sure I'll be able to see what I need through all the noise that will produce.

Recommended topics

Hot tags