Xstream-1.4.7 unmarshaller throws Instantiation exception trying to create an instance for Interface

[Deepika Gadam]

We are facing a strange issue while unmarshalling. For some reason SunLimitedUnsafeReflectionProvider is trying to create an instance for interface , rather than a class.

We are passing an array of classes to process annoations. In Annotation Mapper class, processTypes method at the end adds interfaces also to the annotatedTypes Set, though we passed only List of actual implementing classes.

This is our Spring COnfig:

<bean
class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"
p:targetObject-ref="xstream" p:targetMethod="processAnnotations"
p:arguments-ref="xStreamClassList" />

<bean id="xstream" class="com.thoughtworks.xstream.XStream" />

<util:list id="xStreamClassList">
<value>com.bloodhound.ws.edi.domain.xml.EdiMessageXstream</value>
<value>com.bloodhound.ws.edi.domain.xml.EdiRequestXstream</value>
<value>com.bloodhound.ws.edi.domain.xml.EdiResponseXstream</value>
<value>com.bloodhound.ws.edi.domain.xml.HeaderXstream</value>
</util:list>

Instead of creating an instance for HeaderXstream, it's creating instance for it's interface com.bloodhound.ws.edi.domain.Header

Any Help would be very appreciated.

Stacktrace
---------------------------------------------------------------------------------------------------------------------------------------

com.thoughtworks.xstream.converters.ConversionException: Cannot construct com.bloodhound.ws.edi.domain.Header : com.bloodhound.ws.edi.domain.Header : Cannot construct com.bloodhound.ws.edi.domain.Header : com.bloodhound.ws.edi.domain.Header
---- Debugging information ----
message : Cannot construct com.bloodhound.ws.edi.domain.Header : com.bloodhound.ws.edi.domain.Header
cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct com.bloodhound.ws.edi.domain.Header : com.bloodhound.ws.edi.domain.Header
class : com.bloodhound.ws.edi.domain.Header
required-type : com.bloodhound.ws.edi.domain.Header
converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
path : /response/headers
line number : 3
class[1] : com.bloodhound.ws.edi.domain.xml.EdiResponseXstream
version : 1.4.7
-------------------------------
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:79)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:426)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:257)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)
at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:134)
at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1185)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1157)
at org.apache.camel.dataformat.xstream.AbstractXStreamWrapper.unmarshal(AbstractXStreamWrapper.java:213)
at org.apache.camel.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:67)
at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:105)
at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:279)
at org.apache.camel.processor.DefaultErrorHandler.process(DefaultErrorHandler.java:56)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:166)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
at org.apache.camel.spring.spi.TransactionErrorHandler.processByErrorHandler(TransactionErrorHandler.java:218)
at org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:99)
at org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:112)
at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
at org.apache.camel.spring.spi.TransactionErrorHandler.processByErrorHandler(TransactionErrorHandler.java:218)
at org.apache.camel.spring.spi.TransactionErrorHandler$1.doInTransactionWithoutResult(TransactionErrorHandler.java:181)
at org.springframework.transaction.support.TransactionCallbackWithoutResult.doInTransaction(TransactionCallbackWithoutResult.java:34)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
at org.apache.camel.spring.spi.TransactionErrorHandler.doInTransactionTemplate(TransactionErrorHandler.java:174)
at org.apache.camel.spring.spi.TransactionErrorHandler.processInTransaction(TransactionErrorHandler.java:134)
at org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:103)
at org.apache.camel.spring.spi.TransactionErrorHandler.process(TransactionErrorHandler.java:112)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:423)
at org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211)
at org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:175)
at org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:187)
at org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:114)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
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.thoughtworks.xstream.converters.reflection.ObjectAccessException: Cannot construct com.bloodhound.ws.edi.domain.Header : com.bloodhound.ws.edi.domain.Header
at com.thoughtworks.xstream.converters.reflection.SunLimitedUnsafeReflectionProvider.newInstance(SunLimitedUnsafeReflectionProvider.java:80)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.instantiateNewInstance(AbstractReflectionConverter.java:553)
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:256)
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
... 53 common frames omitted
Caused by: java.lang.InstantiationException: com.bloodhound.ws.edi.domain.Header
at com.thoughtworks.xstream.converters.reflection.SunLimitedUnsafeReflectionProvider.newInstance(SunLimitedUnsafeReflectionProvider.java:76)
... 56 common frames omitted

[Jörg Schaible]

Hi,

Deepika Gadam wrote:

> We are facing a strange issue while unmarshalling. For some reason
> SunLimitedUnsafeReflectionProvider is trying to create an instance for
> interface , rather than a class.
>
> We are passing an array of classes to process annoations. In Annotation
> Mapper class, processTypes method at the end adds interfaces also to the
> annotatedTypes Set, though we passed only List of actual implementing
> classes.
>
> This is our Spring COnfig:
>
> <bean
> class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"
> p:targetObject-ref="xstream" p:targetMethod="processAnnotations"
> p:arguments-ref="xStreamClassList" />
>
> <bean id="xstream" class="com.thoughtworks.xstream.XStream" />
>
> <util:list id="xStreamClassList">
> <value>com.bloodhound.ws.edi.domain.xml.EdiMessageXstream</value>
> <value>com.bloodhound.ws.edi.domain.xml.EdiRequestXstream</value>
> <value>com.bloodhound.ws.edi.domain.xml.EdiResponseXstream</value>
> <value>com.bloodhound.ws.edi.domain.xml.HeaderXstream</value>
> </util:list>
>
> Instead of creating an instance for HeaderXstream, it's creating instance
> for it's interface com.bloodhound.ws.edi.domain.Header
>
> Any Help would be very appreciated.

Well, this is not the normal XStream behavior. However, I am not familiar
with Spring and I have no clue what this configuration actually means for
the setup up of XStream.

If you can provide me an example where Spring is not involved, I might be
able to help you.

From the provided configuration I can see at least that you're using
annotations to configure XStream. Where do you use these annotations
actually?

Cheers,
Jörg

[Deepika Gadam]

I have attached all the source files and sample message., if you see EdiMessageXstrem class, we are using @XStreamImplicit
@XmlAttribute(name = "headers")
private List<Header> headers = new LinkedList<Header>();

Header is an interface implemented by HeaderXstream Class.
If you see sample message it's trying to unmarshal

<?xml version='1.0' encoding='UTF-8'?><com.bloodhound.ws.edi.domain.xml.EdiRequestXstream><headers class="linked-list">

for headers type instead of returning HeaderXstream class, interface is returned and it's throwing exception.

I have tried debugging, this is what I found: while unmarshalling headers
ImplicitCollectionMapper class ImplicitCollectionMapping getImplicitCollectionDefForFieldName(String fieldName) method is returning mapper with interface header.

Any idea how interfac eis returned rather than class?

AbstractReflectionConverter class
line 418 type = implicitCollectionMapping.getItemType();
here type is interface header rather than it's implementation class.

Any help would be much appreciated.

[Jörg Schaible]

Hi,

Am Montag, 21. November 2016, 19:46:26 schrieb Deepika Gadam:
> I have attached all the source files and sample message., if you see
> EdiMessageXstrem class, we are using @XStreamImplicit
> @XmlAttribute(name = "headers")
> private List<Header> headers = new LinkedList<Header>();
>
> Header is an interface implemented by HeaderXstream Class.
> If you see sample message it's trying to unmarshal
>
> <?xml version='1.0'
> encoding='UTF-8'?><com.bloodhound.ws.edi.domain.xml.EdiRequestXstream><head
> ers class="linked-list">
>
> for headers type instead of returning HeaderXstream class, interface is
> returned and it's throwing exception.
>
> I have tried debugging, this is what I found: while unmarshalling headers
> ImplicitCollectionMapper class ImplicitCollectionMapping
> getImplicitCollectionDefForFieldName(String fieldName) method is returning
> mapper with interface header.
>
> Any idea how interfac eis returned rather than class?
>
> AbstractReflectionConverter class
> line 418 type = implicitCollectionMapping.getItemType();
> here type is interface header rather than it's implementation class.
>
> Any help would be much appreciated.

It looks like the XML was written with classes which did not contain the
XStream annotations and now you try to read the XML with a different version
containing the XStream annotations. That will not work.

As a result of your setup your writing and reading a different XML structure
compared to the one you gave as example.

Cheers,
Jörg

[Deepika Gadam]

Hi,

That file is written by same classes, for some some reason it's not honoring alias annotations.

We have a camel route that marshals and unmarshals to and from jms queues. That message is marshalled by same route. Hope it's clear

--
You received this message because you are subscribed to a topic in the Google Groups "XStream User" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xstream-user/jUOktidAvtw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xstream-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xstream-user/5586823.ZpQI2FQ3L5%40floh.
For more options, visit https://groups.google.com/d/optout.

[Jörg Schaible]

Hi Deepika,

Deepika Gadam wrote:

> Hi,
>
> That file is written by same classes, for some some reason it's not
> honoring alias annotations.
>
> We have a camel route that marshals and unmarshals to and from jms queues.
> That message is marshalled by same route. Hope it's clear

All I can say is, that your XML was definitely written with a plain XStream
instance without any further configuration, while you try to read this XML
with an XStream instance that *is* configured for your aliases and implicit
collection.

Since these two XStream instances process a different XML format, it is no
wonder that you get errors.

I have no idea, how Camel or Spring actually do setup the XStream instance.
You configuration snippet implies that Spring invokes at some stage the
preprocessing of the XStream annotations. You will have to ask Spring or
Camel devs why this initialization sequence is sometimes missing.

Cheers,
Jörg