)]}'
{
  "log": [
    {
      "commit": "94ca50181230a837ffb3fba1b6dc0da2c292c068",
      "tree": "c5f39d2c90c049023754db2fcb64dae5c90344e0",
      "parents": [
        "be0857aab86c93fe0a03e86a43072350cc407c4c"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 18:17:11 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 18:17:11 2026 +0200"
      },
      "message": "CAMEL-25736: YAML examples for the data formats and languages that had none (#28023)\n\nSecond part of CAMEL-25736: camel_catalog_sample reads its samples from the\ndocumentation, which had no YAML route example for these data formats and\nlanguages.\n\n- YAML examples for 14 data formats on 12 pages (asn1, barcode, bindy, crypto,\n  fhirJson, fhirXml, flatpack, fory, jaxb, jsonApi, mimeMultipart, parquetAvro)\n  and for the js, openfeature and python languages, checked against the code\n  (the crypto key as a bean, unmarshalType on marshal for parquetAvro and fory,\n  the locale of bindy) and run with camel run.\n- The flatpack Java examples are fixed.\n- CatalogSamples puts the samples of the asked data format first, for the pages\n  that show several (univocity, bindy).\n- The catalog copies of the pages are updated.\n\nData formats with a sample of their own: 56 of 56 (42 before); languages: 28 of\n29 (all but file, on purpose).\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e"
    },
    {
      "commit": "be0857aab86c93fe0a03e86a43072350cc407c4c",
      "tree": "7e09f10919342f95477d4bc068b7bae10bec0829",
      "parents": [
        "1ad29093abba79ee9eca44b05c828a06ff471318"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 18:16:32 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 18:16:32 2026 +0200"
      },
      "message": "chore: camel-jbang - the AI tools see the beans in src/main/resources, catch a route id another file has, and say why a start failed (#28001)\n\nTwo fixes for the AI tools, found with the local-model benchmark, where the\nstep that adds a Java class and declares it as a bean failed in 8 of 10 runs.\n\n- Bean declarations also come from the YAML in src/main/resources, which camel\n  run --source-dir loads, so a reference to a bean declared there is no longer\n  refused, and a file with only beans (or another top-level entry of the YAML\n  DSL) is listed with the route files.\n- The validator refuses a route id that a route in another YAML or XML file of\n  the project has, and names that file. A failed camel_run or restart says its\n  cause first: the error camel run prints as it exits, else the first exception\n  logged at ERROR (the cause of the camel_run answer).\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e"
    },
    {
      "commit": "1ad29093abba79ee9eca44b05c828a06ff471318",
      "tree": "4afffbc472822d84877461a72079c915547134fa",
      "parents": [
        "9250de96834f9e3b53db4ce32bd0d21f5efbdf13"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 16:33:00 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 16:33:00 2026 +0200"
      },
      "message": "CAMEL-25720: camel-jbang - load the kamelet catalog and the Quarkus BOM versions once per JVM (#28005)\n\nEvery export built a new KameletsCatalog, which scans the whole classpath, and\nQuarkusHelper read every Quarkus platform BOM with XPath to find its Camel\nversion (the mapping it keeps on disk is not used for a snapshot, or a version\nthat does not match exactly). A released catalog or BOM does not change, so\nKameletCatalogHelper.loadKamelets and the managed versions of QuarkusHelper are\nnow kept for the JVM; a snapshot is read every time. camel shell, the TUI, the\nMCP server and the tests run several commands in one JVM. ExportTest runs in 44\nseconds instead of 95.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e"
    },
    {
      "commit": "9250de96834f9e3b53db4ce32bd0d21f5efbdf13",
      "tree": "b1d6fe32226b74420d6468cc35aa0bf6e18dfec6",
      "parents": [
        "99af30362c815036c93b7a850268b7c81c5f3066"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 16:32:27 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 16:32:27 2026 +0200"
      },
      "message": "CAMEL-25720: camel-jbang - run the tests of camel-jbang-core in parallel forks (#28004)\n\nThe tests ran one JVM per test class, one class at a time, as they shared the\nstatic home directory of the CLI and files in the working directory. They now\nrun in 4 reused forks. Each fork has a user.home of its own under target, and a\ntest gets a temporary home from useTestHomeDir() (or a given one from\nuseHomeDir(Path)) instead of a fixed target/... directory. The tests that use\nthe working directory (@UsesWorkingDirectory: run, export, dependency,\ntransform, init, a local camel-cli.properties) or a fixed port (@UsesFixedPort)\nrun after the others, one class at a time, in the serial-test execution.\n\nNoFixedHomeDirTest fails on a test that sets a fixed home, and AGENTS.md (and\nCLAUDE.md) of the module tell coding agents how the tests run.\n\nThe surefire time of the module goes from 399 to 153 seconds locally, and to 96\nwith #28005.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e"
    },
    {
      "commit": "99af30362c815036c93b7a850268b7c81c5f3066",
      "tree": "f444951c7389d2b41f8ddec568525a5f79743413",
      "parents": [
        "b5e6edf1cb30b4127a69c2c7144a951071a310f1"
      ],
      "author": {
        "name": "Serdar Gökay",
        "email": "serdar.gokay@etzel.com.tr",
        "time": "Sat Oct 17 17:31:52 2026 +0300"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 16:31:52 2026 +0200"
      },
      "message": "CAMEL-25671: camel-milo - report a node with an unknown namespace URI instead of failing the connection (#27906)\n\nA consumer node ID whose namespace URI (nsu\u003d) is not in the namespace\ntable of the server made lookupNamespace throw a NullPointerException.\nThe exception went to the reconnect path, so one wrong entry in a nodes\nlist took the whole client connection down, including the consumers of\nthe other nodes.\n\nThe consumer now treats such a node like a node that does not exist on\nthe server: one WARN with the node ID and one DataValue with\nBad_NodeIdUnknown for that node (visible with omitNullValues\u003dfalse); the\nother nodes and the connection keep working.\n\nThe badSubscriptions map and the 10 second resubscribe that served the\nold Bad_InvalidArgument branch are removed. That branch could not be\nreached, because lookupNamespace never returned null.\n\nProducers (write, call, read, browse) are not changed.\n\nCo-authored-by: Claude Fable 5.1 \u003cnoreply@anthropic.com\u003e\nCo-authored-by: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "b5e6edf1cb30b4127a69c2c7144a951071a310f1",
      "tree": "88894684de1aa7b11e3c5602625d2569cb3214a0",
      "parents": [
        "ccff8d83bf5191a4f2fa63d8ce12a6f5e7635945"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 16:31:08 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 16:31:08 2026 +0200"
      },
      "message": "CAMEL-25734: camel-core - the bean introspection can be used by another thread while Camel starts (#28003)\n\nDefaultBeanIntrospection kept the log lines of the calls made before the start\nin a plain ArrayList, which every thread that uses the bean introspection adds\nto, and afterPropertiesConfigured iterated it on the thread that starts Camel.\nThe camel-cli-connector, which AbstractCamelContext starts early, uses it at\nthe same time, so the start could fail with a ConcurrentModificationException:\nrarely, as the window is small, but in any Camel with camel-cli-connector, such\nas every camel run. The lines are now added and taken under a lock, and logged\nafter it.\n\nFound in the tests of camel-jbang-core once their JVMs were reused\n(CAMEL-25720).\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e"
    },
    {
      "commit": "ccff8d83bf5191a4f2fa63d8ce12a6f5e7635945",
      "tree": "1ed52365005473a609bbe655138373afba12a6fa",
      "parents": [
        "e33b8cd692927cc5ba986dc6392869e409e31137"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 19:17:44 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 15:47:44 2026 +0200"
      },
      "message": "CAMEL-25686: parent - import the ASM bom so that all ASM artifacts follow asm-version (#27925)\n\nparent/pom.xml managed only org.ow2.asm:asm. The other ASM artifacts\n(asm-commons, asm-tree, asm-util, asm-analysis) kept the version of the\nlibrary that brings them, while asm itself was moved to asm-version. Today\nthis mixes ASM versions in camel-web3j and the cassandra test infra\n(asm 9.10.1 with the others at 5.0.3, through jnr-ffi), camel-cassandraql\n(9.2, through jnr-ffi) and camel-drill (9.5, through drill-java-exec).\ncamel-wasm and camel-opa get 9.10.1 for all of them only because Endive\nimports the same ASM bom version; a later change of asm-version would\nsplit them as well.\n\nThe managed asm entry is replaced by an import of org.ow2.asm:asm-bom at\nasm-version, as the parent already does for the junit, netty and jackson\nboms. All ASM artifacts in the build now resolve to asm-version (9.10.1).\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "e33b8cd692927cc5ba986dc6392869e409e31137",
      "tree": "862c0b39199bc293470727d0a8dbad9a7788e414",
      "parents": [
        "bf3a7214405c6f5a7da5c1d7f911531aae70973b"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 19:17:35 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 15:47:35 2026 +0200"
      },
      "message": "CAMEL-25710: camel-mail - remove the idempotent keys of mails that a poll does not route (#27990)\n\nWith an idempotentRepository, the consumer adds the key of every mail when it\nretrieves the mails of a poll, and removes or confirms it when the exchange completes.\nMails that the poll then did not route kept their key, and were skipped as duplicates\nby every later poll, also of other consumers sharing the repository:\n- the rest of the batch when the consumer stops in the middle of it (a graceful route\n  or CamelContext stop, default ShutdownRunningTask.CompleteCurrentTaskOnly);\n- the mails retrieved before a mail whose exchange cannot be created (for example its\n  attachments cannot be read), which fails the poll, and that mail itself.\n\nprocessBatch now removes the keys of the exchanges it does not route and releases\nthem, as the aws2-s3 consumer does with its in-progress keys (CAMEL-25521), and\nretrieveMessages does the same when creating an exchange fails, before rethrowing.\n\nAs a consequence, with an idempotentRepository a mail whose exchange cannot be\ncreated now fails every poll until it is removed (with the default\nskipFailedMessage\u003dfalse and handleFailedMessage\u003dfalse), as it does without an\nidempotentRepository; before, it was skipped after the first failed poll. Upgrade\nguide note added.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "bf3a7214405c6f5a7da5c1d7f911531aae70973b",
      "tree": "05afb09624d62341560b600b8bd6689aabb05ae2",
      "parents": [
        "eb14b16f700600fe244755a5960a293398942773"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 11:44:46 2026 +0200"
      },
      "committer": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 15:42:36 2026 +0200"
      },
      "message": "chore: camel-jbang - an emoji such as a family or a flag is one character in the AI prompt, filters, captions and diagrams\n\nTamboUI 0.6.0 moves its text fields and the editor by grapheme cluster:\nall the code points of an emoji such as a family (three emoji joined by\nZWJs), a flag or a skin tone at once. The places that handle text on\ntheir own still went a code point at a time, so Backspace took a family\napart in five steps, and a cut could leave part of one on the screen.\n\nThey now go by the character as it is seen (TuiHelper.characterEnd,\ncharacterStart, characterOffset and characterWidth):\n- the AI prompt: Backspace, Delete, Left and Right; Up and Down keep the\n  column on the screen, as the source editor does; the cursor marks the\n  whole emoji under it; a long line scrolls by columns; the Ctrl+R\n  preview is cut between emoji and leaves room for the two spaces in\n  front of it, so its ellipsis is no longer cut off\n- the list filters, the inline caption and the caret of text fields\n- Left and Right in the completion popup of the source editor, in step\n  with the editor\n- captions are typed an emoji at a time, and the drawing tools put an\n  emoji in one cell\n- the link markers and labels of the route diagram, the log and history\n  views scrolled sideways, and the hanging wrap of the detail views\n\nA line break or an escape stays a character of its own, also after a\nZWJ, which TamboUI otherwise joins to whatever follows it.\n\nCo-Authored-By: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e\n"
    },
    {
      "commit": "eb14b16f700600fe244755a5960a293398942773",
      "tree": "cba77de2fca67cdaa533a698dbe37615da7fd70d",
      "parents": [
        "68f43491f3cdce96318261f3da0579a3bd21bb5d"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 15:30:01 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 15:30:01 2026 +0200"
      },
      "message": "CAMEL-25645: camel-milo - ServerCertificateValidationTest writes the value before the consumers start (#27999)\n\nSince CAMEL-25626 a consumer also delivers a null value with a Bad status, so\na client that connected before the test wrote Foo received the initial Bad\nvalue of the item as well, and mock:trustAll got 2 messages. The two changes\nwere merged on main 26 seconds apart and neither PR build ran with the other.\n\nThe consumer routes now start after the value is written, as MonitorItemTest\ndoes since CAMEL-25626, so Foo is the first notification of each client.\n\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "68f43491f3cdce96318261f3da0579a3bd21bb5d",
      "tree": "e9f87bbec18ddf72dedfc8fa3e3b15a8f68b483a",
      "parents": [
        "138d8c645eb8af8cca4eb45f19e36098747e7592"
      ],
      "author": {
        "name": "Federico Mariani",
        "email": "34543311+Croway@users.noreply.github.com",
        "time": "Sat Oct 17 15:00:53 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 15:00:53 2026 +0200"
      },
      "message": "CAMEL-25642: camel-jbang-mcp - runtime tools wiring: receive in one call, routeId honoured, prompts name real tools (#27958)\n\n* CAMEL-25642: camel-jbang-mcp - runtime tools send the routeId as the filter the route-dump and route-structure actions read\n\nThe registry put the route pattern under \"id\" while the CLI connector reads \"filter\" (as camel cmd route-dump\nsends it), so get_route_dump, get_route_structure and get_route_analysis always returned every route.\nget_route_structure also takes brief, write_heap_dump refuses a name with a directory, and send_message is\ndestructive as in the MCP server.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n\n* CAMEL-25642: camel-jbang-mcp - the diagnose and optimize prompts name the MCP runtime tools\n\ncamel_diagnose_route and camel_optimize_route told the model to call the registry names (get_context,\nget_top_processors, ...), which the MCP server does not list. A test checks that every tool a prompt names\nis one the server lists, with the @Tool scan shared with McpSecuredToolClassesTest.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n\n* CAMEL-25642: camel-jbang-mcp - camel_runtime_receive receives one message, and the runtime tools report failures\n\n* camel_runtime_receive started a consumer that kept running and returned no message: it now enables the\n  receive console for the endpoint, waits for a message in the receive file the CLI connector writes,\n  returns it and disables the console, and is marked destructive.\n* A process that does not answer in time is an error of every runtime tool; camel_runtime_ai_trace no longer\n  turns a failed query into \"No AI components detected\", and its nameOrPid is optional.\n* camel_runtime_memory_leak starts one recording by default and returns at once (dual blocked ~90 s); dual is\n  opt-in, compare is a command, and a bad duration or mode is refused.\n* camel_runtime_http_request passes timeoutSeconds, camel_runtime_route_structure brief,\n  camel_runtime_trace_dump reads the traces for read-only clients, heap_dump goes through the registry\u0027s name\n  check, and the history description says when the history is recorded.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n\n* CAMEL-25642: camel-jbang-mcp - camel cmd receive naming, camel.trace.standby hint, bounded camel_runtime_receive, and review nits\n\n- Name the command camel cmd receive (not camel receive) in the receive error, RuntimeService comments, the MCP page\n  and the upgrade guide.\n- The message-history hint names camel.trace.standby (the BacklogTracer, as the dev profile sets it), not\n  camel.main.tracing-standby (the log Tracer).\n- camel_runtime_receive takes limit (default 1, at least 1): it returns the first limit messages of the poll and\n  counts the others (notReturned), which were taken from the endpoint all the same.\n- If the receive console cannot be stopped, return the messages with a warning naming\n  camel cmd receive --action\u003dstop (or add it to the error) instead of losing the answer.\n- Read the receive file from the offset with a SeekableByteChannel instead of reading the whole file each poll.\n- Remove the timeout-text check (failOnTimeout, RuntimeHelper.TIMEOUT_PREFIX) and its test: ToolContext.executeAction\n  throws on timeout since CAMEL-25398, so no registry tool returns that text; drop the upgrade-guide bullet that\n  claimed it as a change of this branch.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n\n* CAMEL-25642: camel-jbang-mcp - camel_runtime_receive reports the messages its own consumer took\n\n- The console numbers every message it takes (uid) and the status reports the count (total): the call reads the\n  count before enabling the console and keeps only the messages above it, so the leftovers of an earlier session\n  are not returned as its own.\n- After the stop, the call waits (3 seconds at most) until the status shows the console disabled: the count then\n  says how many messages this call took, including the ones the connector dumps only after the stop, which are\n  returned too (up to limit) and otherwise counted as notReturned. The answer says when the process did not\n  confirm the stop or had not written every message it took.\n- One camel_runtime_receive call at a time per process: a second call waits up to its own timeout, then fails\n  with a message naming the first call, instead of reading its messages and stopping its consumer.\n- The messages of exceptions without a message are their names, not \"null\".\n\nCo-Authored-By: Claude Fable 5.1 \u003cnoreply@anthropic.com\u003e\n\n---------\n\nCo-authored-by: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "138d8c645eb8af8cca4eb45f19e36098747e7592",
      "tree": "1090c453f945848e73fe11d551129d90137bb82f",
      "parents": [
        "e0855013fbdbfc3e7e811bf0b82415d8459d67a8"
      ],
      "author": {
        "name": "Federico Mariani",
        "email": "34543311+Croway@users.noreply.github.com",
        "time": "Sat Oct 17 14:59:09 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 14:59:09 2026 +0200"
      },
      "message": "CAMEL-25642: camel-jbang-mcp - camel_openapi_scaffold follows the rules of camel-rest-openapi (#27960)\n\n* CAMEL-25642: camel-jbang-mcp - camel_openapi_scaffold follows the rules of camel-rest-openapi\n\n- The id of an operation without operationId comes from the new\n  RestOpenApiHelper.generateOperationId, which DefaultRestOpenapiProcessorStrategy\n  now uses too (GENOPID_GET.pets._petId_, not GENOPID_GET_pets_petId).\n- With missingOperation\u003dmock the scaffold explains the mode and lists one\n  camel-mock/ file per path, named after the request path (no method suffix,\n  path parameters matched by value), with what Camel answers without the file.\n  camel_openapi_mock_guidance, whose walk duplicated the scaffold\u0027s, is removed.\n- camel_openapi_validate reports every security scheme as not enforced, and\n  OpenAPI 3.1 as information (swagger-parser parses it, the component serves\n  its paths like 3.0).\n- Test binding the scaffolded petstore routes and mock file with the real\n  rest-openapi component.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n\n* CAMEL-25642: the upgrade guide shows the path parameter literally, not as an AsciiDoc attribute\n\nCo-Authored-By: Claude Fable 5.1 \u003cnoreply@anthropic.com\u003e\n\n* CAMEL-25642: camel-jbang-mcp - a visible mock file name for the root path, null-safe scheme text, and a unit test of the generated operation id\n\nCo-Authored-By: Claude Fable 5.1 \u003cnoreply@anthropic.com\u003e\n\n* CAMEL-25642: camel-jbang-mcp - mock file names carry a sample path parameter value, HTTP 204 for an operation without a \u0027200\u0027 response, and media type wording\n\n- the mock file of a path with parameters is named with the sample value 1\n  (camel-mock/pets/1.json for /pets/{petId}), as camel-rest-openapi matches the\n  request path; requestPath keeps the template\n- an operation without a \u0027200\u0027 response is listed as answering HTTP 204 with an\n  empty body (CAMEL-25663 fixed the error the text described)\n- the note and the mock mode explanation say the \u0027200\u0027 example is taken for the\n  media type of the request\u0027s Content-Type or Accept header (Accept */* takes\n  application/json, then application/xml), otherwise HTTP 204\n- MockFileInfo javadoc, the camel-jbang-mcp doc page and the tests follow\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n\n* CAMEL-25642: camel-jbang-mcp - shorter per-path mock note, firstExample javadoc, and the example of the media type that names the file\n\n- The per-method note of a mock file points to modeExplanation instead of repeating its media type sentence\n- firstExample javadoc: the example is a preview of the file content; at runtime camel-rest-openapi takes the\n  example of the media type matching the request\u0027s Content-Type or Accept header\n- The example comes from the media type that gives the file extension when it has one, otherwise from the first\n  media type with an example, whose type then gives the extension, so content and extension agree\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n\n---------\n\nCo-authored-by: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "e0855013fbdbfc3e7e811bf0b82415d8459d67a8",
      "tree": "cc0d14a2887d43388c0399e5395ea8ac1bf4f3ea",
      "parents": [
        "0c1d6b11798c7126d75f2be515d7a05165e41915"
      ],
      "author": {
        "name": "Federico Mariani",
        "email": "34543311+Croway@users.noreply.github.com",
        "time": "Sat Oct 17 12:36:28 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 12:36:28 2026 +0200"
      },
      "message": "CAMEL-25642: camel-jbang-mcp - migration and dependency tools answer with the right data (#27959)\n\ncamel_migration_recipes: the Spring Boot command activates\nCamelSpringBootMigrationRecipe (the recipe camel-spring-boot-upgrade-recipes\nships), the recipes artifact is the \u003cmajor\u003e.\u003cminor\u003e.0 release of the target,\nthe rewrite-maven-plugin is not pinned (as in the recipes README), and the\nQuarkus command runs quarkus-maven-plugin at a Quarkus platform version\n(new quarkusPlatformVersion argument, else the latest) with -Drewrite\u003dtrue\nfor a full run instead of the unknown -DrewriteFullRun.\n\ncamel_migration_compatibility: the Java requirement comes from the JDK\nversions of the release in the catalog instead of \"4.19+ requires Java 21\";\nthe unused camelComponents argument is removed.\n\ncamel_dependency_check / camel_dependency_security_audit /\ncamel_migration_analyze: Spring Boot starters and Camel Quarkus extensions\ncount as their component (mapping shared with DependencyLookup), components\nonly in dependencyManagement or plugin dependencies are not declared, the\ncamel-quarkus-bom version is not taken as the Camel version nor recommended\nwith it, the version is compared with the latest release instead of the\nSNAPSHOT catalog version, and the audit says when the Camel version is not\ndetected, reports advisories without components as uncheckedAdvisories (not\nclean), and leaves reachable unset without routes.\n\nRuntime detection: a WAR is WildFly only without Spring Boot or Quarkus, and\nthe war, bundle and WildFly plugins are read from \u003cplugin\u003e elements.\n\ncamel_properties_translate: the Spring Boot only options keep their Spring\nBoot key (camel.springboot.lenient-configuration-binding) and have no\nequivalent on the other runtimes; camel.server.* is camel-main.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "0c1d6b11798c7126d75f2be515d7a05165e41915",
      "tree": "25b0ad6e1f6a2270f7e7a2d3a0f3b632d6e34119",
      "parents": [
        "3af2c90d63ad4e3a8f80e00beaafd700a6272fc3"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 16:06:18 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 12:36:18 2026 +0200"
      },
      "message": "CAMEL-25680: camel-docker - events consumer closes its stream on stop and subscribes again when it ends (#27919)\n\ndocker-java reads an events or stats stream on its own thread and the stream belongs to the callback given to\nexec(). The events and stats consumers closed only the command on stop, and AbstrDockerCmd.close() does nothing\n(docker-java 3.7.1), so the stream stayed open and its callback kept routing what it received: a route that was\nstopped and started again received every event once more for each restart, and each stop left a connection open.\n\nThe events consumer had no onError / onComplete either: when the stream failed or ended (Docker daemon restarted,\nconnection lost) it stayed started without receiving any event, with one ERROR logged by docker-java for a failure and\nnothing for a clean end.\n\nNow both consumers close the stream of their callback on stop (also when the stream only opens after the stop), and a\nclosed callback routes nothing. The events consumer subscribes again when its stream fails or ends: after 1 second,\nthen with a delay that doubles up to 30 seconds while subscribing fails (as the kubernetes consumers watch again). The\nnew stream starts with the events from then on; the events of the time without a stream are not received.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "3af2c90d63ad4e3a8f80e00beaafd700a6272fc3",
      "tree": "c53facd3ded826ddd10780f7bebdbd6b04d7157f",
      "parents": [
        "d09593b4a5847fb24ee47fa0b12dace2890e3762"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 16:06:09 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 12:36:09 2026 +0200"
      },
      "message": "CAMEL-25679: camel-mongodb - keep the consumer thread when a new cursor cannot be opened (#27918)\n\nThe tailable and change streams consumers read from a cursor on one thread. When reading fails (for example the\nconnection to the server is lost) the thread closes the cursor, waits cursorRegenerationDelay and opens a new one.\nOpening it was done outside the try of the loop: while the server is still unreachable the driver gives up after its\nserver selection timeout (30 seconds by default) with a MongoTimeoutException, which ended the thread. The route stayed\nstarted and consumed nothing until it was restarted; the only trace was the uncaught exception on stderr.\n\nThe new cursor is now opened at the start of the next iteration, inside the try: a failure is logged like a failed\nread (\"Will try again on next poll\") and tried again after the delay. A cursor opened while the consumer is being\nstopped is closed instead of read, as stop() could not close it. The cursor field is volatile, as stop() reads it from\nanother thread.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "d09593b4a5847fb24ee47fa0b12dace2890e3762",
      "tree": "0d040a4de72cce55561d62fd0585af153024dd48",
      "parents": [
        "cccaf03679ec4d458e298ebae414c87e2ace5cf1"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 16:06:00 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 12:36:00 2026 +0200"
      },
      "message": "CAMEL-25700: camel-aws2-sqs - extend the visibility of every message of the batch, not only from its turn (#27985)\n\nWith extendMessageVisibility\u003dtrue and maxMessagesPerPoll greater than one, processBatch registered a\nmessage with the TimeoutExtender only when its turn came. The visibility timeout of all messages of a\npoll starts at the receive, so the messages that waited behind slow ones were not extended at all and\nbecame visible again: SQS delivered them a second time (the scenario of CAMEL-10587).\n\nprocessBatch now registers every message of the batch with the extender before it routes the first\none, and removes the messages that it does not route (the consumer is stopping or suspending, or the\nprocessor threw) so that they become visible again as before. The extender\u0027s rule of extending an\nentry only when its deadline is near is unchanged.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "cccaf03679ec4d458e298ebae414c87e2ace5cf1",
      "tree": "0506f6b4cb9b6317b1aa733b317778b2d3ac42ea",
      "parents": [
        "d201af225932ea6e8c7c8e71fc9516f3eb27ec9b"
      ],
      "author": {
        "name": "dependabot[bot]",
        "email": "49699333+dependabot[bot]@users.noreply.github.com",
        "time": "Sat Oct 17 11:13:49 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:13:49 2026 +0200"
      },
      "message": "chore(deps): Bump org.apache.maven.reporting:maven-reporting-api from 3.1.1 to 4.0.0 (#27893)\n\nBumps [org.apache.maven.reporting:maven-reporting-api](https://github.com/apache/maven-reporting-api) from 3.1.1 to 4.0.0.\n- [Release notes](https://github.com/apache/maven-reporting-api/releases)\n- [Commits](https://github.com/apache/maven-reporting-api/compare/maven-reporting-api-3.1.1...maven-reporting-api-4.0.0)\n\n---\nupdated-dependencies:\n- dependency-name: org.apache.maven.reporting:maven-reporting-api\n  dependency-version: 4.0.0\n  dependency-type: direct:production\n  update-type: version-update:semver-major\n..."
    },
    {
      "commit": "d201af225932ea6e8c7c8e71fc9516f3eb27ec9b",
      "tree": "1f05395d49ef7066b5a78bcd20f21649cb274d98",
      "parents": [
        "278254ec258e6b3cd5cdaa38725242ed92ef3b12"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 14:43:42 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:13:42 2026 +0200"
      },
      "message": "CAMEL-25698: camel-jta - roll back the transaction of an exchange marked rollback only last (#27983)\n\nThe JTA TransactionErrorHandler rolled the transaction back only when the\nexchange had an exception or was marked rollback only. markRollbackOnlyLast()\nsets only the rollback only last flag, so the transaction was committed, and\nthe flag and exception were then cleared, so nothing showed that the rollback\nwas skipped.\n\nRoll back when the exchange is marked rollback only last too, as the\ncamel-spring TransactionErrorHandler does since CAMEL-17105. The flag is still\ncleared after the transaction, so an outer transacted() block does not see it.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "278254ec258e6b3cd5cdaa38725242ed92ef3b12",
      "tree": "c5f453bca68bb3c65be9d49c2d91c5ec158935b5",
      "parents": [
        "4f879148b118a131e3aa72467f26b02b6db532b9"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 14:43:34 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:13:34 2026 +0200"
      },
      "message": "CAMEL-25699: camel-protobuf - Keep the content of bytes fields when converting a message to and from a Map (#27984)\n\nProtobufConverter turned a bytes field into ByteString.toString() when a\nmessage was converted to a Map. That is a description for logging (identity\nhash, size and a shortened, escaped preview), not the value, so the content\nof every bytes field was lost without an error. In the other direction a\nbyte[] for a bytes field was passed to Builder.setField unchanged and\nrejected by protobuf.\n\nA bytes field now becomes a byte[] in the Map, and a byte[] in a Map is\nwrapped with ByteString.copyFrom when the Map is converted to a message.\nEnum fields are unchanged. The 4.24 upgrade guide notes the new value type.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "4f879148b118a131e3aa72467f26b02b6db532b9",
      "tree": "fdd4c124ee779509f541fca2eddd94d097b3a1dc",
      "parents": [
        "55d4f9e20a413f7e78130f0cc0e6439277217c79"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 14:43:25 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:13:25 2026 +0200"
      },
      "message": "CAMEL-25701: camel-azure-servicebus - renew a message lock before the run that would come too late (#27986)\n\nThe Camel lock renewer (CAMEL-23937) runs every 10 or 11 seconds (a 10000 ms period on the 1-second\ntimer of the period task scheduler) and renewed a lock only when it expired within 10 seconds. A lock\nthat expired between 10 and 11 seconds after a run was left alone by that run and reached by the next\none only after it had expired, or too close to the expiry for the renewal call: the lock was lost and\nService Bus delivered the message again while the first exchange was still being processed.\n\nThe renewer now renews a lock that expires within two intervals, so every lock is renewed by a run that\ncomes at least about 9 seconds before it expires.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "55d4f9e20a413f7e78130f0cc0e6439277217c79",
      "tree": "0b9e5cfcd863cadafc573047fc8b4963c9b48a95",
      "parents": [
        "86e0ee42e3f538cf758ca5f65982be2ab183aec9"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 14:43:17 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:13:17 2026 +0200"
      },
      "message": "CAMEL-25702: camel-ibm-secrets-manager - skip an Event Streams record that cannot be read instead of ending the refresh task (#27987)\n\nIBMEventStreamReloadTriggerTask is scheduled once (PeriodTaskScheduler.scheduledTask) and runs for as\nlong as Camel runs. Nothing in its loop caught an exception, so the first record it could not read (a\nvalue that is not JSON, or JSON without data.event_type, secrets, secret_name or event_time) ended the\ntask. The exception went into a Future that nobody reads: nothing was logged, and no later secret\nrotation reloaded the CamelContext until the application was restarted.\n\nThe handling of one record moves unchanged into onRecord(), and run() calls it in a try per record: a\nrecord that cannot be processed is skipped with a WARN (stack trace at DEBUG) and the task goes on.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "86e0ee42e3f538cf758ca5f65982be2ab183aec9",
      "tree": "d1c471a2007eee059264bcd887fd983842ebe886",
      "parents": [
        "deadcabda3076a77728b70d8bc1aa6ef9f0dcbad"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 14:43:08 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:13:08 2026 +0200"
      },
      "message": "CAMEL-25703: camel-bindy - keep all decimals of a number field without precision when marshalling (#27988)\n\nSince CAMEL-24168 the default precision of @DataField and @KeyValuePairField\nis -1, so AbstractNumberFormat no longer sets the fraction digits of its\nDecimalFormat. The default pattern of DecimalFormat keeps at most three\nfraction digits, so a BigDecimal, Double or Float field without precision\nand pattern was marshalled rounded: 1.23456 became 1.235 and 0.000123\nbecame 0, and a record unmarshalled and marshalled again changed.\n\nWithout a precision the formatter now keeps all fraction digits. A finite\nFloat with a fraction part is formatted from Float.toString, so 1.1f is\nstill written as 1.1 and not as its widening to double; a whole-number\nFloat keeps its exact digits as before. Explicit precision, pattern and implied\ndecimal separator are unchanged. Upgrade note in the 4.24 guide.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "deadcabda3076a77728b70d8bc1aa6ef9f0dcbad",
      "tree": "1c20bdb862ac45550c1ee1cc5a497853604a252b",
      "parents": [
        "1a4077f0c46f2367aaca8a26aedc8dcb0480accd"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 14:42:59 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:12:59 2026 +0200"
      },
      "message": "CAMEL-25709: camel-core - Aggregate EIP: try the completion timeout of a group again when the repository fails (#27989)\n\nThe timeout map removes an expired entry before it calls the aggregator\u0027s\nlistener, and DefaultTimeoutMap.emitEvent ignores an exception of a listener\nwithout logging it. When the aggregation repository failed in get or remove\nwhile the timeout checker completed a group (only OptimisticLockingException\nwas handled), the group stayed in the repository and was never completed by\nits timeout, unless another message for the key arrived or the route was\nrestarted, and nothing was logged.\n\nAggregationTimeoutMap.onEviction now catches such an exception, logs a WARN\nand puts the key back into the timeout map (putIfAbsent, so an entry of a new\nmessage for the key is kept) to be tried again after the completion timeout\nchecker interval. A group that was already removed is not found by the next\ntry, which then does nothing.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "1a4077f0c46f2367aaca8a26aedc8dcb0480accd",
      "tree": "f50c80d30068f43f9ecb9747c90a1bf2f0ea92d4",
      "parents": [
        "f245636df70f57114750d30b1270bb9dc18f30af"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 14:42:51 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:12:51 2026 +0200"
      },
      "message": "CAMEL-25711: camel-mongodb-gridfs - keep polling after a poll fails (#27991)\n\nGridFsConsumer polls with a BackgroundTask without a duration limit. Only\nthe processing of the exchange was inside a try: an exception of the\nbucket query, the cursor, the file attribute claim, openDownloadStream\nor the persistent timestamp update (for example a MongoTimeoutException\nwhile MongoDB cannot be reached) left the task, so BackgroundTask marked\nit failed and the poll was never scheduled again. The consumer stayed\nstarted, routed nothing and logged nothing.\n\nThe task now calls poll(), which reports the failure through the\nconsumer\u0027s ExceptionHandler (the first of a run of failures; the next\nones at DEBUG, and an INFO line when polling works again) and returns\nfalse, so the next poll tries again after the delay. The persistent\ntimestamp is read by the first poll that reaches MongoDB instead of by\nrun(), so a failure there is retried as well instead of leaving the\nconsumer without any poll.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "f245636df70f57114750d30b1270bb9dc18f30af",
      "tree": "53f82e5e2b7e8cc69cf88917f9361881be8335fb",
      "parents": [
        "55ed20f14e902a400dc5048691f4f592481ffbbf"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 14:42:42 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 11:12:42 2026 +0200"
      },
      "message": "CAMEL-25712: camel-google-pubsub - keep pulling after a failed nack of a message at max delivery attempts (#27992)\n\nWith synchronousPull\u003dtrue and maxDeliveryAttempts in effect (set on the\nendpoint or read from the dead-letter policy of the subscription), a\nmessage that reached the limit is nacked without routing. The nack is a\nModifyAckDeadline call; AcknowledgeSync wraps its failure in a\nRuntimeCamelException that no catch of the pull loop handles, so the\nexception ended the consumer thread. The consumer stayed started and\nnever pulled again; only an ERROR \"Failure getting messages from PubSub\"\nwas logged.\n\nThe failure is now reported through the consumer\u0027s ExceptionHandler and\nthe loop goes on. The message is delivered again when its ack deadline\nexpires and is nacked then.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "55ed20f14e902a400dc5048691f4f592481ffbbf",
      "tree": "e219a51721afc279171d80a3d2a0daeef66b6813",
      "parents": [
        "a7af64a3ca1132a15fabdc366d581d7ec0401188"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 10:08:11 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 10:08:11 2026 +0200"
      },
      "message": "CAMEL-25717: camel-jbang - The docs of camel test init list its own options, not those of camel init (#27997)\n\nPrepareCamelJBangCommandsMojo found the source of a parent class (and of a mixin type) by its simple name, so camel test init, whose parent is the Init of Citrus, was documented with the options of camel init. A type that the class imports by name is now only taken from a source of that type, or else (also when that source cannot be parsed) its options are read from the class on the classpath of the project, by reflection. A type that is not imported by name is looked up as before, as the package that Roaster resolves for it is not certain with a static import on demand. camel test init now lists --directory and -h,--help.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "a7af64a3ca1132a15fabdc366d581d7ec0401188",
      "tree": "a1471353c5f3ddaaecb6dacd751fac9abee14f8f",
      "parents": [
        "826a664c5f165c15a9ac7abada64707a3e4afe8e"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 10:03:20 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 10:03:20 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - An LLM given with --url is the only one used (#27994)\n\nAn LLM given with --url (or the URL of the AI settings of Camel TUI) is the only one tried: when it does not answer, the command fails rather than falling back to the discovery of other providers, which may be a hosted one the user did not choose to send the prompts to. Without a URL the provider is detected as before. The AI panel of Camel TUI says which URL does not answer (start the LLM there, or Ctrl+P for another provider), rather than the setup guide for when no provider is found.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "826a664c5f165c15a9ac7abada64707a3e4afe8e",
      "tree": "1bed6e08b6b0c2942883bc6a16aa0341e95b4027",
      "parents": [
        "7b5d129971f07a59d90e4498fc2911dca8e7d442"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 09:09:43 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 09:09:43 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - camel init does not overwrite a file without --force (#27995)\n\ncamel init exits with 1 and leaves the file as it is when the file it creates exists already, and the new option --force overwrites it. The files downloaded from GitHub or a gist are all checked before any is written. When the template is picked in the terminal, camel init asks there whether to overwrite the file (no by default).\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "7b5d129971f07a59d90e4498fc2911dca8e7d442",
      "tree": "8a60aa78847bbfc135532a61f81935c93f802951",
      "parents": [
        "e339a2e9019fa1ce241b3bb1c2d855c5942d4794"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 09:07:49 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 09:07:49 2026 +0200"
      },
      "message": "CAMEL-25716: camel-management - remote exchange counters per route, for camel get processor --remote (#27996)\n\nThe routes count the exchanges that came from a remote endpoint, as the CamelContext does (CAMEL-20879): ManagedRouteMBean has RemoteExchangesTotal, Completed, Failed and Inflight. A route with a remote consumer uses its own counters; a route with an internal consumer counts the exchanges that came from a remote endpoint. The route dev console has the remote counters, so camel get processor --remote shows remote/total pairs; camel get route and camel top route have --remote, and the JSON of camel get context, route and processor has the remote counters. A reset keeps the remote exchanges inflight, of the routes and of the context, which went below 0 when reset with exchanges inflight.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "e339a2e9019fa1ce241b3bb1c2d855c5942d4794",
      "tree": "926699e06bf402bd104a81c713a7428fdfae2772",
      "parents": [
        "9fb9bc911f7850994166bd23a81838dfda1c568b"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 07:51:20 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 07:51:20 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for cmd route-diagram and cmd span (#27969)\n\nTests for camel cmd route-diagram of a running integration as text (25%\ncovered before) and the views of camel cmd span (33%): the traces, the\nflat list of spans, the waterfall of a trace and the JSON. They found\nthese bugs, fixed here:\n\n* camel cmd route-diagram --highlight never filtered the routes (the\n  helper keeps them all without the order of a message), so its check\n  for routes without the nodes was never reached, and node ids that no\n  route has drew a diagram with nothing highlighted; now not found (3).\n  Its errors went to stdout with exit 1; they go to stderr, and a\n  graphical --theme without terminal graphics exits with 2.\n* camel cmd span --trace with an id that matches no trace printed a\n  message and exited with 0; now not found (3). An unknown --sort of the\n  traces sorted the newest first; now a usage error.\n\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "9fb9bc911f7850994166bd23a81838dfda1c568b",
      "tree": "a2ad16874924e6e5eb6fcc12204bc059e0777b37",
      "parents": [
        "3646c6c7536e11c3c8595a7ab17d2ead586474bd"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 01:03:09 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 01:03:09 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for the runtime tools of camel ask (#27982)\n\nTests for the runtime tools of ToolRegistry (48% covered), which camel ask\nand the MCP servers give an AI, against an integration that answers their\nactions (FakeIntegration, shared with the eval tests): what each tool asks\nthe integration for (the source, dump, structure, topology, tracing,\nbrowse, spans, heap dump, SQL, route control, messages), the sections of\nthe status, the circuit breakers, the errors and history, and the\nanalysis tools. They found these bugs, fixed here:\n\n* send_message (camel ask) and tui_send_message (camel tui --mcp) put\n  the headers, given as key\u003dvalue lines as their description says, in\n  the action as one text; the send action of the CLI connector reads a\n  list of keys and values, so the message failed. RuntimeHelper sends the\n  list now, and a line that is not key\u003dvalue is an error of the tool.\n* get_circuit_breakers left out the calls of the fallback, the calls\n  that timed out and the calls a full bulkhead rejected, which camel get\n  circuit-breaker shows.\n* get_route_analysis, get_eip_stats and detect_config_drift put the\n  answers of the integration in their answer as JSON text (escaped),\n  instead of as JSON.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "3646c6c7536e11c3c8595a7ab17d2ead586474bd",
      "tree": "bfca7e38c4fd92b380fbe444d29062316d1586f5",
      "parents": [
        "1a90f44e5f8fd15c1b21baefd20af1190c87bd04"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 00:34:38 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 00:34:38 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for the questions of camel ask (#27981)\n\nTests for camel ask with a question (34% covered), against FakeLlmServer\nplaying Ollama: the answer, the tools the model calls and their results\nin the next question, a failed call of the LLM, the maximum iterations\nand the stats. FakeLlmServer can now reply in sequence, such as a tool\ncall and then the answer. They found these bugs, fixed here:\n\n* camel ask exited with 0 without an answer when the call of the LLM\n  failed, such as with an error of the model or a refused connection:\n  the error answer of the client was taken as the final answer.\n* The model in use, the integration, the note about a small model and\n  the output of --show-tools and --show-stats were printed on stdout\n  with the answer; they go to stderr, as with camel explain.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "1a90f44e5f8fd15c1b21baefd20af1190c87bd04",
      "tree": "40d434083969fa40c7c6494d8fc92bf2c8c6c78e",
      "parents": [
        "26a31bf3939f41161ef18f714f89d4c216ab94a5"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 00:30:10 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 00:30:10 2026 +0200"
      },
      "message": "CAMEL-23688: camel-console - the receive dev console dumps nothing when it has received nothing (#27980)\n\nThe receive dev console took the timestamps of the first and last\nmessage of a dump without checking that there was a message, so a dump\nwith nothing received yet, or since the last dump, failed with an\nIndexOutOfBoundsException. The CLI connector of an integration dumps it\nall the time, which failed (and was swallowed) whenever no message had\ncome in, and a dump through the HTTP dev console failed. Found while\ntesting camel cmd receive.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "26a31bf3939f41161ef18f714f89d4c216ab94a5",
      "tree": "c5a5f94a262b3c1e4a28a9e96d9edd800c383d64",
      "parents": [
        "21b3604c4e56bbe8ddcc95d847bb604fa4f8031e"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 00:28:05 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 00:28:05 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - camel cmd eval and the eval tools send the expression as it is (#27979)\n\ncamel cmd eval, the eval_expression tool of camel ask and the shared\nExpressionEvaluator (camel_eval_expression of the MCP servers) JSON-escaped\nthe expression and the body before putting them in the action, which is\nJSON already. The eval action of the CLI connector does not unescape them\n(unlike the transform action, whose client escapes for it), so an\nexpression with a double quote failed, such as ${body} \u003d\u003d \"hello\", and a\nslash, as in every XPath, or a quote in the body became part of the text.\n\nTests run the eval-language dev console as the connector does (the values\nof the action as they are): an expression with quotes and a slash, a JSON\nbody and the eval tool of camel ask, and camel cmd eval sends both as\ngiven. ToolRegistryTest no longer depends on whether an integration runs\non the machine.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "21b3604c4e56bbe8ddcc95d847bb604fa4f8031e",
      "tree": "d4e997500415499eb5abb2e1841c4f3c31621326",
      "parents": [
        "384d8ec110a8c8f6928cac222853e68ee3e1e4d8"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 00:09:31 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 00:09:31 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for camel version list without downloads (#27978)\n\nTests for camel version list (57% covered; its JSON was not tested),\nwithout downloads: the Camel releases the catalog knows, here the 4.10\nto 4.12 releases, which do not change any more. The table, JSON (and []),\n--patch\u003dfalse, --lts, --eol\u003dfalse, --from-date and --to-date, the order\nand --tail, and --date-format. They found these bugs, fixed here:\n\n* A --date-format that is not a date pattern showed the dates\n  unformatted, and a --from-date or --to-date that is not a date was\n  ignored; now usage errors.\n* The \"Last updated\" note was printed on stdout after the table; it goes\n  to stderr.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "384d8ec110a8c8f6928cac222853e68ee3e1e4d8",
      "tree": "b4707740073e7f7b03c264b1065a4ada3944bbaa",
      "parents": [
        "5e50108f3e3f3e05482a14b2ccf8c335af0e14c3"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Sat Oct 17 00:00:22 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 17 00:00:22 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for the chat with tools of the LLM client (#27976)\n\nTests for the chat with tools of LlmClient (38% covered), which camel ask\nuses, against FakeLlmServer playing each provider: the request in the\nformat of Ollama, OpenAI-compatible servers and Anthropic (the system\nprompt, the tools, the tool calls and their results in the\nconversation), the answer with its tool calls, reasoning and token\nusage, streamed or not, and the errors. FakeLlmServer can now give the\nreply of any path, and keeps the headers of the last request. They found\nthese bugs, fixed here:\n\n* A streamed answer that failed printed the error on stdout, after the\n  answer so far, while the other errors go to stderr; camel explain,\n  camel ask and camel overview --ai stream against Ollama by default.\n* A failure without a message, such as a refused connection, printed\n  \"null\" instead of the message of its cause.\n* The arguments of a tool call that an OpenAI-compatible server gives as\n  a JSON object, instead of JSON text, were dropped.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "5e50108f3e3f3e05482a14b2ccf8c335af0e14c3",
      "tree": "3d628cfa89335bea7069a5290e915ae9c5ae1349",
      "parents": [
        "dcb04ce16ebfabbc5f5704184ccabde563445703"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 23:49:55 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 23:49:55 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for camel catalog kamelet (#27977)\n\nTests for the listing of camel catalog kamelet (19% covered: only its\nsort was tested, as the command downloads the catalog), with a few\nKamelets instead of the catalog: the table, --type, --filter by name or\ndescription, JSON, and a catalog that cannot be downloaded. They found\nthese bugs, fixed here:\n\n* --filter failed with a NullPointerException (exit 70) when a Kamelet\n  of the catalog has no description.\n* An unknown --type showed nothing; now a usage error.\n* A --filter that matched nothing printed nothing; it says so on stderr,\n  as the other catalog commands do.\n\nThe command also has --json now, as the other catalog commands.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "dcb04ce16ebfabbc5f5704184ccabde563445703",
      "tree": "f1a78209a27b17bdf9249f996fc271b5ac953623",
      "parents": [
        "633e1bf0b75d3d6bf778354ebdf9275969de1c27"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 23:37:29 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 23:37:29 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for get bean, get route-controller and top source (#27975)\n\nTests for camel get bean (58% covered), camel get route-controller (52%)\nand camel top source (52%), with the answers of the bean, bean-model,\nroute-controller and top dev consoles. They found these bugs, fixed\nhere:\n\n* camel get bean --dsl paired the configuration of the properties with\n  the properties by position: it showed the configuration of another\n  property, or failed with an IndexOutOfBoundsException with\n  --nulls\u003dfalse, where the two lists differ. Now by name. An unknown\n  --scope showed every bean; now a usage error.\n* camel get route-controller read the back-off times and attempts, which\n  are longs, as ints, and showed \"Starting Routes: false\" for the default\n  route controller, which does not report it.\n* camel top source --json had its counters as text, unlike the JSON of\n  the other listings.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "633e1bf0b75d3d6bf778354ebdf9275969de1c27",
      "tree": "2ab1c0997631138e024ea9b4c638288a2f3a4f7f",
      "parents": [
        "9712c5e703008111c6b17d104b7c7f89eace0dc8"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 23:27:16 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 23:27:16 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for get route, processor, metric and health (#27974)\n\nTests for camel get route (65% covered), get processor (59%), get metric\n(58%) and get health (60%), with status files as the route, micrometer\nand health dev consoles write them. They found these bugs, fixed here:\n\n* camel get metric skipped an integration that has a distribution\n  summary, with a warning: it read the count of the summary from a field\n  the dev console does not have.\n* camel get metric --filter\u003dtimer*, the example of its help, showed\n  nothing; the filter takes a pattern now. --custom left out the metrics\n  of Camel in the classic naming (CamelExchangesTotal) only, not in the\n  default naming of Micrometer (camel.exchanges.total).\n* camel get route --error --limit limited the routes before it picked\n  the ones with an error, so it could show none, and --note did not show\n  the notes of the routes with an error.\n* camel get processor --filter showed the matching processors without\n  their route, and so without the name and pid of their integration;\n  --filter-mean left out the faster routes but not the faster processors.\n* camel get health --level with a value other than full or default was\n  taken as full; now a usage error.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "9712c5e703008111c6b17d104b7c7f89eace0dc8",
      "tree": "f1ea07825f0d785dd65ea706e1e49cf52d13a3d3",
      "parents": [
        "f2d8a8d19069ed1b03d75e068c32411c675fb316"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 22:29:04 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 22:29:04 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for explain and harden (#27971)\n\nTests for camel explain (9% covered) and camel harden (14%) against a local\nserver that plays Ollama and an OpenAI-compatible service (FakeLlmServer),\nwhich keeps the question it answered, so a test can check the prompt.\nThey found these bugs, fixed here:\n\n* camel harden --api-type\u003dopenai printed only the header: with --stream\n  (the default) it took the answer as printed, but the OpenAI-compatible\n  service answers in one go.\n* The LLM configuration, the progress and the prompts of --show-prompt\n  were printed on stdout with the answer; they go to stderr, so stdout\n  has only the answer.\n* An unknown --format was ignored; now a usage error.\n* An API key of up to four characters was shown whole in the\n  configuration; a key of eight characters or fewer is not shown.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "f2d8a8d19069ed1b03d75e068c32411c675fb316",
      "tree": "06272a66b38cddebf6b0af628f617b6b4a0fe4eb",
      "parents": [
        "c93c26fdecb80c1705487216a2e4dba787f886c4"
      ],
      "author": {
        "name": "dependabot[bot]",
        "email": "49699333+dependabot[bot]@users.noreply.github.com",
        "time": "Fri Oct 16 22:18:24 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 22:18:24 2026 +0200"
      },
      "message": "chore(deps): Bump io.github.classgraph:classgraph from 4.8.198 to 4.8.199 (#27972)\n\nchore(deps): Bump io.github.classgraph:classgraph\n\nBumps [io.github.classgraph:classgraph](https://github.com/classgraph/classgraph) from 4.8.198 to 4.8.199.\n- [Release notes](https://github.com/classgraph/classgraph/releases)\n- [Commits](https://github.com/classgraph/classgraph/compare/classgraph-4.8.198...classgraph-4.8.199)\n\n---\nupdated-dependencies:\n- dependency-name: io.github.classgraph:classgraph\n  dependency-version: 4.8.199\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n...\n\nSigned-off-by: dependabot[bot] \u003csupport@github.com\u003e\nCo-authored-by: dependabot[bot] \u003c49699333+dependabot[bot]@users.noreply.github.com\u003e"
    },
    {
      "commit": "c93c26fdecb80c1705487216a2e4dba787f886c4",
      "tree": "55eff81865bb32700a01347fdef78f57d2c49f2d",
      "parents": [
        "5750f3739402067121393df5d1c317b2c278643b"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 22:17:08 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 22:17:08 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for cmd browse and cmd stub (#27973)\n\nTests for the views of camel cmd browse (57% covered) and camel cmd stub\n(46%): the endpoints or queues, their order, --mask, --filter, the dump\nof the messages (--only-body, --grep, latest first) and the JSON. They\nfound that camel cmd browse --endpoint with an endpoint that the\nintegration cannot browse printed an empty table and exited with 0; now\nnot found (3).\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "5750f3739402067121393df5d1c317b2c278643b",
      "tree": "e11cccd3889139008c3520ff82cd5faa89b6e49e",
      "parents": [
        "83aaa80754f998c5b298b942c6b4ddb88f0f75ec"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 22:01:12 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 22:01:12 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for overview and transform route (#27967)\n\nTests for camel overview (21% covered), including --ai with a local\nserver that plays Ollama and --apply-descriptions, and for camel\ntransform route (29%): Java read without compiling, the conversion to\nJava (printed and into a directory) and to an XML file. They found these\nbugs, fixed here:\n\n* camel overview printed the markdown for a --format it does not have;\n  now a usage error.\n* camel transform route ran the routes and printed nothing for a\n  --format it does not have; now a usage error. A route that cannot be\n  read, such as invalid YAML, failed with an internal error (70) and a\n  stack trace; now 1 with the error of the parser.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "83aaa80754f998c5b298b942c6b4ddb88f0f75ec",
      "tree": "8a58d84a9aa7e8480ed3f1eaa5370844226de61f",
      "parents": [
        "41f4feade203688e4d030d1724a2bf90c9572951"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Sat Oct 17 01:28:36 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 21:58:36 2026 +0200"
      },
      "message": "CAMEL-25683: camel-azure-eventhubs - after a batch size checkpoint, the batch timeout checkpoints again (#27922)\n\nWhen checkpointBatchSize was reached, processCommit cancelled the\nscheduled timeout checkpoint of the partition but left the task\nregistered. Until the time that task had been scheduled for, the next\nevents of the partition only updated that cancelled task, so nothing\ncheckpointed them by time. At the end of a burst those events stayed\nuncheckpointed until the next event, and a restart or a partition moving\nto another consumer delivered them again (up to checkpointBatchSize - 1\nper partition; with the defaults, a burst of 700 events within 5 seconds\nleft events 501-700 uncheckpointed).\n\n* The cancelled task is now removed with its future, so the next event\n  starts a new timeout window, as the first event after start does.\n* The timeout task reset the per-partition counter when its checkpoint\n  was stored, without the lock, which could wipe the count of the next\n  window. It now takes the count when the checkpoint starts and adds it\n  back if storing the checkpoint fails, and the batch size check also\n  checkpoints when that count went past the batch size.\n\nNo option or default changes.\n\nCo-authored-by: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "41f4feade203688e4d030d1724a2bf90c9572951",
      "tree": "4d341573b06e369e80c0ebb8f2f84068857b68b6",
      "parents": [
        "d6eaeb5a334734504418deed1e4e0cdf03409bcd"
      ],
      "author": {
        "name": "Federico Mariani",
        "email": "34543311+Croway@users.noreply.github.com",
        "time": "Fri Oct 16 21:58:32 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 21:58:32 2026 +0200"
      },
      "message": "CAMEL-25541: camel-jbang-mcp - bounded camel_catalog_doc component answer (#27839)\n\nIn an evaluation of coding agents on Mule-to-Camel migrations, the\ncomponent answer of camel_catalog_doc was 15-38K characters by default\n(95K for kafka), a filter that matched nothing came back as an empty list\nthat agents read as \"not supported\", and the page sections that decide\ncorrectness (xslt header parameters, mail useHeader*, camel.server.* for\nplatform-http under camel run) were never in the answer.\n\n* A component lists its required options and 20 others in full (the new\n  limit argument changes it) and the rest by name, and every answer is\n  capped at 16 000 characters, with a marker of what was cut.\n* An option of both the endpoint and the component is listed once, with\n  its application.properties key (configKey).\n* A filter that matches nothing says so and names the closest options.\n* The section titles of the page are listed, and docPage\u003d\u003csection title\u003e\n  returns one section. smtp, imap and pop3 get the mail page, and the\n  platform-http page says how camel run enables the HTTP server.\n* The camel_component_properties tool is removed: it gave endpoint\n  options as camel.component.* keys, which camel run rejects. Noted in\n  the 4.24 upgrade guide.\n\nCo-authored-by: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "d6eaeb5a334734504418deed1e4e0cdf03409bcd",
      "tree": "c317fec54928f2684c10458c989a0fc6f36d3676",
      "parents": [
        "d4c36141a4c3ddc3e4a507ece3a250a084084377"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 21:45:42 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 21:45:42 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for get history and restart (#27966)\n\nTests for camel get history (28% covered) and camel restart (22%), which\nnow also covers a successful restart: the integration is a shell script\nthat writes the status of a started Camel for its pid. They found these\nbugs, fixed here:\n\n* camel get history failed with a NullPointerException for a failed step\n  with --show-exception\u003dfalse (or without an exception). --diagram and\n  --it with several integrations printed a message on stdout and exited\n  with 1; they are usage errors now (2), and the errors of --diagram go to\n  stderr. --json ignored --mask.\n* camel restart rebuilt the command line of an integration from a single\n  text (as on Windows) with a backslash escaping the next character, so a\n  path such as C:\\Program Files\\Java lost its backslashes; it now follows\n  the Windows quoting rules (backslashes count only in front of a quote).\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "d4c36141a4c3ddc3e4a507ece3a250a084084377",
      "tree": "e5e2a7230784ec6035e36917e0bd5a04cfaa0e0f",
      "parents": [
        "c1c397b7574fbb6002e65f6f770226d204275b4a"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 21:07:58 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 21:07:58 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for update run, dependency copy, get error, init and doc (#27964)\n\nTests for commands that work on the project and the catalog, which had\nlittle coverage (update run 0-5%, dependency copy 13%, init 39%, doc 33%,\nget error 41%). They found these bugs, fixed here:\n\n* camel dependency copy deleted the whole --output-directory before it\n  copied (--output-directory\u003d. deleted the project); it deletes the JARs of\n  an earlier copy only. It exited with 0 when a dependency could not be\n  resolved or copied (now 1), and went on when --output-directory is a\n  file (now 2).\n* camel update run: --download\u003dfalse without --quarkusMavenPluginVersion\n  failed with an IllegalStateException that named an option that does not\n  exist (now a usage error), a version without recipes failed with a\n  NullPointerException, and the error without a project named the command\n  camel upgrade run. The project directory, the downloader and the Maven\n  invocation can be replaced in a test.\n* camel get error --last showed the newest error of the integration with\n  the lowest pid, not the newest one; an --ago that is not a duration was\n  ignored, a --handled that is not true or false filtered out every error\n  (both now 2); the errors of --diagram went to stdout.\n* camel init of a Java file in src/main/java failed with a\n  StringIndexOutOfBoundsException, and a folder such as src/main/javafx\n  gave a package.\n* camel doc documented an EIP in JSON, but not as text (\"not found\"); it\n  does now, also with the prefix eip: for an EIP with the name of a\n  component, such as eip:log.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "c1c397b7574fbb6002e65f6f770226d204275b4a",
      "tree": "abd5ba7f819e90b583bee91cb8d095591d500c2d",
      "parents": [
        "23457461383da81f7d1a8337fa5cbffce7e9e8d6"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 20:45:15 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 20:45:15 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests for log, trace, cmd receive, cmd send, transform message and cmd memory-leak (#27963)\n\nTests for the commands that show the messages and logs of an integration,\nwhich had little coverage (cmd receive 9%, trace 17%, transform message\n14%, cmd memory-leak 6%). They found these bugs, fixed here:\n\n* camel log, camel trace --action\u003ddump and camel cmd receive --action\u003ddump\n  exited with 0 for a name that matches no running integration, when they\n  do not follow; now 3, as the exit codes say.\n* camel cmd receive --action\u003ddump without a name showed nothing, and\n  --output\u003djson printed a batch of messages once for each message in it.\n  camel trace and camel cmd receive ignored an unknown --sort key; now 2.\n* The colored parts of camel trace, cmd send, transform message and camel\n  log were printed on the console of the JVM, so a CLI that runs commands in\n  its JVM (camel ask, the AI panel) lost them. CamelCommand.printColored\n  prints them with the printer of the command when it does not print to the\n  console, and StringPrinter keeps the escape character that starts a\n  colored line.\n* camel cmd send and camel transform message failed with a\n  NullPointerException (exit 70) when the integration failed the action\n  itself; they print its error and exit with 1.\n* camel cmd memory-leak printed nothing and exited with 0 when the\n  integration failed the action or has no jfr-memory-leak console, misread\n  the answers to --status, and printed the duration ratio with the decimal\n  comma of the locale.\n* camel trace --tail showed the end of an exchange as returning from its\n  route.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "23457461383da81f7d1a8337fa5cbffce7e9e8d6",
      "tree": "413c90f1d3074f4e7b4c38b42b1197363d00fb36",
      "parents": [
        "880722fee3003d341d54ed23389b6ecaa6f09edd"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 20:37:36 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 20:37:36 2026 +0200"
      },
      "message": "CAMEL-25400: camel-jbang - The CLI that runs several commands gives each a fresh start (#27962)\n\ncamel ask (cli_exec) and the AI panel of the monitor run Camel CLI commands\nin their own JVM with CliRunner, which reused one command tree: a field of\na command that is not an option kept the value of the run before. Each run\nnow gets new instances of the commands (CamelJBangMain.newCommandLine, with\nthe plugins already loaded).\n\nlog4j was configured once per JVM, so a later command in such a CLI (or in\ncamel shell) that logs otherwise, such as export to its log file, only got\nits level, and logged to the console. The first logging configuration of\na new command is now applied; a command run on its own behaves as before.\n\ncamel doc and the catalog listings load the catalog of their runtime with\none method.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "880722fee3003d341d54ed23389b6ecaa6f09edd",
      "tree": "adc00de64c10e4ecd6254c7444a25afb15a0b0f9",
      "parents": [
        "472378346689482502c919f350c1cc5651788dac"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 20:30:35 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 20:30:35 2026 +0200"
      },
      "message": "CAMEL-25693: camel-vertx-websocket - close a WebSocket that connects just after the connect timeout (#27911)\n\nWhen the connect finished between the timed out wait and the cancel of the connect future, the cancel had no\neffect and nothing closed the WebSocket. Close the WebSocket the future completed with in that case.\n\nCo-Authored-By: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e"
    },
    {
      "commit": "472378346689482502c919f350c1cc5651788dac",
      "tree": "1b7c0c2d66cd9349f7e437ea1c408fb308b29967",
      "parents": [
        "d0a1031e27b77cf828a2da8aa06fee1e744ea4a4"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 20:30:31 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 20:30:31 2026 +0200"
      },
      "message": "chore: dependabot - ignore classgraph 6.x, it needs Java 25 (#27953)\n\nclassgraph 6.0.0 is compiled for Java 25 (class file version 69) and removes\nResourceList.forEachByteArrayThrowingIOException, which camel-datasonnet uses.\nDependabot PR #27940 for it was closed; ignore the major updates the same way\nas fugue 7 until Camel\u0027s minimum Java is 25.\n\nCo-Authored-By: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Claus Ibsen \u003cclaus.ibsen@gmail.com\u003e"
    },
    {
      "commit": "d0a1031e27b77cf828a2da8aa06fee1e744ea4a4",
      "tree": "c7b6da8ed1ae80e1e2d4043ed2a78fded278be5b",
      "parents": [
        "d46511e45eba0a4cbfd7d47851d5bb830ebe17d9"
      ],
      "author": {
        "name": "Guillaume Nodet",
        "email": "gnodet@gmail.com",
        "time": "Fri Oct 16 20:30:27 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 20:30:27 2026 +0200"
      },
      "message": "CAMEL-25538: fix configuration-validate to accept all camel.* groups and report accepted\u003dfalse as valid\u003dfalse (#27841)\n\nAbstractCamelCatalog.validateConfigurationProperty() accepted only 10 hardcoded camel.* prefixes, so the keys\nof the other groups of camel-main-configuration-metadata.json (camel.server.*, camel.management.*,\ncamel.vault.*, ...) were never checked, and camel_configuration_validate answered accepted:false together\nwith valid:true.\n\nThe catalog now accepts every group of the main model, matching group names ignoring case and dashes as\ncamel-main binds them (camel.error-registry.* is the camel.errorRegistry group), nested groups such as\ncamel.vault.aws.* included. The MCP tool reports a line as checked only when the catalog accepted it, valid\nonly when it is checked and has no errors, and counts the other lines as unchecked. With runtime\u003dspring-boot\nan unknown option under a newly accepted group is reported as unchecked, as the starter-only options are not\nin the main metadata.\n\nCatalogService also falls back to the default catalog when the Spring Boot catalog cannot be downloaded\n(offline).\n\nCo-authored-by: Claude Sonnet 4.6 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "d46511e45eba0a4cbfd7d47851d5bb830ebe17d9",
      "tree": "3040bebabbba61f0da9097731d3edba05ae366f2",
      "parents": [
        "a897120ba2fc57b351b86b4c3d1a672ad879241e"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 18:55:27 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 18:55:27 2026 +0200"
      },
      "message": "CAMEL-25400: camel-jbang - One sort, one row copy and one format for the listings (#27961)\n\nThe listings sorted their rows with a copy of the same sortRow method in 48\ncommands. RowSort gives each listing its order once (pid, name and age of\nthe integration, and the keys of the listing), with a - in front for the\nreverse order, a row without the value first, and a usage error (exit 2)\nfor a key the listing does not have; an unknown key left the rows\nunsorted. The top commands add the slowest first to the order of their\nstatus command.\n\ncamel get bean sorts by type, as its help says, and camel get transformer\nno longer offers total.\n\nCopyableRow replaces the 18 copies of the copy() method of the rows, and\nListingFormat the copies of the short URI, since last, delta and load\nhelpers.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "a897120ba2fc57b351b86b4c3d1a672ad879241e",
      "tree": "a6c2b3e304f9d08487915c96e8e613931db9e752",
      "parents": [
        "16b6e9dfbe82939fc0a1131f7b20780570bd5936"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 18:37:31 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 18:37:31 2026 +0200"
      },
      "message": "CAMEL-25449: camel-jbang - camel debug sends its commands in files of their own (#27955)\n\ncamel debug was the last command that always used the action file all the\nclients of an integration share (\u003cpid\u003e-action.json): a step, step over or\nskip over, and the attach of --remote-attach, could be overwritten by\nanother client before the integration read it. It now sends them with\nActionClient, which gives each command a file of its own (Camel 4.21 or\nlater), uses the shared file only for an older integration, and waits until\nthe integration took the command; a failed attach exits with its exit code.\nThe monitor already did this.\n\nCamelCommand.getActionFile and getOutputFile, no longer used, are\ndeprecated for plugin commands in favour of ActionClient.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "16b6e9dfbe82939fc0a1131f7b20780570bd5936",
      "tree": "6e6c755ff13fc0e2f143c0b6f14c86fe4b5833b0",
      "parents": [
        "1109759ffa2906d8023c8d7193cbdecf462bd155"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 17:35:49 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 17:35:49 2026 +0200"
      },
      "message": "CAMEL-25696: camel-jbang - A boolean option given without a value is on (#27951)\n\npicocli sets a boolean flag to the opposite of its default value, so the\nflag of an option that is on by default turned it off: camel export\n--maven-wrapper exported no Maven wrapper, camel config set --global wrote\nthe local configuration, camel cmd receive --show-body hid the body, and\ncamel kubernetes run --dev --cleanup left the deployment behind.\n\nAll 82 boolean options that are on by default, also those whose default\ncomes from the field (such as --global) or from the environment (run\n--logging-color), take arity 0..1 with the fallback value true, as --follow\ndoes since CAMEL-25396: a bare flag is on, --option\u003dfalse is off, and a\nname or file after the flag is not taken as its value. A test in\ncamel-jbang-core and in the kubernetes and validate plugins walks the\ncommands and fails for a new option without it.\n\nA test checks the colors option of camel run on run, dev and debug\nwhatever the environment, as its default is off in CI.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "1109759ffa2906d8023c8d7193cbdecf462bd155",
      "tree": "2cef03f8348c7fff6bc9e7768b8bf4aa22650670",
      "parents": [
        "ac792d3385174b63acd5a18efa8dee92830c4699"
      ],
      "author": {
        "name": "Andrea Cosentino",
        "email": "ancosen@gmail.com",
        "time": "Fri Oct 16 17:00:10 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 17:00:10 2026 +0200"
      },
      "message": "CAMEL-25645: camel-milo - let the OPC UA client validate the server certificate against a trust list\n\n[CAMEL-25645](https://issues.apache.org/jira/browse/CAMEL-25645)\n\n`milo-client` and `milo-browse` built the Eclipse Milo client configuration without a certificate validator, so they kept Milo\u0027s default, `CertificateValidator.InsecureCertificateValidator`, and the certificate of a server offering a Sign or SignAndEncrypt endpoint was not checked. The client had no option to configure trust material.\n\nThis PR:\n\n- adds three client options, at component and endpoint level, shared by `milo-client` and `milo-browse`:\n  - `trustListDirectory`: a trust list in Eclipse Milo\u0027s file based layout (`trusted/certs`, `trusted/crl`, `issuer/certs`, `issuer/crl`).\n  - `certificateValidator`: a custom `CertificateValidator` bean, used instead of the trust list. It is not autowired.\n  - `trustAllCertificates`: accept any server certificate, marked `security \u003d \"insecure:ssl\"`.\n- validates the server certificate whenever the selected endpoint uses a security policy other than `None`. When neither `trustListDirectory` nor `certificateValidator` is set and `trustAllCertificates` is false, the client does not connect.\n- builds the trust list validator with `APPLICATION_URI`, `VALIDITY` and `REVOCATION`. It refuses a server certificate that:\n  - does not chain up to a trusted certificate;\n  - is outside its validity period;\n  - is revoked;\n  - or whose application URI differs from the server\u0027s.\n\nCloses #27824\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "ac792d3385174b63acd5a18efa8dee92830c4699",
      "tree": "230453efd378f488cb20aa5a66e2c94c86e005de",
      "parents": [
        "5961fc46e56b43cf29a022fb7e93a46041315753"
      ],
      "author": {
        "name": "Guillaume Nodet",
        "email": "gnodet@gmail.com",
        "time": "Fri Oct 16 16:59:56 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:59:56 2026 +0200"
      },
      "message": "CAMEL-25631: camel-core - Deprecate Route.clearRouteModel() and stop calling it from RouteReifier\n\nDeprecate Route.clearRouteModel() (since 4.24.0, for removal) and turn it\ninto a default no-op. RouteReifier no longer calls it, so the route model\nreturned by Route.getRoute() and the error handler factory are kept at\nruntime, also for routes added after the CamelContext has started.\nDefaultRoute.route is now final and the getRoute() javadoc describes what it\nreturns. RouteModelRetainedTest covers routes created at startup and routes\nadded later, and the 4.24 upgrade guide documents the deprecation.\n\nCloses #27835\n\nCo-authored-by: Hermes Agent \u003chermes@nousresearch.com\u003e"
    },
    {
      "commit": "5961fc46e56b43cf29a022fb7e93a46041315753",
      "tree": "c4ec4bc34a9b7ba552be91f3bc3b30f607b76dd7",
      "parents": [
        "72701dd5700788539872ed1406eef406d0331e43"
      ],
      "author": {
        "name": "Serdar Gökay",
        "email": "serdar.gokay@etzel.com.tr",
        "time": "Fri Oct 16 17:59:44 2026 +0300"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:59:44 2026 +0200"
      },
      "message": "CAMEL-25626: camel-milo - deliver a data change with a Bad status even when its value is null\n\n[CAMEL-25626](https://issues.apache.org/jira/browse/CAMEL-25626).\n\nWith the default `omitNullValues\u003dtrue`, the `milo-client` consumer dropped every data change whose value was null, regardless of its status code. OPC UA Part 4 requires a server to send a null value together with a Bad status, so dropping null values drops every Bad status: a sensor failure, a removed node or a monitored item that could not be created (#27780, #27906) never reached the route unless `omitNullValues\u003dfalse` was set.\n\nWhy this matters in automation: a route that feeds a historian, an MES, a UNS topic or an alarm evaluates the last value it received. When the quality of a tag goes Bad and the route never hears about it, the stale value keeps being treated as current, and the plant acts on a number that nobody is measuring any more. Quality propagation is the first thing an OT integration is expected to get right; the component should deliver it by default.\n\nCloses #27908\n\nCo-authored-by: Claude Fable 5.1 \u003cnoreply@anthropic.com\u003e\nCo-authored-by: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "72701dd5700788539872ed1406eef406d0331e43",
      "tree": "07e803e923003087dbb0e7aac76bb282f489f358",
      "parents": [
        "24cd63f10fb22a520b1a83fba00a47459422943b"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Fri Oct 16 20:29:33 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:59:33 2026 +0200"
      },
      "message": "CAMEL-25678: camel-core - Switch case values and Dynamic Router uriDelimiter resolve property placeholders\n\n[CAMEL-25678](https://issues.apache.org/jira/browse/CAMEL-25678)\n\nEvery String option of an EIP is resolved with `parseString` when the route is created, which is also how route template and Kamelet parameters reach an EIP (CAMEL-25047 resolved several more of them). Two options were used as written:\n\n- **Switch EIP, case `value`.** `SwitchReifier` resolved the `uri` of each case and of `otherwise` (`staticUri` calls `parseString`), but built the table from `c.getValue().toLowerCase(Locale.ENGLISH)`. A case such as `doCase(\"{{tier}}\", \"direct:gold\")` was keyed by the text `{{tier}}`, so no selector result matched it: every message went to `otherwise`, or continued after the Switch without a destination when there is no `otherwise`, and nothing was logged. This includes a route template or Kamelet parameter used as a case value. The duplicate check compared the unresolved text too, so two cases that resolve to the same value started without error.\n- **Dynamic Router EIP, `uriDelimiter`.** `DynamicRouterReifier` used the delimiter as written, while `RoutingSlipReifier` and `RecipientListReifier` resolve theirs. With `uriDelimiter(\"{{delim}}\")` the slip was not split and the exchange was sent to one endpoint whose uri is the whole slip.\n\nCloses #27917\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "24cd63f10fb22a520b1a83fba00a47459422943b",
      "tree": "1062838ca4f6e6941c1f30d376548b679fae2b47",
      "parents": [
        "68329f0919bc2b7f22a6ff2ecfc373b58269948c"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Fri Oct 16 20:29:21 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:59:21 2026 +0200"
      },
      "message": "CAMEL-25682: camel-resilience4j - a timed-out call waits for a write-back of the task that is in progress\n\n[CAMEL-25682](https://issues.apache.org/jira/browse/CAMEL-25682)\n\nCAMEL-24134 added a write guard so that the task of the circuit breaker does not write its result into the exchange after a timeout handed the exchange to the fallback. The task claims the guard with `compareAndSet(false, true)` and then copies its result (`ResilienceProcessor.processTask`, and `processTaskAsync` in asynchronous mode). The fallback task only did `exchangeWriteGuard.set(true)` before writing the exchange. When the timeout fires after the task has won the guard and before it has finished copying, the two write the same exchange at the same time:\n\n- with `onFallback`, the body of the fallback is replaced by the body of the task, or `CamelCircuitBreakerResponseFromFallback` is set back to `false` (and `CamelCircuitBreakerResponseSuccessfulExecution` to `true`) after the fallback set them, while the exchange already continues in the route;\n- without fallback, `ExchangeHelper.copyResults` ends with `setException(null)` and clears the `TimeoutException` that the caller has just set;\n- headers and properties are written by two threads.\n\nThe caller does not wait for the task here (the task runs in `CompletableFuture.supplyAsync` behind `TimeLimiter.decorateFutureSupplier`, or `decorateCompletionStage` in async mode), so the window is the time the task needs to copy its result; it needs a task that ends at about the moment of the timeout.\n\nCloses #27921\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "68329f0919bc2b7f22a6ff2ecfc373b58269948c",
      "tree": "1ddd2c5f24e512c6ea04352359c420497130b6e2",
      "parents": [
        "b8d785ce36078ceb80e5a5b5906b9518bc5be474"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Fri Oct 16 20:29:09 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:59:09 2026 +0200"
      },
      "message": "CAMEL-25684: camel-slack - the consumer keeps the messages of a poll it did not route when the route is suspended\n\n[CAMEL-25684](https://issues.apache.org/jira/browse/CAMEL-25684)\n\n`SlackConsumer.createExchanges` moved the timestamp to the most recent message of the poll before `processBatch` routes the messages. `processBatch` stops when `isBatchAllowed()` is false, which `ScheduledBatchPollingConsumer` returns when the route is being suspended (`RouteController.suspendRoute`, also from a route policy that suspends the route through the route controller, such as `DurationRoutePolicy`, or `CamelContext.suspend()`, which resumes the same consumer). The rest of that poll was then never routed: after the resume the same consumer asks Slack only for messages after the timestamp. Nothing is logged. With the defaults the most recent message is routed first, so the older messages of the poll were lost: the rest of that poll, which since CAMEL-25523 can be several pages of `maxResults` (default 10) messages each. This is the shape that CAMEL-25570 fixed for aws2-ddbstream. A consumer suspended directly (`consumer.suspend()`, as `ScheduledRoutePolicy` and the throttling route policies do) does not end the batch and is not affected; a route that is stopped and started gets a new consumer and is not affected either.\n\nCloses #27923\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "b8d785ce36078ceb80e5a5b5906b9518bc5be474",
      "tree": "3e4019b47aa7245a66b8268d842cd4d4522e9e15",
      "parents": [
        "73b3eba6f8d397eccb94c4849114f8269d136e93"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Fri Oct 16 20:28:58 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:58:58 2026 +0200"
      },
      "message": "CAMEL-25685: camel-jetty - map the query parameters when Jetty cannot read the request body parameters\n\n[CAMEL-25685](https://issues.apache.org/jira/browse/CAMEL-25685)\n\n`AttachmentHttpBinding.populateRequestParameters` maps the query parameters through `request.getParameterNames()`. Jetty 12 reads the body parameters and the query parameters together there, and throws for the whole request when it cannot read the body parameters. The `catch` around the loop only logs at DEBUG, so the exchange is routed without any query parameter and the client gets 200. Two requests that I measured take this path:\n\n- a form-urlencoded POST with a body over Jetty\u0027s `maxFormContentSize` (200000 bytes by default), default options. The form fields are still mapped (Camel parses them from the body in `readFormUrlEncodedBody`); only the query parameters are lost. Example: `POST /upload?customerId\u003d42` with a 250 KB form gives `header(\"customerId\") \u003d\u003d null`;\n- any multipart request on an endpoint with `enableMultipartFilter\u003dfalse`, whatever its size. The catch was written for this case; the query parameters were dropped together with the multipart body parameters.\n\nCloses #27924\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "73b3eba6f8d397eccb94c4849114f8269d136e93",
      "tree": "485f898276e25798af6ed937648deacfb54a0122",
      "parents": [
        "b9ce3e7931940652a92790cadbd1f12d9013bf0e"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Fri Oct 16 20:28:43 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:58:43 2026 +0200"
      },
      "message": "CAMEL-25677: camel-wasm - remove the wasm language\n\n[CAMEL-25677](https://issues.apache.org/jira/browse/CAMEL-25677)\n\nPart 3 of the camel-wasm redesign (part 1: #27678, part 2: #27793, both merged): remove the `wasm` expression language.\n\nAuthor: Shashank Mohan Jain (@allthingssecurity), working with Claude Code (Claude Opus 5.5).\n\nSince CAMEL-25531 the `wasm` endpoint runs WASI Preview 1 command modules: the message body is standard input and standard output becomes the new body. The `wasm` language still used the old protocol: it called a named exported function of the module through the `alloc`/`dealloc` exports and a JSON envelope of the body and headers (`WasmFunction`, `WasmSupport`).\n\nOn #27793 @davsclaus decided to remove the language rather than move it to WASI: \"remove wasm language, this module was an experiment so its fine to do such changes\", and \"the removal can be in a follow up PR\" (https://github.com/apache/camel/pull/27793#issuecomment-6163046916). This PR is that follow-up.\n\nCloses #27929\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "b9ce3e7931940652a92790cadbd1f12d9013bf0e",
      "tree": "3765d1893cc6a6e00b906d257d67d78d25b6916b",
      "parents": [
        "442e440e43e6a0ec45b4e9a29716069a6b78227d"
      ],
      "author": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Fri Oct 16 16:58:30 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:58:30 2026 +0200"
      },
      "message": "CAMEL-24812: ci - do not include modules located under src/ in the incremental build\n\npom.xml files under a module\u0027s src/ directory (src/main/resources archetype templates, src/it fixtures) are not reactor modules and must not be selected with -pl. Walk up to the owning module in findProjectRoot, skip files nested in archetype-resources, and filter such paths out of the Scalpel report.\n\nRemove the camel-salesforce-maven-plugin exclusion and manual IT mapping which are no longer needed.\n\nCloses #27947\n\nCo-authored-by: IBM Bob 2.2.1"
    },
    {
      "commit": "442e440e43e6a0ec45b4e9a29716069a6b78227d",
      "tree": "e0bfb335085d54bc7dba171cc1a72e7c1333c5ed",
      "parents": [
        "004809689f98d3c3ffd21a91e0ffd30555e87fc6"
      ],
      "author": {
        "name": "Andrea Cosentino",
        "email": "ancosen@gmail.com",
        "time": "Fri Oct 16 16:58:20 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:58:20 2026 +0200"
      },
      "message": "CAMEL-25706: camel-elasticsearch - bind the basic authentication credentials to the cluster nodes\n\n[CAMEL-25706](https://issues.apache.org/jira/browse/CAMEL-25706): `ElasticsearchProducer.createClient()` registered the configured `user` and `password` with `AuthScope.ANY`, which matches any host.\n\n- The credentials are now held by a `NodeScopedCredentialsProvider`, which offers them only to the nodes the client talks to: the hosts of `hostAddresses` and, when `enableSniffer` is set, the nodes the sniffer finds.\n- A node matches on scheme, host name (in any case) and port. A node without a port matches the default port of its scheme.\n- The provider reads the nodes from the `RestClient` (`getNodes()`) on each lookup, so it follows the nodes the sniffer adds or removes. Every configured node keeps receiving the credentials.\n- HttpClient 4\u0027s `BasicCredentialsProvider` matches an `AuthScope` on host and port only, never on the scheme. The provider therefore checks the origin of the scope that HttpClient looks the credentials up with, both preemptively and after a challenge.\n- `setCredentials` and `clear` do nothing, because the credentials come from the endpoint configuration only. HttpClient calls `setCredentials` for the user info of a request URI.\n- A client set with the `client` option is not changed.\n\nCloses #27946\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "004809689f98d3c3ffd21a91e0ffd30555e87fc6",
      "tree": "13c5fc354e837341d277b4820badfd207c0069fd",
      "parents": [
        "f8bd57d57c79af147024704ca24eb95ec059baf7"
      ],
      "author": {
        "name": "Andrea Cosentino",
        "email": "ancosen@gmail.com",
        "time": "Fri Oct 16 16:58:09 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:58:09 2026 +0200"
      },
      "message": "CAMEL-25708: camel-opensearch - bind the basic authentication credentials to the cluster nodes\n\n[CAMEL-25708](https://issues.apache.org/jira/browse/CAMEL-25708): `OpensearchProducer.createClient()` registered the configured `user` and `password` with `new AuthScope(null, null, -1, null, null)`, which matches any host. [CAMEL-24815](https://issues.apache.org/jira/browse/CAMEL-24815) switched to it so that every node of a multi-host cluster receives the credentials, not only the first configured host.\n\n- The credentials are now held by a `NodeScopedCredentialsProvider`, which offers them only to the nodes the client talks to: the hosts of `hostAddresses` and, when `enableSniffer` is set, the nodes the sniffer finds. Every configured node keeps receiving them, as CAMEL-24815 intended.\n- A node matches on scheme, host name (in any case) and port. A node without a port matches the default port of its scheme.\n- The provider reads the nodes from the `RestClient` (`getNodes()`) on each lookup, so it follows the nodes the sniffer adds or removes.\n- A client set with the `client` or `openSearchClient` option is not changed.\n\nThis is the same change as #27946 (CAMEL-25706) for camel-elasticsearch. Here it is written against HttpClient 5, whose `CredentialsProvider` only looks credentials up, and whose `AuthScope` carries the scheme (`getProtocol()`).\n\nUpgrade guide (4.24): a request to another host is sent without the credentials. This includes the host of a node with another scheme or port.\n\nCloses #27948\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "f8bd57d57c79af147024704ca24eb95ec059baf7",
      "tree": "271bc2b7efce197c002bec9a1dd410f78bdfbb04",
      "parents": [
        "7b12fca82cf49980c0d477ffb6370b99c2acef31"
      ],
      "author": {
        "name": "Andrea Cosentino",
        "email": "ancosen@gmail.com",
        "time": "Fri Oct 16 16:57:57 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:57:57 2026 +0200"
      },
      "message": "CAMEL-25707: camel-elasticsearch-rest-client - bind the basic authentication credentials to the cluster nodes\n\n[CAMEL-25707](https://issues.apache.org/jira/browse/CAMEL-25707): `ElasticsearchRestClientProducer.createClient()` registered the configured `user` and `password` with `AuthScope.ANY`, which matches any host.\n\n- The credentials are now held by a `NodeScopedCredentialsProvider`, which offers them only to the nodes the client talks to: the hosts of `hostAddressesList` and, when `enableSniffer` is set, the nodes the sniffer finds.\n- A node matches on scheme, host name (in any case) and port. A node without a port matches the default port of its scheme.\n- The provider reads the nodes from the `RestClient` (`getNodes()`) on each lookup, so it follows the nodes the sniffer adds or removes. Every configured node keeps receiving the credentials.\n- HttpClient 4\u0027s `BasicCredentialsProvider` matches an `AuthScope` on host and port only, never on the scheme. The provider therefore checks the origin of the scope that HttpClient looks the credentials up with, both preemptively and after a challenge.\n- `setCredentials` and `clear` do nothing, because the credentials come from the endpoint configuration only. HttpClient calls `setCredentials` for the user info of a request URI.\n- A client set with the `restClient` option is not changed.\n\nThis is the same change as #27946 (CAMEL-25706) for camel-elasticsearch. The provider class is duplicated because the two components are separate modules.\n\nCloses #27949\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "7b12fca82cf49980c0d477ffb6370b99c2acef31",
      "tree": "41cb4c9cd89bbc1fdadf59f3a0c8a3d06fb6cd6d",
      "parents": [
        "18f53efde6c706c2ad04a818ea75deed1bbfeb20"
      ],
      "author": {
        "name": "allthingssecurity",
        "email": "49463903+allthingssecurity@users.noreply.github.com",
        "time": "Fri Oct 16 20:27:36 2026 +0530"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 16:57:36 2026 +0200"
      },
      "message": "CAMEL-25681: camel-support - FileIdempotentRepository caches a key only once it is stored\n\n[CAMEL-25681](https://issues.apache.org/jira/browse/CAMEL-25681)\n\n`FileIdempotentRepository.add(key)` put the key into its 1st-level cache first, and then checked the file store (`containsStore`) and appended the key to it (`appendToStore`). When the store could not be read or written (disk full, permissions, an I/O error of a network file system), `add` threw and the message failed, but the key stayed in the cache. Every later `add` of that key returned `false` from the cache until the application was restarted.\n\nSo the retry of the failed message was taken for a duplicate and skipped, also after the store worked again. For example an `idempotentConsumer` with a file repository behind a JMS consumer: during a \"disk full\" period every message fails, the broker redelivers them, and the redeliveries are filtered as duplicates and acknowledged.\n\n`KafkaIdempotentRepository.add` (camel-kafka, lines 352-363 on main) already takes the key out of its cache again when storing it fails. The other repositories in the project have no cache in front of their store.\n\nCloses #27920\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "18f53efde6c706c2ad04a818ea75deed1bbfeb20",
      "tree": "2ef116d6b09e7daf8207c814c6717ee17d85e283",
      "parents": [
        "71633593ebdcc3b3e658f858283bd6a03bf9556c"
      ],
      "author": {
        "name": "Andrea Cosentino",
        "email": "ancosen@gmail.com",
        "time": "Fri Oct 16 11:14:16 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 11:14:16 2026 +0200"
      },
      "message": "CAMEL-25436: camel-test-infra-spiffe - fix the SPIRE readiness race and rootless engines (#27936)\n\nThe SPIRE infra handed the stack to the tests as soon as the agent\u0027s\nWorkload API socket existed. The SPIRE server only passes a new\nregistration entry on to its agents when it next rebuilds its entry cache\n(every 5 seconds by default) and the agent picks it up on its next sync,\nso for several seconds every fetch was answered PERMISSION_DENIED \"no\nidentity issued\". SpiffeMutualTlsIT\u0027s X509Source retries through that\nwindow, SpiffeWorkloadApiIT\u0027s one-shot fetches do not, so the ITs failed\non the CI nodes where failsafe ran SpiffeWorkloadApiIT first. The infra\nnow waits for the agent to log the creation of the workload X509-SVID,\nwhich it does once the entry is in its cache.\n\nThe entry\u0027s unix:uid selector used the host uid of the test JVM, but the\nagent\u0027s unix workload attestor sees that uid through the user namespace\nof the agent container, so under rootless Podman or Docker (where the\nengine owner is uid 0) it never matched. The entry is now created once\nthe agent runs, for the uid translated through the agent\u0027s uid_map.\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\nSigned-off-by: Andrea Cosentino \u003cancosen@gmail.com\u003e"
    },
    {
      "commit": "71633593ebdcc3b3e658f858283bd6a03bf9556c",
      "tree": "2aabb3295938adb374922fcfba919fa6cbf08a1a",
      "parents": [
        "b1bb59f18a518e691c5014ea12c942103df11989"
      ],
      "author": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Fri Oct 16 09:21:20 2026 +0200"
      },
      "committer": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Fri Oct 16 11:04:36 2026 +0200"
      },
      "message": "CAMEL-25688: Stabilize flaky FTP consumer integration tests\n\nSeven FTP consumer IT tests were susceptible to receiving more messages\nthan expected because:\n\n1. The Camel context and routes are started *before* doPostSetup() runs,\n   so the FTP consumer scheduler can fire its first poll against an\n   empty or partially-populated directory.\n2. Without idempotency protection (no noop/delete/idempotent), files are\n   re-consumed on every subsequent poll interval within the\n   MockEndpoint.assertIsSatisfied() 10-second wait window, causing\n   \"expected \u003cN\u003e but was \u003cM\u003e\" assertion failures non-deterministically.\n\nFix: add \u0026noop\u003dtrue to all affected consumer URLs. noop\u003dtrue\nautomatically enables idempotent\u003dtrue, so each file path is tracked in\na MemoryIdempotentRepository and consumed exactly once regardless of how\nmany poll cycles occur during the test.\n\nA separate getFtpProducerUrl() helper is introduced in each test where\nsendFile() previously reused getFtpUrl(). This prevents consumer-only\noptions (noop, recursive, include, filter, sorter, sortBy) from leaking\ninto producer URLs, which would cause endpoint resolution failures.\n\nFtpConsumerDirectoriesNotMatchedIT now also verifies the exact set of\nmatched file names via mock.expectedHeaderValuesReceivedInAnyOrder(),\nwhich reports the unexpected file names when the assertion fails.\n\nFor FtpConsumerRelativeFileNameIT and FromFtpRemoteFileSorterIT, which\ncheck strict delivery order (sortBy\u003dfile:name and a custom alphabetical\nsorter), the route is started explicitly after doPostSetup() completes\nthe upload (autoStartup\u003dfalse + startRoute()) to guarantee all files\nare present before the first poll fires.\n\nAffected tests:\n- FtpConsumerDirectoriesNotMatchedIT (original flaky test, CAMEL-25688)\n- FtpConsumerRelativeFileNameIT\n- FtpConsumerMultipleDirectoriesIT\n- FtpConsumerSkipDotFilesIT\n- FromFtpRemoteFileFilterIT\n- FromFtpRemoteFileSorterIT\n- FromFtpRegexPatternIT\n\nCo-authored-by: IBM Bob 2.2.1\nSigned-off-by: Aurélien Pupier \u003capupier@ibm.com\u003e\n"
    },
    {
      "commit": "b1bb59f18a518e691c5014ea12c942103df11989",
      "tree": "e2da593e3a7262b301c8ea33876acbf1c9eff5d2",
      "parents": [
        "407d1674961f09e759abcaa8471b7ac985eadfdc"
      ],
      "author": {
        "name": "dependabot[bot]",
        "email": "49699333+dependabot[bot]@users.noreply.github.com",
        "time": "Fri Oct 16 07:56:05 2026 +0000"
      },
      "committer": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Fri Oct 16 11:03:58 2026 +0200"
      },
      "message": "chore(deps): Bump org.webjars:swagger-ui from 5.33.1 to 5.33.2\n\n---\nupdated-dependencies:\n- dependency-name: org.webjars:swagger-ui\n  dependency-version: 5.33.2\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n...\n\nSigned-off-by: dependabot[bot] \u003csupport@github.com\u003e"
    },
    {
      "commit": "407d1674961f09e759abcaa8471b7ac985eadfdc",
      "tree": "aa6369f0caf284e88f6428349aa2c930ba4a4afc",
      "parents": [
        "07c54cb62eaed250041226023fb97db6e20c3309"
      ],
      "author": {
        "name": "dependabot[bot]",
        "email": "49699333+dependabot[bot]@users.noreply.github.com",
        "time": "Fri Oct 16 07:55:23 2026 +0000"
      },
      "committer": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Fri Oct 16 11:03:41 2026 +0200"
      },
      "message": "chore(deps): Bump aws-java-sdk2-version from 2.55.14 to 2.55.15\n\nBumps `aws-java-sdk2-version` from 2.55.14 to 2.55.15.\n\nUpdates `software.amazon.awssdk:sqs` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:kinesis` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:s3` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:sns` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:cloudwatch` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:ec2` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:eventbridge` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:iam` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:kms` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:lambda` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:secretsmanager` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:ssm` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:sts` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:dynamodb` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:config` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:apache5-client` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:transcribe` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:auth` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:regions` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:sdk-core` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:aws-core` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:netty-nio-client` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:athena` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:bedrock` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:bedrockruntime` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:bedrockagent` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:bedrockagentruntime` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:cloudtrail` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:comprehend` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:ecs` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:eks` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:firehose` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:kafka` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:mq` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:polly` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:redshiftdata` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:checksums` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:s3vectors` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:ses` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:sfn` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:textract` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:timestreamquery` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:timestreamwrite` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:translate` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:rekognition` from 2.55.14 to 2.55.15\n\nUpdates `software.amazon.awssdk:securityhub` from 2.55.14 to 2.55.15\n\n---\nupdated-dependencies:\n- dependency-name: software.amazon.awssdk:sqs\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:kinesis\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:s3\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:sns\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:cloudwatch\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:ec2\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:eventbridge\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:iam\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:kms\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:lambda\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:secretsmanager\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:ssm\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:sts\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:dynamodb\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:config\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:apache5-client\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:transcribe\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:auth\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:regions\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:sdk-core\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:aws-core\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:netty-nio-client\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:athena\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:bedrock\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:bedrockruntime\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:bedrockagent\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:bedrockagentruntime\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:cloudtrail\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:comprehend\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:ecs\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:eks\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:firehose\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:kafka\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:mq\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:polly\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:redshiftdata\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:checksums\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:s3vectors\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:ses\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:sfn\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:textract\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:timestreamquery\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:timestreamwrite\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:translate\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:rekognition\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n- dependency-name: software.amazon.awssdk:securityhub\n  dependency-version: 2.55.15\n  dependency-type: direct:production\n  update-type: version-update:semver-patch\n...\n\nSigned-off-by: dependabot[bot] \u003csupport@github.com\u003e"
    },
    {
      "commit": "07c54cb62eaed250041226023fb97db6e20c3309",
      "tree": "597351ab3d00ca20ed3e47a069a7cdae26d95b5d",
      "parents": [
        "a24a1b5f3db11d00b0a44e59acfdf03f3e7979e2"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 10:51:47 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 10:51:47 2026 +0200"
      },
      "message": "CAMEL-23688: camel-jbang - Tests of more commands, and the bugs they found (#27934)\n\nTests for commands and helpers that had none: camel log (tail, grep, find,\nsince, startup, prefix, a log named after the integration), trace (status,\nstart, stop, clear), cmd send (the message, the exit code of the answer, the\nreply file), eval expression in a running integration, cmd sql, cmd\nheap-histogram, get datasource, get sql-trace, infra run and stop, jolokia, the name\nof an integration (ProcessHelper), the user configuration as the default of\nthe options (placeholders, local before global, not for the plugin\ncommands), and the version comparison.\n\nThe bugs they found:\n- cmd send --reply failed with a ClassCastException when the exchange failed\n  with an exception without a message, such as a NullPointerException.\n- get source failed for routes without a source location, and for an answer\n  without routes.\n- Versions compared as text: 3.27.3.1 came after 3.27.4 (the Quarkus\n  platform has four parts), and 4.24.10-SNAPSHOT came after 4.24.10; a\n  pre-release (-SNAPSHOT, -RC1, -M2) now comes before its release and\n  another qualifier after it, as in Maven.\n- jolokia exited 1 for a name that matches no integration or several (the\n  second on stdout); now 3, as hawtio does.\n- config set \u003dvalue stored a value with an empty key: a parameter without a\n  key or a value exits 2 with the error on stderr, and creates no file.\n- dependency list with an unknown --output exits 2.\n- cmd memory-leak --min-size\u003d10B (and a value that is not a size) turned the\n  filter off: 10B is 10 bytes, and a value that is not a size exits 2.\n- camel run of a GitHub repository or a gist skipped .camel.xml files.\n- cmd heap-dump printed the size with the decimal separator of the locale.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "a24a1b5f3db11d00b0a44e59acfdf03f3e7979e2",
      "tree": "7c549d68b74b24254cfcb1e4a1cc3cae55282d2b",
      "parents": [
        "d46d51c245506b866182d16184a76380b0e82df4"
      ],
      "author": {
        "name": "Andrea Cosentino",
        "email": "ancosen@gmail.com",
        "time": "Fri Oct 16 10:29:57 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 10:29:57 2026 +0200"
      },
      "message": "CAMEL-25604, CAMEL-25605, CAMEL-25622: upgrade guide notes for the 4.22.2 and 4.18.6 backports (#27939)\n\nThe camel-mina, camel-mllp and camel-smpp host name verification changes are\nbackported to camel-4.22.x and camel-4.18.x; add their notes to the 4.22.1 to\n4.22.2 and 4.18.5 to 4.18.6 sections, with the same text as in the 4.24 guide.\n\nSigned-off-by: Andrea Cosentino \u003cancosen@gmail.com\u003e\nCo-authored-by: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "d46d51c245506b866182d16184a76380b0e82df4",
      "tree": "ad1c154d86c64b5fa46cd7a67e838d04f93e373a",
      "parents": [
        "c7d3889e053b22d8faf75e0cff12d953b1293564"
      ],
      "author": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Thu Oct 15 15:00:26 2026 +0200"
      },
      "committer": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Fri Oct 16 09:04:01 2026 +0200"
      },
      "message": "CAMEL-25666: Stabilize ConsumeChildrenIT - replace fixed delay with\nAwaitility\n\nThe test shouldAwaitCreationAndGetDataNotification fires 5 ZooKeeper\nmutations in sequence and expects the mock endpoint to receive exactly\n5 messages (1 NodeCreated + 4 NodeChildrenChanged).\n\nThe consumer uses a single-threaded OperationsExecutor: after each\nChildrenChangedOperation fires it must synchronously call getChildren()\nin getResult(), deliver the exchange to the processor, then re-enqueue\na copy of itself via createCopy(), and finally call installWatch() on\nthe new copy to re-register the ZooKeeper watcher before the next event\ncan be captured.\n\nThe original test relied on a 200 ms pre-delay in TestZookeeperClient\n(delay(200) fires before the ZooKeeper mutation, not after). On a slow\nor loaded machine this is not long enough for the consumer to finish\nprocessing + re-registering the watch before the next mutation fires,\ncausing a ZooKeeper NodeChildrenChanged event to be silently dropped.\nThe mock then receives 4 instead of 5 messages.\n\nFix: use Awaitility after each mutation to wait until the mock has\nactually received the corresponding message before triggering the next\none. This guarantees the watch is re-registered before the next event\nfires, making the sequencing deterministic regardless of machine speed.\n\nAlso rename the ZooKeeper node from /grimm to /grimm-ConsumeChildrenIT\nto isolate this test from any other test that might share the same\nZooKeeper server, consistent with the same fix already applied to\nConsumeDataIT and the cluster integration tests.\n\nCo-authored-by: IBM Bob 2.2.1\nSigned-off-by: Aurélien Pupier \u003capupier@ibm.com\u003e\n"
    },
    {
      "commit": "c7d3889e053b22d8faf75e0cff12d953b1293564",
      "tree": "0d8fdd23c19b157407807e21a07c61920a46944b",
      "parents": [
        "cb4b60637046ac383bdfc964160e4b57643a70ff"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 08:41:20 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 08:41:20 2026 +0200"
      },
      "message": "CAMEL-25400: camel-jbang - One helper for child processes and the Maven wrapper (#27933)\n\n- ChildProcess.stopOnExit replaces the 8 copies of the shutdown hook that\n  stops the Maven process of camel run (Spring Boot, Quarkus, an existing\n  project) and camel debug, and then removes the files of the run. It\n  stops the processes Maven started too (the app runs in a JVM of its own,\n  which could outlive Maven), and kills what has not stopped after 30\n  seconds (the hooks waited, and left a process that did not stop).\n- MavenCommand replaces the 9 lookups of the Maven wrapper (mvnw, or\n  mvnw.cmd on Windows, else mvn) in camel run, camel debug and camel\n  kubernetes run.\n- A plugin that cannot be loaded (not found, or too new for the Camel\n  version) ends the command with exit code 1 and the error, instead of\n  System.exit in the middle of the plugin loading, which ended a JVM that\n  embeds the CLI.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "cb4b60637046ac383bdfc964160e4b57643a70ff",
      "tree": "6673020568709c6a054a65767bd3de3e96840602",
      "parents": [
        "7089992f4a977a51eac52f95e67c4f0c5f29edb7"
      ],
      "author": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Thu Oct 15 14:31:32 2026 +0200"
      },
      "committer": {
        "name": "Aurélien Pupier",
        "email": "apupier@ibm.com",
        "time": "Fri Oct 16 08:06:33 2026 +0200"
      },
      "message": "CAMEL-25348: stabilize LumberjackComponentTest using\nFixedLengthFrameDecoder for ACK framing\n\nThe test client\u0027s ACK recorder was vulnerable to both TCP coalescing\n(multiple 6-byte ACK frames arriving in one ByteBuf) and TCP\nfragmentation (one ACK split across two reads). Replace the raw\nSimpleChannelInboundHandler\u003cByteBuf\u003e with a FixedLengthFrameDecoder(6)\nin front of it: Netty reassembles exactly one complete ACK frame per\nchannelRead0 call, regardless of how TCP delivers the bytes.\n\nSigned-off-by: Aurélien Pupier \u003capupier@ibm.com\u003e\nCo-authored-by: IBM Bob 2.2.1\n"
    },
    {
      "commit": "7089992f4a977a51eac52f95e67c4f0c5f29edb7",
      "tree": "6bdb6e5c856e132051b5b9cba9d07f553345cd9e",
      "parents": [
        "2907675a4288579217948cf93f7e4c2d76f4a909"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 07:52:39 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 07:52:39 2026 +0200"
      },
      "message": "CAMEL-25399: camel-jbang - Remaining command exit code and error fixes (#27932)\n\n- harden --url that cannot be reached exits 1, instead of sending the route\n  to a local Ollama.\n- export does not clean the current directory, or one that contains it, as\n  the export directory without --clean-dir: ./, $PWD and .. compared as\n  text with \".\" and deleted the files of the project.\n- doc \u003cname\u003e looks in the catalog of Camel before it downloads the Kamelet\n  catalog (works offline), catalog kamelet uses --repos, and --sort on a\n  row without a description or support level no longer fails.\n- version get shows a configuration with only the kamelets version,\n  version set --reset removes it too, and version list exits 1 when the\n  versions cannot be downloaded.\n- sbom: an unknown --sbom-format or --sbom-output-format exits 2 before\n  exporting (it exited 0 doing nothing), and Maven not finishing in time\n  exits 124 with a message.\n- update run applies --upgradeTimeout (the output was read to the end\n  before the wait) and exits 124 when it is reached.\n- debug does not run the jar of a Spring Boot or Quarkus build that failed.\n- validate yaml/properties with no file to validate exits 3.\n- kubernetes logs exits 3 when no pod shows up and 1 when reading fails,\n  kubernetes run prints the end of the Maven output when the build or\n  deployment fails (it was hidden without --verbose), and a pod that is not\n  running after 10 minutes exits 124.\n- --jvm-args keeps a quoted value with spaces as one argument.\n\ncamel kubernetes run removes the Maven log once Maven has ended.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "2907675a4288579217948cf93f7e4c2d76f4a909",
      "tree": "e259d5cbb5bcf1f40a9504fd014aee98cc802127",
      "parents": [
        "30589ef8d6eeb6d4d01e2c93bb4a196d8b069ac7"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 19:56:58 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Bump parent to 4.24.0-SNAPSHOT and clarify redelivery doc\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "30589ef8d6eeb6d4d01e2c93bb4a196d8b069ac7",
      "tree": "1fe24bc98c501aa799726cef37167f19c7589da3",
      "parents": [
        "d2ec84933cf0482981b88b0821a2245d782ed669"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 17:34:12 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Fix receive mode failure recording and document edge cases\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "d2ec84933cf0482981b88b0821a2245d782ed669",
      "tree": "645a5dbe31af897f6e26e89bdb412cf0bd5417a2",
      "parents": [
        "cbf84d90b2fae4fc7bbcad1b5ac1e8f920c475c7"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 16:53:41 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Only write back new or changed variables after Citrus validation\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "cbf84d90b2fae4fc7bbcad1b5ac1e8f920c475c7",
      "tree": "833e947866dcd959e2559e46e520cd547893b903",
      "parents": [
        "2059cf2a25437bcb0e9980d870d568d7af4a1e4c"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 13:51:22 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Restore name field with accessor overrides and add missing tests\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "2059cf2a25437bcb0e9980d870d568d7af4a1e4c",
      "tree": "f0b9f5625e045de5ff3967e56c14efeee7963fe3",
      "parents": [
        "51013863a91a7e89ebe9592f6a66cc100e0015d6"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 11:15:43 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Remove dead name field and guard supplier against NPE\n\n- Remove shadowing `name` field from CitrusEndpoint — MockEndpoint\n  already declares @UriPath name, and the inherited getName()/setName()\n  handle the runtime value. The local field was never written to.\n- Extract createTestContext() method with null guard to prevent NPE\n  if the supplier is invoked after doStop() nulls citrusContext.\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "51013863a91a7e89ebe9592f6a66cc100e0015d6",
      "tree": "f8647f8d7028cf9f4f3b8b13cc7a2c5bd82f9ddf",
      "parents": [
        "042cbc00e7e269ae67753759697726c0cc055c3b"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 10:44:19 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Address davsclaus review feedback\n\n- Override @UriPath name with Citrus-specific description to prevent\n  inheriting MockEndpoint\u0027s metadata\n- Inject Supplier\u003cTestContext\u003e into CitrusValidationProcessor so specs\n  configured before doStart() (e.g. isUseAdviceWith tests) work correctly\n- Indexed specs imply a minimum expected message count when the test\n  has not set one explicitly\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "042cbc00e7e269ae67753759697726c0cc055c3b",
      "tree": "ddfb9fe413145959694468dcf30dd0434c52bc96",
      "parents": [
        "70984a67070320f7f2e26696ba14d8b3041422a6"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 10:15:02 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Make nextSpecIndex final and allow variable overwrite\n\n- Make nextSpecIndex field final with set(0) in reset() instead of\n  replacing the AtomicInteger reference\n- Allow Citrus-extracted variables to overwrite existing exchange\n  variables so @variable()@ extractions are not silently dropped\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "70984a67070320f7f2e26696ba14d8b3041422a6",
      "tree": "0da10ffc2f98a88bcbc71ac9f3da79a90137df86",
      "parents": [
        "5d8e3d72d783eef6787b30492a160c36f71a52a3"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 09:34:19 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Fix validate() return type and doc inaccuracy\n\n- Fix WhenMessageValidationSpec.validate() to return the correct\n  covariant type so .validate(...).then().respond() chains compile\n- Fix docs: unmatched exchanges pass through silently, not as failures\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "5d8e3d72d783eef6787b30492a160c36f71a52a3",
      "tree": "90350aa60fbed61c0689f2d6b8a7e140ede4ec90",
      "parents": [
        "737a9994c060b3ac9d3b803b50cf12f7662e82b5"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 09:11:24 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Use case-insensitive header validation for Citrus\n\nCamel uses CaseInsensitiveMap for exchange headers, so Citrus header\nvalidation should ignore case to match Camel\u0027s behavior.\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "737a9994c060b3ac9d3b803b50cf12f7662e82b5",
      "tree": "751751c964e0a7f5fc33c9d2c3822da2aaf8a55d",
      "parents": [
        "c91fed0060f3b7b287ae7c9f9fbb44d8bfc67240"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 08:56:40 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Address review feedback on camel-test-citrus\n\n- Handle StreamCache body in buildReceivedMessage to prevent stream\n  drain on pass-through validate operation\n- Filter Citrus-internal variables (citrus.*, CITRUS_*) in\n  writeBackExtractedVariables to avoid polluting exchange variables\n- Fix documentation to use 1-based indexing (matching MockEndpoint)\n- Rewrite receive operation docs to match actual chained API\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "c91fed0060f3b7b287ae7c9f9fbb44d8bfc67240",
      "tree": "7cec7a24e81e08c7529275e0e5efae228e7fdd75",
      "parents": [
        "5587fc57a47e8bfadf52661f64251339ca7b8a32"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Thu Oct 15 08:35:33 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Escape Citrus variable placeholder in adoc to fix website build\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "5587fc57a47e8bfadf52661f64251339ca7b8a32",
      "tree": "1d7ebe43d90a83b8a4bb71b5b06a99fa1733f777",
      "parents": [
        "371e18657eab910f8778b4f5a5132de112245c5c"
      ],
      "author": {
        "name": "Guillaume Nodet",
        "email": "gnodet@gmail.com",
        "time": "Thu Oct 15 06:35:48 2026 +0000"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "Regen\n"
    },
    {
      "commit": "371e18657eab910f8778b4f5a5132de112245c5c",
      "tree": "32015d769c77fdc06e0cc5c7f34833b3c81afd79",
      "parents": [
        "30c38b3f83cb267d2182ae0ad89b723c7281a481"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Wed Oct 14 22:30:17 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Use MockEndpoint processor infrastructure for Citrus validation\n\nLeverage whenExchangeReceived() and whenAnyExchangeReceived() from\nMockEndpoint to dispatch Citrus validation and response logic via\nCitrusValidationProcessor. This replaces the previous custom spec\nresolution and indexing approach.\n\nBenefits:\n- Eliminates custom spec resolution, indexing and state tracking\n- Reuses MockEndpoint\u0027s built-in processor dispatch (indexed and\n  default) for both validation and response handling\n- Simplifies the Gherkin-style API with a fluent\n  when().receive().body().then().respond().body() chain\n- Failure reporting uses performAssertions() to capture processor\n  exceptions from the exchange and add them to the failures list;\n  for validate mode the exception is cleared so it does not\n  propagate through the route\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "30c38b3f83cb267d2182ae0ad89b723c7281a481",
      "tree": "89a63a73bee81739bd5c87ab4e848dfc9e769233",
      "parents": [
        "5b2016dfae5ae07a13a396d033aa0ca54714bc2b"
      ],
      "author": {
        "name": "Guillaume Nodet",
        "email": "gnodet@gmail.com",
        "time": "Wed Oct 14 19:56:16 2026 +0000"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "Regen\n"
    },
    {
      "commit": "5b2016dfae5ae07a13a396d033aa0ca54714bc2b",
      "tree": "1886dd7346fdf6df815dcc311278ef08e8e453ce",
      "parents": [
        "85aad94850991e829f5d72f18fa739f8df342e6f"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Wed Oct 14 20:04:34 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Address review feedback on camel-test-citrus\n\n- Validate operation errors: record failures instead of throwing,\n  reported via assertIsSatisfied() (MockEndpoint pattern)\n- Receive operation: still throws on validation failure\n- Add operation validation in CitrusComponent (reject invalid ops)\n- Add volatile to shared mutable fields for thread safety\n- Reset counters in expectedMessageCount()\n- Auto-derive expected count from indexed specs\n- Add CitrusContext lifecycle management (doStop)\n- Propagate exchange variables (both directions) between Camel/Citrus\n- Use Locale.ROOT for case conversions\n- Switch test dependency to camel-test-junit6\n- Update firstVersion to 4.24.0\n- Add operation enum constraint\n- Improve documentation: Maven dependency snippet, path validation\n  API usage, missing spec error behavior, exchange variables\n- Regenerate catalog and endpoint DSL artifacts\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "85aad94850991e829f5d72f18fa739f8df342e6f",
      "tree": "5a6eec299bebf3af10a6878d85806b64f524bdfa",
      "parents": [
        "1bbffc407dfc16c71f42c1c4b3a317629411d2e1"
      ],
      "author": {
        "name": "Guillaume Nodet",
        "email": "gnodet@gmail.com",
        "time": "Tue Oct 13 21:35:46 2026 +0000"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "Regen\n"
    },
    {
      "commit": "1bbffc407dfc16c71f42c1c4b3a317629411d2e1",
      "tree": "7e1374df5b129da3e81fd2d603485dc16797398f",
      "parents": [
        "7d31f3b0d8c7d7e1aa2335b18f318c254852e0cc"
      ],
      "author": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Tue Oct 06 21:42:56 2026 +0200"
      },
      "committer": {
        "name": "Christoph Deppisch",
        "email": "christoph.deppisch@web.de",
        "time": "Fri Oct 16 07:22:46 2026 +0200"
      },
      "message": "CAMEL-25378: Add camel-test-citrus component for Citrus message validation\n\nIntroduces a new camel-test-citrus component that integrates with the\nCitrus integration test framework for message validation in Camel route\ntests.\n\nValidate operation:\n- Template-based message validation using Citrus validation modules\n  (JSON, XML, YAML, plain text, binary, Hamcrest)\n- Fluent API: allMessages() for uniform validation, message(index)\n  for per-exchange sequential validation with automatic fallback\n- Support for Citrus ignore expressions, validation matchers, and\n  test variable resolution via exchange properties\n- Path validation (JsonPath/XPath) through Citrus validation contexts\n- Auto-detection of message type from body content\n\nReceive operation (request/response simulation):\n- Gherkin-style fluent API: when().message(n).receive() for expected\n  request validation, then().message(n).respond() for simulated\n  response definition\n- Response bodies support Citrus test variables and functions\n- Per-exchange and allMessages() fallback for both request validation\n  and response specs\n- send() alias for respond()\n- Response-only mode (no request validation)\n\nMessage payload builders:\n- body(MessagePayloadBuilder) overload on both validation and response\n  specs, accepting Citrus payload builders (GroovyScriptPayloadBuilder,\n  marshalling builders, custom implementations) and lambdas\n\nCo-Authored-By: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e\n"
    },
    {
      "commit": "7d31f3b0d8c7d7e1aa2335b18f318c254852e0cc",
      "tree": "36b8c78b53c8d8c3eee34223d2fb00d9c89a21c9",
      "parents": [
        "cbfee553a4891738a41f839b19e6406818228306"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 06:14:03 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 06:14:03 2026 +0200"
      },
      "message": "CAMEL-25398: camel-jbang - camel ask, MCP tools and the monitor surface CLI failures to agents (#27931)\n\n- CliRunner runs a CLI command in this JVM and returns CliResult (exit\n  code, stdout and stderr apart, elapsed time, timed out), under one lock\n  that the camel shell (each command) and the AI panel of the monitor take\n  too. The panel\u0027s commands get picocli\u0027s help output captured as well.\n- camel ask cli_exec returns that result as JSON with a 60 second timeout\n  (the exit code was dropped whenever there was output), and refuses a\n  command that runs until it is stopped, with the form that returns\n  (run without --background, --watch without --duration, log following,\n  infra run, shell, debug, tui, ...; export --clean-dir needs --yes).\n- Tool failures are errors (MCP isError): camel_run with status failed, a\n  failed restart, an action the integration answers with an error or does\n  not answer (ToolContext.executeAction), route stop/start/suspend/resume\n  and camel_control stop-routes/start-routes/reset-stats/reload send the\n  action and wait for the confirmation (an integration before 4.24 takes\n  it unconfirmed), camel_runtime_ai_trace no longer reads a failed query\n  as no AI components, and the monitor\u0027s MCP server and AI panel rethrow\n  the errors of shared tools; only an unknown tool is \"Unknown tool\".\n- The monitor watches a restarted Camel Main integration like a launch\n  (failed starts show why, quitting stops it), camel_control restart waits\n  for the outcome, a launch counts as started by the status file of the\n  integration (or its child, for a Maven launch), and a failed\n  tui_run_example is a tool error.\n- docker/podman info and the Ollama monitor\u0027s commands read their output\n  while they run (ExternalCommand), so the timeout holds; camel doctor had\n  none.\n\nA command that timed out while it waited for another one does not run\nafterwards, and the MCP server of the monitor answers a tool error with the\nmessage of the tool as it is.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "cbfee553a4891738a41f839b19e6406818228306",
      "tree": "50ea53600e899d8104398b03326e13f318b55f9b",
      "parents": [
        "ae2e38efecfa3d78c1b5d22ec809578c12cef663"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 04:59:30 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 04:59:30 2026 +0200"
      },
      "message": "CAMEL-25397: camel-jbang - camel run: background startup reporting and early input errors (#27930)\n\n- --background-wait takes how long to wait, such as 2m (default 60s, it was\n  20s); true and false still work, and a file after a bare --background-wait\n  is not taken as its value. An integration still starting after the wait\n  exits with 124 and is left running (it exited with 0).\n- The output of an integration in the background goes to\n  ~/.camel/\u003cpid\u003e-run.log, whose path is printed; it is kept while the\n  integration runs and camel stop removes it. --background-wait\u003dfalse logs\n  to the file too, instead of a pipe that nobody read. camel restart uses\n  the same log.\n- An integration that loads no routes exits with 1 \"No routes found in:\n  ...\" instead of running idle, except with --source-dir, --empty, dev mode\n  and the runs of export and transform.\n- Dev mode with --max-seconds, --max-messages or --max-idle-seconds exits\n  at the limit, rather than only stopping the routes.\n- A file that does not exist exits with 3 \"File does not exist\" for every\n  extension, before the configuration is printed. Files with --source-dir,\n  and --background with a runtime that cannot run in the background, exit\n  with 2.\n\nA process that cannot start leaves no log behind, the end of a log is read\nline by line, keeping only the last lines, and the log of a failed startup\nis read leniently, also when it is not UTF-8.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "ae2e38efecfa3d78c1b5d22ec809578c12cef663",
      "tree": "d0ae6a19d36844d1e6cc24dc99b6570e22c24aed",
      "parents": [
        "f5015f3b201551ac3287abdccc144fd8258f1775"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 03:56:22 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 03:56:22 2026 +0200"
      },
      "message": "CAMEL-25396: camel-jbang - Commands must not hang without a terminal (#27928)\n\nWithout an interactive terminal (a script, a CI job, an AI agent) nobody can\npress Enter, so no command waits for it:\n\n- --watch without --duration shows the output once with a WARN on stderr,\n  and the new --duration option (camel get, top, ps, the cmd actions with\n  --watch, log, trace, cmd receive, infra log) keeps going for that long and\n  exits with 0. Refreshes no longer print screen escape codes into a pipe.\n- camel log, trace and cmd receive do not follow unless --follow or\n  --duration is given; infra log prints the end of the logs and gets\n  --follow. A bare --follow now turns following on (picocli turned a\n  default-true flag off), and infra log stops its tailers when done (the\n  tailer was started twice).\n- camel hawtio opens no browser and prints the URL; --openUrl is now\n  --open-url (the old name still works).\n- camel debug (busy-spun at 100% CPU), nano, shell, edit, tui (except\n  --record and the --web browser sessions), ask without a question,\n  run --prompt and get history --it exit with 2: \"requires an interactive\n  terminal\".\n- The end of the input (Ctrl+D) stops a command that watches or follows, and\n  the terminal check uses Console.isTerminal on Java 22 and later.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "f5015f3b201551ac3287abdccc144fd8258f1775",
      "tree": "42d2d27bce9bb94be497d5add8ff3355a8d88993",
      "parents": [
        "9d4222f80bdaf5fdcd940d66882c248b8caa11a8"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 03:21:33 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 03:21:33 2026 +0200"
      },
      "message": "CAMEL-25395: camel-jbang - camel stop and restart wait and verify (#27927)\n\ncamel stop waits until the integration has stopped, up to --timeout (60s by\ndefault), and exits 124 with a hint to use --kill when it did not stop in\ntime; --no-wait returns at once as before. An integration without a pid file\nis stopped with SIGTERM, which did nothing before. A name or pid that matches\nno running integration exits 3.\n\ncamel restart stops the integration the same way (terminating it when it\ndoes not stop within --timeout) and does not start it again while the old\nprocess is alive (124). It waits until the new integration has started,\nkeeps its output in a log file in ~/.camel and prints the path (the log was\nremoved on exit); a new integration that stops right away prints the end of\nits log and exits 1, one that is still starting after --timeout exits 124.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "9d4222f80bdaf5fdcd940d66882c248b8caa11a8",
      "tree": "3bb8b4ce10e8d17f7e16456fa96c64867289106d",
      "parents": [
        "76c2a6f0d4ab7f9d4403189abaebcc0f114ab477"
      ],
      "author": {
        "name": "Claus Ibsen",
        "email": "claus.ibsen@gmail.com",
        "time": "Fri Oct 16 02:49:02 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Oct 16 02:49:02 2026 +0200"
      },
      "message": "CAMEL-25394: camel-jbang - camel get/top/ps: robust listing and consistent JSON schema (#27926)\n\nThe listings read the integrations with forEachIntegration: a name or pid\nthat matches no running integration exits 3, nothing running prints a note on\nstderr, and a status file a listing cannot read (an older Camel without a\nvalue it needs) skips that integration with a warning instead of failing the\nlisting of all of them.\n\nThe JSON of the listings has numbers as numbers (pid, counters, processing\ntimes, throughput), splits the values that combined several numbers\n(sinceLast, the routes and reload of get context, load, heap, non-heap, gc and\nthreads of top context, the readiness, rate and since of get health), has\nuptime in millis next to age, durations in millis, routeId and status as the\nnames, a boolean ready, and failed instead of fail in ps.\n\nFixes get activity SINCE (subtracted now twice), camel dirty matching pid 12\nto 123-status.json and removing the files of a live process, --limit applied\nbefore sorting in get endpoint/consumer/producer, get processor --limit\ncounting processors, and get health without a name parameter.\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    }
  ],
  "next": "76c2a6f0d4ab7f9d4403189abaebcc0f114ab477"
}
