Consistant Property Mapping Order

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configure an object to map more than one property and log the order it was 
set
2. Run on a different JVM/OS (or in my experience restart the JVM)
3. Possibly see different output, possibly not depending on your luck

What is the expected output? What do you see instead?
Properties mapped in the same order across servers JVMs

What version of the product are you using? On what operating system?
1.2 snapshot on OS X and Windows

Please provide any additional information below.
This stems I believe from the properties being stored as sets which don't have 
an order and can change the order based upon implementation. I think a 
LinkedHashSet might meet the requirements. Also I would find it a nice bonus if 
I can explicitly specify the properties to be mapped first then call 
byDefault() to have add the remaining properties to happen afterwards.

Please let me know if I can provide any additional info

Original issue reported on code.google.com by kentong...@gmail.com on 17 Aug 2012 at 10:28

[GoogleCodeExporter]

Please check with current updates to 1.2.0; HashSet and HashMap implementations 
have been replaced with LinkedHashSet and LinkedHashMap where applicable.

Haven't put together a test case yet as this issue is a little tricky to unit 
test...

Original comment by matt.deb...@gmail.com on 17 Aug 2012 at 11:01

• Changed state: Started

[GoogleCodeExporter]

Original comment by matt.deb...@gmail.com on 18 Aug 2012 at 12:52

[GoogleCodeExporter]

Matt, we can just sort fieldMaps based on source/destination property name just 
after collecting metadata. this could fit the needs.

Original comment by elaat...@gmail.com on 24 Aug 2012 at 10:17

[GoogleCodeExporter]

Yes, I think that's right, or at least we could simply convert the 
Set<FieldMaps> to a LinkedHashSet<FieldMaps> in the toClassMap() method (I 
think it could possibly be iterated more than once)...I'll see about reverting 
most of these replacements back to the minmum necessary.

Original comment by matt.deb...@gmail.com on 28 Aug 2012 at 5:36

[GoogleCodeExporter]

now that I look at it a bit more, if we don't use an ordered set for the field 
mappings the whole time, we lose the order in which the user specified the 
field mappings; don't you think we should preserve this?

Original comment by matt.deb...@gmail.com on 28 Aug 2012 at 3:02

[GoogleCodeExporter]

Matt, I haven't had a chance to test out your patch but I think user field 
ordering is important

Original comment by kentong...@gmail.com on 28 Aug 2012 at 3:06

[GoogleCodeExporter]

Field ordering has been implemented in past versions; in most current version 
(1.3.0) there is even a special class included for consistent ordering of 
mapper and converter resolution.
Marking as fixed. (we can always reopen or create another ticket if issues 
arise)

Original comment by matt.deb...@gmail.com on 5 Oct 2012 at 6:49

• Changed state: Fixed