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

Improve Expression Language pluggability

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 7.18.0, 7.18.0-alpha2
    • None
    • engine
    • None

      User Story (Required on creation):

      I want to use an alternative default Expression Language than JUEL, e.g. Spring Expression Language (SpEL). Since the ExpressionManager used in the engine configuration is not an interface, I have to subclass it and overwrite JUEL-specific code. This is an inconvenient API experience. Furthermore, the ExpressionManager is an internal API and might change at any point without further notice.

      Functional Requirements (Required before implementation):

      Have the process engine configuration rely on an interface, using a default implementation that uses JUEL.

      Technical Requirements (Required before implementation):

      • Turn the ExpressionManager into an interface
      • Turn the current implementation into a concrete implementation of that interface using JUEL
      • Allow setting a different expression manager in the engine configuration
      • Take care of providing an ElProvider in the DMN engine configuration from the process engine configuration. This can be based on the Expression Manager and derived from it by default, but could also be a new configuration option.

      Limitations of Scope (Optional):

      Hints (optional):

        This is the controller panel for Smart Panels app

            [CAM-14530] Improve Expression Language pluggability

            Jan Cheng created issue -
            Tobias Metzke-Bernstein made changes -
            Assignee New: Tobias Metzke-Bernstein [ tobias.metzke ]
            Tobias Metzke-Bernstein made changes -
            Link New: This issue is related to CAMTEAM-233 [ CAMTEAM-233 ]

            Tobias Metzke-Bernstein added a comment -

            Hey jan,

            thanks for creating this proposal. We'll look into it as soon as possible and get back with proper feedback.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hey jan , thanks for creating this proposal. We'll look into it as soon as possible and get back with proper feedback. Best, Tobias

            Tobias Metzke-Bernstein added a comment -

            Hi jan,

            thanks again for creating this.

            Let me know if the following is correct:
            You would like to replace the current ExpressionManager with a custom solution that uses a different EL than JUEL.
            However, we currently rely on a concrete class for the expression manager in the process engine configuration instead of relying on an interface.
            This makes it more inconvenient to replace the current expression manager with a custom implementation.

            If that is the case, I think your proposal makes sense in the scope of the product in general.
            It would make users more independent from the default choice of JUEL as the general EL.
            I will forward your proposal to product management to consider this in our roadmap planning.
            Be aware that this does not yet mean that we will work on this in the near future.

            If you would like to speed up the process and provide a code contribution, feel free to create an appropriate Pull Request in our GitHub repository. If you intend to go this way, please also make sure your changes are covered with tests.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hi jan , thanks again for creating this. Let me know if the following is correct: You would like to replace the current ExpressionManager with a custom solution that uses a different EL than JUEL. However, we currently rely on a concrete class for the expression manager in the process engine configuration instead of relying on an interface. This makes it more inconvenient to replace the current expression manager with a custom implementation. If that is the case, I think your proposal makes sense in the scope of the product in general. It would make users more independent from the default choice of JUEL as the general EL. I will forward your proposal to product management to consider this in our roadmap planning. Be aware that this does not yet mean that we will work on this in the near future. If you would like to speed up the process and provide a code contribution, feel free to create an appropriate Pull Request in our GitHub repository . If you intend to go this way, please also make sure your changes are covered with tests. Best, Tobias
            Tobias Metzke-Bernstein made changes -
            Summary Original: ExpressionManager should be interface to make it easy to implement a alternative el like spel. New: Turn ExpressionManager into an interface
            Tobias Metzke-Bernstein made changes -
            Labels Original: expression
            Tobias Metzke-Bernstein made changes -
            Description Original: h3. User Story (Required on creation):

            I want implement a alternative el instead of juel, e.g. spring expression language. It's wired to extends ExpressionManager, because it contains juel specified implement.
            h3. Functional Requirements (Required before implementation):
            h3. Technical Requirements (Required before implementation):
            h3. Limitations of Scope (Optional):
            h3. Hints (optional):             		New: h3. User Story (Required on creation):

            I want to use an alternative default Expression Language than JUEL, e.g. Spring Expression Language (SpEL). Since the ExpressionManager used in the engine configuration is not an interface, I have to subclass it and overwrite JUEL-specifc code. This is an inconvenient API experience. Furthermore, the ExpressionManager is internal API and might change at any point without further notice.

            h3. Functional Requirements (Required before implementation):

            Have the process engine configuration rely on an interface, using a default implementation that uses JUEL.

            h3. Technical Requirements (Required before implementation):

            * Turn the ExpressionManager into an interace
            * Turn the current implementation into a concrete implementation of that interface using JUEL
            * Allow setting a different expression manager in the engine configuration

            h3. Limitations of Scope (Optional):
            h3. Hints (optional):
            Tobias Metzke-Bernstein made changes -
            Assignee Original: Tobias Metzke-Bernstein [ tobias.metzke ]
            Tobias Metzke-Bernstein made changes -
            Status Original: Open [ 1 ] New: Ready [ 10005 ]

              Unassigned Unassigned
              jan Jan Cheng
              Tobias Metzke-Bernstein Tobias Metzke-Bernstein
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: