Develop Reference

Springboot: Can DTO be changed at runtime with null values not being present in the object returned from api?

I have a springboot application which is hitting raw api's of the datasource. Now suppose I have a Customer entity with approx 50 fields and I have a raw api for it in which I pass names of the columns and I get the values for that column. Now I am implementing api in springboot which consumes raw api.
I need to implement different api's in springboot for different combinations of the fields of Customer entity and return only those fields setted in object for which user had queried and remove the null valued fields from the object. One way is to implement different dto's for different combinations of the columns of Customer entity. Is there any other way to implement the same in which I don't need to define different dto's for different combinations of the columns of Customer entity in Spring boot ???

You can configure the ObjectMapper directly, or make use of the #JsonInclude annotation:
mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
OR
#JsonInclude(JsonInclude.Include.NON_NULL)
#JsonInclude(JsonInclude.Include.NON_NULL)
public class Customer {
private Long id;
private String name;
private String email;
private String password;
public Customer() {
}
// getter/setter ..
}
You can see how to do it with this sample code:
Customer customer = new Customer();
customer.setId(1L);
customer.setName("Vikas");
customer.setEmail("info#vikas.com");
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
String valueAsString = objectMapper.writeValueAsString(customer);
Since the password is left null, you will have an object that does not exist password.
{
"id": 1,
"name": "Vikas",
"email": "info#vikas.com"
}

with Jackson 2.0 serialization you can specify data inclusion on non nulls at different levels, i.e. on the object mapper (with constructor options), the DTO class or DTO class fields (with annotations).
See Jackson annotations here

This can be done using #JsonInclude inside the DTO class. Please refer following code block for ignoring null values.
#JsonInclude(Include.NON_NULL) // ignoring null values
#Data //lombock
#Builder //builder pattern
public class Customer {
private Long id;
private String name;
private String email;
private String password;
}

Jackson with Spring boot: control object substitution for specific method

I have entity type as item in recursive tree, so any item has references to its parent and children (of same type)
public class Category {
private Integer id;
private String displayName;
#JsonIdentityInfo(generator=ObjectIdGenerators.PropertyGenerator.class, property="id")
#JsonIdentityReference(alwaysAsId=true)
private Category parent;
#JsonInclude(JsonInclude.Include.NON_EMPTY)
#JsonIdentityInfo(generator=ObjectIdGenerators.PropertyGenerator.class, property="id")
#JsonIdentityReference(alwaysAsId=true)
private Set<Category> children;
// constructors, getters and setters
}
As you can see, I marked both reference fields with #JsonIdentityReference annotation forcing them to render as plain ids. Currently with this setup an entity is rendered as follows:
// from .../categories/0
{
"id" : 0,
"displayName" : "Root",
"parent" : null,
"children" : [ 1, 13, 17 ]
}
(which is perfectly fine).
However, very common use scenario for client is to fetch whole sub-tree starting from specific node, which in this implementation requires several requests to server. I want to create another enpoint that allows client to perform this operation with single request.
#RestController
#RequestMapping(value = "/categories")
public class CategoryController {
#Autowired
private CategoryService categoryService;
#Autowired
private CategoryRepository categoryRepo;
#RequestMapping(value = "/tree", method = RequestMethod.GET)
public Category getTree(#RequestParam(name = "root", required = false) Integer id) {
Category root = id == null ? categoryService.getRoot() : categoryRepo.findOne(id);
return categoryService.getTree(root);
}
// other endpoints
// getOne(id)
// getAll()
}
Response from this endpoint renders full objects only if I manually remove (alwaysAsId=true) flag from the children field. However, I want both endpoints coexist and render different layout. So, the question is: How can I make specific controller method choose whether full entities are replaced with ids?.
I already tried various combinations with #JsonView, but it seems this approach doesn't work. #JsonView can only control whether specific field is included or completely omitted, whereas I need children field to only change layout. Also, since child type is same as entity type, there is no way to split annotation marks between different classes.

/* Updated answer, after the remark about loosing the view markers in multiple levels hierarchies. */
The result you are looking for can still be achieved by using #JsonViews and a minor work-around inside Category object.
Supposing we have two types used as markers to output JSON views FlatView and HierarchicalView.
The principle of the solution is:
we associate most of the fields with the views. children field remains associated with FlatView only.
we create an additional getter for the children field, providing it with another property name, not clashing with the field or its original getter. This property is associated with HierarchicalView only.
It gives the following layout for Category class:
public class Category {
#JsonView({ FlatView.class, HierarchicalView.class}) // both views
private Integer id;
#JsonView({ FlatView.class, HierarchicalView.class}) // both views
private String displayName;
#JsonView({ FlatView.class, HierarchicalView.class}) // both views
#JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "id")
#JsonIdentityReference(alwaysAsId = true)
private Category parent;
#JsonView(FlatView.class) // flat view only!
#JsonInclude(JsonInclude.Include.NON_EMPTY)
#JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "id")
#JsonIdentityReference(alwaysAsId = true)
private Set<Category> children;
#JsonView(HierarchicalView.class) // hierarchical view only!
// note that the name is not `getChildren`: this generates another JSON property.
// Or use #JsonProperty to customize it.
public Set<Category> getChildrenAsTree() {
return this.children;
}
// constructors, getters and setters
}
The controller methods producing the output should be annotated with respective #JsonViews.
Drawbacks:
This approach does not use the same property name for same information represented differently. This might cause some difficulties for property matching, deserialization at client side.
If the default view is still used somewhere for Category, it will contain both the field and the property accessed via the additional getter.
Redundant and repetitive annotations :) harder to maintain.
Redundant getter for children field.

I finally found solution. It is based on first version of Antot's answer and uses custom serializer for content of children collection. The tree producing endpoint is marked with #JsonView(Category.TreeView.class) annotation and unmarked field inclusion is turned ON
#application.properties
spring.jackson.mapper.default-view-inclusion=true
// Category.java
#JsonInclude(JsonInclude.Include.NON_EMPTY)
#JsonSerialize(contentUsing = CategoryChildSerializer.class)
private Set<Category> children;
// CategoryChildSerializer.java
public class CategoryChildSerializer extends JsonSerializer<Category> implements ResolvableSerializer {
private JsonSerializer<Object> defaultSerializer;
private JsonSerializer<Object> idSerializer;
public void serialize(Category value, JsonGenerator gen, SerializerProvider provider) throws IOException, JsonProcessingException {
if(provider.getActiveView() == Category.TreeView.class)
defaultSerializer.serialize(value, gen, provider);
else
idSerializer.serialize(value.getId(), gen, provider);
}
public void resolve(SerializerProvider provider) throws JsonMappingException {
defaultSerializer = provider.findValueSerializer(Category.class);
idSerializer = provider.findValueSerializer(Integer.class);
}
}
Note how switching serializer delegates serialization instead of directly using JsonGenerator. Implementing ResolvableSerializer is in fact optional, it's just optimization step.

Spring Data JPA - bidirectional relation with infinite recursion

First, here are my entities.
Player :
#Entity
#JsonIdentityInfo(generator=ObjectIdGenerators.UUIDGenerator.class,
property="id")
public class Player {
// other fields
#ManyToOne
#JoinColumn(name = "pla_fk_n_teamId")
private Team team;
// methods
}
Team :
#Entity
#JsonIdentityInfo(generator=ObjectIdGenerators.UUIDGenerator.class,
property="id")
public class Team {
// other fields
#OneToMany(mappedBy = "team")
private List<Player> members;
// methods
}
As many topics already stated, you can avoid the StackOverflowExeption in your WebService in many ways with Jackson.
That's cool and all but JPA still constructs an entity with infinite recursion to another entity before the serialization. This is just ugly ans the request takes much longer. Check this screenshot : IntelliJ debugger
Is there a way to fix it ? Knowing that I want different results depending on the endpoint. Examples :
endpoint /teams/{id} => Team={id..., members=[Player={id..., team=null}]}
endpoint /members/{id} => Player={id..., team={id..., members=null}}
Thank you!
EDIT : maybe the question isn't very clear giving the answers I get so I'll try to be more precise.
I know that it is possible to prevent the infinite recursion either with Jackson (#JSONIgnore, #JsonManagedReference/#JSONBackReference etc.) or by doing some mapping into DTO. The problem I still see is this : both of the above are post-query processing. The object that Spring JPA returns will still be (for example) a Team, containing a list of players, containing a team, containing a list of players, etc. etc.
I would like to know if there is a way to tell JPA or the repository (or anything) to not bind entities within entities over and over again?

Here is how I handle this problem in my projects.
I used the concept of data transfer objects, implemented in two version: a full object and a light object.
I define a object containing the referenced entities as List as Dto (data transfer object that only holds serializable values) and I define a object without the referenced entities as Info.
A Info object only hold information about the very entity itself and not about relations.
Now when I deliver a Dto object over a REST API, I simply put Info objects for the references.
Let's assume I deliever a PlayerDto over GET /players/1:
public class PlayerDto{
private String playerName;
private String playercountry;
private TeamInfo;
}
Whereas the TeamInfo object looks like
public class TeamInfo {
private String teamName;
private String teamColor;
}
compared to a TeamDto
public class TeamDto{
private String teamName;
private String teamColor;
private List<PlayerInfo> players;
}
This avoids an endless serialization and also makes a logical end for your rest resources as other wise you should be able to GET /player/1/team/player/1/team
Additionally, the concept clearly separates the data layer from the client layer (in this case the REST API), as you don't pass the actually entity object to the interface. For this, you convert the actual entity inside your service layer to a Dto or Info. I use http://modelmapper.org/ for this, as it's super easy (one short method call).
Also I fetch all referenced entities lazily. My service method which gets the entity and converts it to the Dto there for runs inside of a transaction scope, which is good practice anyway.
Lazy fetching
To tell JPA to fetch a entity lazily, simply modify your relationship annotation by defining the fetch type. The default value for this is fetch = FetchType.EAGER which in your situation is problematic. That is why you should change it to fetch = FetchType.LAZY
public class TeamEntity {
#OneToMany(mappedBy = "team",fetch = FetchType.LAZY)
private List<PlayerEntity> members;
}
Likewise the Player
public class PlayerEntity {
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "pla_fk_n_teamId")
private TeamEntity team;
}
When calling your repository method from your service layer, it is important, that this is happening within a #Transactional scope, otherwise, you won't be able to get the lazily referenced entity. Which would look like this:
#Transactional(readOnly = true)
public TeamDto getTeamByName(String teamName){
TeamEntity entity= teamRepository.getTeamByName(teamName);
return modelMapper.map(entity,TeamDto.class);
}

In my case I realized I did not need a bidirectional (One To Many-Many To One) relationship.
This fixed my issue:
// Team Class:
#OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
private Set<Player> members = new HashSet<Player>();
// Player Class - These three lines removed:
// #ManyToOne
// #JoinColumn(name = "pla_fk_n_teamId")
// private Team team;
Project Lombok might also produce this issue. Try adding #ToString and #EqualsAndHashCode if you are using Lombok.
#Data
#Entity
#EqualsAndHashCode(exclude = { "members"}) // This,
#ToString(exclude = { "members"}) // and this
public class Team implements Serializable {
// ...
This is a nice guide on infinite recursion annotations https://www.baeldung.com/jackson-bidirectional-relationships-and-infinite-recursion

You can use #JsonIgnoreProperties annotation to avoid infinite loop, like this:
#JsonIgnoreProperties("members")
private Team team;
or like this:
#JsonIgnoreProperties("team")
private List<Player> members;
or both.

how to save an entity with a DiscriminatorValue

I have two entities User and Candidat, where Candidat extends the class User, as following :
User entity :
#Entity
#Table(name="users")
#Inheritance(strategy=InheritanceType.SINGLE_TABLE)
#DiscriminatorColumn(name="TYPE_USER",discriminatorType=DiscriminatorType.STRING,length=2)
#JsonTypeInfo(use=JsonTypeInfo.Id.NAME,include=JsonTypeInfo.As.PROPERTY,property="type")
#JsonSubTypes({
#Type(name="UC",value=Candidat.class)
})
#XmlSeeAlso({Candidat.class})
public class User implements Serializable {
#GeneratedValue(strategy=GenerationType.IDENTITY)
private Long codeUser;
//other code ...
Candidat entity :
#Entity
#DiscriminatorValue("UC")
#XmlType(name = "UC")
public class Candidat extends User {
private String codeMassar;
and to save a new Candidat I call this repository method :
candidatRepository.save()
from :
public interface CandidatRepository extends JpaRepository<Candidat, String> {
}
This is my rest service that calls the save method:
#RequestMapping(value = "/candidats", method = RequestMethod.POST)
public Candidat saveCandidat(#RequestBody Candidat candidat) throws Exception {
return candidatMetier.saveCandidat(candidat);
}
The problem is when I want to save a new Candidat as following :
{
"username": "User",
"password": "123456",
"email": "user#gmail.com"
}
I get an error saying :
Failed to read HTTP message:
org.springframework.http.converter.HttpMessageNotReadableException:
Could not read document: Unexpected token (END_OBJECT), expected
FIELD_NAME: missing property 'type' that is to contain type id (for
class org.capvalue.fme.domain.Candidat)
What I understand from it that I have to specify the type in the JSON object I'm sending, but I don't think that's necessary because I save a new Candidat which has the #DiscriminatorValue("UC"), so when its save in the User table it will be saved with type='UC' automatically.
how can I solve this ?

what I understand from it that I have to specify the type in the json
object I'm sending
Since you've added the #JsonTypeInfo, you should specify the actual class of object instances using the type field. For instance, if you set the type field to UC, Jackson will create an instance of Candidat class.
but I dont think that's necessary because I save a new Candidat which
has the #DiscriminatorValue("UC") so when its save in the User table
it will be saved with type='UC' automatically.
#DiscriminatorValue is going to be handled by your JPA provider. On the contrary, #JsonTypeInfo is a Jackson concept, so No! You can't expect your JPA #DiscriminatorValue helps Jackson to determine the actual type of the object instances.
You should either send type information in your JSON representation or remove #JsonTypeInfo and #JsonSubTypes from your User class. I guess removing the Jackson type annotations is the better approach, since you're using the actual subclasses in:
public Candidat saveCandidat(#RequestBody Candidat candidat) { ... }
Also, try to define some DTOs and return them as your REST endpoint return values. One advantage of this approach is that your Jackson and JPA metadatas are separated, hence you would avoid these problems.

Ignore JsonIgnore in Elasticsearch

I am developing an application which uses Spring-boot, a relational database and Elasticsearch.
I use JSON serialization at 2 differents places in the code:
In the response of the REST API.
When the code interacts with Elasticsearch.
There are some properties that I need in Elasticsearch but that I want to hide to the application user (e.g. internal ids coming from the relational database).
Here is an example of entity :
#Document
public class MyElasticsearchEntity {
#Id
private Long id; //I want to hide this to the user.
private String name;
private String description;
}
Problem : When the object it persisted in Elasticsearch, it gets serialized as JSON. Hence, fields with #JsonIgnore are ignored when serialized to Elasticsearch.
Up to now, I found 2 unsatisfying solutions :
Solution 1 : Use #JsonProperty like this :
#Id
#JsonProperty(access = JsonProperty.Access.READ_ONLY)
private Long id;
The id gets written in Elasticsearch and is nullified in the JSON response :
{
"id" : null,
"name" : "abc",
"description" : null
}
So it works but the application user still sees that this property exists. This is messy.
Solution 2 : Cutomize the object mapper to ignore null values
Spring-boot has a built-in option for that :
spring.jackson.serialization-inclusion=NON_NULL
Problem : it suppresses all non-null properties, not only those that I want to ignore. Suppose that the field description of the previous entity is empty, the JSON response will be :
{
"name" : "abc"
}
And this is problematic for the UI.
So is there a way to ignore such field only in the JSON response?

You could use Jackson JsonView for your purpose. You can define one view which will be used to serialize pojo for the application user :
Create the views as class, one public and one private:
class Views {
static class Public { }
static class Private extends Public { }
}
Then uses the view in your Pojo as an annotation:
#Id
#JsonView(Views.Private.class) String name;
private Long id;
#JsonView(Views.Public.class) String name;
private String publicField;
and then serialize your pojo for the application user using the view:
objectMapper.writeValueUsingView(out, beanInstance, Views.Public.class);
This is one example of many others on how view can fit your question. Eg. you can use too objectMapper.configure(SerializationConfig.Feature.DEFAULT_VIEW_INCLUSION, false); to exclude field without view annotation and remove the Private view.