chore(deps): update plugin org.springframework.boot to v3.4.0 #400
Conversation
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
![renovate-approve[bot]](https://avatars.githubusercontent.com/in/7394?s=60&v=4){kind=small}
WalkthroughThe changes include an update to the PostgreSQL image version in the Changes
Possibly related PRs
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
4244edf to
84b4a78
Compare
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
84b4a78 to
d29baa3
Compare
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
304e619 to
41c8fd9
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- gradle.properties (1 hunks)
Additional comments not posted (1)
gradle.properties (1)
11-11: Approve the version update.The update from
3.4.0-M1to3.4.0-M2in thespring_boot_versionproperty is consistent with the PR's objectives to keep dependencies up-to-date. This change is expected to bring new features and bug fixes as outlined in the PR summary.It's advisable to verify that this version update is compatible with other dependencies and configurations specified in the project. Consider running integration tests or checking the compatibility matrix provided by Spring Boot to ensure that there are no breaking changes affecting your project's specific setup.
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
41c8fd9 to
80f0e2b
Compare
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
80f0e2b to
1f4ad81
Compare
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
1f4ad81 to
d6cd81f
Compare
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
d6cd81f to
976b380
Compare
renovate
bot
changed the title
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
976b380 to
ad078de
Compare
renovate
bot
changed the title
renovate
bot
force-pushed
the
renovate/spring-boot
branch
2 times, most recently
from
de49faf to
da74d41
Compare
renovate
bot
force-pushed
the
renovate/spring-boot
branch
from
71265b0 to
20630f1
Compare
renovate
bot
changed the title
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
rajadilipkolli
force-pushed
the
renovate/spring-boot
branch
from
98a7dc9 to
dc3c689
Compare
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
docker/docker-compose.yml (1)
4-4: Consider documenting the upgrade processSince this is a major version upgrade, consider adding upgrade instructions to the README or documentation:
- Required steps for existing deployments
- Database backup procedures
- Version-specific configuration changes
Would you like me to help create a documentation template for the upgrade process?
src/main/java/com/learning/mfscreener/config/Initializer.java (1)
53-57: Consider using UriComponentsBuilder for URL constructionWhile the RestClient usage is correct, consider using
UriComponentsBuilderinstead ofURI.create()for better URL handling and encoding:- String allNAVs = restClient - .get() - .uri(URI.create(AppConstants.AMFI_WEBSITE_LINK)) - .retrieve() - .body(String.class); + String allNAVs = restClient + .get() + .uri(UriComponentsBuilder.fromHttpUrl(AppConstants.AMFI_WEBSITE_LINK) + .build() + .toUri()) + .retrieve() + .body(String.class);This approach provides:
- Proper URL encoding
- Better handling of query parameters
- Protection against malformed URLs
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (9)
docker/docker-compose.yml(1 hunks)gradle.properties(1 hunks)src/main/java/com/learning/mfscreener/config/Initializer.java(4 hunks)src/main/java/com/learning/mfscreener/config/RestClientConfiguration.java(1 hunks)src/main/java/com/learning/mfscreener/config/RestTemplateConfiguration.java(0 hunks)src/main/java/com/learning/mfscreener/config/WebMvcConfig.java(1 hunks)src/main/resources/application.properties(1 hunks)src/test/java/com/learning/mfscreener/TestApplication.java(1 hunks)src/test/java/com/learning/mfscreener/common/SQLContainersConfig.java(1 hunks)
💤 Files with no reviewable changes (1)
- src/main/java/com/learning/mfscreener/config/RestTemplateConfiguration.java
🔇 Additional comments (10)
src/main/resources/application.properties (1)
65-68: HTTP client configuration looks good, but verify timeout values.
The new HTTP client configuration is well-structured and uses appropriate defaults. The JDK HTTP client factory is a good choice as it's lightweight and supports virtual threads.
However, please verify that the timeout values align with your application's requirements:
- Read timeout (1 minute): Suitable for most operations, but consider if any long-running API calls exist
- Connect timeout (30 seconds): This seems quite long for connection establishment
Let's verify if there are any long-running operations that might require adjusted timeouts:
Consider adding comments in the properties file to document:
- The rationale for chosen timeout values
- Any specific operations that influenced these values
- Guidelines for adjusting these in different environments
# HttpClient
spring.http.client.factory=jdk
+# Read timeout for HTTP operations (adjust based on longest expected operation)
spring.http.client.read-timeout=PT1M
+# Connection timeout for HTTP operations (consider reducing in production)
spring.http.client.connect-timeout=PT30S✅ Verification successful
Let me gather more information about HTTP client usage to better understand the timeout requirements.
Let me search for any HTTP client usage patterns and external API calls to better understand the timeout requirements.
Based on the findings, I can now generate the final response:
HTTP client timeouts are appropriate for the application's needs
The configured timeouts (1 minute read, 30 seconds connect) are well-suited for the application's usage pattern:
- The main HTTP client usage is for fetching NAV data from AMFI portal (portal.amfiindia.com)
- The operation is a simple GET request to download NAV history reports
- No complex or long-running API operations were found
The current timeout values provide:
- Sufficient buffer for network latency and server processing
- Protection against hanging connections
- Reasonable resource cleanup in case of failures
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for RestClient usage patterns and HTTP calls
ast-grep --pattern 'class $_ {
$$$
@$_($$$)
$_ $_(RestClient $_, $$$) {
$$$
}
}'
# Look for existing timeout configurations or comments
rg -i "timeout|long.*running|slow.*operation" --type java
Length of output: 378
Script:
#!/bin/bash
# Search for HTTP client usage and external API calls
rg -A 5 -B 2 "RestClient|WebClient|HttpClient" --type java
# Look for configuration properties that might indicate external service dependencies
rg -i "url|endpoint|api|service" src/main/resources/
Length of output: 76318
Script:
#!/bin/bash
# Search for HTTP client usage patterns and external API calls
rg -A 10 "restClient\." --type java
# Look for any scheduled or background tasks that might make HTTP calls
rg -A 5 "@Scheduled|@Async" --type java
Length of output: 1515
src/test/java/com/learning/mfscreener/TestApplication.java (1)
13-13: Improved Spring profile configuration approach!
The change from using System.setProperty to withAdditionalProfiles is a better approach as it:
- Aligns with Spring Boot 3.x best practices
- Makes profile configuration more explicit and maintainable
- Avoids system property side effects
src/test/java/com/learning/mfscreener/common/SQLContainersConfig.java (1)
17-17: Verify PostgreSQL 17.x compatibility
The upgrade from PostgreSQL 16.x to 17.x is a major version change that requires careful consideration:
- PostgreSQL 17 introduces breaking changes
- Database compatibility settings might need adjustment
- Production environment synchronization should be verified
Let's check for any PostgreSQL-specific configurations in the codebase:
✅ Verification successful
PostgreSQL 17.2 upgrade appears safe to proceed
The verification shows:
- The application uses PostgreSQL 17.2-alpine consistently in both test (
SQLContainersConfig.java) and development environments (docker-compose.yml) - Database schema uses standard SQL features through Liquibase migrations without any PostgreSQL 17-specific features
- Only PostgreSQL-specific customizations are basic data type mappings (
textfor strings andtimestamptzfor timestamps) - No usage of advanced features like stored procedures, triggers, or generated columns that might be affected by version changes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for PostgreSQL-specific configurations and properties
echo "Searching for PostgreSQL configurations..."
rg -l "postgresql" --type properties --type yaml --type xml
# Search for potential compatibility issues in SQL files
echo "Checking SQL files for potential compatibility issues..."
rg -l "(?i)(generated always|procedures|triggers)" --type sql
Length of output: 525
Script:
#!/bin/bash
# Search for PostgreSQL-specific configurations with broader file patterns
echo "Searching for PostgreSQL configurations..."
rg -l "postgresql|postgres" -g "*.properties" -g "*.yml" -g "*.yaml" -g "*.xml"
# Search for SQL files first
echo "Looking for SQL files..."
fd -e sql
# Search for database configuration classes
echo "Searching for database configuration files..."
rg -l "DataSource|JdbcTemplate|EntityManager|PostgreSQL" -g "*.java"
Length of output: 1173
Script:
#!/bin/bash
# Check the content of docker-compose files and application config for PostgreSQL version
echo "Checking PostgreSQL version in docker-compose and application configs..."
rg "postgres:" docker/docker-compose*.yml src/main/resources/application*.yml
# Check database migration files for any PostgreSQL-specific features
echo "Checking database migration files for PostgreSQL features..."
cat src/main/resources/db/changelog/migration/*.xml
# Check if there are any PostgreSQL-specific tests or configurations
echo "Checking PostgreSQL-specific test configurations..."
cat src/test/java/com/learning/mfscreener/repository/SchemaValidationPostgresTest.java
Length of output: 20579
docker/docker-compose.yml (1)
4-4: Version alignment is good, but verify upgrade path
The PostgreSQL version update to 17.2-alpine aligns with the test container configuration, which is good for consistency. However, consider the following:
- Ensure a database backup before upgrading
- Verify data persistence across the major version upgrade
- Check if pgAdmin and other dependent services are compatible with PostgreSQL 17.x
Let's check for version compatibility between services:
✅ Verification successful
PostgreSQL upgrade is safe to proceed
The version upgrade from 16.6-alpine to 17.2-alpine is well-aligned across the environment:
- The test containers configuration explicitly uses the same version (17.2-alpine)
- pgAdmin4 is used without version constraints and will work with PostgreSQL 17.x
- The application's database configuration doesn't specify version constraints
- No specific version dependencies found in the codebase
Just remember to:
- Back up your data before the upgrade
- Follow PostgreSQL's official upgrade procedure from 16.x to 17.x
- Test the application thoroughly after the upgrade
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any version constraints in application properties
echo "Checking for PostgreSQL version constraints..."
rg -l "postgresql.*version" --type properties --type yaml
# Look for potential service dependencies
echo "Checking for service dependencies..."
rg -l "postgresql.*dependency" --type gradle --type maven
Length of output: 370
Script:
#!/bin/bash
# Let's try a broader search for PostgreSQL-related configurations and dependencies
echo "Checking for PostgreSQL configurations..."
rg -l "postgres|postgresql" --type yaml --type json
# Look for potential version constraints or dependencies in any file
echo "Checking for version constraints and dependencies..."
rg -l "postgres|postgresql"
# Check if pgAdmin is used in the project
echo "Checking for pgAdmin configurations..."
fd -t f "pgadmin|pg_admin"
Length of output: 1261
Script:
#!/bin/bash
# Let's check the content of relevant files to understand version constraints and configurations
echo "Checking docker-compose configurations..."
cat docker/docker-compose.yml
echo "Checking pgAdmin configuration..."
cat docker/docker_pgadmin_servers.json
echo "Checking test container configuration..."
cat src/test/java/com/learning/mfscreener/common/SQLContainersConfig.java
echo "Checking application configuration..."
cat src/main/resources/application-localdocker.yml
Length of output: 3551
gradle.properties (2)
13-13: Verify SpringDoc OpenAPI compatibility
The SpringDoc OpenAPI upgrade to 2.7.0 should be verified for compatibility with Spring Boot 3.4.0.
✅ Verification successful
SpringDoc OpenAPI 2.7.0 is compatible with Spring Boot 3.4.0
The project is using SpringDoc OpenAPI starter for WebMVC UI version 2.7.0 with Spring Boot 3.4.0. This combination is compatible as SpringDoc OpenAPI 2.x series is specifically designed for Spring Boot 3.x, and version 2.7.0 supports all current Spring Boot 3.x releases including 3.4.0.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for OpenAPI configurations and usage
echo "Searching for OpenAPI configurations..."
rg "springdoc|openapi" --type java --type yaml --type properties
Length of output: 190
Script:
#!/bin/bash
# Check for OpenAPI configurations and usage with proper file extensions
echo "Searching for OpenAPI configurations..."
rg "springdoc|openapi" -g "*.java" -g "*.yml" -g "*.yaml" -g "*.properties"
# Check Spring Boot version in build files
echo -e "\nChecking Spring Boot version..."
rg "org\.springframework\.boot" -g "*.gradle" -g "*.properties"
Length of output: 1466
Script:
#!/bin/bash
# Check Spring Boot version in properties
echo "Checking Spring Boot version in properties..."
rg "spring_boot_version" -g "*.properties" -g "*.gradle"
# Check for OpenAPI dependencies in build files
echo -e "\nChecking OpenAPI dependencies..."
rg "springdoc-openapi" -g "build.gradle"
Length of output: 521
11-11: Verify Spring Boot 3.4.0 compatibility with project dependencies
The upgrade from milestone (3.4.0-M1) to stable release (3.4.0) is good. However, we should verify compatibility with other major dependencies.
✅ Verification successful
Let me gather more information about the Spring Boot version compatibility by checking the build configuration and dependency versions.
Based on the analysis of the build files, I can now generate the final response:
Spring Boot 3.4.0 upgrade appears compatible with project dependencies
The upgrade from 3.4.0-M1 to 3.4.0 is safe based on the following observations:
- All Spring Boot starters will automatically align with the new version through the dependency management plugin
- Key dependencies are compatible with Spring Boot 3.x:
- JobRunr 7.3.2 explicitly supports Spring Boot 3
- SpringDoc OpenAPI starter is using the webmvc-ui variant compatible with Spring Boot 3
- MapStruct 1.6.3 and its Spring extensions are version-compatible
- All test containers and testing libraries are recent versions supporting Spring Boot 3
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check build.gradle files for potential compatibility issues
echo "Searching for Spring-related dependencies..."
rg -l "org\.springframework" --type gradle
echo "\nSearching for Spring Boot starter dependencies..."
rg "spring-boot-starter" --type gradle
Length of output: 936
Script:
#!/bin/bash
# Check build.gradle for version declarations and plugin usage
echo "Checking build.gradle content..."
cat build.gradle
echo -e "\nChecking settings.gradle content..."
cat settings.gradle
Length of output: 6573
src/main/java/com/learning/mfscreener/config/WebMvcConfig.java (2)
20-20: Good addition of @nonnull annotation
Adding @nonnull improves null-safety and makes the contract more explicit.
Line range hint 21-27: Verify CORS security configuration
The CORS configuration is property-driven, which is good for flexibility. Let's verify the security settings in the properties file.
src/main/java/com/learning/mfscreener/config/Initializer.java (2)
13-13: LGTM! Import changes align with RestClient migration
The new imports correctly support the migration from RestTemplate to RestClient.
Also applies to: 25-25
34-34: Verify RestClient bean configuration
The migration from RestTemplate to RestClient looks good. However, ensure that the RestClient bean is properly configured with appropriate timeouts and other settings in the RestClientConfiguration class.
Also applies to: 40-41, 44-45
✅ Verification successful
RestClient configuration is minimal but present
The RestClient bean is configured in RestClientConfiguration.java, but it uses the default builder settings without explicit timeout configurations. While this is a valid configuration, you might want to consider adding timeout settings and other configurations based on your application's needs.
Locations that might need attention:
src/main/java/com/learning/mfscreener/config/RestClientConfiguration.java: Consider enhancing the RestClient configuration with appropriate timeout settings and other configurations if required for your use case.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for RestClient configuration
ast-grep --pattern 'class RestClientConfiguration {
$$$
@Bean
$$$
RestClient $$$($$$) {
$$$
}
$$$
}'
Length of output: 118
Script:
#!/bin/bash
# Let's try a broader search for RestClient configuration
rg -l "RestClient" --type java
# Then check content of any configuration files
fd ".*Config.*\.java$" --type f --exec cat {}
Length of output: 6934
| @Bean | ||
| RestClient restClient(RestClient.Builder restClientBuilder) { | ||
| return restClientBuilder.build(); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding essential RestClient customizations
While the basic configuration is good, consider adding these essential customizations for production readiness:
- Connection timeout
- Read timeout
- Error handling
- Logging interceptor
@Bean
RestClient restClient(RestClient.Builder restClientBuilder) {
- return restClientBuilder.build();
+ return restClientBuilder
+ .requestInterceptor(new LoggingInterceptor())
+ .defaultHeader(HttpHeaders.ACCEPT, MediaType.APPLICATION_JSON_VALUE)
+ .defaultStatusHandler(HttpStatusCode::isError,
+ (request, response) -> throw new CustomHttpException(response))
+ .build();
}Committable suggestion skipped: line range outside the PR's diff.
This PR contains the following updates:
3.4.0-M1->3.4.0Release Notes
spring-projects/spring-boot (org.springframework.boot)
v3.4.0v3.4.0-RC1⭐ New Features
@BatchTaskExecutorto make it easier to configure Spring Batch to use a custom task executor #40040🐞 Bug Fixes
@ControllerEndpointand@RestControllerEndpointinfrastructure remains undeprecated #42499@ConditionalOn(Missing)Bean(annotation = …) infers the type to match when used on a@Beanmethod #42484📔 Documentation
@Qualifieron one bean and@Primaryon another to suggest a single bean with defaultCandidate=false #42831@Primaryis recommended when defining your own ObjectMapper that replaces JacksonAutoConfiguration's #42788@Bean's autowireCandidate and defaultCandidate #42586@ConditionalOn(Missing)Bean will infer the type to match #42506🔨 Dependency Upgrades
❤️ Contributors
Thank you to all the contributors who worked on this release:
@1328032567, @IMWoo94, @anthonydahanne, @arefbehboudi, @choi-hyeseong, @eddumelendez, @gkdis6, @izeye, @jeonghyeon00, @mmoayyed, @mturbe, @ngocnhan-tran1996, @nosan, @qingbozhang, @quaff, and @woosung1223
v3.4.0-M3⭐ New Features
@DependsOn,@Description,@Fallback,@Lazy,@Primary, and@Roleon@ConfigurationPropertiesbeans #42289@EnableConfigurationPropertiesto define the MessageSourceProperties bean #42181@AutoConfigureTestDatabase(replace=NONE) when using a test-provided database #35253🐞 Bug Fixes
@RestartScopecan cause 'Recursive update' exceptions when used with container beans #42108📔 Documentation
🔨 Dependency Upgrades
❤️ Contributors
Thank you to all the contributors who worked on this release:
@Alchemik, @PiyalAhmed, @abc5259, @arefbehboudi, @bazzi2548, @eddumelendez, @einarpehrson, @famaridon, @izeye, @martinfrancois, @mushroom528, @ngocnhan-tran1996, @nosan, @onobc, @quaff, @slissner, @timpeeters, and @vpavic
v3.4.0-M2⭐ New Features
@ConditionalOnAvailableEndpointand migrate simple conditions #41969@ConditionalOnSingleCandidateto deal with fallback beans #41580@Namewith JavaBean-based configuration properties #39452🐞 Bug Fixes
@Bean-methodfails with spring-boot-testcontainers dependency in classpath (3.4.0-M1) #41839@ControllerEndpointand@RestControllerEndpointinfrastructure remains undeprecated #41620@ConditionalOnBeanmatches beans that are not autowire candidates resulting in UnsatisfiedDependencyException when an attempt is made to inject the bean #41526📔 Documentation
@Nameto customize a property name #41586🔨 Dependency Upgrades
❤️ Contributors
Thank you to all the contributors who worked on this release:
@BenchmarkingBuffalo, @PiyalAhmed, @Rajin9601, @cms04, [@
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.
Summary by CodeRabbit
New Features
RestClient.Bug Fixes
Documentation
Chores
RestTemplateConfigurationclass.Tests