Make Model types interact with Spring caching

[marcelboettcher]

Hey,

thanks for your awesome work! I struggled over a problem when serializing and deserializing my class that extends ResourceSupport. During that process the links are lost, because ResourceSupport is not Serializable - meaning only the default Constructor is called and no fields are set.

Could you please make ResourceSupport implement Serializable? Or am I missing a point?

Thank's a lot!

[odrotbohm]

Any chance you can elaborate on why ResourceSupport needs to be serialized in the first place? The sole reason it exists is to be able to easily create model classes to render representations of said model. So instances of that class should only be created in the controller (or a ResourceAssembler) and then evaluated by whatever marshalling infrastructure is in place.

I feel a bit weird adding Serializable to any class at will.

[marcelboettcher]

Hey Oliver, thanks for your answer. I'm caching some of my REST-API calls with Spring Cache Abstraction @Cacheable. The underlying cache implementation (I use redis) serializes the objects - hence I need them to be Serializable. Is that a normal use case or am I on the wrong spot for caching a REST API here?

Many thanks in advance! Marcel

[miguelcobain]

Usually people use DTO's and not their domain objects. These are just objects that represent your entities. There is an additional step needed that is to convert your entities to DTO's and vice verse, but it is usually worth it. Spring-hateoas provides Resource assemblers to make that task easier (Here a Resource is a DTO). Regarding DTO's you have complete control over them. You can easily make them serializable.

[marcelboettcher]

Hey Miguel, yes, I use Spring-hateoas and its Assembler to map my BOs to DTOs. I can make them Serializable, but they extend Resources and ResourceSupport, which are not Serializable. So for example Links in the ResourceSupport are not serialized as ResourceSupport is not Serializable. Any way to make this happen without making ResourceSupport Serializable?

[miguelcobain]

Ok, now I understand your problem. In my case, Jackson serializes them as JSON with no problems. But obviously your cache handles objects in a different way. I don't think there's any way to make a super class serializable. The only workarounds I can come up with are either:

• rebuild spring-hateoas with Serializable
• copy paste those classes in your project, make them serializable, extend only your resources from them until the main project has them serializable

I agree with you that it makes sense to make them serializable. After all, the purpose of a DTO is to be serialized, so it even makes sense in a semantic way.

[marcelboettcher]

Thanks! Currently I'm using your second work-around, but that does not feel so good in sense of clean code ;) Perfect, looking forward to the next release. Thanks again!

[miguelcobain]

Of course, its not the ideal solution in any way. Just trying to keep you going while this gets solved. :) The first solution shouldn't be very difficult and results in a much cleaner code. Additionally, your code base doesn't need to be changed at all when spring-hateoas updates (since you are using the same classes).

[tirsoh]

I am running into this exact same problem and it still looks like ResourceSupport has not been made Serializable. Are there any plans to put this in a future release?

[gregturn]

We should test out storing Spring HATEOAS responses with Spring's caching abstraction, and apply any necessary changes to properly support that.