Issue 36: Collection handling and deserializers for JSON-HAL

[Laures]

According to the spec and the mailing list, collections of resources are supposed to be serialized in the "_embedded" property with relations.

This pull request does the following:

• serialize instances of Resources in this fashion using the "content" relation. Currently there is no specific logic to "find" a specific relation.
• add deserializers for JSON-HAL for ResourceSupport and Resources
• add serialization and deserialization tests

A piece of Information about the deserializers: currently the only way for a deserializer to figure out the content type of a Resources instance is by evaluating the Jackson BeanProperty. This type resolution is not perfect as it does not handle other available sources of Type information (Jackson annotations on interfaces for example)
See: FasterXML/jackson-databind#165

Should fix #36

[odrotbohm]

What's the effect here? You store the value but then don't use it going forward.

[Laures]

in json hal the relation does not have to be in the link so the original idea was to set it on the read link.
but currently Link is basicly imutable. i wanted to open an issue to discuss that. thanks for reminding me.

[odrotbohm]

Immutable types are a virtue, not a bug :). We can get that sorted out, I think. You could simply create a new Link instance. Regarding the issue of resolving the relation attribute on serialization. What if we had a Spring bean available exposing the following interface:

interface RelProvider {

  String getSingleResourceRel(Class<?> type);

  String getCollectionResourceRel(Class<?> type);
}

If the serializer implementations are injection aware (accepting such a RelProvider) you could lookup the rel to be used based on the property type and only fall back to content in undefined cases. In Spring Data REST we already maintain configurable relation type attributes through @RestResource which could be exposed this way, and even for plain Spring Hateoas we have @ExposesResourceFor to be used on controller methods.

I've quickly tried to adapt your code accordingly but it seems that by default the (De)Serializers are expected to have a no-arg constructor as Jackson instantiates them by reflection which get's in the way here. There seem to be options to work around that (see this blog post for example) but that seems to require the Module implementation to be rather set up in setupModule(SetupContext context) instead of by using mixins.

So what if we were be able to provide a RelProvider to the module constructors? Would you mind giving the idea a spin to setup the module using the (de)serializer factory APIs handing the RelProvider forward? I gave it a quick spin but got lost in Jackson to some degree and you seem to be into it already.

[Laures]

unfortunately getting spring managed beans (or any pre created instance) into jackson is a pain. I'll try to go the way with a custom handler instantiator (it works, but is a bit buggy right now). As fallback I might use a class level annotation. something like @HateoasRelation

[odrotbohm]

I don't think we need to rely on direct Spring DI into the (de)serializers. Assume you get the RelProvider handed as constructor argument on the Module implementation. The thing I got stuck with was that as the (de)serializer implementations need to have no arg constructors there's no way to pass the RelProvider from the module to the (de)serializer (at least with the current implementation). If you could tweak it to achive that, we're all set.

I've started work on a general @EnableHypermediaSupport annotation (see #50) to tweak the ObjectMapper setup by registering the module manually. So we should be set in this regard, I think.

[odrotbohm]

An annotation based RelProvider reading the information from the entities is not a bad idea I think. It's just that I guess that most people don't want to annotate their domain types with web related stuff in the first place. Plus, we're still stuck with the problem that there's no real way to call the setter you exposed on the serializer, as Jackson is creating instances for this class over and over again and there's no way to massage the serializer after that has happened, right?

[Laures]

as Jackson is creating instances for this class over and over again and there's no way to massage the serializer after that has happened, right?

not totally. Jackson checks if a HandlerInstanciator is configured for the object mapper. If it is the instanciator is asked to supply an instance for the (de)serializer class (same happens for a lot of other handler classes) if the instanciator returns null an instance is created by using the default constructor. By default there is no instanciator configured.

The blog post you mentioned created a handlerinstantiator that tries to look up instances from the application context.

I would suggest two HandlerInstantiators: one where you can simply configure the resolver and that returns a configured serializer when required and a second one that tries to look up everything from the application context.

[odrotbohm]

Feel free to go ahead. I think you're more into Jackson than I am. We can discuss stuff then. Just wanted to make sure we think (and implement) in the same direction ;).

[Laures]

added relation resolution on a "by object" base. resolvers have to be configured on the handler instatiators (nested inside the module). The module can't do this as it has no access to the real objectmapper.
please take a look at the handler instantiators inside the modules. maybe i was a bit to generic^^

[odrotbohm]

I've tried to rebase the changes onto current master but failed unfotunately. I got an initial set of your work working again in the hal-#47 branch. Any chance you can get your latest work rebased on that one?

In the worst case, simply remove the HAL modules in the current codebase, take f5a6441 and build your latest version of that on top of that. I'll have a look at that then…

[Laures]

created a new pull request based on your hal-#47 branch.

#60