Unable to solve "Provider xx not a subtype" problem

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Unable to solve "Provider xx not a subtype" problem

David Karr
This is not a proper subject for a "dev" list, but I've queried every other reasonable resource, with no result.

I have a small app using CXF, JAX-RS, JAXB, along with two JAXB extensions, and Maven.

I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and "Fluent API" JAXB extensions, to generate a set of Java classes from a set of schemas.  This works fine.

I'm attempting to convert this build from Maven to Gradle.  The key part is XJC and these JAXB extensions.  Ever single way I've tried to run XJC fails with the following exception (the referenced classname varies depending on whether I leave in both JAXB extensions or remove one from my classpath):

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've tried using the Ant XJC task from Gradle. I've tried it from an Ant "build.xml".  I tried a Bash script directly calling the XJCFacade class. They all get the same result.  I have the 2.2.7 version of the xjc, impl, and api jaxb jars in my classpath, along with the extension jars and other dependencies of those jars.

I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they think this only works with the cxf maven plugin), stackoverflow, and the issues page for the ElementWrapper plugin. The only response of any substance I got was indirectly from Martin Gainty, from my ant-user posting, where he talked a bit about how the "ServiceLoader" framework works.  He didn't really provide a solution, but he implied that "Maven solves the issue by inheriting System CL at CLI before tacking on maven-core and  any consequent plugins". I've tried some classpath ordering changes along those lines, but that doesn't help.

Any useful information or leads would be appreciated.
Reply | Threaded
Open this post in threaded view
|

Re: Unable to solve "Provider xx not a subtype" problem

Marcel Valovy
Hi David,

one of our teams has experienced the same problem with BeanValidationPlugin (part of EclipseLink). We are still analyzing the problem. I suspect that it is caused by having multiple different JAXB jars on classpath and having Context CL load one of the jars and having an APP CL load the plugin. When I get the info I need about the jars they use I will create a test case for this.

Should you get any more information on this issue, I would greatly appreciate if you shared it with me/the group. I will share my results with you/the group too, after I get the required info.

BR,
Marcel


On 21/01/15 17:12, David Karr wrote:
This is not a proper subject for a "dev" list, but I've queried every other reasonable resource, with no result.

I have a small app using CXF, JAX-RS, JAXB, along with two JAXB extensions, and Maven.

I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and "Fluent API" JAXB extensions, to generate a set of Java classes from a set of schemas.  This works fine.

I'm attempting to convert this build from Maven to Gradle.  The key part is XJC and these JAXB extensions.  Ever single way I've tried to run XJC fails with the following exception (the referenced classname varies depending on whether I leave in both JAXB extensions or remove one from my classpath):

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've tried using the Ant XJC task from Gradle. I've tried it from an Ant "build.xml".  I tried a Bash script directly calling the XJCFacade class. They all get the same result.  I have the 2.2.7 version of the xjc, impl, and api jaxb jars in my classpath, along with the extension jars and other dependencies of those jars.

I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they think this only works with the cxf maven plugin), stackoverflow, and the issues page for the ElementWrapper plugin. The only response of any substance I got was indirectly from Martin Gainty, from my ant-user posting, where he talked a bit about how the "ServiceLoader" framework works.  He didn't really provide a solution, but he implied that "Maven solves the issue by inheriting System CL at CLI before tacking on maven-core and  any consequent plugins". I've tried some classpath ordering changes along those lines, but that doesn't help.

Any useful information or leads would be appreciated.

Reply | Threaded
Open this post in threaded view
|

Re: Unable to solve "Provider xx not a subtype" problem

David Karr
Ok, thanks for the reply. I now have at least a minimal test case, and I've even found a situation where the test succeeds.

I was able to build a minimal Gradle build script, and nothing else needs to be manually installed (except for Java and Gradle) to run the test. This test still fails on my Win7 box, but I found that it works on my CentOS VM.  I just compared the environments, and right now my Win7 box has Gradle 2.2.1 and the CentOS box only 2.1. Also, the CentOS box is running JDK 1.7 and the Win7 box 1.8.  I'm going to do some swapping of those versions and see what other variations provide a clue.  I could also run either test with verbose class loading, but I'm not sure what I'd look for in that noise.

In any case, here's my minimal Gradle test script (not that the test succeeds if it just complains about a missing schema):
-----------------------------
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'

sourceCompatibility = 1.7
targetCompatibility = 1.7

repositories {
  mavenCentral()
}

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
-------------------------

On Fri, Jan 23, 2015 at 3:23 AM, Marcel Valovy <[hidden email]> wrote:
Hi David,

one of our teams has experienced the same problem with BeanValidationPlugin (part of EclipseLink). We are still analyzing the problem. I suspect that it is caused by having multiple different JAXB jars on classpath and having Context CL load one of the jars and having an APP CL load the plugin. When I get the info I need about the jars they use I will create a test case for this.

Should you get any more information on this issue, I would greatly appreciate if you shared it with me/the group. I will share my results with you/the group too, after I get the required info.

BR,
Marcel



On 21/01/15 17:12, David Karr wrote:
This is not a proper subject for a "dev" list, but I've queried every other reasonable resource, with no result.

I have a small app using CXF, JAX-RS, JAXB, along with two JAXB extensions, and Maven.

I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and "Fluent API" JAXB extensions, to generate a set of Java classes from a set of schemas.  This works fine.

I'm attempting to convert this build from Maven to Gradle.  The key part is XJC and these JAXB extensions.  Ever single way I've tried to run XJC fails with the following exception (the referenced classname varies depending on whether I leave in both JAXB extensions or remove one from my classpath):

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've tried using the Ant XJC task from Gradle. I've tried it from an Ant "build.xml".  I tried a Bash script directly calling the XJCFacade class. They all get the same result.  I have the 2.2.7 version of the xjc, impl, and api jaxb jars in my classpath, along with the extension jars and other dependencies of those jars.

I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they think this only works with the cxf maven plugin), stackoverflow, and the issues page for the ElementWrapper plugin. The only response of any substance I got was indirectly from Martin Gainty, from my ant-user posting, where he talked a bit about how the "ServiceLoader" framework works.  He didn't really provide a solution, but he implied that "Maven solves the issue by inheriting System CL at CLI before tacking on maven-core and  any consequent plugins". I've tried some classpath ordering changes along those lines, but that doesn't help.

Any useful information or leads would be appreciated.


Reply | Threaded
Open this post in threaded view
|

Re: Unable to solve "Provider xx not a subtype" problem

David Karr
Weird. I'm now seeing that this Gradle script will fail or succeed depending on what directory I execute it from. If I execute it from the original project directory where I first saw this problem, it fails. If I execute it from a different directory that just holds this build script, it succeeds. I don't see anything significant in the project that directory that might make this happen. I'm currently comparing the verbose classloading output from both tests to see if I can find any clues.

On Fri, Jan 23, 2015 at 6:58 AM, David Karr <[hidden email]> wrote:
Ok, thanks for the reply. I now have at least a minimal test case, and I've even found a situation where the test succeeds.

I was able to build a minimal Gradle build script, and nothing else needs to be manually installed (except for Java and Gradle) to run the test. This test still fails on my Win7 box, but I found that it works on my CentOS VM.  I just compared the environments, and right now my Win7 box has Gradle 2.2.1 and the CentOS box only 2.1. Also, the CentOS box is running JDK 1.7 and the Win7 box 1.8.  I'm going to do some swapping of those versions and see what other variations provide a clue.  I could also run either test with verbose class loading, but I'm not sure what I'd look for in that noise.

In any case, here's my minimal Gradle test script (not that the test succeeds if it just complains about a missing schema):
-----------------------------
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'

sourceCompatibility = 1.7
targetCompatibility = 1.7

repositories {
  mavenCentral()
}

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
-------------------------

On Fri, Jan 23, 2015 at 3:23 AM, Marcel Valovy <[hidden email]> wrote:
Hi David,

one of our teams has experienced the same problem with BeanValidationPlugin (part of EclipseLink). We are still analyzing the problem. I suspect that it is caused by having multiple different JAXB jars on classpath and having Context CL load one of the jars and having an APP CL load the plugin. When I get the info I need about the jars they use I will create a test case for this.

Should you get any more information on this issue, I would greatly appreciate if you shared it with me/the group. I will share my results with you/the group too, after I get the required info.

BR,
Marcel



On 21/01/15 17:12, David Karr wrote:
This is not a proper subject for a "dev" list, but I've queried every other reasonable resource, with no result.

I have a small app using CXF, JAX-RS, JAXB, along with two JAXB extensions, and Maven.

I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and "Fluent API" JAXB extensions, to generate a set of Java classes from a set of schemas.  This works fine.

I'm attempting to convert this build from Maven to Gradle.  The key part is XJC and these JAXB extensions.  Ever single way I've tried to run XJC fails with the following exception (the referenced classname varies depending on whether I leave in both JAXB extensions or remove one from my classpath):

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've tried using the Ant XJC task from Gradle. I've tried it from an Ant "build.xml".  I tried a Bash script directly calling the XJCFacade class. They all get the same result.  I have the 2.2.7 version of the xjc, impl, and api jaxb jars in my classpath, along with the extension jars and other dependencies of those jars.

I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they think this only works with the cxf maven plugin), stackoverflow, and the issues page for the ElementWrapper plugin. The only response of any substance I got was indirectly from Martin Gainty, from my ant-user posting, where he talked a bit about how the "ServiceLoader" framework works.  He didn't really provide a solution, but he implied that "Maven solves the issue by inheriting System CL at CLI before tacking on maven-core and  any consequent plugins". I've tried some classpath ordering changes along those lines, but that doesn't help.

Any useful information or leads would be appreciated.



Reply | Threaded
Open this post in threaded view
|

Re: Unable to solve "Provider xx not a subtype" problem

David Karr
The other minimal test I have is the following shell script, which directly runs XJCFacade. This fails on both Win7 and CentOS (remove the cygpath reference if you don't use cygwin):
------------------------
#! /bin/bash
basedir=$(cygpath -m $HOME/work/xjctest)
cp="\
$basedir/lib/jaxb-core-2.2.7.jar;\
$basedir/lib/jaxb-xjc-2.2.7.jar;\
$basedir/lib/jaxb-fluent-api-2.1.8.jar;\
$basedir/lib/jaxb-xew-plugin-1.4.jar;\
"
#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
java -classpath "$cp" com.sun.tools.xjc.XJCFacade -extension
---------------------

On Fri, Jan 23, 2015 at 9:00 AM, David Karr <[hidden email]> wrote:
Weird. I'm now seeing that this Gradle script will fail or succeed depending on what directory I execute it from. If I execute it from the original project directory where I first saw this problem, it fails. If I execute it from a different directory that just holds this build script, it succeeds. I don't see anything significant in the project that directory that might make this happen. I'm currently comparing the verbose classloading output from both tests to see if I can find any clues.

On Fri, Jan 23, 2015 at 6:58 AM, David Karr <[hidden email]> wrote:
Ok, thanks for the reply. I now have at least a minimal test case, and I've even found a situation where the test succeeds.

I was able to build a minimal Gradle build script, and nothing else needs to be manually installed (except for Java and Gradle) to run the test. This test still fails on my Win7 box, but I found that it works on my CentOS VM.  I just compared the environments, and right now my Win7 box has Gradle 2.2.1 and the CentOS box only 2.1. Also, the CentOS box is running JDK 1.7 and the Win7 box 1.8.  I'm going to do some swapping of those versions and see what other variations provide a clue.  I could also run either test with verbose class loading, but I'm not sure what I'd look for in that noise.

In any case, here's my minimal Gradle test script (not that the test succeeds if it just complains about a missing schema):
-----------------------------
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'

sourceCompatibility = 1.7
targetCompatibility = 1.7

repositories {
  mavenCentral()
}

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
-------------------------

On Fri, Jan 23, 2015 at 3:23 AM, Marcel Valovy <[hidden email]> wrote:
Hi David,

one of our teams has experienced the same problem with BeanValidationPlugin (part of EclipseLink). We are still analyzing the problem. I suspect that it is caused by having multiple different JAXB jars on classpath and having Context CL load one of the jars and having an APP CL load the plugin. When I get the info I need about the jars they use I will create a test case for this.

Should you get any more information on this issue, I would greatly appreciate if you shared it with me/the group. I will share my results with you/the group too, after I get the required info.

BR,
Marcel



On 21/01/15 17:12, David Karr wrote:
This is not a proper subject for a "dev" list, but I've queried every other reasonable resource, with no result.

I have a small app using CXF, JAX-RS, JAXB, along with two JAXB extensions, and Maven.

I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and "Fluent API" JAXB extensions, to generate a set of Java classes from a set of schemas.  This works fine.

I'm attempting to convert this build from Maven to Gradle.  The key part is XJC and these JAXB extensions.  Ever single way I've tried to run XJC fails with the following exception (the referenced classname varies depending on whether I leave in both JAXB extensions or remove one from my classpath):

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've tried using the Ant XJC task from Gradle. I've tried it from an Ant "build.xml".  I tried a Bash script directly calling the XJCFacade class. They all get the same result.  I have the 2.2.7 version of the xjc, impl, and api jaxb jars in my classpath, along with the extension jars and other dependencies of those jars.

I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they think this only works with the cxf maven plugin), stackoverflow, and the issues page for the ElementWrapper plugin. The only response of any substance I got was indirectly from Martin Gainty, from my ant-user posting, where he talked a bit about how the "ServiceLoader" framework works.  He didn't really provide a solution, but he implied that "Maven solves the issue by inheriting System CL at CLI before tacking on maven-core and  any consequent plugins". I've tried some classpath ordering changes along those lines, but that doesn't help.

Any useful information or leads would be appreciated.




Reply | Threaded
Open this post in threaded view
|

Re: Unable to solve "Provider xx not a subtype" problem

David Karr
By running this code in the debugger, I can confirm that a more complete error message for this situation would be "Provider xx not a subtype of "com.sun.tools.xjc.Plugin".

I set a breakpoint at the top of ServiceLoader$LazyIterator.next() and let my test run.

The method is this:
------------------------------
        public S next() {
            if (!hasNext()) {
                throw new NoSuchElementException();
            }
            String cn = nextName;
            nextName = null;
            Class<?> c = null;
            try {
                c = Class.forName(cn, false, loader);
            } catch (ClassNotFoundException x) {
                fail(service,
                     "Provider " + cn + " not found");
            }
            if (!service.isAssignableFrom(c)) {
                fail(service,
                     "Provider " + cn  + " not a subtype");
            }
            try {
                S p = service.cast(c.newInstance());
                providers.put(cn, p);
                return p;
            } catch (Throwable x) {
                fail(service,
                     "Provider " + cn + " could not be instantiated: " + x,
                     x);
            }
            throw new Error();          // This cannot happen
        }
------------------

I'm able to only see some of the variables (perhaps all of the "this" properties, but no local variables).

The value of "nextName" at this point is "org.jvnet.jaxb2_commons.tools.xjc.plugin.fluent_api.XjcFluentApiPlugin". The value of "service" is an instance of "com.sun.tools.xjc.Plugin". I entered the following expression in the Display view:

     service.isAssignableFrom(Class.forName("org.jvnet.jaxb2_commons.tools.xjc.plugin.fluent_api.XjcFluentApiPlugin", false, loader))

This returns "false", which results in the symptom.  When I view the "org.jvnet.jaxb2_commons.tools.xjc.plugin.fluent_api.XjcFluentApiPlugin" class in the provided jar and trace its ancestry, it is clearly a subclass of "com.sun.tools.xjc.Plugin". The only way this could be false if these two classes, "org.jvnet.jaxb2_commons.tools.xjc.plugin.fluent_api.XjcFluentApiPlugin" or "com.sun.tools.xjc.Plugin" were loaded by different classloaders.

I don't know what else I can do here.

On Fri, Jan 23, 2015 at 9:20 AM, David Karr <[hidden email]> wrote:
The other minimal test I have is the following shell script, which directly runs XJCFacade. This fails on both Win7 and CentOS (remove the cygpath reference if you don't use cygwin):
------------------------
#! /bin/bash
basedir=$(cygpath -m $HOME/work/xjctest)
cp="\
$basedir/lib/jaxb-core-2.2.7.jar;\
$basedir/lib/jaxb-xjc-2.2.7.jar;\
$basedir/lib/jaxb-fluent-api-2.1.8.jar;\
$basedir/lib/jaxb-xew-plugin-1.4.jar;\
"
#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
java -classpath "$cp" com.sun.tools.xjc.XJCFacade -extension
---------------------


On Fri, Jan 23, 2015 at 9:00 AM, David Karr <[hidden email]> wrote:
Weird. I'm now seeing that this Gradle script will fail or succeed depending on what directory I execute it from. If I execute it from the original project directory where I first saw this problem, it fails. If I execute it from a different directory that just holds this build script, it succeeds. I don't see anything significant in the project that directory that might make this happen. I'm currently comparing the verbose classloading output from both tests to see if I can find any clues.

On Fri, Jan 23, 2015 at 6:58 AM, David Karr <[hidden email]> wrote:
Ok, thanks for the reply. I now have at least a minimal test case, and I've even found a situation where the test succeeds.

I was able to build a minimal Gradle build script, and nothing else needs to be manually installed (except for Java and Gradle) to run the test. This test still fails on my Win7 box, but I found that it works on my CentOS VM.  I just compared the environments, and right now my Win7 box has Gradle 2.2.1 and the CentOS box only 2.1. Also, the CentOS box is running JDK 1.7 and the Win7 box 1.8.  I'm going to do some swapping of those versions and see what other variations provide a clue.  I could also run either test with verbose class loading, but I'm not sure what I'd look for in that noise.

In any case, here's my minimal Gradle test script (not that the test succeeds if it just complains about a missing schema):
-----------------------------
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'war'

sourceCompatibility = 1.7
targetCompatibility = 1.7

repositories {
  mavenCentral()
}

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
-------------------------

On Fri, Jan 23, 2015 at 3:23 AM, Marcel Valovy <[hidden email]> wrote:
Hi David,

one of our teams has experienced the same problem with BeanValidationPlugin (part of EclipseLink). We are still analyzing the problem. I suspect that it is caused by having multiple different JAXB jars on classpath and having Context CL load one of the jars and having an APP CL load the plugin. When I get the info I need about the jars they use I will create a test case for this.

Should you get any more information on this issue, I would greatly appreciate if you shared it with me/the group. I will share my results with you/the group too, after I get the required info.

BR,
Marcel



On 21/01/15 17:12, David Karr wrote:
This is not a proper subject for a "dev" list, but I've queried every other reasonable resource, with no result.

I have a small app using CXF, JAX-RS, JAXB, along with two JAXB extensions, and Maven.

I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and "Fluent API" JAXB extensions, to generate a set of Java classes from a set of schemas.  This works fine.

I'm attempting to convert this build from Maven to Gradle.  The key part is XJC and these JAXB extensions.  Ever single way I've tried to run XJC fails with the following exception (the referenced classname varies depending on whether I leave in both JAXB extensions or remove one from my classpath):

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've tried using the Ant XJC task from Gradle. I've tried it from an Ant "build.xml".  I tried a Bash script directly calling the XJCFacade class. They all get the same result.  I have the 2.2.7 version of the xjc, impl, and api jaxb jars in my classpath, along with the extension jars and other dependencies of those jars.

I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they think this only works with the cxf maven plugin), stackoverflow, and the issues page for the ElementWrapper plugin. The only response of any substance I got was indirectly from Martin Gainty, from my ant-user posting, where he talked a bit about how the "ServiceLoader" framework works.  He didn't really provide a solution, but he implied that "Maven solves the issue by inheriting System CL at CLI before tacking on maven-core and  any consequent plugins". I've tried some classpath ordering changes along those lines, but that doesn't help.

Any useful information or leads would be appreciated.





Reply | Threaded
Open this post in threaded view
|

Re: Unable to solve "Provider xx not a subtype" problem

David Karr
In reply to this post by David Karr

Ok.  I have a solution to this.  You can read about the basic solution at http://stackoverflow.com/questions/27977479/com-sun-tools-xjc-plugin-provider-plugin-not-a-subtype .

Basically, the classpath provided for XJC has to be separated into two pieces.  The jaxb-api, jaxb-core, and jaxb-xjc jars need to be provided to "load" or reference XJC, but the JAXB extension jars have to be loaded ONLY by XJC itself.  You will likely see this error if the extension jars are loaded "too early".

So, if you're using XJCFacade, specify the "jaxb-" jars in the classpath parameter given to "java", but specify the extension jars in the classpath parameter for the "XJCFacade" class.


On Wed, Jan 21, 2015 at 8:12 AM, David Karr <[hidden email]> wrote:
This is not a proper subject for a "dev" list, but I've queried every other reasonable resource, with no result.

I have a small app using CXF, JAX-RS, JAXB, along with two JAXB extensions, and Maven.

I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and "Fluent API" JAXB extensions, to generate a set of Java classes from a set of schemas.  This works fine.

I'm attempting to convert this build from Maven to Gradle.  The key part is XJC and these JAXB extensions.  Ever single way I've tried to run XJC fails with the following exception (the referenced classname varies depending on whether I leave in both JAXB extensions or remove one from my classpath):

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've tried using the Ant XJC task from Gradle. I've tried it from an Ant "build.xml".  I tried a Bash script directly calling the XJCFacade class. They all get the same result.  I have the 2.2.7 version of the xjc, impl, and api jaxb jars in my classpath, along with the extension jars and other dependencies of those jars.

I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they think this only works with the cxf maven plugin), stackoverflow, and the issues page for the ElementWrapper plugin. The only response of any substance I got was indirectly from Martin Gainty, from my ant-user posting, where he talked a bit about how the "ServiceLoader" framework works.  He didn't really provide a solution, but he implied that "Maven solves the issue by inheriting System CL at CLI before tacking on maven-core and  any consequent plugins". I've tried some classpath ordering changes along those lines, but that doesn't help.

Any useful information or leads would be appreciated.

Reply | Threaded
Open this post in threaded view
|

Re: Unable to solve "Provider xx not a subtype" problem

Marcel Valovy
Hi David,

Thanks for investigating the issue, your input is much appreciated. It is great that solution is known.

I am still investigating how to improve JAXB users experience in the future. I found some spots in JAXB-RI, with my colleague Iaroslav Savitskyi where we could improve handling of loading xjc plugins.

Informative logging will be added to improve user's experience. On top of that, we currently have two alternate proposed solutions that would change the current handling of error (i.e. propagating java.util.ServiceConfigurationError to user) to either:
1) swallow the error + log warning OR
2) after catching the error, add the package of the unsuccessfully loaded plugin to masked packages in MaskingClassLoader (where package "com.sun.tools.xjc" is) and load plugins again. That way all plugins of the Plugin interface would be loaded the same way as plugins under "com.sun.tools.xjc" package, i.e. they will be loaded with user's ClassLoader, using correct interface. + log warning that a Plugin which is not under "com.sun.tools.xjc" has been loaded.

Both solutions are yet to undergo discussion next week. Other ideas and comments are sincerely welcome.

Thanks again for valuable input.

Best Regards
Marcel Valovy

On 29/01/15 15:49, David Karr wrote:

Ok.  I have a solution to this.  You can read about the basic solution at http://stackoverflow.com/questions/27977479/com-sun-tools-xjc-plugin-provider-plugin-not-a-subtype .

Basically, the classpath provided for XJC has to be separated into two pieces.  The jaxb-api, jaxb-core, and jaxb-xjc jars need to be provided to "load" or reference XJC, but the JAXB extension jars have to be loaded ONLY by XJC itself.  You will likely see this error if the extension jars are loaded "too early".

So, if you're using XJCFacade, specify the "jaxb-" jars in the classpath parameter given to "java", but specify the extension jars in the classpath parameter for the "XJCFacade" class.


On Wed, Jan 21, 2015 at 8:12 AM, David Karr <[hidden email]> wrote:
This is not a proper subject for a "dev" list, but I've queried every other reasonable resource, with no result.

I have a small app using CXF, JAX-RS, JAXB, along with two JAXB extensions, and Maven.

I use the "cxf-xjc-plugin" in Maven, along with the "Element Wrapper" and "Fluent API" JAXB extensions, to generate a set of Java classes from a set of schemas.  This works fine.

I'm attempting to convert this build from Maven to Gradle.  The key part is XJC and these JAXB extensions.  Ever single way I've tried to run XJC fails with the following exception (the referenced classname varies depending on whether I leave in both JAXB extensions or remove one from my classpath):

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've tried using the Ant XJC task from Gradle. I've tried it from an Ant "build.xml".  I tried a Bash script directly calling the XJCFacade class. They all get the same result.  I have the 2.2.7 version of the xjc, impl, and api jaxb jars in my classpath, along with the extension jars and other dependencies of those jars.

I've posted about this on jaxb-user, ant-user, cxf-user (to ask why they think this only works with the cxf maven plugin), stackoverflow, and the issues page for the ElementWrapper plugin. The only response of any substance I got was indirectly from Martin Gainty, from my ant-user posting, where he talked a bit about how the "ServiceLoader" framework works.  He didn't really provide a solution, but he implied that "Maven solves the issue by inheriting System CL at CLI before tacking on maven-core and  any consequent plugins". I've tried some classpath ordering changes along those lines, but that doesn't help.

Any useful information or leads would be appreciated.