Add support for @BeanParam like JAX-RS in Spring MVC [SPR-17237]

[spring-projects-issues]

Ankur Pathak opened SPR-17237 and commented

We can collect various parameters of HTTP Request like Path, Query, Header inside bean using @BeanParam in JAX-RS.

public class MyBean {

  @FormParam("myData") private String data;

  @HeaderParam("myHeader") private String header;

  @PathParam("id") public void setResourceId(String id) {
    // ...
  }

  // ...

}

We should have something similar to same in Spring to collect them inside Bean and also apply Bean Validation API for them at once. Listing all those parameters as method parameter list is inelegant way of handling them and does not allow to transfer them at once from one layer to other layer.

---

Affects: 5.1 RC2

Reference URL: https://docs.oracle.com/javaee/7/api/javax/ws/rs/BeanParam.html

[spring-projects-issues]

Juergen Hoeller commented

From my perspective, our method-based resolution model is very intentional, separating the extraction of request information from further processing. Putting such binding annotations into bean classes pollutes those classes with web annotations which arguably makes them less than ideal for passing down to another layer... Even technically, such bean classes will have to be compiled with web imports for those annotations, so can't be part of a service/repository module without web dependencies.

Rossen Stoyanchev, what's your take on this?

[spring-projects-issues]

Ankur Pathak commented

Hey Juergen Hoellar,

I totally agree with you completely. But they are service layer dtos, so it will be ok for them to have imports from

web layer. If required we can take out interface from them and use interface for them in bottom layer. So this will

solve the problem of web imports in bottom layer. At end collecting all request param in one bean will be good way

to handle them at once. Imagine i need two query params, two headers and two path params, it will require six parametes

for them in controller method apart from other parametres like request body, http request, http response, locale and

security principal. They together with all these other parameter create long list of parameter, this make controller method

look ugly and inelegant.

Thanks for Interacting with Me.

It was my dream to Interact with You and Rod from the begining of my career.

You guys are Role models.

[spring-projects-issues]

Ankur Pathak commented

Currently we are supporting this feature partially  for domains of Spring Data By Spring Data Web Support For Spring MVC.

https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/web/config/EnableSpringDataWebSupport.html

By DomainClassConverter - to allow usage of domain types managed by Spring Data repositories as controller method arguments bound with PathVariable or RequestParam.

So, why can't we have it as a dedicated feature in Spring MVC and web Flux for all param types.

 

[spring-projects-issues]

Rossen Stoyanchev commented

Listing each parameter individually is not the only option. Headers aside, you can use data binding to populate a command object from form data, query params, and path params, i.e.:

@PostMapping("/resource/{id}")
public String handleForm(MyBean myBean) {
    // ...
}

[spring-projects-issues]

Rossen Stoyanchev commented

Resolving due to inactivity.

[DaBlick]

I'm astonished that this was declined. The JAX-RS BeanParam feature provides tremendous value:

• Sharing common request facets like pagination, date filters, etc

In our JAX-RS applications we write a BeanParam bean for such filters. We just pass the BeanParam bean down from the REST layer, through the service layer and into the DAO layer. When we need to add a new request param, we just add it to the bean param and write code to handle it in the DAO layer.

What we avoid is the need to assemble the bean param from request params in ALL the resources that use it. The BeanParam also service as a nice "property bag" that is simply passed thru the layers that don't examine the contents.

[Frantch]

+1

Simple use case is for query params such as limit, offset, order, sort that needs to be copy pasted in every single controllers

[sm0217]

Apologies for commenting on a closed issue, This is still a pain point to not repeat the common headers, params etc across every http method and even across controllers in some cases. Is there a chance this will be supported? Or Has anyone found a cleaner way of doing this without the support for bean param. Thanks