Weird SAX exception only with jar-with-dependencies

Issue #98 closed
Marc M. Adkins created an issue

I have code that is working fine in my test environment (running command line from Maven) but fails when I generate a jar-with-dependencies and run that from the command line. The relevant error is:

[XMPP Writer Thread] INFO org.doorways.montage.Chatter - XMPP status: DISCONNECTED (old status: AUTHENTICATED)
Status change caused by:
javax.xml.bind.MarshalException
 - with linked exception:
[com.sun.istack.internal.SAXException2: class rocks.xmpp.extensions.delay.model.DelayedDelivery nor any of its super class is known to this context.
javax.xml.bind.JAXBException: class rocks.xmpp.extensions.delay.model.DelayedDelivery nor any of its super class is known to this context.]
[XMPP Writer Thread] ERROR org.doorways.montage.Chatter - XMPP error: 
javax.xml.bind.MarshalException
 - with linked exception:
[com.sun.istack.internal.SAXException2: class rocks.xmpp.extensions.delay.model.DelayedDelivery nor any of its super class is known to this context.
javax.xml.bind.JAXBException: class rocks.xmpp.extensions.delay.model.DelayedDelivery nor any of its super class is known to this context.]
    at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:311)
    at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:163)
    at rocks.xmpp.core.session.XmppStreamWriter.lambda$send$2(XmppStreamWriter.java:124)
    at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1626)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: com.sun.istack.internal.SAXException2: class rocks.xmpp.extensions.delay.model.DelayedDelivery nor any of its super class is known to this context.
javax.xml.bind.JAXBException: class rocks.xmpp.extensions.delay.model.DelayedDelivery nor any of its super class is known to this context.
    at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:232)
    at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247)
    at com.sun.xml.internal.bind.v2.runtime.property.ArrayReferenceNodeProperty.serializeListBody(ArrayReferenceNodeProperty.java:107)
    at com.sun.xml.internal.bind.v2.runtime.property.ArrayERProperty.serializeBody(ArrayERProperty.java:144)
    at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:345)
    at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:578)
    at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:326)
    at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:479)
    at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:308)
    ... 10 more
Caused by: javax.xml.bind.JAXBException: class rocks.xmpp.extensions.delay.model.DelayedDelivery nor any of its super class is known to this context.
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:567)
    at com.sun.xml.internal.bind.v2.runtime.property.ArrayReferenceNodeProperty.serializeListBody(ArrayReferenceNodeProperty.java:97)
    ... 16 more

The only reference to this weirdness I've found online is four years old:

https://stackoverflow.com/questions/10350549/jaxb-marshal-exception-impl-class-nor-any-of-its-super-class-is-not-known-to-a

I'm currently using:

<dependency>
  <groupId>rocks.xmpp</groupId>
  <artifactId>xmpp-extensions-client</artifactId>
  <version>0.7.3</version>
</dependency>

I can see the relevant classes in my jar-with-dependencies:

rocks/xmpp/extensions/data/validate/model/Validation$ValidationMethod.class
rocks/xmpp/extensions/data/validate/model/Validation.class
rocks/xmpp/extensions/delay/model/DelayedDelivery.class
rocks/xmpp/extensions/delay/model/package-info.class
rocks/xmpp/extensions/disco/model/info/Feature.class
rocks/xmpp/extensions/disco/model/info/Identity.class

Comments (8)

  1. Marc M. Adkins reporter

    Wait one, I just found another issue here that looks applicable. Should have looked harder before creating this one. :-(

  2. Marc M. Adkins reporter

    Yup, issue #73 did it. Switched from maven-assembly-plugin to maven-shade-plugin following your example and the problem cleared right up.

  3. Christian Schudt repo owner

    Yes, the reason is java.util.ServiceLoader which looks in the jar's META-INF folder for extensions. The assembly plugin overrides the files from all jars and only takes the last one, while the shade plugin "merges" all into one file correctly.

  4. Log in to comment