search

Mause / snakeyaml

Automatically exported from code.google.com/p/snakeyaml
Apache License 2.0
0 stars 0 forks source link

org.yaml.snakeyaml.error.YAMLException: No single argument constructor found for interface java.io.Serializable #203

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Problem occurs seemingly random. I cannot reproduce it on command.

What is the expected output? What do you see instead?

We are randomly getting an exception deserializing a YAML object defined as

    public class FaqContent extends ContentIdentifierImpl {
which extends 
    public class ContentIdentifierImpl implements ContentIdentifier, Serializable {

Here is the stack trace:

===========

tion [Request processing failed; nested exception is Cannot create property=id 
for 
JavaBean=com.edlogics.elrc.model.FaqContent@1ff711a6[id=<null>,urlFriendlyId=<nu
ll>,type=FAQS]
 in 'reader', line 2, column 3:
      id: 10001
      ^
No single argument constructor found for interface java.io.Serializable
 in 'reader', line 2, column 7:
      id: 10001
          ^
] with root cause

org.yaml.snakeyaml.error.YAMLException: No single argument constructor found 
for interface java.io.Serializable
    at org.yaml.snakeyaml.constructor.Constructor$ConstructScalar.construct(Constructor.java:390)
    at org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:182)
    at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:297)
    at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.construct(Constructor.java:189)
    at org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:340)
    at org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:182)
    at org.yaml.snakeyaml.constructor.BaseConstructor.constructDocument(BaseConstructor.java:141)
    at org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:127)
    at org.yaml.snakeyaml.Yaml.loadFromReader(Yaml.java:481)
    at org.yaml.snakeyaml.Yaml.load(Yaml.java:412)

=====

If I put a debugger on Constructor.ConstructScalar.construct, *normally* all of 
the node.getType() values are either String or a number. I don't know why, on 
occasion, they would be instead marked as Serializable. That is when the 
exception seems to arise.

Finally, after the Serializable glitch arrises, it doesn't go away. It is stuck 
in this permanent error state and we need to restart the JVM to reset it.

What version of SnakeYAML are you using? On what Java version?

1.14 and Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

Please provide any additional information below. (Often a failing test is
the best way to describe the problem.)

This seems like a JVM glitch dealing with interfaces and reflection which 
probably stems from PropertyUtils.getPropertiesMap, but I could be wrong. I am 
not familiar enough with SnakeYaml to diagnose the exact problem.

We are looking for a workaround at the very least at this point. Any pointers 
would be greatly appreciated.

Original issue reported on code.google.com by murp...@gmail.com on 6 Jan 2015 at 7:52

GoogleCodeExporter commented 9 years ago 
Also, just to clarify, ContentIdentifierImpl contains the id property, which is 
what seems to be failing. 

    @Override
    public Long getId() {
        return this.id;
    }

    @Override
    public void setId( Long id ) {
        this.id = id;
    }

Why a Long would be getting interpreted as a Serializable is mystifying to me.

Original comment by murp...@gmail.com on 6 Jan 2015 at 8:00

GoogleCodeExporter commented 9 years ago 
Well, since you do not give the complete source my guess is that the 
ContentIdentifierImpl class needs a single argument constructor, because your 
YAML documents expects it (the document would be also helpful to see). 
Solution 1:

public ContentIdentifierImpl(Long id) {
    this.id = id;
{

Solution 2:
change YAML to avoid single argument constructor

Original comment by py4fun@gmail.com on 6 Jan 2015 at 9:28

GoogleCodeExporter commented 9 years ago 
Thanks for the quick response. 

After further investigation, I believe our problem is a combination of using 
generics to define the type for the id from a super class and a possible JVM 
bug (this this occurs sporadically). We are going to try to remove the generic 
interface definition and see if that fixes the problem. The interfaces in 
question are defined as such:

    public interface ContentIdentifier extends Identifiable<Long>

then:

    public interface Identifiable<ID extends Serializable> {
    ID getId();
    }

I will report back on the results.

Original comment by murp...@gmail.com on 7 Jan 2015 at 1:38

GoogleCodeExporter commented 9 years ago 
Well, SnakeYAML does a lot of magic to support generics. If you can provide a 
small test to reproduce the problem we can further investigate the cause.
In the past we also experienced different failures for different platforms (and 
JDK versions). It may be related only to the platform you use.

Original comment by py4fun@gmail.com on 7 Jan 2015 at 11:27

GoogleCodeExporter commented 9 years ago 
I wrote a test for this issue and does not fail.
Can you please check it ?
https://code.google.com/p/snakeyaml/source/detail?r=879e957656c95ca3e896988af2fd
d2e22bd244df

Original comment by py4fun@gmail.com on 8 Jan 2015 at 5:53

GoogleCodeExporter commented 9 years ago 
I made some minor changes to your test case to better align with our code. I 
put in a loop to run it 10,000 times since the problem occurs occasionally. No 
error. When I can get a few minutes I will try to run it the same JVM as our 
server and see what it does. Stay tuned.

Original comment by murp...@gmail.com on 8 Jan 2015 at 8:07

GoogleCodeExporter commented 9 years ago 
I cannot reproduce within your test project, even running it a million times on 
the same JVM producing the problem. I even included the same 1.14 dependency 
that our project is using. I need to think a bit more on this and how it can be 
reproduced. Thanks.

Original comment by murp...@gmail.com on 9 Jan 2015 at 1:57