Xstream no-args constructor error
Asked Answered
V

4

14

I'm getting the following error when it tries to create an instance of 'Transacao'

`Error: Cannot construct br.com.cbmp.ecommerce.resposta.Transacao as it does not have a no-args constructor : Cannot construct br.com.cbmp.ecommerce.resposta.Transacao as it does not have a no-args constructor `

---- Debugging information ----

message : Cannot construct br.com.cbmp.ecommerce.resposta.Transacao as it does not have a no-args constructor 

cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException 

cause-message : Cannot construct br.com.cbmp.ecommerce.resposta.Transacao as it does not have a no-args constructor `

class : br.com.cbmp.ecommerce.resposta.Transacao 

required-type : br.com.cbmp.ecommerce.resposta.Transacao 

path : /transacao

I am aware that there's a bug with XStream 1.3.1 and JDK7, but I'm currently using XStream 1.3.1 and JDK6. Any ideas why this error is still happening?

Thanks

Vociferance answered 8/3, 2012 at 16:43 Comment(3)
Does you class have a non-arg constructor? If you don't write a constructor it uses the no-arg constructor from Object but if you write a constructor it doesn't therefore you have to provide your own no-arg constructor.Alleris
@Alleris the class indeed does have a constructor with arguments, which brings me to the question: do I really have to create a no-arg constructor? I need to pass the parameters, or else the class will not work. If add the no-arg constructor, it'll call this constructor and the object will be incomplete, resulting in a NullPointerExceptionVociferance
I had a similar problem a little while ago with a Dynamic Web Project wanting me to define a no-args constructor and once I did everything seemed to work. I don't exactly know why it was required (I assume for when the REST service was trying to create a response without data it was called by default) but as far as I can tell adding it did not affect the performance of my code. All I did in the constructor was call super()Alleris
A
18

3 solutions:

  1. Provide a no-args constructor (obvious)
  2. Make this object implement Serializable.
  3. Upgrade to xstream 1.4.4*

I use solution #2 all the time.

*I verified 1.2.2 doesn't work and 1.4.4 does work, haven't tried any versions in-between

Androecium answered 28/10, 2012 at 20:42 Comment(1)
I'm using XStream 1.4.4 with JDK6 and I have similar problem. I can't use solution 1 or 2. Any other ideas?Abernathy
B
6

Simple answer: all of your inner classes must be marked static, or you should use full e.g. not inner classes.

Long answer: Java does a few things automatically, and you've encountered an edge case (See here). It's (mostly) impossible for an inner class to have a no-args constructor. Java always adds one argument to any constructors in an inner/local class, and that argument is a reference to the parent class. This is used so you can access all variables/methods of the parent, but means that even a no-args (in code) constructor has (when using reflection, like xstream does) one argument. To fix, mark the class as static so that it no longer requires inheriting all of the parent class methods/variables.

Baier answered 8/3, 2012 at 16:43 Comment(2)
+1 Thanks for the long answer, good to know why things occur rather than just how to solve them. Also solved my issue.Fungistat
I upgraded to XStream 1.4.4 as JRL said not worked, but this worked for me, Thank you @BaierReichel
S
3

xstream 1.3.1 does not support anymore the deserialization under JDK 1.7 if there is no non-arg constructor.

Resolution:

1) To resolve this issue, you need to use JDK6 if you want to continue with 1.3.1 jar.

2) If you using JDK7 or later then to resolve this issue, you need to upgrade JAR xstream.jar 1.3.1 to later release.

For more detail, please refer https://jira.atlassian.com/browse/JRA-32823.

Selfhypnosis answered 11/9, 2015 at 9:44 Comment(0)
W
2

I was able to fix a similar error message by updating to xstream 1.4.4 Now it's jdk7 friendlier. In my particular instance (even odder) it would fail in the editor, and succeed on the command line. Turns out my command line was using jdk6, editor was using jdk7. Go figure.

ref: http://xstream.10960.n7.nabble.com/JAVA-7-compatibility-problem-td7172.html

Womera answered 24/4, 2013 at 19:19 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.