search

UcasRichard / snakeyaml

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

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Recursive objects are not fully supported. Dumping works but loading does not.

Original issue reported on code.google.com by aso...@gmail.com on 8 Jun 2009 at 4:27

GoogleCodeExporter commented 9 years ago 
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

Original comment by alexande...@gmail.com on 29 Jun 2009 at 10:43

GoogleCodeExporter commented 9 years ago 
http://vomos.blogspot.com/2009/06/blog-post.html

Feel free to contribute the implementation !

Original comment by py4fun@gmail.com on 29 Jun 2009 at 12:36

GoogleCodeExporter commented 9 years ago 
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.

Original comment by alexande...@gmail.com on 2 Jul 2009 at 2:20

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Original comment by py4fun@gmail.com on 2 Jul 2009 at 5:46

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by py4fun@gmail.com on 3 Jul 2009 at 9:13

GoogleCodeExporter commented 9 years ago

Original comment by py4fun@gmail.com on 3 Jul 2009 at 10:09

GoogleCodeExporter commented 9 years ago 
main fix: object collection for 2nd step initialization moved from 
callConstructor to constructObject

Original comment by alexande...@gmail.com on 4 Jul 2009 at 11:54

Attachments:

GoogleCodeExporter commented 9 years ago 
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%.

Original comment by py4fun@gmail.com on 6 Jul 2009 at 4:40

GoogleCodeExporter commented 9 years ago 
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 ;)

Original comment by alexande...@gmail.com on 9 Jul 2009 at 8:02

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Original comment by py4fun@gmail.com on 9 Jul 2009 at 11:04

GoogleCodeExporter commented 9 years ago 
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)

Original comment by infinity0x@gmail.com on 9 Jul 2009 at 6:25

GoogleCodeExporter commented 9 years ago 
can you please run:

mvn clean test

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

Original comment by py4fun@gmail.com on 10 Jul 2009 at 7:11

GoogleCodeExporter commented 9 years ago 
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 :(

Original comment by alexande...@gmail.com on 10 Jul 2009 at 10:42

Attachments:

GoogleCodeExporter commented 9 years ago 
$ 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

Original comment by infinity0x@gmail.com on 10 Jul 2009 at 11:06

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Original comment by py4fun@gmail.com on 10 Jul 2009 at 2:50

GoogleCodeExporter commented 9 years ago 
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

Original comment by py4fun@gmail.com on 13 Jul 2009 at 2:01

GoogleCodeExporter commented 9 years ago

Original comment by aso...@gmail.com on 6 Aug 2009 at 10:01