Details

    • Type: New Feature New Feature
    • Status: In Progress
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2
    • Fix Version/s: 4.1 RC1
    • Component/s: Web
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      Jackson's JSONView annotation allows the developer to control which aspects of a method are serialiazed. With the current implementation, the Jackson view writer must be used but then the content type is not available. It would be better if as part of the RequestBody annotation, a JSONView could be specified.

        Issue Links

          Activity

          Hide
          Arjen Poutsma added a comment -

          Moved to SPR.

          Show
          Arjen Poutsma added a comment - Moved to SPR.
          Hide
          Arjen Poutsma added a comment -

          I am not completely sure what you mean, but I believe you can use the ResponseBody class to accomplish this.

          Show
          Arjen Poutsma added a comment - I am not completely sure what you mean, but I believe you can use the ResponseBody class to accomplish this.
          Hide
          Robert Pond added a comment -

          You can use JsonViews to determine what properties of a bean to include in the Json reponse. I think you can already accomplish this with the renderedAttributes property of the MappingJacksonJsonView though.

          Show
          Robert Pond added a comment - You can use JsonViews to determine what properties of a bean to include in the Json reponse. I think you can already accomplish this with the renderedAttributes property of the MappingJacksonJsonView though.
          Hide
          marc schipperheyn added a comment -

          @JsonView is intended to allow the developer to select which attributes to include in a json response on a per view basis. When you are using a ResponseBody, you are not manually creating any jsonViews anymore. As such this functionality should be integrated on @ResponseBody level either as a set of attributes or as an extra annotation, so that a developer can determine per responsebody which values he would like to include in the response. Also, it seems a bit inelegant to maintain a list of modelKeys to render at the view level (apart from the fact that it doesn't allow you to just use @ResponseBody). When the underlying model changes with new attributes to render, you would have to update all your views.

          Show
          marc schipperheyn added a comment - @JsonView is intended to allow the developer to select which attributes to include in a json response on a per view basis. When you are using a ResponseBody, you are not manually creating any jsonViews anymore. As such this functionality should be integrated on @ResponseBody level either as a set of attributes or as an extra annotation, so that a developer can determine per responsebody which values he would like to include in the response. Also, it seems a bit inelegant to maintain a list of modelKeys to render at the view level (apart from the fact that it doesn't allow you to just use @ResponseBody). When the underlying model changes with new attributes to render, you would have to update all your views.
          Hide
          Filip Spiridonov added a comment - - edited

          Here is an example and the spring black magic workaround:
          http://stackoverflow.com/questions/7637467/jacksons-jsonview-jsonfilter-and-spring
          I agree, it would be nice to have an ability to simply declare the @JsonView(ViewName.class) next to (or inside of) the @ResponseBody.

          Show
          Filip Spiridonov added a comment - - edited Here is an example and the spring black magic workaround: http://stackoverflow.com/questions/7637467/jacksons-jsonview-jsonfilter-and-spring I agree, it would be nice to have an ability to simply declare the @JsonView(ViewName.class) next to (or inside of) the @ResponseBody.
          Hide
          Alex added a comment -

          Here you can find an implementation that can be a starting point: https://github.com/martypitt/JsonViewExample
          I would find a cleaner solution if the name of the view could be selected as a property of @ResponseBody annotation.
          The same property could be used also for similar task for the XML or other marshallers

          Show
          Alex added a comment - Here you can find an implementation that can be a starting point: https://github.com/martypitt/JsonViewExample I would find a cleaner solution if the name of the view could be selected as a property of @ResponseBody annotation. The same property could be used also for similar task for the XML or other marshallers
          Hide
          Elnur Abdurrakhimov added a comment -

          I want and need this badly. Any neat solutions yet?

          Show
          Elnur Abdurrakhimov added a comment - I want and need this badly. Any neat solutions yet?
          Hide
          Gunnar Hillert added a comment -

          This is maybe not the perfect Jira - but for XD-999 it would have been nice to "fine-tune" Jackson serialization on a per-controller basis. We had to add a Jackson MixIn, but only needed that for one controller to suppress serialization for one property. The problem is that when doing it on a more global level you may introduce unnecessary project dependencies for other sub-projects.

          Show
          Gunnar Hillert added a comment - This is maybe not the perfect Jira - but for XD-999 it would have been nice to "fine-tune" Jackson serialization on a per-controller basis. We had to add a Jackson MixIn, but only needed that for one controller to suppress serialization for one property. The problem is that when doing it on a more global level you may introduce unnecessary project dependencies for other sub-projects.
          Hide
          Willie Wheeler added a comment - - edited

          +1

          I have a RESTful web service that exposes collection resources (e.g., /data-centers) and single resources (e.g., /data-centers/chandler). The collection resource endpoints present a more summary view of the data, whereas the single resource endpoints are more detailed. For the collection resource endpoints, I want to use @JsonView to suppress fields not included in that view, as opposed to having them show up null. (Besides keeping the representation tidy, I'd like to distinguish unused fields from fields that have null values.) The single resource endpoints should show all fields.

          So the JSON view varies from endpoint to endpoint, and it would be useful to have a clean way to communicate this to the ObjectMapper.

          Show
          Willie Wheeler added a comment - - edited +1 I have a RESTful web service that exposes collection resources (e.g., /data-centers) and single resources (e.g., /data-centers/chandler). The collection resource endpoints present a more summary view of the data, whereas the single resource endpoints are more detailed. For the collection resource endpoints, I want to use @JsonView to suppress fields not included in that view, as opposed to having them show up null. (Besides keeping the representation tidy, I'd like to distinguish unused fields from fields that have null values.) The single resource endpoints should show all fields. So the JSON view varies from endpoint to endpoint, and it would be useful to have a clean way to communicate this to the ObjectMapper.

            People

            • Assignee:
              Sébastien Deleuze
              Reporter:
              Brandon Whiteman
              Last updater:
              Sébastien Deleuze
            • Votes:
              21 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since last comment:
                20 weeks, 2 days ago