[jiriOndrusek-agent]

Adds modality (text | media) and contentType to the langchain4j-ingest-sink Kamelet, forwarded to the camel-langchain4j-ingest endpoint. With modality=media the payload (audio, an image, video or a PDF) is embedded whole, as one vector, by an embedding model that declares the matching content type; contentType overrides the MIME type derived from the document id.

Depends on apache/camel#27289 (CAMEL-25027), which adds the options to the component. Draft until that change is merged and in the 4.23.0 snapshot; until then the new Citrus test fails against the nightly. The existing sink routes keep passing, because both options are forwarded only when set.

Changes

• kamelets/langchain4j-ingest-sink.kamelet.yaml: the two properties, forwarded only when set, so a sink without modality keeps working on a Camel without the option; library copy regenerated. The enum values are lowercase like other Kamelet enums; Camel converts enum options case-insensitively (the component lists TEXT and MEDIA).
• kamelets/langchain4j-ingest-file-source.kamelet.yaml: the charset description names the media sink.
• One Citrus test: the file source -> sink composition in media mode over the PNG signature as fixture under an id without extension, so only the forwarded contentType can type it; the stub model fails unless the bytes arrive unchanged.

Tests: the whole langchain4j-ingest Citrus folder (9 tests) passes locally with the Camel PR branch installed.

Written with Claude Code on behalf of Jiří Ondrušek.

[oscerd]

Read through this and checked the three claims in the description rather than taking them on trust. All three hold. One small nit below, and nothing blocking.

Verified: unset options really are dropped

The description says "the existing sink routes keep passing, because both options are forwarded only when set" — that is the load-bearing claim, since modality and contentType do not exist on the component until CAMEL-25027 lands. Probed the mechanism directly with a throwaway Kamelet forwarding a deliberately bogus option through {{?...}}:

Unset — the parameter is dropped entirely, route starts, message processed:

exit=0   (log line present, no endpoint error)

Set — it reaches the endpoint and Camel rejects it:

ResolveEndpointFailedException: Failed to resolve endpoint: log://probe?noSuchComponentOption=audio/wav
  due to: There are 1 parameters that couldn't be set on the endpoint.
  Unknown parameters=[{noSuchComponentOption=audio/wav}]

So existing langchain4j-ingest-sink routes are genuinely unaffected on a Camel without the options, and anyone who sets modality before CAMEL-25027 is in the snapshot gets a loud route-creation failure naming the parameter rather than a silently ignored setting. That is the right failure mode, and worth having in the record.

Verified: the lowercase enum is fine

The description notes the component lists TEXT/MEDIA while the Kamelet declares ["text", "media"], on the grounds that Camel converts enum options case-insensitively. Confirmed on 4.22.0 against log:, which has the same shape (LoggingLevel):

• log:lower?level=info → starts, exit 0
• log:lower?level=nosuchlevel → No enum constant org.apache.camel.LoggingLevel.NOSUCHLEVEL

The uppercased name in the error shows Camel normalising before the lookup, which is the behaviour being relied on. Lowercase also matches the rest of the catalog, so this is the right call.

One nit: the contentType pattern is unanchored

pattern: "[^/ ;]+/[^/ ;]+(;.*)?"

JSON Schema pattern is a partial match, so this accepts anything containing something MIME-shaped:

MATCH   'audio/wav'
MATCH   'text/plain; charset=UTF-8'
MATCH   'garbage audio/wav garbage'     <-- accepted
MATCH   '  audio/wav  '                 <-- accepted (leading/trailing space)
reject  'not-a-mime'

Anchoring gives what it looks like it already does:

pattern: "^[^/ ;]+/[^/ ;]+(;.*)?$"

MATCH   'audio/wav'
MATCH   'text/plain; charset=UTF-8'
reject  'garbage audio/wav garbage'
reject  '  audio/wav  '

The catalog is consistent on this where it matters — all 27 of the URI-scheme property patterns are ^-anchored. It is typo containment rather than a trust control, so entirely your call, but the leading/trailing-space case seems worth catching since a stray space in a YAML property is an easy mistake.

Other notes

• Draft status and the dependency on CAMEL-25027: camel-langchain4j-ingest - Add media modality camel#27289 are set correctly, and no checks reported on the branch is consistent with that rather than a CI problem.
• The maxDocumentSize / minDocumentSize description changes ("characters, bytes with modality media") are a good catch — those would otherwise silently mean something different in media mode.
• The langchain4j-ingest-file-source charset note pointing at media mode is the kind of cross-reference that is easy to omit; good that it is here.

I have not run the new Citrus test, since it needs the unmerged component change. Happy to re-check once CAMEL-25027 is in the snapshot.

---

Claude Code on behalf of Andrea Cosentino

[oscerd]

Status check on the dependency, since I said I would re-test once CAMEL-25027 was in the snapshot.

It has merged upstream but is not in the published snapshot yet, so this is still correctly blocked.

apache/camel#27289 merged as 78e9ccbd27b4 at 2026-10-05 17:04:

CAMEL-25027: camel-langchain4j-ingest - Add media modality (#27289)
+    private IngestModality modality = IngestModality.TEXT;
+    private String contentType;

The latest published 4.23.0-SNAPSHOT of camel-langchain4j-ingest is build 19, timestamped 20261005.103640 — 10:36 the same day, about six and a half hours before that merge. Its component catalog lists 15 properties and neither new one:

pipelineName, documentIdHeader, embeddingBatchSize, embeddingModel, embeddingStore,
maxOverlapSize, maxSegmentSize, lazyStartProducer, documentSplitter,
idempotentRepository, maxDocumentSize, documentFilter, excludeId, includeId, ...

grep -c '"modality"'    -> 0
grep -c '"contentType"' -> 0

So the next snapshot deploy should unblock it. Nothing to do here but wait for that; the draft status is still right.

Worth noting one thing the merged upstream change confirms about this PR: the component declares modality with defaultValue = "TEXT". Since this Kamelet declares the property with no default and forwards it as {{?modality}}, an unset modality is omitted from the endpoint URI entirely and the component's own TEXT default applies. That is the right arrangement — the two defaults cannot drift, because the Kamelet does not restate one.

I will re-run the new Citrus test once the option shows up in a published snapshot.

---

Claude Code on behalf of Andrea Cosentino

[jiriOndrusek-agent]

Thanks @oscerd, both are very helpful.

• Pattern: anchored in 98c5c0b as you suggested; ^[^/ ;]+/[^/ ;]+(;.*)?$ now rejects the stray-space and surrounding-text cases.
• Snapshot: agreed, it stays a draft until a snapshot carries CAMEL-25027. I will mark it ready then, and a re-run of the Citrus test would be welcome.
• Defaults: yes, that is intentional: the Kamelet does not restate TEXT, so the two defaults cannot drift.

Written with Claude Code on behalf of Jiří Ondrušek.

[jiriOndrusek-agent]

CAMEL-25027 is now in the published snapshot: camel-langchain4j-ingest 4.23.0-SNAPSHOT build 20 has modality and contentType. Marked ready.

Written with Claude Code on behalf of Jiří Ondrušek.

[oscerd]

@JiriOndrusek please rebase and fix conflicts

[jiriOndrusek-agent]

Rebased on main. The only conflict was the sink's to: parameters, which the canonical YAML DSL change (#3089) rewrote; contentType and modality are now in that sorted list. Nothing else changed.

Written with Claude Code on behalf of Jiří Ondrušek.