…ects
The loadDocuments() method only fetched the first page of results (max
1000 objects) from Tencent COS. This is a follow-up to #5662 which fixed
the same issue in AmazonS3DocumentLoader.
Use a while-loop with isTruncated() and listNextBatchOfObjects() to
iterate through all pages, matching the pattern already used by
AmazonS3DocumentLoader and GoogleCloudStorageDocumentLoader.
<!--
Thank you so much for your contribution!
Please fill in all the sections below.
Please open the PR as ready for review (not as a draft), with tests and
documentation already included.
Please note that PRs with breaking changes, or without tests and
documentation, 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 #
## Change
<!-- Please describe the changes you made. -->
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] There are no breaking changes (API, behaviour)
- [ ] 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
- [ ] 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)
- [ ] 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#5683
## Change
`GitHubDocumentLoader.fromGitHub()` wrapped an `IOException` using an
SLF4J `{}` placeholder. `RuntimeException(String, Throwable)` never
substitutes `{}`, so the message leaked a literal `{}` and dropped the
failing file's URL. The fix concatenates `content.getHtmlUrl()`,
matching the sibling message on line 210:
```java
throw new RuntimeException("Failed to load document from GitHub: " + content.getHtmlUrl(), ioException);
```
Control flow, return value, and exception type are unchanged; backward
compatible.
Added `GitHubDocumentLoaderTest` (the module's first unit test): it
injects a mock `GitHub` via the `GitHubDocumentLoader(GitHub)`
constructor, forces `GHContent.read()` to throw, and asserts the message
contains the URL and not `{}` (positive and negative).
## 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
and main modules, and they are all green <!-- N/A: change isolated to
github document-loader module -->
- [ ] I have added/updated the documentation <!-- N/A: no public
API/behavior contract change -->
- [ ] I have added an example in the examples repo <!-- N/A: bug fix,
not a feature -->
- [ ] I have added/updated Spring Boot starter(s) <!-- N/A: not
applicable -->
## Build / test evidence
- `./mvnw -pl document-loaders/langchain4j-document-loader-github -am
clean test` (JDK 17): GitHubDocumentLoaderTest 1 run, 0 failures. IT
skipped (`@EnabledIfEnvironmentVariable` GITHUB_TOKEN absent).
- Spotless verified via MAIN_ROOT `spotless:apply` (jgit `ratchetFrom`
cannot open a git worktree's file-based `.git`): no reformatting of
either file.
## Issue
Closes#5672
## Change
`GcsSource` built its metadata by calling `metadata.put("contentType",
blob.getContentType())`. `Blob.getContentType()` is nullable, and core
`Metadata.put(String, String)` rejects null with an
`IllegalArgumentException`. Loading a valid, non-empty object without a
content type therefore failed: `loadDocument()` threw, and
`loadDocuments()` caught the exception and silently skipped the object.
This change skips the `contentType` key when `getContentType()` returns
null, so the key is absent rather than holding a meaningless `"null"`
string. The sibling `AzureBlobStorageSource` already guards its metadata
(via `String.valueOf`); this brings the GCS loader in line. Scope is
limited to the `contentType` line.
Added `GcsSourceTest` with a Mockito-mocked `Blob`: a regression case
(null content type builds successfully, key absent) and a positive case
(`text/plain` preserved).
## 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
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)
## Issue
Closes#5670
## Change
`SeleniumDocumentLoader.load(String url, DocumentParser)` encoded the
fetched page content with `pageContent.getBytes()`, using the
platform-default charset. `TextDocumentParser` decodes those bytes as
UTF-8 by default, so on a JVM whose default charset is not UTF-8 (Java
17 target, before JEP 400) non-ASCII page content was corrupted after
parsing.
This encodes explicitly with UTF-8, matching the parser's default
decoding and the repo convention (`Utils.java`, `UriUtils.java` already
use `getBytes(StandardCharsets.UTF_8)`):
```java
documentParser.parse(new ByteArrayInputStream(pageContent.getBytes(StandardCharsets.UTF_8)));
```
The change is limited to that one line plus the `StandardCharsets`
import. `load(String url)` is untouched: it wraps the raw string via
`Document.from(String, Metadata)` and never round-trips through bytes.
Added a credential-free unit test that mocks `WebDriver`, feeds
non-ASCII page content, captures the bytes the parser receives, and
asserts they equal the UTF-8 encoding — locking the contract
deterministically on any default charset.
Series probe: the sibling `PlaywrightDocumentLoader` has the identical
`getBytes()` pattern and is intentionally left for a follow-up PR once
this one merges.
## 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
<!-- The added unit test asserts UTF-8 bytes (positive path) and the
metadata contract; the platform-default path was the bug being fixed.
-->
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
<!-- New unit test passes. The pre-existing SeleniumDocumentLoaderIT is
Testcontainers/browser-gated and was not run locally. -->
- [ ] 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
<!-- N/A — change is isolated to the selenium document-loader module.
-->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
<!-- N/A — bug fix, no doc change; per CONTRIBUTING, docs added after
review. -->
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
<!-- N/A — not a big feature. -->
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
<!-- N/A — no Spring Boot starter for this module. -->
<!-- Checklist for adding new maven module: omitted — no new module. -->
<!-- Checklist for new/changed embedding store integration: omitted —
not an embedding store. -->
## Issue
Closes#5667
## Change
Add `loadDocuments(String containerName, String prefix, DocumentParser
parser)` to `AzureBlobStorageDocumentLoader`. It lists blobs with `new
ListBlobsOptions().setPrefix(prefix)`, so only blobs whose names start
with `prefix` are loaded.
The existing `loadDocuments(containerName, parser)` now delegates with
`prefix = null`. The Azure SDK's no-arg `listBlobs()` already uses a
default `ListBlobsOptions` with a null prefix, so `setPrefix(null)`
lists all blobs exactly as before. No behavior change, no breaking
change.
This brings the Azure loader in line with `AmazonS3DocumentLoader` and
`TencentCosDocumentLoader`, which already offer a prefix overload.
```java
public List<Document> loadDocuments(String containerName, String prefix, DocumentParser parser) {
ListBlobsOptions options = new ListBlobsOptions().setPrefix(prefix);
blobServiceClient.getBlobContainerClient(containerName).listBlobs(options, null).forEach(...);
}
```
## Testing
Added two tests to `LocalAzureBlobStorageDocumentLoaderIT` (Azurite
Testcontainers): `should_load_documents_with_prefix` asserts a matching
prefix returns only the matching blob, and
`should_return_empty_list_when_prefix_matches_no_blobs` asserts a
non-matching prefix returns an empty list. The existing
`should_load_multiple_documents` confirms the no-arg overload still
returns all blobs.
`./mvnw -pl
document-loaders/langchain4j-document-loader-azure-storage-blob -am
clean test` passes (module tests are Testcontainers ITs run via
failsafe; test sources compile). The Azurite IT was not executed locally
because Docker was unavailable in this environment.
## 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
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)
<!-- Not adding a new maven module or embedding store integration: those
checklist sections are omitted. -->
## Issue
<!-- Update with the real issue number once the bug report above is
filed. -->
Closes#5661
## Change
`AmazonS3DocumentLoader.loadDocuments` called
`s3Client.listObjectsV2(request)` once, reading only the first response.
S3 ListObjectsV2 returns at most 1000 keys per response, so
buckets/prefixes with more than 1000 objects silently lost everything
past the first page, despite the Javadoc promising to load all
documents.
This replaces the single call with
`s3Client.listObjectsV2Paginator(request)`. The returned
`ListObjectsV2Iterable.contents()` transparently follows the
continuation token and flattens every page, so the existing filter/load
loop is unchanged. The change is scoped to this one method plus the new
import.
Added a unit test class (`AmazonS3DocumentLoaderTest`, JUnit 5 + AssertJ
+ Mockito) that drives the real paginator: a truncated first page plus a
second page asserts both objects load (the >1000-keys path); single-page
and empty-bucket cases cover the boundaries. The existing LocalStack IT
is untouched.
## 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 <!-- unit tests
green; LocalStack IT needs Docker — run before submitting, then check
-->
- [ ] 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)
## Issue
<!-- Please specify the ID of the issue this PR is addressing. -->
N/A - routine dependency maintenance prompted by the new Azure Java SDK
release.
## Change
Bumps `com.azure:azure-sdk-bom` from `1.3.5` to `1.3.7` (latest). Most
managed libraries are minor/patch bumps, but the new BOM pulls two
changes that require work:
- **`azure-search-documents` 11.8.1 -> 12.0.0** (major release) used by
`langchain4j-azure-ai-search`.
- **`azure-core` 1.57.1 -> 1.58.0**, which shifts the required
Netty/Reactor stack.
**azure-search-documents 12.0.0 migration**
(`langchain4j-azure-ai-search`). The public langchain4j API of the
module is unchanged; only the internal calls into the Azure SDK were
rewritten:
- `search(text, options, Context)` ->
`search(options.setSearchText(text))`
- `SearchDocument` / `getDocument(...)` removed -> read fields via
`SearchResult.getAdditionalProperties()` (a `Map`)
- `uploadDocuments` / `deleteDocuments` removed ->
`indexDocuments(IndexDocumentsBatch)` built from `IndexAction`s (new
private `toUploadBatch` / `toSearchDocument` helpers)
- `VectorSearchOptions` / `SemanticSearchOptions` removed ->
`setVectorQueries(...)` and `setSemanticConfigurationName(...)`
- `getSemanticSearch().getRerankerScore()` -> `getRerankerScore()`;
`setKNearestNeighborsCount` -> `setKNearestNeighbors`; `new
SearchIndex(name, fields)` constructor
**Dependency re-alignment.** The bump to `azure-core 1.58.0` raises the
minimum Netty/Reactor versions, so the local `dependencyManagement`
workaround pins in `github-models`, `azure-cosmos-nosql`,
`document-loader-azure-storage-blob`, and
`code-execution-engine-azure-acads` were updated (`reactor-core 3.7.17`,
`reactor-netty-http 1.2.16`, `azure-core-http-netty 1.16.4` and
siblings, `netty-bom 4.1.132.Final`) so the `maven-enforcer`
`RequireUpperBoundDeps` rule keeps passing.
Note for reviewers: this is a major version jump of
`azure-search-documents`, so please give the rewritten index/read/write
paths in `AbstractAzureAiSearchEmbeddingStore` a careful look. End-user
behaviour of the module is intended to be unchanged. Integration tests
require live Azure credentials and were not run; all unit tests pass
locally across every affected Azure module.
## 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)
## Checklist for adding new maven module
N/A - no new module.
## Checklist for adding new embedding store integration
N/A - no new embedding store integration.
## Checklist for changing existing embedding store integration
- [ ] I have manually verified that the `AzureAiSearchEmbeddingStore`
works correctly with the data persisted using the latest released
version of LangChain4j
<!-- Integration tests require live Azure resources; the existing IT
compiles but was not executed in this change. -->
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Issue
Closes#5429
## Change
`AzureBlobStorageDocumentLoader.loadDocument()` passed `accountName` and
`containerName` in the wrong order to the `AzureBlobStorageSource`
constructor, producing incorrect `source` metadata URLs.
- `AzureBlobStorageDocumentLoader.loadDocument()` (line 33): swapped
2nd/3rd arguments so they match the constructor signature `(InputStream,
containerName, accountName, blobName, properties)`.
- `LocalAzureBlobStorageDocumentLoaderIT`: tightened `source` assertions
from `.endsWith(...)` to `.isEqualTo(...)` with the full canonical URL
`https://devstoreaccount1.blob.core.windows.net/test-container/<blob>`.
- `AzureBlobStorageSource.java` is correct and was not modified.
> **Spotless caveat:** `spotless:apply` cannot run on JDK 25; human must
run `./mvnw -Pspotless spotless:apply -pl
document-loaders/langchain4j-document-loader-azure-storage-blob` on JDK
17 before submitting.
## 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 <!-- N/A — only
positive assertion was strengthened; no explicit negative case added -->
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green <!-- N/A — not run
by pipeline -->
- [ ] I have manually run all the unit and integration tests in the core
and main modules, and they are all green <!-- N/A — not run by pipeline
-->
- [ ] I have added/updated the documentation <!-- N/A — bug fix only, no
public API change -->
- [ ] I have added an example in the examples repo (only for "big"
features) <!-- N/A — bug fix, not a new feature -->
- [ ] I have added/updated Spring Boot starter(s) (if applicable) <!--
N/A — no starter affected -->
<!-- omit the "new maven module" and "embedding store integration"
conditional sections — not applicable. -->
---------
Co-authored-by: Julien Dubois <316835+jdubois@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Issue
Closes#5433
## Change
`TencentCosDocumentLoader.loadDocument(String bucket, String key,
DocumentParser parser)` built `new GetObjectRequest(bucket, key)`
without validating arguments. This PR wraps both with `ensureNotBlank`:
```java
GetObjectRequest getObjectRequest = new GetObjectRequest(ensureNotBlank(bucket, "bucket"), ensureNotBlank(key, "key"));
```
- Mirrors `AmazonS3DocumentLoader.loadDocument()` and fixes an internal
inconsistency: `loadDocuments()` already calls `ensureNotBlank(bucket,
"bucket")` (line 73). No new imports.
- Spotless (`palantir 2.44.4`) applied; formatting-only lines in the
diff are required by CI `spotless:check`.
- New unit test `TencentCosDocumentLoaderTest`: 4 negative cases
(null/blank bucket, null/blank key) asserting
`IllegalArgumentException`, using a Mockito-mocked `COSClient` (no
stubbing — `ensureNotBlank` throws before any client call). All 4 pass
on JDK 17 and 25.
## 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 <!-- negative
input assertions here; positive path covered by credential-gated
TencentCosDocumentLoaderIT -->
- [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
and main modules, and they are all green <!-- N/A — single-module
validation fix -->
- [ ] I have added/updated the documentation <!-- N/A — no public API
change -->
- [ ] I have added an example in the examples repo (only for "big"
features) <!-- N/A — minor fix -->
- [ ] I have added/updated Spring Boot starter(s) (if applicable) <!--
N/A — no starter covers this loader -->
---
## Summary
Removed 18 unused import statements from 17 source files across multiple
modules.
### Modules affected
- `langchain4j-core` (6 files)
- `langchain4j` (3 files)
- `langchain4j-azure-ai-search`
- `langchain4j-cassandra`
- `langchain4j-couchbase`
- `langchain4j-agentic`
- `langchain4j-agentic-mcp`
- `langchain4j-local-ai`
- `langchain4j-workers-ai`
- `document-loaders/langchain4j-document-loader-azure-storage-blob`
### Verification
Each import was verified to be unused — the imported symbol does not
appear in any non-import line of its file (including javadoc `@link` and
`@see` tags).
<!--
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 #
## Change
<!-- Please describe the changes you made. -->
Upgrade playwright-java to 1.57 to support latest Chromium / Chrome for
Testing.
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [x] There are no breaking changes (API, behaviour)
- [ ] 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
<!-- 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#4326
## Change
Added exception handling to skip failed documents in
`AzureBlobStorageDocumentLoader.loadDocuments()` and
`GoogleCloudStorageDocumentLoader.loadDocuments()`, matching the
behavior of `AmazonS3DocumentLoader` and `TencentCosDocumentLoader`.
- Added try-catch blocks to skip failed documents and log warnings
- Updated Javadoc to document skip 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
- [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)
## 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
Bumps org.apache.logging.log4j:log4j-core from 2.22.0 to 2.25.3.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/langchain4j/langchain4j/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
- Update to the Azure SDK 1.3.3, which fixes several transitive
dependencies vulnerabilities (specifically with Azure Identity)
- Update the OpenAI Official SDK to its latest version
- Started to modify the naming from Azure OpenAi to Microsoft Foundry
(the new official name)
- Replaced Dall-e 3.0 (which will be discontinued soon) by
gpt-image-1-mini
<!--
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 #
## Change
<!-- Please describe the changes you made. -->
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] There are no breaking changes (API, behaviour)
- [ ] 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)
## 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
Fix should_load_and_parse_html_document
- Extract the document using HtmlToTextDocumentTransformer and make sure
that it doesn't contain the tag <head>
Co-authored-by: Harikrishna <harikrishna.gurram@walmart.com>
github-actions[bot]