java 由生成的代码引起的 JAXBException

JAXBException caused by generated code

提问by FrustratedWithFormsDesigner

I am getting the following JAXBException of the form

我得到以下形式的 JAXBException

class SomeClass nor any of its super class is known to this context.

类 SomeClass 或其任何超类在此上下文中都是已知的。

The full stack trace looks like this:

完整的堆栈跟踪如下所示：

 javax.xml.ws.WebServiceException: javax.xml.bind.JAXBException: class com.myCompany.generatedCode.WebServiceOperationName nor any of its super class is known to this context.
    at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
    at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
    at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
    at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:586)
    at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:130)
    at org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:93)
    at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:364)
    at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:185)
    at $Proxy41.deleteAccount(Unknown Source)
    at com.myCompany.myPackage.MyWebServiceClient.callSomeWebService(MyWebServiceClient.java:100)
(other classes specific to my application and framework)
...
Caused by: 
javax.xml.bind.JAXBException: class com.myCompany.generatedCode.WebServiceOperationName nor any of its super class is known to this context.
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:556)
    at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:452)
    at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:314)
    at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:243)
    at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:75)
    at com.ibm.xml.xlxp2.jaxb.marshal.MarshallerProxy.marshal(MarshallerProxy.java:100)
    at org.apache.axis2.datasource.jaxb.JAXBDSContext.run(JAXBDSContext.java:470)
    at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76)
    at org.apache.axis2.datasource.jaxb.JAXBDSContext.marshalByElement(JAXBDSContext.java:455)
    at org.apache.axis2.datasource.jaxb.JAXBDSContext.marshal(JAXBDSContext.java:414)
    at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:189)
    at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:372)
    at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:296)
    at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:808)
    at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:975)
    at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:1016)
    at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:271)
    at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:233)
    at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:1016)
    at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeImpl.java:488)
    at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:88)
    at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.writeMessage(SOAPOverHTTPSender.java:3271)
    at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.sendChunkedRequest(SOAPOverHTTPSender.java:888)
    at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.sendSOAPRequest(SOAPOverHTTPSender.java:807)
    at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:611)
    at com.ibm.ws.websvcs.transport.http.HTTPTransportSender.invoke(HTTPTransportSender.java:364)
    at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:531)
    at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401)
    at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
    at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
    at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:581)
    ... 52 more

What triggers this is attempting to make a call to a web service operation named WebServiceOperationName. I've seen other tips for dealing with this error which usually involve adding a @XmlSeeAlsoannotation or making adjustments to how marshalling and unmarshalling are done.

触发此操作的是尝试调用名为 的 Web 服务操作WebServiceOperationName。我已经看到处理此错误的其他技巧，这些技巧通常涉及添加@XmlSeeAlso注释或调整编组和解组的方式。

In this case, I am calling a webservice whose code is generated by Maven based on a WSDL (and supporting schemas). I don't have direct control over the code produced by Maven, and I don't have control over the marshall/unmarshall calls. Other webservice calls in the application don't seem to be having any problem.

在这种情况下，我正在调用一个 web 服务，其代码由 Maven 基于 WSDL（和支持模式）生成。我无法直接控制 Maven 生成的代码，也无法控制 marshall/unmarshall 调用。应用程序中的其他网络服务调用似乎没有任何问题。

Even stranger, I can't reproduce this on my local server, though it happens on the development server. The generated JAR for the webservice is the same, as it the rest of the application's code.

更奇怪的是，我无法在我的本地服务器上重现这个，尽管它发生在开发服务器上。为 Web 服务生成的 JAR 与应用程序的其余代码相同。

This exception has appeared suddenly this week (and consistently), and I suspect that something has changed, environmentally, but I'm not sure what. Any ideas?

这个例外在本周（并且一直）突然出现，我怀疑环境已经发生了变化，但我不确定是什么。有任何想法吗？

---

---

A new observation:

一个新的观察：

The first time I attempt to run this code on the server after it's been started/restarted, it takes a while (About a minute) before it fails and throws an exception. Every time after that, the exception is almost instantaneous...

我第一次尝试在服务器启动/重新启动后运行此代码时，需要一段时间（大约一分钟）才能失败并引发异常。之后的每一次，异常几乎都是瞬间的......

---

---

Further information:

更多信息：

This problem is present in WebSphere 7.0.0.23 (which is on the server), but not in WebSphere 7.0.0.7 (on the workstation).

此问题存在于 WebSphere 7.0.0.23（在服务器上）中，但在 WebSphere 7.0.0.7（在工作站上）中不存在。

采纳答案by FrustratedWithFormsDesigner

The issue's been resolved. I was inspecting the jar that contained the class WAS was complaining about and noticed that some of the classes were duplicated at different levels of package hierarchy. It's worth pointing out that the class that was reported in the original error was not actually one of these duplicated classes. Also, the application did not reference different variants of the same class - the classes referenced were in the expected package. The extra duplicates one level up were not referenced anywhere (as far as I can tell).

问题已经解决了。我正在检查包含 WAS 所抱怨的类的 jar，并注意到某些类在包层次结构的不同级别上是重复的。值得指出的是，原始错误中报告的类实际上并不是这些重复类之一。此外，应用程序没有引用同一类的不同变体 - 引用的类在预期的包中。上一级的额外重复项在任何地方都没有被引用（据我所知）。

It lookedlike a bad Maven configuration, but when I inspected the xjb binding files, I couldn't figure out how the types in that schema namespace got bound to two different packages. Either way, I cleanded up some of the binding files used by Maven, refactored common bindings into one file, had Maven rebuild the jar, and then tested, and suddenly the issue was gone!

它看起来像是一个糟糕的 Maven 配置，但是当我检查 xjb 绑定文件时，我无法弄清楚该架构命名空间中的类型是如何绑定到两个不同的包的。无论哪种方式，我清理了一些Maven使用的绑定文件，将常见绑定重构为一个文件，让Maven重建jar，然后进行测试，突然问题消失了！

Clearly there was a problem in WAS 7.0.0.23 since the original jar worked fine on WAS 7.0.0.7. It mayhave been caused by a problem with the Maven bindings which resulted in a strange-looking but technically valid jar.

很明显，WAS 7.0.0.23 中存在问题，因为原始 jar 在 WAS 7.0.0.7 上运行良好。这可能是由 Maven 绑定的问题引起的，该问题导致了一个看起来很奇怪但技术上有效的 jar。

Also interesting: one of our developers upgraded WAS to 7.0.0.25 and used the original "bad" jar and got a "no such operation" error instead of the JAXBException.

同样有趣的是：我们的一位开发人员将 WAS 升级到 7.0.0.25 并使用原始的“坏”jar 并得到“无此类操作”错误而不是 JAXBException。

回答by AleC

I have the same problem in Guidewire ClaimCenter, which is an insurance application that can be configured but the core can't be modified at all, It's Java based it has component included like axis2 but I created a seperate java project that wraps a webservice call, I created all the stub code with wsimport. It works well under my deve enviroment which is windows and jetty because is the Guidewire platform to configure it (no other option). we use WAS 7 as production server.

我在 Guidewire ClaimCenter 中遇到了同样的问题，这是一个可以配置但核心根本无法修改的保险应用程序，它是基于 Java 的，它包含了像axis2 这样的组件，但我创建了一个单独的 Java 项目，它包装了一个 web 服务调用，我用 wsimport 创建了所有存根代码。它在我的开发环境（windows 和 jetty）下运行良好，因为是 Guidewire 平台来配置它（没有其他选择）。我们使用 WAS 7 作为生产服务器。

    Caused by: javax.xml.ws.WebServiceException: javax.xml.bind.JAXBException: au.com.mycompany.policyinquiry.retrieveinsurancepolicydetails.v1.RetrieveInsurancePolicyDetailsResp is not known to this context
    at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
    at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
    at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
    at org.apache.axis2.jaxws.marshaller.impl.alt.DocLitBareMinimalMethodMarshaller.demarshalResponse(DocLitBareMinimalMethodMarshaller.java:158)
    at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.createResponse(JAXWSProxyHandler.java:499)
    at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:377)
    at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:185)
    at $Proxy80.retrieveInsurancePolicyDetails(Unknown Source)

I tried to generate and compile the client in the server side just in case it was something related with different JDK platform, but that didn't solve the problem. I found the next article was 6! but for WAS 6 , I haven't tried though.

我试图在服务器端生成和编译客户端，以防万一它与不同的 JDK 平台相关，但这并没有解决问题。我发现下一篇文章是 6！但是对于 WAS 6 ，我还没有尝试过。

    When the JAX-WS web service engine receives a message, it uses
    the JAXB engine to convert the message into java beans.
    The message indicates a failure occurred while converting xml
    into an object of type
    com.somecom.lib.business.xml.ComIdentifierXml.  The failure
    indicates that the JAXB engine was not initialized with
    information about this user class.
    .
    In this use case, the class
    com.somecom.lib.business.xml.ComIdentifierXml is packaged in a
    JAR at the EAR level. The exception does not happen if the
    class is packaged in a JAR located in the WAR module's
    WEB-INF/lib directory.

SOLUTION:

Target Environment: IBM server IBM JDK 1.6 IBM Webpshere 7.0.0.25

目标环境：IBM 服务器 IBM JDK 1.6 IBM Webpshere 7.0.0.25

The client to call the webservice is using pure JAVA no dependency on external library JAX-WS RI 2.1.6

调用 webservice 的客户端使用纯 JAVA，不依赖外部库 JAX-WS RI 2.1.6

In webspehre 1- Set for the application the class loading to parent last 2- Turn off webservice annotations with this: Set the com.ibm.websphere.webservices.DisableIBMJAXWSEngine property to true. this will disabled Websphere own implementation based on a modified Axis2 3- Deploy your application with third-party JAX-WS runtime in my case i used Glassfish Metro 1.5 which includes JAX-WS RI 2.1.7 and is the same as my local environment with JDK 1.6.0_37

在 webspehre 中 1- 为应用程序设置最后加载到父级的类 2- 关闭 web 服务注释：将 com.ibm.websphere.webservices.DisableIBMJAXWSEngine 属性设置为 true。这将禁用基于修改后的 Axis2 3- 使用第三方 JAX-WS 运行时部署您的应用程序的 Websphere 自己的实现，在我的情况下，我使用了 Glassfish Metro 1.5，其中包括 JAX-WS RI 2.1.7 并且与我的本地环境相同JDK 1.6.0_37

That's it

而已

Cheers Alex :)

干杯亚历克斯:)