Recent changes to bugs

#42 Exception during deserialization after upgrading to new java version

Piotr — Thu, 14 Jan 2016 15:57:06 -0000

I made more tests and it seems to fix the bug the DetailScanner.methods(Class) should be changed as follows:

   private void methods(Class type) {
      Method[] list = type.getDeclaredMethods();

      for(Method method : list) {
         if (!method.isBridge()) {  // FIX
            MethodDetail detail = new MethodDetail(method);
            methods.add(detail);
         }
      }
   }

#42 Exception during deserialization after upgrading to new java version

Piotr — Thu, 14 Jan 2016 14:57:06 -0000

To filter out bridge methods the java.lang.reflect.Method.isBridge() can be used.

Exception during deserialization after upgrading to new java version

Piotr — Thu, 14 Jan 2016 14:55:54 -0000

After upgrading java on my workstation I am observing one of these two exceptions during xml deserialization:

java.lang.ClassCastException: java.lang.Object cannot be cast to java.lang.String

org.simpleframework.xml.core.MethodException: Method types do not match for value in class java.lang.String

I investigated the problem and found out that this exception is thrown, because of java bug fix JDK-6695379 introduced in version 1.7.0_80 (Oracle Corporation). With this fix java compiler copies annotations to bridge methods. Therefore method MethodScanner.build(MethodPart, MethodPart) throws an exception, because cannot match get() and set() types. Or the ClassCastException is thrown, because the bridge with wrong data type is chosen.

I am attaching an example program demonstrating this problem. To test it, run the SerializationUtilsTest.testDeserializeXml test on Oracle java version 1.7.0_79 (the test should pass) and on Oracle java version 1.7.0_80 or higher (the test should fail).

#41 Transform ignores the name specified in the Root tag.

philipp — Thu, 10 Dec 2015 21:10:23 -0000

Maybe related to bug [#35].

Transform ignores the name specified in the Root tag.

Phyambre — Sun, 04 Oct 2015 14:28:59 -0000

If you create a class with a tag Root(name=xxx) and that class has a Transform registered, the serialization to XML will ignore the name specified in the tag Root and will just use the name of the class. This ony happens if the class is the root tag of the XML, because if you use it as an attribute or element in another class, it will take the name specified there.
See attached poject to play with the bug

#40 Converter and Transformer violate contract of ElementUnion during deserialization

Phyambre — Tue, 22 Sep 2015 14:38:33 -0000

Note, I have a problem showing the XML, but it is correct: inside the tag x there is a tag b as expected. Anyway, you can try it in the code.

Converter and Transformer violate contract of ElementUnion during deserialization

Phyambre — Tue, 22 Sep 2015 14:37:10 -0000

Let us imagine 3 classes: A, B extends A, and C extends A, all representing tags without attributes or inner elements. And now a fouth class X containg the ElementUnion:

@ElementUnion({
@Element(name="b", type=B.class, required=false),
@Element(name="c", type=C.class, required=false)
})
protected A a;

It seems clear that if the inner tag of X tag is b, the attribute a should be an instance of B. For example, for the code:

X x = new X(new B());
Object retrievedObject = null;
serializer.write(x, tmpFile);
System.out.println("Written Object: " + x);
retrievedObject = serializer.read(X.class, tmpFile);
System.out.println("Retrieved Object: " + retrievedObject);

The expected output is:
Written Object: X [a=B []]
Retrieved Object: X [a=B []]

The problem seems to happen due deserialization, because the XML file seems correct:
<x>

</x>

However if A is a class (not an interface) and A has a converter, then the output is (independently of whether B has also a converter or not):
Written Object: X [a=B []]
Retrieved Object: X [a=A []]
Which is wrong, because the attribute a should only be of type B or C according to the type attriubute of the annotation ElementUnion. This does not happen with interfaces because they cannot be instantiated.

In addition, if there are no converters, but we set matchers, the output becomes:
Written Object: X [a=B []]
Retrieved Object: X [a=null]
Which should also be wrong, although it does not violate the contract.

I attach a sample code so you can play with it and see the results.

ContainerServer and Server are missing from the maven repository

Andre Francois — Wed, 15 Jul 2015 05:18:26 -0000

Can you recreate the jars on the maven repository for 6.0.1 with all the classes? ContainerServer and Server are missing.

#38 StackOverflowError (recursion) during Exception serialization (PrefixResolver.resolvePrefix/getPrefix)

Philipp — Sun, 15 Mar 2015 23:07:04 -0000

Friendly reminder

StackOverflowError (recursion) during Exception serialization (PrefixResolver.resolvePrefix/getPrefix)

Philipp — Tue, 23 Dec 2014 12:25:46 -0000

Thanks for the great work. I'm using SimpleXML massively in my project. I'm getting a recursive exception when trying to serialize a n Exception object:

Exception in thread "main" java.lang.StackOverflowError
  at org.simpleframework.xml.stream.PrefixResolver.resolvePrefix(PrefixResolver.java:183)
  at org.simpleframework.xml.stream.PrefixResolver.getPrefix(PrefixResolver.java:123)
  at org.simpleframework.xml.stream.PrefixResolver.resolvePrefix(PrefixResolver.java:183)
  at org.simpleframework.xml.stream.PrefixResolver.getPrefix(PrefixResolver.java:123)
  at org.simpleframework.xml.stream.PrefixResolver.resolvePrefix(PrefixResolver.java:183)
  ... (continues)

This code reproduces the exception:

public class MainClass {
  public static void main(String[] args) throws Exception {
    SomeClass someClass = new SomeClass();
    someClass.exception = new Exception();

    StringWriter stringWriter = new StringWriter();
    new Persister().write(someClass, stringWriter);

    System.out.println(stringWriter.toString()); // <<< Bam!
  }

  public static class SomeClass {
    private Exception exception;        
  }
}