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
> <davidmichaelkarr_at_gmail.com <mailto:davidmichaelkarr_at_gmail.com>> 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.
>
>