Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@JsonPropertyOrder, Mixins and PropertyNamingStrategy ignored #4

Open
mjmeyer opened this issue Sep 30, 2014 · 1 comment
Open

@JsonPropertyOrder, Mixins and PropertyNamingStrategy ignored #4

mjmeyer opened this issue Sep 30, 2014 · 1 comment
Labels

Comments

@mjmeyer
Copy link

mjmeyer commented Sep 30, 2014

I really really like this approach to HAL generation and have been playing with it in a RESTEasy/JAX-RS environment to good results so far.

However, I also really like using the some of the jackson serialization annotations and mixins on my domain entities (or DTOs) to do things like order the properties, ellide properties and apply a naming strategy.

Unfortunately, the design of AbstractResourceFactoryStrategy which walks the inheritance hierarchy of the object used to create the resource, copying fields into it's internal map breaks all of that. Jackson never sees my class to apply the mixins or annotations to and never sees any class (just a map of <String,Object>) to apply naming strategy to.

I half wonder if preserving the object given to create the resource in the AbstractResourceFactoryStrategy's map couldnt be possible? I suspect it would break being able to have embeded resources but not sure.

I wouldnt be opposed to having my DTOs implement some ResourceEmbedding interface where the impl is expected to have a member to hold embedded resources in and then HyperExpress can populate it based on the relationship config as it walks the hierarchy. This way my type can be preserved for normal jackson serialization annotations to be processed?

Any other thoughts on how we can continue to use jackson serialization annotations and mixins with HyperExpress?

@tfredrich
Copy link
Member

Some very good thoughts here. Thanks!

Perhaps the AbstractResource could be just a wrapper (instead of essentially a Map), referencing the object instead of copying it. The downside is that since the Resource would hold that object as a Reference, modifying the referenced object would change the resource.

Either that, or we could maybe leverage the Jackson serializer to populate the Resource instead of simply copying every property.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants