Recursive objects are not fully supported. Dumping works but loading does not.

Hi.

Do you have already any ideas haw to implement it?

Like dividing construction process into 2 steps: 1. createObject - which creates instance without setting any internal properties. Then you can store this instance in constructeuObjects map for further references 2. initObject - read all stored properties... It could resolve self-referencing problem.

or passing some Interface to the Construct.construct making the contract that constructor will add new object as soon as it is created using provided interface?

-Alex

http://vomos.blogspot.com/2009/06/blog-post.html

Feel free to contribute the implementation !

here is initial implementation patch for recursive objects. It needs more tests for recursion, but it passes those ones from pyyaml (included in current distribution, but ignored).

During parsing recursive objects are identified and marked in Node as need2StepConstruction. Then it is up to Constructor how object will be created (1 step or 2). If recursive object is map's key or set's member, than it is added to map or set only after 2nd step (partial creation may have influence on object's hash code). Because of this (and the way how it's done) now LinkedMap or Set will have wrong order of items if one of them (items) is recursive object.

would be nice to have more complex tests for recursive object.

Thank you very much ! This is a very important contribution. It will take some time to evaluate the change. In the meantime you can apply this patch ON TOP of yours to see the questions I have.

Because the patch decreases the total test coverage I need to provide more tests.

I will do my best to finish the evaluation and accept the patch next week.

Andrey

main fix: object collection for 2nd step initialization moved from callConstructor to constructObject

Thanks. I have applied the patch. There is still some room for improvement.

BaseConstructor: dropped pushToConstruction2ndStep method Constructor: dpopped ConstuctYamlObject.construct2ndStep method Constructor: simplified createMappingNode method - drop an argument Test coverage in the constructor package dropped from 97% to 94%.

HumanTest enhanced: Human with children as Map, as Set, as List HumanGenericsTest added: same as HumanTest, but internal structure defined using generics,

Constructor: callConstructor & callPostCreate changed to work with 2steps creation for Sets & Sequences, getClassForNode created BaseConstructor: createDefauldSet() created

Do not know how you count coverage. For me Clover now shows 96.9%, only places there Exceptions thrown are shown as never invoked.

patch is against assembla repo of course

P.S. 1. there is typo in Human "parner" most probably should be "partner", but I decided not to change it. 2. there is typo also in all constructors: Constuct.... instead of Construct... (but it could be an author's decision ;)

Thank you very much. Your contribution is in the master repository. (I have also fixed the typos)

To see the reports you can run mvn clean site and check the target/site/index.html (Project Reports > Cobertura Test Coverage)

This is how it looks like for version 1.2: http://snakeyamlrepo.appspot.com/releases/1.2/site/project-reports.html

-Andrey

hi,

i get failed tests for revision 04dd2fc416:

Failed tests: testNoChildren(org.yaml.snakeyaml.recursive.generics.HumanGenericsTest) testChildren(org.yaml.snakeyaml.recursive.generics.HumanGenericsTest) testChildren2(org.yaml.snakeyaml.recursive.generics.HumanGenericsTest) testChildren3(org.yaml.snakeyaml.recursive.generics.HumanGenericsTest) testBeanRing(org.yaml.snakeyaml.recursive.generics.HumanGenericsTest)

can you please run:

mvn clean test

and attach here the zipped target folder together with the Java version and the OS details ?

I can reproduce it also. Seems like connected to jvm used.

Some results

OS X: PASSED 1. java version "1.5.0_19" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-304) Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode, sharing) PASSED 2. java version "1.6.0_13" Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)

Fedora 11: PASSED 1. java version "1.6.0_14" Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) FAILED 2. java version "1.6.0_0" OpenJDK Runtime Environment (IcedTea6 1.5) (fedora-22.b16.fc11-i386) OpenJDK Client VM (build 14.0-b15, mixed mode) FAILED with exception 3. java version "1.5.0" gij (GNU libgcj) version 4.4.0 20090506 (Red Hat 4.4.0-4)

first guess it is something connected to reflection, how types for properties assigned. there are 2 archives of target folder attached for mentioned 2 FAILURES.

P.S. Fedora running under VMWare Fusion 2.0.5 Under fedora maven 2.2.0 was used. Installed in home folder. invoked like ../../apache-maven-2.2.0/bin/mvn clean test MAVEN_HOME were also set. ....just because fedora 11 has only maven 2.0.4 available as official package :(

$ java -version java version "1.6.0_0" OpenJDK Runtime Environment (IcedTea6 1.5) (6b16-4) OpenJDK 64-Bit Server VM (build 14.0-b15, mixed mode)

$ mvn --version Maven version: 2.0.9 Java version: 1.6.0_0 OS name: "linux" version: "2.6.30-1-amd64" arch: "amd64" Family: "unix"

$ cat /etc/debian_version squeeze/sid

I could reproduce the issue. I think it may be caused by a bug on non-Sun Java implementations. Because we test SnakeYAML and not Java I have disabled the failing tests. Feel free to fix them properly if you have time.

-Andrey

The issue is finally fixed. The details are here:

http://code.google.com/p/snakeyaml/wiki/Documentation#Generics

It appears that the failing tests actually succeeded and vice versa. Any hint on why java.beans.Introspector works so unpredictably is much appreciated.

-Andrey