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

Cmmn model API returns internal classes

    • Icon: Bug Report Bug Report
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 7.4.0, 7.4.0-alpha3
    • None
    • cmmn model api
    • None

      The public api returns in same cases internal classes, for example (ConditionExpression is part of the internal api):
      https://github.com/camunda/camunda-cmmn-model/blob/master/src/main/java/org/camunda/bpm/model/cmmn/instance/RepetitionRule.java#L31

      AT:

      • the public api does not return internal classes

      Please note: This is a breaking change!

        This is the controller panel for Smart Panels app

            [CAM-4932] Cmmn model API returns internal classes

            Roman Smirnov added a comment - See commits: https://github.com/camunda/camunda-cmmn-model/commit/600edb6d8a1a1a16fc3940d5e5eb21a0980b1ce4 https://github.com/camunda/camunda-bpm-platform/commit/9c06bf963f64d06d0aeeb5bf3024115a1cb19a85

            Sebastian Menski added a comment - roman.smirnov is this related to https://app.camunda.com/jira/browse/CAM-2269?

            Yes.

            Roman Smirnov added a comment - Yes.

            Hi roman.smirnov,

            is https://github.com/camunda/camunda-cmmn-model/blob/master/src/main/java/org/camunda/bpm/model/cmmn/impl/instance/CaseFileItemTransitionStandardEvent.java
            intentionally still an impl class without interface? It isn't actually exposed by the API but maybe it would be got to be consistent on this?

            Cheers,
            Sebastian

            Sebastian Menski added a comment - Hi roman.smirnov , is https://github.com/camunda/camunda-cmmn-model/blob/master/src/main/java/org/camunda/bpm/model/cmmn/impl/instance/CaseFileItemTransitionStandardEvent.java intentionally still an impl class without interface? It isn't actually exposed by the API but maybe it would be got to be consistent on this? Cheers, Sebastian

            Hi sebastian.menski,

            Yes, it was my intention to keep the classes CaseFileItemTransitionStandardEvent and PlanItemTransitionStandardEvent as impl classes without an interface.

            I agree with you that we should be consistent and expose them by the API. But I would suggest to bring both classes together, because if you have for example the following situation:

            <sentry>
              <planItemOnPart>
                <standardEvent>complete</standardEvent>
              </planItemOnPart>
              <caseFileItemOnPart>
                <standardEvent>update</standardEvent>
              </caseFileItemOnPart>
            </sentry>
            

            and if you execute the following line of code:

            Collection<CaseFileItemTransitionStandardEvent> events = modelInstance.getModelElementsByType(CaseFileItemTransitionStandardEvent.class);
            

            then you get both standard events independent from the fact that the first standard event is a PlanItemTransitionStandardEvent and the second is a CaseFileItemTransitionStandardEvent.

            So I would introduce a new interface named StandardEvent and a impl class StandardEventImpl, and the classes PlanItemTransitionStandardEvent and CaseFileItemTransitionStandardEvent will be deleted.

            What do you think? Feel free to reopen this issue, I will take care of it.

            Cheers,
            Roman

            Roman Smirnov added a comment - Hi sebastian.menski , Yes, it was my intention to keep the classes CaseFileItemTransitionStandardEvent and PlanItemTransitionStandardEvent as impl classes without an interface. I agree with you that we should be consistent and expose them by the API. But I would suggest to bring both classes together, because if you have for example the following situation: <sentry> <planItemOnPart> <standardEvent>complete</standardEvent> </planItemOnPart> <caseFileItemOnPart> <standardEvent>update</standardEvent> </caseFileItemOnPart> </sentry> and if you execute the following line of code: Collection<CaseFileItemTransitionStandardEvent> events = modelInstance.getModelElementsByType(CaseFileItemTransitionStandardEvent.class); then you get both standard events independent from the fact that the first standard event is a PlanItemTransitionStandardEvent and the second is a CaseFileItemTransitionStandardEvent . So I would introduce a new interface named StandardEvent and a impl class StandardEventImpl , and the classes PlanItemTransitionStandardEvent and CaseFileItemTransitionStandardEvent will be deleted. What do you think? Feel free to reopen this issue, I will take care of it. Cheers, Roman

              sebastian.menski Sebastian Menski
              roman.smirnov Roman Smirnov
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: