Conversation
...restclient/src/main/java/dev/langchain4j/http/client/spring/restclient/SpringRestClient.java
Outdated
Show resolved
Hide resolved
...restclient/src/main/java/dev/langchain4j/http/client/spring/restclient/SpringRestClient.java
Outdated
Show resolved
Hide resolved
arey
force-pushed
the
feature/spring-boot-4
branch
from
c4d7f3a to
a44eeef
Compare
arey
force-pushed
the
feature/spring-boot-4
branch
from
a44eeef to
9d7a48f
Compare
|
@arey please ping me by @dliubarskyi once this PR is ready (but no rush!) |
…map instead of the asMultiValueMap deprecated method
Hi @dliubarskyi, that sounds OK to me. I've added some comments to the main conversation. Other than the OPENAI_API_KEY, I don't have any other API tokens. Could you perhaps checkout my branch and execute all the integration tests? |
|
|
I am wondering if we should migrate straight to 4 (as is done in this PR), or support both 3 and 4 in parallel for some time. WDYT? |
…ot 4 BOM from 9.2.3 to 8.19.2
|
@dliubarskyi I fixed the Elasticsearch issue by sticking with version 8.19.2. I don't know how, within the Langchain project, you support different versions of technologies that are not upward compatible, such as Spring Boot 4 against Spring Boot 3. In general, I think most developers are using the latest stack for their GenAI project. Therefore, it could be acceptable to only keep the most recent version of Spring Boot. Of course, it would be better to support both major versions of Spring Boot. I think it's technically possible to do this using reflection on the |
|
@arey I was thinking more of a duplicated set of modules for Spring Boot 4, but if reflection approach works, why not |
|
@dliubarskyi my last commit 833ac80 provides an overview of how to use reflection to support both versions of Spring Boot without duplicating modules (see the We use a strategy pattern. Of course, the code is much more complex to maintain. But in a few months/years, we could revert this commit in order to remove support for Spring Boot 3.x No unit tests have been written for the Another approach could be to move the SpringBoot3HttpClientSettings class into a legacy |
|
Hello any update when the Spring boot 4 upgrade is probably going to be released on maven central? |
arey
changed the title
|
Hi @dliubarskyi, did you see my latest commit? Would you like to merge it as it is, or would you prefer to have a code without introspection in a new Maven module? |
|
@arey I just tested your latest changes with Spring Boot 3.4.2 app and it fails to start: I am not sure this approach is reliable, I would probably go with a separate set of module(s) for SB4, WDYT? |
|
I mean keeping existing modules for SB 3 and introduce new modules for SB 4 |
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
|
@dliubarskyi I see where the problem you're encountering comes from. The I tried to stop loading the Spring Boot starters again to remove as many auto-configuration classes as possible, but it didn't work
Rather than duplicating the 18 modules of the langchain4j-spring project, I wonder if we shouldn't maintain a WDYT? |
|
@arey we certainly need to maintain SB3 compatibility, these modules have lots of users at the moment, we can't just break it for them. If we want to support SB4, we either need to release a next major version of LC4j (e.g., 2.X), or have a separate set of dependencies released specifically for SB4. Since 2.X is still far away, I would go with a separate set of modules. Introducing separate branch would also work, but it would complicate the release process because we would need to change it to release from both branches. |
| import java.time.Duration; | ||
|
|
||
| /** | ||
| * The Spring Boot 3.5+ implementation uses reflection because Spring Boot 4 is no longer included in the langchain4J-spring classpath. |
There was a problem hiding this comment.
Spring Boot 3.5 will reach end of life in June and projects are encouraged to upgrade (see Support page). I would suggest considering if it's desireable to maintain 3.5 support here, even if not supported upstream. If it is, I would recommend considering publishing separate modules, as it's quite risky and complex to support both major version in the same artifact.
There was a problem hiding this comment.
Considering that I see a lot of usage of LC4j-SB modules (and given that they support only 3.x), and it is growing, I think it is worth maintaining it untill we see a considerable drop in usage of these modules.
Also, as far as I see, enterprise support of 3.5.x is planned untill 2032.
There was a problem hiding this comment.
@ThomasVitale @dliubarskyi
I think I might have found a solution to avoid duplicated all the Maven modules. I've tested it with langchain4j-openai-springboot-starter on https://github.com/spring-petclinic/spring-petclinic-langchain4j, which still uses Spring Boot 3.4.
My idea is to exclude all the Spring artefacts and allow the application client to decide which Spring Boot version to use. To do that, we could use the Maven <scope>provided</scope>
Exemple: pom-langchain4j-open-ai-spring-boot-starter.xml
Maven dependency tree on Langchain4j starter side:
dependency-tree-langchain4j-open-ai-spring-boot-starter.log
Maven dependency tree on the Spring Petclinic side:
dependency-tree-petclinic.log
Spring Petclinic startup log:
2026-03-07T11:04:28.725+01:00 DEBUG 13176 --- [ main] c.s.r.SpringBootHttpClientSettingsHelper : Detected Spring Boot major version 3
See complete logs: petclinic-logs.log
Existing Spring Boot 3.x applications should not be impacted because the ClientHttpRequestFactorySettings class belongs to the main spring-boot-3.x.jar.
Future Spring Boot 4 applications may have to add the spring-boot-http-client dependency (or spring-boot-restclient) in addition to the langchain4j-open-ai-spring-boot-starter dependency.
@dliubarskyi if you want to test, I could a go ahead and prepare a commit with the described solution.
There was a problem hiding this comment.
@dliubarskyi @ThomasVitale I have another idea for avoiding the duplication of all the Maven modules.
We could use two Maven profiles to build the project: sb3 and sb4.
Each profile contains a property with the Spring Boot version.
By default, we could target Spring Boot 4 (the sb4 profile). However, GitHub Actions could also build the project against the sb3 profile. We will have to run two Maven releases. Once for each profile.
If we take this approach, we must decide about a naming convention on the artefactId or the Maven version (or another proposal).
In the parent pom.xml:
<profile>
<id>sb3</id>
<properties>
<langchain4j-spring-prefix>sb3</langchain4j-spring-prefix>
<spring.boot.version>3.5.9</spring.boot.version>
</properties>
</profile>At the top of the Open AI Spring boot starter :
<artifactId>langchain4j-open-ai-spring-boot-starter</artifactId>
<name>LangChain4j Spring Boot starter for OpenAI</name>
<version>1.12.0-beta20-${langchain4j-spring-prefix}-SNAPSHOT</version>or
<artifactId>langchain4j-open-ai-spring-boot-starter-${langchain4j-spring-prefix}</artifactId>
<name>LangChain4j Spring Boot starter for OpenAI</name>
<version>1.12.0-beta20-SNAPSHOT</version>To avoid git tag conflict during the maven release, the first option is maybe the better.
With this second solution, I suppose we could have only 2 duplicated modules for the langchain4j-http-client-spring-restclient artefact, each for one major version of Spring Boot. No more introspection code.
4 participants
Issue
Fixes langchain4j/langchain4j#4268 [BUG] Not compatible with Spring Boot 4.0
Change
This pull request updates dependencies and refactors code across several modules to ensure compatibility with Spring Boot 4. The most important changes are grouped below:
SpringRestClientrefactoring to useHttpClientSettingsinstead of the previousClientHttpRequestFactorySettingstestcontainers-junit-jupiter,testcontainers-elasticsearch,testcontainers-milvus)General checklist
mvn clean install -Dmaven.test.skipcommand line)langchain4j-spring-boot-starter,langchain4j-open-ai-spring-boot-starterandlangchain4j-http-client-spring-restclienttested on the Spring Boot 4 version of Spring Petclinic Langchain4j.langchain4j-springOn my laptop, integration tests are unstable. Sometimes they failed at the
LangChain4j Spring Boot starter for OpenAImodule, sometimes later. For instance:We'll have to change the section https://github.com/langchain4j/langchain4j/blob/main/docs/docs/tutorials/spring-boot-integration.md#supported-versions
Checklist for adding new Spring Boot starter
N/A