Support catalog-defined presets for Citrus test actions

Please describe the feature that you want to propose

Problem

Kaoto currently derives the inserted Citrus action exclusively from the
selected catalog entry name and group.

A custom catalog entry named company-login therefore produces:

- company-login: {}

This prevents custom Citrus catalogs from exposing reusable action presets
that should serialize to an existing standard Citrus action, for example:

- applyTemplate:
    name: company-login

Proposed solution

Allow ICitrusComponentDefinition to optionally provide a complete
defaultValue.

When present, Kaoto should deep-clone and insert this value instead of
generating an empty action from the catalog entry name.

When absent, the current behavior must remain unchanged.

Use case

A custom Citrus catalog generated by an external template registry can expose
one catalog tile per reusable test template while keeping the resulting test
compatible with standard Citrus YAML.

Acceptance criteria
A Citrus catalog entry may provide a complete initial action value.
Selecting that entry inserts the provided value.
The catalog value is deep-cloned before being added to the test.
Existing Citrus catalog entries behave exactly as before.
The resulting YAML may use standard actions such as applyTemplate.
Unit tests cover preset insertion, cloning, and fallback behavior.

@mirchello

Hi @mirchello, thanks for raising this issue. Could you please provide a bit more context about what's the desired outcome? It's not clear whether the defaults needs to be added in the catalog itself or as part of the existing default mechanism we have for Camel EIPs.

Hi @christophd, could you please provide more context into this functionality?

@lordrip

Hi @lordrip, thanks for the question.

The desired outcome is for the initial value to be provided by the Citrus catalog entry itself, rather than adding another hard-coded case to the Camel EIP default logic.

For example, an external Citrus catalog could contain an entry such as:

{
  "kind": "testAction",
  "name": "company-login",
  "defaultValue": {
    "applyTemplate": {
      "name": "company-login",
      "parameters": [
        {
          "name": "username",
          "value": "${username}"
        }
      ]
    }
  }
}

When the company-login tile is selected, Kaoto should insert:

- applyTemplate:
    name: company-login
    parameters:
      - name: username
        value: ${username}

rather than deriving the action name from the catalog entry and producing:

- company-login: {}

This needs to be catalog-defined because these entries may come from an external/custom catalog, and Kaoto cannot know their presets ahead of time. The existing Citrus default mechanism would consume and deep-clone this value. If the catalog entry does not provide it, the current name/group-based fallback would remain unchanged. This proposal does not require changing the defaults for Camel EIPs.
I proposed exposing this as ICitrusComponentDefinition.defaultValue. If the preferred architecture is to
map the catalog value into an existing generic DefinedComponent.defaultValue or another shared default pipeline, I am happy to align with that. The important part for this use case is that the value originates in the catalog and does not require a hard-coded Kaoto change for every custom entry.

@lordrip

In general I think this is a valid use case. It covers the area of custom test actions as well as custom action templates. Both of them have not been a focus of our work so far when introducing the first version of the Citrus integration in Kaoto.

@lordrip for your understanding: action templates in Citrus are similar to Kamelets where users may define a set of test actions into a named template with defined input parameters. The action template can be applied as part of a test with the applyTemplate test action as seen in the code examples in this issue.

The idea to have a custom Citrus catalog with custom templates is good IMO. I would prefer to introduce a new kind "testActionTemplate" though instead of using the default value as a kind of highjack. With the new catalog component kind "testActionTemplate" we can load the available templates and their defined parameters in Kaoto and render a proper applyTemplate test action.

WDYT?

@christophd

Thanks for the clarification @christophd, yes, I think that makes sense. @mirchello, do you agree with this approach? I believe this is not too far from your implementation, and also have the side benefit of giving you an individual catalog to update easily.

@mirchello when you have the time, could you please confirm if this aligns with your intention?

@christophd

Thanks @christophd and @lordrip, yes, this approach aligns with my intention.

The main requirement is to expose reusable Citrus templates from an external catalog, including their input parameters, and insert a standard applyTemplate action when a user selects a template. A dedicated testActionTemplate kind makes sense for this.

My defaultValue proposal was a way to support that workflow; the field itself is not a requirement. As long as templates and their parameters can be defined in the catalog without requiring a Kaoto code change for each template, this covers my use case.

I’m happy to adapt the implementation accordingly. Do you already have a preferred catalog schema for testActionTemplate, particularly for parameter definitions, or should I propose one in the PR?

@mirchello

Hi @mirchello, I'm glad the intention is aligned. If you don't mind, I think it would be more flexible and perhaps even easier to add a new catalog entry testActionTemplate.

The advantage I see doing it this way, is that we would be effectively opening the possibility to add additional entries without necessaringly adding them directly to Kaoto if those templates are private.

We would need to settle a few things before deciding what route to take. Generally speaking, we use the camel-catalog repository to build the catalogs with specific camel and citrus versions, but as you can see, this section is pretty static in terms of limiting to existing library versions.

In this case, I believe we shouldn't go 1:1 on that path because that would mean the templates needs to exist at the moment of the catalog generation in the main repository or for you to fork it and adapt it, the downside is that you need to kkeep the fork up to date because the catalog definitions change from time to time as we need for Kaoto.

I have a couple of alternatives, we could choose between generation-time vs design-time.

Generation time

We could write an additional generator for Citrus, next to the CitrusCatalogGenerator.class that will read a citrus-templates folder specified by a new CLI flag and bring all those templates to the catalog. From this point, everything else works as usual in Kaoto.

Pros: It's a one-time thing, if the templates don't change, we just need to do this once. This could perfectly live in the repository because by default we don't necessarily need to add citrus templates ourselves (Kaoto)
Cons: You need to generate the catalog at least once.

Design time

We recently addded functionality in Kaoto to read catalog entries dynamically at design time, and the first consumer of this feature was the Kamelets catalog, where we point a folder in VS Code's settings and then we include those additional Kamelets into the catalog. Depending on whether your templates are repository-based or global-based, this might be interesting, having a folder with some templates.

Pros: You don't deal with forks or generating the catalog yourself, just point to a folder and the templates should appear directly, and more importantly, changing, adding, removing templates won't need generating a new catalog. At some point, we could think even about fetching these templates from a GitHub repository, similar to how we load the catalogs today for the web version.

Cons: It's a bit more work, but if you're interested, we can certainly guide you through the process, so it shouldn't be complicated.

This is how we read kamelet files in VS Code Kaoto

This is how we ask for those kamelets from Kaoto

I hope this give you more clarity about the topic 💪, please take a look and if you're still interested, we can certainly guide you through the process.

Once again, thanks for your interest @mirchello

@lordrip

Thanks @lordrip and @christophd. I’ve opened #3936 implementing the design-time approach with a dedicated testActionTemplate kind.

This fits workflow: templates are edited alongside tests, so additions, updates and deletions need to be reflected without regenerating the catalog.

The implementation reuses the host resource callback already used for Kamelets. The host supplies native Citrus template YAML; selecting a template inserts a standard applyTemplate action with its declared parameters. No changes to camel-catalog are required.

I’ve also included a Storybook example using the actual designer to demonstrate discovery, insertion, parameter editing and reopening the generated YAML. The PR provides the Kaoto-side support; host-specific integration, such as a VS Code folder reader, remains a separate step.

I’d appreciate your feedback on the template resource format and the host integration point.

Navigation Menu

Repository navigation

Support catalog-defined presets for Citrus test actions #3767

Please describe the feature that you want to propose

Problem

Generation time

Design time

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support catalog-defined presets for Citrus test actions #3767

Description

Please describe the feature that you want to propose

Problem

Activity

lordrip commented on Aug 26, 2026

mirchello commented on Aug 27, 2026

christophd commented on Sep 7, 2026

lordrip commented on Sep 8, 2026

mirchello commented on Sep 14, 2026

lordrip commented on Sep 15, 2026

Generation time

Design time

mirchello commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions