Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-13581

@class is being shown on process definition statistics api endpoint

    • Icon: Bug Report Bug Report
    • Resolution: Won't Fix
    • Icon: L3 - Default L3 - Default
    • None
    • None
    • engine
    • None

      When:

      Calling an endpoints such as:
      https://localhost:8080/engine-rest/process-definition/GenUTs:4:fe3819d8-aaa4-11eb-9c96-7603ee83ccb9/statistics?incidents=true
       (including the ones used by Cockpit)

      Then: 
      The @class field is exposed:

       [
      
      { "@class":"org.camunda.bpm.engine.rest.dto.repository.ActivityStatisticsResultDto", "id":"Activity_0lha8wn", "instances":1, "failedJobs":0, "incidents":[] }
      
      ]
      

      Expected:
      The @class field isn't exposed.

        This is the controller panel for Smart Panels app

            [CAM-13581] @class is being shown on process definition statistics api endpoint

            occurs in regular rest endpoints and in cockpit web apps endpoints

            Stephen Russett added a comment - occurs in regular rest endpoints and in cockpit web apps endpoints

            Hi StephenOTT,

            Thank you for reporting this.

            The @class field is generated by the Jackson @JsonTypeInfo annotation (in the parent StatisticsResultDto). It is used to extract type information for JSON serialization and deserialization, to preserve information about the actual class of the Jackson object.

            As the ActivityStatisticsResultDto is only provided in responses, the @class field is not necessary.

            Furthermore, this field shouldn't be visible, as the default behavior is to exclude it from the response.

            I will forward this ticket for scheduling.

            Best,
            Nikola

            Nikola Koevski added a comment - Hi StephenOTT , Thank you for reporting this. The @class field is generated by the Jackson @JsonTypeInfo annotation (in the parent StatisticsResultDto ). It is used to extract type information for JSON serialization and deserialization, to preserve information about the actual class of the Jackson object. As the ActivityStatisticsResultDto is only provided in responses, the @class field is not necessary. Furthermore, this field shouldn't be visible, as the default behavior is to exclude it from the response. I will forward this ticket for scheduling. Best, Nikola

            Steps to reproduce this issue:

            1. Deploy and start an instance of the testProcess.bpmn.
            2. The job related to the Script Task will produce an incident.
            3. Call https://localhost:8080/engine-rest/process-definition/GenUTs:4:fe3819d8-aaa4-11eb-9c96-7603ee83ccb9/statistics?incidents=true in your browser or Postman.
            4. You will see a @class field in the JSON Response.

            Nikola Koevski added a comment - Steps to reproduce this issue: Deploy and start an instance of the  testProcess.bpmn . The job related to the Script Task will produce an incident. Call https://localhost:8080/engine-rest/process-definition/GenUTs:4:fe3819d8-aaa4-11eb-9c96-7603ee83ccb9/statistics?incidents=true in your browser or Postman. You will see a @class field in the JSON Response.

            Hi StephenOTT,

            thanks for making us aware of this issue. We consider this a valid bug.

            However, we do not see any unexpected behavior triggered by this other than unnecessary information being exposed in the result. We therefore consider this issue to have a low priority and will not put it on the roadmap as of now.

            Feel free to disagree with us on that and let us know if you have a different opinion.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hi StephenOTT , thanks for making us aware of this issue. We consider this a valid bug. However, we do not see any unexpected behavior triggered by this other than unnecessary information being exposed in the result. We therefore consider this issue to have a low priority and will not put it on the roadmap as of now. Feel free to disagree with us on that and let us know if you have a different opinion. Best, Tobias

            We are closing this ticket as part of our backlog grooming. Reasons:

            • We did not receive sufficient evidence that this ticket is important

            Thorben Lindhauer added a comment - We are closing this ticket as part of our backlog grooming. Reasons: We did not receive sufficient evidence that this ticket is important

              Unassigned Unassigned
              StephenOTT Stephen Russett
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: