本文介绍了使用JAXB / XJC插件时无法识别的参数-XsomePlugin错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用JAXB / XJC编译XML Schema,我想使用一些XJC插件来增加生成的代码。

我将插件包含到XJC类路径中并使用激活它-XsomePlugin

I am compiling an XML Schema using JAXB/XJC and I want to use some XJC plugin to augment generated code.
I include plugin into the XJC classpath and activate it using -XsomePlugin.

但是我收到如下错误:

Caused by: com.sun.tools.xjc.BadCommandLineException: unrecognized parameter -XsomePlugin
    at com.sun.tools.xjc.Options.parseArguments(Options.java:859)
    at com.sun.tools.xjc.XJCBase._doXJC(XJCBase.java:804)
    ... 21 more

显然,插件没有被XJC拾取或未被激活。

So apparently the plugin is not picked up by XJC or is not activated.

可能是什么原因以及如何调试此错误?

What could be the reason and how can I debug this error?

推荐答案

XJC使用服务加载程序机制发现并实例化插件。 XJC插件提供了一个资源 META-INF \services \ com.sun.tools.xjc.Plugin ,其中列出了插件类的FQCN。

XJC discovers and instantiates plugins using a "service loader" mechanism. XJC plugins provide a resource META-INF\services\com.sun.tools.xjc.Plugin which lists FQCN of plugin classes.

可能有不同的原因导致插件无法加载/实例化。

There may be different reasons why the plugin could not be loaded/instantiated.

不幸的是,XJC通常不会显示在插件实例化期间发生了哪些特定错误。你只得到这个无法识别的参数-XsomePlugin 消息就是这样。

Unfortunately, XJC normally does not show which specific errors occured during instantiation of the plugin. You only get this unrecognized parameter -XsomePlugin message and that's it.

幸运的是,有一个调试开关可以使用以下系统属性之一激活:

Fortunately, there is a "debug" switch which can be activated using one of the following system properties:


  • com.sun.tools.xjc.Options。 findServices = true

  • com.sun.tools.internal.xjc.Options.findServices = true

  • com.sun.tools.xjc.Options.findServices=true
  • com.sun.tools.internal.xjc.Options.findServices=true

(我通常会设置这两个属性,我会解释下面的原因。)

(I normally set both properties, I'll explain the reason below.)

这会使XJC记录在插件实例化期间发生的实际错误,例如:

This would make XJC log the actual error which occured during instantiation of the plugin, for instance:

  [xjc] java.util.ServiceConfigurationError: com.sun.tools.xjc.Plugin: Provider org.jvnet.jaxb2_commons.plugin.tostring.ToStringPlugin could not be instantiated
  [xjc]     at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:581)
  [xjc]     at java.base/java.util.ServiceLoader.access$100(ServiceLoader.java:390)
  [xjc]     at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:799)
  [xjc]     at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721)
  [xjc]     at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1389)
  [xjc]     at com.sun.tools.xjc.Options.findServices(Options.java:1009)
  [xjc]     at com.sun.tools.xjc.Options.getAllPlugins(Options.java:385)
  [xjc]     at com.sun.tools.xjc.Options.parseArgument(Options.java:724)
  [xjc]     at com.sun.tools.xjc.Options.parseArguments(Options.java:857)
  ....
  [xjc] Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/apache/tools/ant/AntClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of org/apache/tools/ant/loader/AntClassLoader5) for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature
  [xjc]     at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:306)
  [xjc]     at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)
  [xjc]     at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:156)
  [xjc]     at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
  [xjc]     at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:274)
  [xjc]     at org.jvnet.jaxb2_commons.plugin.AbstractPlugin.<init>(AbstractPlugin.java:28)
  .....





如果你有交流这些系统属性生动但仍然没有看到任何关于在日志中加载插件的错误消息,最可能的原因是:

If you've activated these system properties but still don't see any error message about loading your plugin in the logs, most probable reasons for this are:


  • 插件库未正确添加到XJC类路径;

  • 插件库无效,即不提供 META-INF \services \ com.sun .tools.xjc.Plugin 包含插件类FQCN的资源。

  • the plugin library is not correctly added to the XJC classpath;
  • the plugin library is invalid i.e. does not provide the META-INF\services\com.sun.tools.xjc.Plugin resource with FQCNs of the plugin classes.

有两种口味的XJC:


  • 独立XJC可用作 jaxb-xjc-< version> .jar 工件。在。

  • 与JDK打包在一起的内部XJC。这是从命令行调用 xjc 时调用的内容。

  • "Standalone" XJC available as the jaxb-xjc-<version>.jar artifact. Used (among others) in maven-jaxb2-plugin.
  • "Internal" XJC packaged with the JDK. This is what is invoked when you call xjc from the command line.

不幸的是,内部XJC存在一个大问题。

Unfortunately there is a big problem with the "internal" XJC.

当为JDK打包XJC时,所有XJC包都从 com重命名。 sun.tools.xjc。* com.sun.tools.internal.xjc。* 。我猜这背后有一些非技术原因,但我不会推测。

When XJC is packaged for the JDK, all XJC packages are renamed from com.sun.tools.xjc.* to com.sun.tools.internal.xjc.*. I guess there are some non-technical reasons behind this but I won't speculate.

com.sun时.tools.xjc。* 包重命名为 com.sun.tools.internal.xjc。* ,这实质上打破了为开发的插件的兼容性独立XJC:

When com.sun.tools.xjc.* packages are renamed to com.sun.tools.internal.xjc.*, this essentially breaks compatibility of plugins developed for the "standalone" XJC:


  • 为独立XJC开发的XJC插件必须扩展 com.sun。 tools.xjc.Plugin 。 内部XJC期望插件类扩展 com.sun.tools.internal.xjc.Plugin

  • 对于独立 XJC插件必须列在 META-INF \services \ com.sun.tools.xjc.Plugin 中。对于中的内部XJC,META-INF \services \ com.sun.tools.internal.xjc.Plugin

  • An XJC plugin developed for the "standalone" XJC must extend com.sun.tools.xjc.Plugin. "Internal" XJC expects plugin classes to extend com.sun.tools.internal.xjc.Plugin.
  • For the "standalone" XJC plugins must be listed in META-INF\services\com.sun.tools.xjc.Plugin. For the "internal" XJC in META-INF\services\com.sun.tools.internal.xjc.Plugin.

(这也是你应该打开 com.sun.tools.xjc.Options.findServices = true 以及 com.sun.tools.internal.xjc.Options.findServices = true 调试加载插件。)

(This is also the reason why you should turn on both com.sun.tools.xjc.Options.findServices=true as well as com.sun.tools.internal.xjc.Options.findServices=true to debug loading of the plugins.)

基本上,为独立XJC开发的插件与内部XJC不兼容,反之亦然。

Basically, plugins developed for the "standalone" XJC are not compatible to the "internal" XJC and vice versa.

据我所知,大多数XJC插件是为独立XJC开发的。

To the best of my knowledge, most of the XJC plugins are developed for the "standalone" XJC.

另一个问题是XJC版本之间存在不兼容的变化。

Another problem is that there are incompatible changes between XJC versions.

因此在XJC 2.3中类 Aspect 已从包 com.sun.tools.xjc.model 移至包 com.sun.tools.xjc.outline 。这意味着在2.3之前的XJC版本中使用 com.sun.tools.xjc.model.Aspect 的插件将无法与2.3一起使用。可能还有其他一些例子。

Thus in XJC 2.3 the class Aspect was moved from the package com.sun.tools.xjc.model to the package com.sun.tools.xjc.outline. This means that plugins which used the com.sun.tools.xjc.model.Aspect in XJC versions earlier than 2.3 won't work with 2.3. There are probably other examples as well.

这意味着XJC插件可能与您使用的XJC版本不兼容。

This means that an XJC plugin may simply be not compatible to the XJC version you use.

这篇关于使用JAXB / XJC插件时无法识别的参数-XsomePlugin错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-18 14:05