Bug when serializing resources with HalEmbeddedBuilder

[chringwer]

I encountered a bug in HalEmbeddedBuilder. Adding more than 2 values with the same reltype to an embedded collection will result in somthing like this:

  "_embedded" : {
    "listItem" : {
      "label" : "lorem",
      "_links" : {
        "self" : {
          "href" : "http://localhost:3000/rest/lists/lorem"
        }
      }
    },
    "listItems" : [ {
      "label" : "ipsum",
      "_links" : {
        "self" : {
          "href" : "http://localhost:3000/rest/lists/ipsum"
        }
      }
    }, {
      "label" : "dolor",
      "_links" : {
        "self" : {
          "href" : "http://localhost:3000/rest/lists/dolor"
        }
      }
    } ]
  }

A fourth item would be merged with the single listItem and then replace the collection and so on...

[chringwer]

There is another bug occurring when serializing a Resources collection containing mixed resource types. The appropriate JsonSerializer instance in OptionalListJackson2Serializer was retrieved only for the first element's type and then cached for the whole process. I pushed a another commit fixing this issue.

[Laures]

@olivergierke can we merge this soon?

[gregorriegler]

please. i need this. its critical for my project -_-

[gregorriegler]

@olivergierke
i suggest to improve this project further towards the Open-Closed principle. Everything is tightly coupled.

---

//inside HypermediaSupportBeanDefinitionRegistrar

registerWithGeneratedName(new RootBeanDefinition(Jackson2ModuleRegisteringBeanPostProcessor.class), registry);

//inside serializer

HalEmbeddedBuilder builder = new HalEmbeddedBuilder(relProvider);

thus i am not able to replace the HalEmbeddedBuilder with a customized or "corrected" version as a "user"

[odrotbohm]

Does that make sense here? It seems we're now arbitrarily picking a serializer to return it, don't we?

[edrik]

I would say that it is just as "random" as it was befor (the type of the first item is not less random)

[odrotbohm]

@gregorriegler Let's try to keep tickets focused on a single change (SRP). Feel free to open a new one and suggest changes.

[gregorriegler]

@olivergierke good point. yes, of course. ill might even do that in the near future ;-)

[drdamour]

i believe this can be closed

[odrotbohm]

This is working in current versions.