## Issue
Closes#5775
## Context
`OllamaBaseChatModel#init()` rebuilds the model's default
`OllamaChatRequestParameters` by copying fields one by one, but it
omitted seven Ollama-specific fields:
`numThread`, `numKeep`, `typicalP`, `numBatch`, `numGPU`, `mainGPU`,
`useMmap`.
These fields have no shortcut setter on the model builder, so
`defaultRequestParameters(...)` is the only way to configure them as
model-level defaults. Because `init()` dropped them, the values were
silently lost and never sent to Ollama — even though
`OllamaChatRequestParameters#overrideWith(...)` and the wire mapping in
`InternalOllamaHelper#toOllamaChatRequest(...)` already handle all
seven. They therefore worked as per-request overrides but not as model
defaults.
## Change
Copy the seven missing fields in `init()`, matching the field handling
already present in `overrideWith(...)`. The change is purely additive
and does not alter behavior when the fields are unset (they remain
`null`, as today). Both `OllamaChatModel` and `OllamaStreamingChatModel`
benefit (shared `init()`).
## Tests
Added
`OllamaChatModelTest#default_request_parameters_should_preserve_all_ollama_specific_parameters`,
a pure unit test (no running Ollama server) that builds a model with all
Ollama-specific parameters set via `defaultRequestParameters(...)` and
asserts they are preserved on `model.defaultRequestParameters()`. It
fails on `main` (the seven fields are `null`) and passes with this fix.
Existing `OllamaChatRequestParametersTest` and
`InternalOllamaHelperTest` continue to pass.
- [x] Unit tests added, covering the previously-dropped fields (and
guarding the already-copied ones against regression)
- [x] `./mvnw -Pspotless spotless:check` passes
Signed-off-by: wushiyuanmaimob <wushiyuanwork@outlook.com>
## Issue
Closes#1153 — distinguish APIs for embedding queries vs. documents/keys
(adds `EmbeddingInputType.QUERY`/`DOCUMENT` as a per-call parameter,
plus opt-in `embeddingInputType(...)` on
`EmbeddingStoreContentRetriever` / `EmbeddingStoreIngestor`).
Partially addresses #4019 — adds the multimodal image-embedding API at
the core level (`EmbeddingInput` of `Content` parts) and wires Cohere,
Voyage, Jina, Google (Gemini Embedding 2), and Bedrock Titan; does
not implement it for `OnnxEmbeddingModel`.
Relates to #5142 — provider-specific / per-call parameters for OpenAI
embeddings (`OpenAiEmbeddingRequestParameters`: `user`,
`encodingFormat`, `customParameters`; e.g. NVIDIA NIM `input_type` via
custom
parameters).
Relates to #4273 — observability for `EmbeddingModel` via listeners
(`EmbeddingModelListener` + request/response/error contexts, wired
across providers).
## Change
Introduces an `EmbeddingModel.embed(EmbeddingRequest) →
EmbeddingResponse` API, structured like `ChatModel`'s request/response
API, so embeddings can carry **per-call parameters** and **multimodal
inputs** and
participate in **observability**. Everything is additive and
`@Experimental`; the existing `embed(String)` / `embed(TextSegment)` /
`embedAll(List)` methods keep working unchanged.
### Core (`langchain4j-core`)
- New request/response types: `EmbeddingRequest`, `EmbeddingResponse`,
`EmbeddingResponseMetadata`, `EmbeddingRequestParameters` (+
`DefaultEmbeddingRequestParameters` and typed `EmbeddingParameter<T>`
tokens), `EmbeddingInput`, `EmbeddingInputType`.
- New default methods on `EmbeddingModel`: `embed(EmbeddingRequest)`,
`doEmbed(...)`, `defaultRequestParameters()`, `supportedParameters()`,
`supportedContentTypes()`, `provider()`, `listeners()`.
- **Strict opt-in / fail-fast:** per-call parameters and content types
are token/type-checked; a request that uses something the model doesn't
declare is rejected with `UnsupportedFeatureException` instead of
being silently ignored. `overrideWith` preserves the provider-specific
parameters subtype (as on the chat side).
- **Multimodal:** an `EmbeddingInput` is an ordered list of `Content`
parts (text/image); models fuse them into one embedding (or
one-per-item, per provider). Modality is auto-detected — no manual flag.
- **Observability:** `EmbeddingModelListener` + request/response/error
contexts (same shape as `ChatModelListener`), fired inline from
`embed(EmbeddingRequest)`. `addListener(...)` still works.
- **RAG opt-in:** `EmbeddingStoreContentRetriever` and
`EmbeddingStoreIngestor` gain an optional `embeddingInputType(...)`
(QUERY / DOCUMENT). Default behavior is unchanged (no input type sent).
- `ModelProvider`: added `COHERE`, `VOYAGE_AI`, `JINA`, with matching
OpenTelemetry `gen_ai.provider.name` mappings (`cohere` is a well-known
OTel value; `voyage_ai` / `jina` are custom, as permitted by the
spec).
### Providers
- **OpenAI** (dimensions, `user`/`encodingFormat`/custom params),
**Cohere** (Embed v4 multimodal + input types), **Voyage** (multimodal +
input types), **Jina** (CLIP multimodal), **Google AI Gemini** (input
types; **Gemini Embedding 2** multimodal), **Amazon Bedrock Titan**
(multimodal).
- **Google Gen AI** (`langchain4j-google-genai`): input type → SDK
`task_type`, per-call dimensions → `outputDimensionality`, `provider()`,
listeners.
- **Ollama**: text-only — `provider()` + listeners (per-call params
correctly fail fast).
- **In-process models** (ONNX / `AbstractInProcessEmbeddingModel`):
already work via the default `doEmbed→embedAll` bridge (text-only,
image/param requests fail fast); observability via `addListener(...)`.
No
code change (no builders to wire listeners into, no dedicated
`ModelProvider`).
- **Gemini Embedding 2** dropped the `task_type` parameter, so input
types are applied as prompt instructions (`task: search result | query:
…` / `title: none | text: …`) automatically; `gemini-embedding-001`
still uses `task_type`.
- `modelName` in the response metadata reflects the API-reported model
where the provider returns one (OpenAI/Voyage/Jina), falling back to the
configured name.
### Tests
- `AbstractEmbeddingModelIT` — a shared IT base (like
`AbstractChatModelIT`) covering the new API, convenience methods,
listeners, and fail-fast; each provider adds a small
`common/…EmbeddingModelIT` that
parameterizes it and declares its capabilities via `supports*()`
overrides.
- Mock-based unit tests per provider for wire format / routing /
fail-fast (run in CI without keys), plus core value-type and listener
tests.
### Docs
- Embedding-model section in the RAG tutorial (request/response,
multimodal, query-vs-document opt-in), the EmbeddingModel listener
section in the Observability tutorial, the embedding contribution
guidance in
`CONTRIBUTING.md`, and the six provider integration pages.
### Notes
- `EmbeddingResponseMetadata` intentionally has no `finishReason`
(embeddings have no finish reason). No real provider is affected: the
only provider that emits `STOP` (Cloudflare WorkersAI) overrides the
convenience methods directly, and every other provider always returned
`null` here.
- `revapi.json` suppressions were added where the new (non-breaking)
types are exposed in provider APIs.
## General checklist
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [x] I have added/updated the documentation
- [ ] I have manually run all the unit and integration tests in the core
and main modules, and they are all green
- [ ] I have added an example in the examples repo (only for "big"
features)
- [ ] I have added/updated Spring Boot starter(s) (if applicable)
---------
Co-authored-by: agent <agent@langchain4j.dev>
## Issue
Closes#5116
## Change
Adds a new **`onUnmappedRawEvent`** streaming callback that gives
advanced users access to provider streaming events that LangChain4j does
**not** map to one of its typed callbacks — e.g. OpenAI server-tool
lifecycle events (`response.web_search_call.in_progress` / `searching` /
`completed`). This is an escape hatch so power users don't have to fall
back to a provider's native SDK for events we don't model yet.
**API** (both `@Experimental`, `@since 1.17.0`, `default` so nothing
breaks):
- `StreamingChatResponseHandler.onUnmappedRawEvent(Object rawEvent)` —
low-level API
- `TokenStream.onUnmappedRawEvent(Consumer<Object> rawEventHandler)` —
AI Services API
**Semantics — no duplication.** The callback fires **only** for events
that were *not* already delivered via a typed callback
(`onPartialResponse`, `onPartialThinking`, `onPartialToolCall`,
`onCompleteToolCall`, `onCompleteResponse`). So you can consume the
typed callbacks and the raw stream together without seeing the same
event twice. This is enforced by a small internal
`MappingTrackingStreamingChatResponseHandler` that records whether an
event was mapped to a typed callback (`wasMapped()`), and providers emit
the raw event only when it wasn't.
> Naming note: it's called `onUnmappedRawEvent` (not `onRawEvent`) to
leave room for a planned follow-up that also exposes the raw event
behind *mapped* callbacks (e.g. `PartialToolCall.rawEvent()`), giving a
clean mapped/unmapped split.
**The concrete `rawEvent` type is provider-specific:**
| Provider | Raw event type |
|---|---|
| OpenAI, Anthropic, Google AI Gemini, Mistral, Ollama |
`dev.langchain4j.http.client.sse.ServerSentEvent` |
| OpenAI (official) – Responses API |
`com.openai.models.responses.ResponseStreamEvent` |
| OpenAI (official) – Chat Completions API |
`com.openai.models.chat.completions.ChatCompletionChunk` |
| Amazon Bedrock |
`software.amazon.awssdk.services.bedrockruntime.model.ConverseStreamOutput`
|
| Google GenAI | `com.google.genai.types.GenerateContentResponse` |
**Providers wired:** OpenAI (Chat Completions + Responses),
OpenAI-official (Chat Completions + Responses), Anthropic, Google AI
Gemini, Google GenAI, Amazon Bedrock, Mistral, Ollama.
**Docs:** added a "Unmapped Raw Events" section to
`response-streaming.md` and the callback to the `TokenStream` example in
`ai-services.md`.
## General checklist
- [x] There are no breaking changes (API, behaviour) — all additions are
`default` and `@Experimental`
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases — i.e. unmapped
events are forwarded *and* typed (text/tool) events are **not** repeated
as raw events
- [x] I have manually run all the unit and integration tests in the
module(s) I have added/changed, and they are all green
- [x] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [x] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
Extend SpyingHttpClient to capture HTTP responses and SSE events, then
use it to verify raw response content in Ollama thinking mode tests,
completing 4 TODOs.
Changes to SpyingHttpClient:
- Add responses list to capture SuccessfulHttpResponse from sync calls
- Add sseEvents list to capture SSE event data from streaming calls
- Wrap ServerSentEventListener to intercept events before delegation
Changes to Ollama tests:
- OllamaChatModelThinkingIT: add SpyingHttpClient to 2 tests and verify
raw HTTP response contains/does not contain 'thinking' field
- OllamaStreamingChatModelThinkingIT: add SpyingHttpClient to 2 tests
and verify raw SSE events contain/does not contain 'thinking' field
---
## Issue
Closes # (discovered via code audit)
## Change
Extend `SpyingHttpClient` to capture HTTP responses and SSE events, then
use it to verify raw response content in Ollama thinking mode tests.
**SpyingHttpClient enhancements:**
- Add `responses` list to capture `SuccessfulHttpResponse` from sync
calls
- Add `sseEvents` list to capture SSE event data from streaming calls
- Wrap `ServerSentEventListener` to intercept events before delegation
**Test changes:**
- `OllamaChatModelThinkingIT`: add `SpyingHttpClient` to 2 tests and
verify raw HTTP response contains/does not contain "thinking" field
- `OllamaStreamingChatModelThinkingIT`: add `SpyingHttpClient` to 2
tests and verify raw SSE events contain/does not contain "thinking"
field
**Completed TODOs:**
- `OllamaChatModelThinkingIT.java:102` — verify raw HTTP response
contains "thinking" field
- `OllamaChatModelThinkingIT.java:133` — verify raw HTTP response does
not contain "thinking" field
- `OllamaStreamingChatModelThinkingIT.java:130` — verify raw SSE events
contain "thinking" field
- `OllamaStreamingChatModelThinkingIT.java:169` — verify raw SSE events
do not contain "thinking" field
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green — *requires Ollama
running locally*
- [ ] I have added/updated the documentation
## Issue
Closes#5578
## Change
`OllamaDateDeserializer.deserialize()` extracted the fractional-second
run and called `date.replaceAll(nanoseconds, "")`.
`replaceAll` treats its first argument as a regex and removes every
occurrence in the whole string, not just the fractional part.
Ollama trims trailing zeros from its Go `RFC3339Nano` timestamps, so a
short run such as `.54` or `.04` can collide with a digit pair in the
date or time fields.
For `2024-08-04T00:54:54.54+02:00` the run `54` is stripped everywhere,
yielding `2024-08-04T00::.+02:00`, and `OffsetDateTime.parse` throws
`DateTimeParseException`.
This breaks `OllamaModels.availableModels()`, `runningModels()`, and
`modelCard()` on normal input.
The method body becomes:
```java
return OffsetDateTime.parse(p.getText()).withNano(0);
```
`OffsetDateTime.parse` defaults to `ISO_OFFSET_DATE_TIME`, which
natively parses 0-9 fractional digits plus `Z`/`+`/`-` offsets, so the
string manipulation is unnecessary.
`.withNano(0)` keeps the existing contract that sub-second precision is
dropped.
The now-unused `DateTimeFormatter` import is removed and the stale class
comment updated.
Added regression tests for short fractional seconds with offset and with
`Z` (which the old code corrupted) and a no-fractional-second case. The
three existing tests are unchanged, confirming backward compatibility.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [ ] The tests cover both positive and negative cases <!-- All new
tests are positive (valid timestamps that previously crashed now parse
correctly); this is a parse fix, not a validation guard, so there is no
invalid-input-rejection case. -->
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
<!-- Checklist for new maven module / embedding store: not applicable
(single-file bug fix). -->
## Pre-check notes
- Unit tests on JDK17: `OllamaDateDeserializerTest` 6 tests pass (3
original + 3 new); full `langchain4j-ollama` module 39 tests pass.
- `*IT` (Testcontainers/Ollama) not run — they need Docker + a running
Ollama and are skipped by `clean test`.
- Spotless: the touched files were pre-palantir, so `spotless:apply`
reformatted them in full (import ordering, blank lines) per
`ratchetFrom=origin/main` — CI-required, not hand edits. `spotless:check
-pl langchain4j-ollama` → BUILD SUCCESS.
## Summary
Fixes#5107
When Ollama encounters an error during streaming, it returns a simple
JSON error response:
```json
{"error":"an error was encountered while running the model"}
```
([Ollama docs: Errors that occur while
streaming](https://docs.ollama.com/api/errors#errors-that-occur-while-streaming))
Currently, `OllamaChatResponse` and `CompletionResponse` use
`@JsonIgnoreProperties(ignoreUnknown = true)`, which silently drops the
`error` field. The parsed object ends up with all null fields, and the
null message check in `OllamaClient` returns without ever calling
`handler.onError()`. The streaming handler never learns the request
failed.
## Changes
- Added `error` field to `OllamaChatResponse` and `CompletionResponse`
- Added error detection in `OllamaClient.streamingChat()` and
`streamingCompletion()` — checks for error before processing the
response
- Created `OllamaStreamingException` (follows the same pattern as
`AnthropicStreamingException`)
- Added 2 unit tests using MockWebServer:
- Error-only response — verifies `onError()` is called
- Partial response then error — verifies partial content is received AND
error is propagated
## Test plan
- [x] `mvn test -pl langchain4j-ollama
-Dtest="OllamaStreamingErrorTest"` — 2/2 pass
- [x] `mvn test -pl langchain4j-ollama -Dtest="!*IT"` — 22/22 pass (all
unit tests)
- [x] `mvn spotless:check -pl langchain4j-ollama` — formatting clean
---------
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
## Issue
Closes#5163
## Change
Adds `Content-Type: application/json` to Ollama streaming
`/api/generate` and `/api/chat` requests.
The non-streaming Ollama request paths already set the JSON content
type, but the streaming request paths did not. When those requests are
sent through Spring RestClient, the JSON body is written as a `String`;
without an explicit JSON content type, Spring can encode it as
`text/plain;charset=ISO-8859-1`, which can replace non-ASCII characters
with `?`.
This keeps the existing custom header behavior intact: custom headers
are still applied after the default `Content-Type`, so users can
override it if needed.
## Test Plan
- `./mvnw -pl langchain4j-ollama -DskipITs verify`
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
- [ ] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
## Issue
Closes#5153
## Change
Adds experimental Ollama image generation support.
Summary:
- Add `OllamaImageModel`, implementing `ImageModel` through Ollama's
native `/api/generate` endpoint.
- Add the experimental image-generation request fields `width`,
`height`, and `steps` to `CompletionRequest`.
- Add the generated image response field `image` to
`CompletionResponse`.
- Send `seed` through Ollama `options.seed`, matching Ollama's current
request handling.
- Add unit coverage for request serialization, response mapping,
validation, experimental annotation, and missing-image responses.
- Add documentation for the experimental Ollama image model.
Scope:
- This PR is intentionally limited to Ollama's experimental
text-to-image path.
- It does not add image editing, multiple-image generation,
OpenAI-compatible image endpoints, web search/fetch, model
recommendations, negative prompts, or streaming progress fields.
- Spring Boot starter support is not included here because starters live
in the separate `langchain4j-spring` repository, and experimental image
model integrations do not appear to be added there immediately in all
cases. This can be handled as a follow-up if maintainers prefer.
## Test Plan
- `./mvnw -B -pl langchain4j-ollama -DskipOllamaITs
-DembeddingsSkipCache -Dtinylog.writer.level=info verify`
- `./mvnw -B -pl langchain4j-core -DskipITs -Drevapi.skip=true test`
- `./mvnw -B -pl langchain4j -DskipITs -Drevapi.skip=true test`
- `npm run build` from `docs/`
- `git diff --check`
- `./mvnw -pl langchain4j-ollama -Pspotless spotless:check` in a regular
checkout
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [X] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
Closes#3333.
## Summary
- align the existing `OllamaModelCard` response DTO with the
`ShowResponse` linked in #3333
- add missing response fields: `system`, `messages`, `projector_info`,
`tensors`, and `details.parent_model`
- add typed nested DTOs for model-card messages, tool calls, and tensors
- cover full and partial JSON mapping plus builder behavior
## Scope
This PR is intentionally limited to the existing Ollama model info
response path. It does not add request-side options, and it does not
chase newer Ollama fields outside the `ShowResponse` linked in the
issue.
## Test Plan
- `./mvnw -pl langchain4j-ollama -am
-Dtest=OllamaModelCardTest,RunningOllamaModelTest
-Dsurefire.failIfNoSpecifiedTests=false test`
<!--
Thank you so much for your contribution!
Please fill in all the sections below.
Please open the PR as a draft initially. Once it is reviewed and
approved, we will ask you to add documentation and examples.
Please note that PRs with breaking changes or without tests will be
rejected.
Please note that PRs will be reviewed based on the priority of the
issues they address.
We ask for your patience. We are doing our best to review your PR as
quickly as possible.
Please refrain from pinging and asking when it will be reviewed. Thank
you for understanding!
-->
## Issue
<!-- Please specify the ID of the issue this PR is addressing. For
example: "Closes #1234" or "Fixes #1234" -->
This PR adds support for several additional options in
`OllamaChatRequestParameters` to provide more fine-grained control over
Ollama models.
https://github.com/ollama/ollama/blob/main/docs/api.md#request-8https://github.com/ollama/ollama/blob/main/api/types.go
These parameters are implemented based on the Ollama API type
definitions, as the documentation currently lacks exhaustive
explanations.
## Change
<!-- Please describe the changes you made. -->
* Added fields, getters, and builder methods for the new parameters in
`OllamaChatRequestParameters` and `Options`.
* Updated `InternalOllamaHelper` to correctly map these new parameters
when converting to `OllamaChatRequest`.
* Added unit tests in `OllamaChatRequestParametersTest` to verify
builder logic and `overrideWith` behavior. (Generated by Gemini)
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Before adding documentation and example(s) (below), please wait
until the PR is reviewed and approved. -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
## Issue
Closes#4967
## Change
Adds `numThread` parameter to `OllamaChatRequestParameters` so users on
CPU-only machines can control the number of threads used during
inference.
Changes:
- `OllamaChatRequestParameters` — added `numThread` field, accessor,
builder method with Javadoc, `equals`/`hashCode`/`toString`, and
`overrideWith` support
- `Options` — added `numThread` field, getter/setter, and builder method
(this is the DTO serialized to the Ollama REST API)
- `InternalOllamaHelper` — wired `numThread` from
`OllamaChatRequestParameters` into `Options`
- `OllamaChatRequestParametersTest` — added 6 unit tests covering
builder, null default, `overrideWith` (both directions),
`equals`/`hashCode`, and `toString`
## General checklist
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
---------
Co-authored-by: Gorre Surya <sgorre92@gmail.com>
## Issue
Closes https://github.com/langchain4j/langchain4j/issues/3804
Closes https://github.com/langchain4j/langchain4j/issues/3320
## Change
- Integrate https://revapi.org/ (`revapi-maven-plugin`) into the build
to automatically detect breaking API changes
- Revapi runs during the `verify` phase on every build, comparing the
current code against the latest released version on Maven Central
(`RELEASE`)
- Suppress `java.method.varargOverloadsOnlyDifferInVarargParameter`
globally — this is a design warning about varargs overloads, not an
actual breaking change
- Add per-module `revapi.json` justifications for pre-existing
`java.class.nonPublicPartOfAPI` warnings in `langchain4j-ollama`,
`langchain4j-bedrock`, `langchain4j-onnx-scoring`, and
`langchain4j-google-ai-gemini` — these are package-private classes
exposed through protected members on package-private base classes, so
they cannot actually leak to external
users
- Do not check depndencies - we do not expose them explicitly and are
not responsible for any changes there
- skip `integration-tests` modules - we do not release them
### How it works
- Revapi downloads the latest released JAR from Maven Central and
compares it against the locally built JAR at the bytecode level
- Any removal, signature change, or visibility reduction of public API
elements will fail the build
- Adding new public API is always fine
- To justify an intentional breaking change, add a `revapi.json` in the
module root — justifications auto-expire on the next release since the
baseline moves forward
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [X] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Summary
Adds support for the `dimensions` field in Ollama embedding requests.
This change enhances `EmbeddingRequest` to include an optional
`dimensions` property, allowing callers to request embeddings with a
custom output vector size for models that support configurable
dimensions.
Example request payload:
```json
{
"model": "all-minilm",
"input": [
"Why is the sky blue?",
"What is the best place to visit in summer"
],
"dimensions": 2
}
---------
Co-authored-by: Harikrishna <harikrishna.gurram@walmart.com>
## Issue
Closes#4833
## Change
This PR adds the missing `contextLength` field to `RunningOllamaModel`
so the `context_length` value returned by Ollama `/api/ps` is preserved
instead of being silently dropped during deserialization.
Changes included:
- add `contextLength` field, getter/setter, and builder support to
`RunningOllamaModel`
- add a unit test to verify `context_length` is deserialized from the
running models response
- extend the existing `OllamaModelsIT` assertion to check that
`contextLength` is present for running models
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [ ] The tests cover both positive and negative cases
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
- [ ] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
Signed-off-by: ZhangDT-sky <485918776@qq.com>
## Issue
Closes https://github.com/langchain4j/langchain4j/issues/4652
## Change
- Add support for `@Tool`-annotated methods to return multimodal content
(images) to the LLM, not just text. Tools can now return `Image`,
`ImageContent`, `Content`, `List<Content>`, `Content[]`, etc.
- Refactor `ToolExecutionResultMessage` to store `List<Content>`
internally instead of a plain `String`, with backward-compatible
`text()` accessor and new `contents()` / `hasSingleText()`
methods.
- Refactor `ToolExecutionResult` to support
`resultContents(List<Content>)` as an alternative to
`resultText(String)` and `resultTextSupplier(Supplier)`.
- Implement multimodal tool result mapping for providers that support
it: Anthropic, Amazon Bedrock, and Google AI Gemini.
- Add `UnsupportedFeatureException` guards in providers that do not
support non-text tool results: Azure OpenAI, GitHub Models, Jlama,
Mistral AI, Ollama, OpenAI (Chat Completions
& Responses), Vertex AI (Anthropic & Gemini), Watsonx, and Workers AI.
- Update `ToolExecutedEvent` / `DefaultToolExecutedEvent` to carry
`resultContents` alongside the existing `resultText` accessor.
- Add comprehensive unit and integration tests
(`should_execute_tool_returning_Image`,
`should_execute_tool_returning_ImageContent`,
`should_execute_tool_returning_ContentList`,
`should_fail_when_tool_returns_image_and_provider_does_not_support_it`).
- Update tools documentation with new "Returning Images and Multimodal
Content" and "Multimodal Tool Results" sections.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [X] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [X] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Issue
Closes#4839
## Change
This PR replaces the reported `Stream.toList()` usages with
`Collectors.toList()` in the affected Android crash paths.
I manually verified the targeted tests for the affected Ollama and
Gemini paths and confirmed the fix locally.
Changes included:
- Replaced `Stream.toList()` in Ollama's `InternalOllamaHelper`
- Replaced `Stream.toList()` in Gemini's `PartsAndContentsMapper`
- Added a unit test for `InternalOllamaHelper.toToolExecutionRequests`
This keeps the behavior unchanged while improving compatibility with
Android runtimes that do not support `Stream.toList()`.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
- [ ] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
## Issue
Closes#4720
## Change
Ollama has been returning `id` in `/api/chat` tool calls since
[v0.12.10](https://github.com/ollama/ollama/releases/tag/v0.12.10) (Nov
2025,
[ollama/ollama#12732](https://github.com/ollama/ollama/pull/12732)), but
`ToolCall` class lacked the `id` field. Combined with
`@JsonIgnoreProperties(ignoreUnknown = true)`, the `id` was silently
discarded during deserialization.
This PR adds `id` support across all three code paths:
- **Non-streaming** (`InternalOllamaHelper.toToolExecutionRequests`):
propagate `id` from `ToolCall` to `ToolExecutionRequest`
- **Streaming** (`OllamaClient.streamingChat`): pass `id` to
`ToolCallBuilder`
- **Reverse mapping** (`InternalOllamaHelper.otherMessages`): carry `id`
back from `ToolExecutionRequest` to `ToolCall`
The change is backward-compatible — for older Ollama versions that don't
return `id`, the field stays `null`, preserving existing behavior.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
<!--
Thank you so much for your contribution!
Please fill in all the sections below.
Please open the PR as a draft initially. Once it is reviewed and
approved, we will ask you to add documentation and examples.
Please note that PRs with breaking changes or without tests will be
rejected.
Please note that PRs will be reviewed based on the priority of the
issues they address.
We ask for your patience. We are doing our best to review your PR as
quickly as possible.
Please refrain from pinging and asking when it will be reviewed. Thank
you for understanding!
-->
## Issue
<!-- Please specify the ID of the issue this PR is addressing. For
example: "Closes #1234" or "Fixes #1234" -->
Closes#1599
## Change
<!-- Please describe the changes you made. -->
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [x] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Before adding documentation and example(s) (below), please wait
until the PR is reviewed and approved. -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
## Issue
Follow-up to #4403
Applying the same `Supplier<Map<String, String>>` pattern to Ollama
module
## Change
Add `Supplier<Map<String, String>>` support for `customHeaders` in
`langchain4j-ollama` module.
### Problem
OAuth2 tokens expire, requiring model rebuild - impractical for
production use.
### Solution
```java
// Before: fixed at build time
.customHeaders(Map.of("Authorization", "Bearer " + token))
// After: fresh on each request
.customHeaders(() -> Map.of("Authorization", "Bearer " + tokenProvider.getToken()))
```
### Modified files
- `OllamaClient.java` - Add Supplier field and `buildRequestHeaders()`
helper
- `OllamaBaseChatModel.java` - Add Supplier overload (covers ChatModel &
StreamingChatModel)
- `OllamaEmbeddingModel.java` - Add Supplier overload
- `OllamaLanguageModel.java` - Add Supplier overload
- `OllamaStreamingLanguageModel.java` - Add Supplier overload
- New test: `OllamaCustomHeadersSupplierTest.java`
## General checklist
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [x] I have manually run all the unit and integration tests in the core
and main modules, and they are all green
- [ ] I have added/updated the documentation
- [ ] I have added an example in the examples repo (only for "big"
features)
- [ ] I have added/updated Spring Boot starter(s) (if applicable)
<!--
Thank you so much for your contribution!
Please fill in all the sections below.
Please open the PR as a draft initially. Once it is reviewed and
approved, we will ask you to add documentation and examples.
Please note that PRs with breaking changes or without tests will be
rejected.
Please note that PRs will be reviewed based on the priority of the
issues they address.
We ask for your patience. We are doing our best to review your PR as
quickly as possible.
Please refrain from pinging and asking when it will be reviewed. Thank
you for understanding!
-->
## Issue
<!-- Please specify the ID of the issue this PR is addressing. For
example: "Closes #1234" or "Fixes #1234" -->
Closes#3437
## Change
<!-- Please describe the changes you made. -->
Allow customers to discover available models and their capabilities
programmatically without visiting provider websites.
Core Infrastructure (langchain4j-core):
- Added ModelDiscovery interface for unified model discovery API
- Added ModelDescription class for standardized model metadata
- Added ModelType enum (CHAT, EMBEDDING, IMAGE_GENERATION, etc.)
- Added ModelDiscoveryFilter for filtering models by type, capabilities,
context window, etc.
- Added ModelPricing class for model pricing information
- Created comprehensive unit tests for all core classes
- Created AbstractModelDiscoveryIT base class for provider integration
tests
OpenAI Implementation (langchain4j-open-ai):
- Extended OpenAiClient with listModels() method for GET /v1/models
endpoint
- Added ModelsListResponse and OpenAiModelInfo API response classes
- Implemented OpenAiModelDiscovery with client-side filtering support
- Follows existing OpenAI builder pattern and conventions
Anthropic Implementation (langchain4j-anthropic):
- Implemented AnthropicModelDiscovery with static model registry
- Includes Claude 3.5 Sonnet, Haiku, Opus and Claude 3 models
- Provides complete pricing and capability metadata
- Supports client-side filtering
Key Features:
- Unified API across all providers
- Flexible filtering by type, capabilities, context window, name pattern
- Builder pattern consistent with existing LangChain4j conventions
- Immutable data structures for thread safety
- No breaking changes to existing APIs
- Comprehensive test coverage
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [ ] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Before adding documentation and example(s) (below), please wait
until the PR is reviewed and approved. -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
<!--
Thank you so much for your contribution!
Please fill in all the sections below.
Please open the PR as a draft initially. Once it is reviewed and
approved, we will ask you to add documentation and examples.
Please note that PRs with breaking changes or without tests will be
rejected.
Please note that PRs will be reviewed based on the priority of the
issues they address.
We ask for your patience. We are doing our best to review your PR as
quickly as possible.
Please refrain from pinging and asking when it will be reviewed. Thank
you for understanding!
-->
## Issue
<!-- Please specify the ID of the issue this PR is addressing. For
example: "Closes #1234" or "Fixes #1234" -->
Closes#4237
## Change
- Replace identity comparison (`==`) with type comparison in
`InternalOllamaHelper.toOllamaResponseFormat()`:
- `responseFormat == ResponseFormat.TEXT` → `responseFormat.type() ==
ResponseFormatType.TEXT`
- `responseFormat == ResponseFormat.JSON` → `responseFormat.type() ==
ResponseFormatType.JSON`
- Add tests for explicitly built `JSON` and `TEXT` response formats in
`OllamaStructuredOutputIT`
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [x] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Before adding documentation and example(s) (below), please wait
until the PR is reviewed and approved. -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
<!--
Thank you so much for your contribution!
Please fill in all the sections below.
Please open the PR as a draft initially. Once it is reviewed and
approved, we will ask you to add documentation and examples.
Please note that PRs with breaking changes or without tests will be
rejected.
Please note that PRs will be reviewed based on the priority of the
issues they address.
We ask for your patience. We are doing our best to review your PR as
quickly as possible.
Please refrain from pinging and asking when it will be reviewed. Thank
you for understanding!
-->
## Issue
<!-- Please specify the ID of the issue this PR is addressing. For
example: "Closes #1234" or "Fixes #1234" -->
Closes#2410Closes#3871
Replaces #2411
## Change
<!-- Please describe the changes you made. -->
Allows to set custom `ChatRequestParameters` when calling chat method on
`AiServices` interface.
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Before adding documentation and example(s) (below), please wait
until the PR is reviewed and approved. -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
---------
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
github-actions[bot]