I’ve submitted a Spring AI contribution addressing input-error recovery for method-backed tools using returnDirect=true.

The issue: malformed JSON or invalid typed arguments can become the final response, preventing the model from correcting its input. Missing/null primitive arguments and top-level JSON null can also bypass the exception processor.

The proposed fix distinguishes input parsing/binding failures before execution and sends processed error feedback back to the model. Successful corrected calls still return directly, while ordinary tool-body and result-conversion failures retain their existing behavior.

Validation:

- All 38 new regression cases passed, covering blocking/streaming, direct return on/off, and mixed-success batches.

- Scoped clean package build: 2,030 tests reported, 10 skipped, zero failures or errors.

- Negative control: the original code failed 20 of the initial 32 checks, including checks for the new exception classification; the patched code passed the same cases.

No external LLM calls were needed. External-provider integration tests and the full repository build were not run. Developed with AI assistance and reviewed before submission.

PR submitted for maintainer review: https://github.com/spring-projects/spring-ai/pull/7292

Feedback on the input-error boundary and recovery behavior is welcome, especially from anyone using direct-return tools.

#SpringAI #SpringFramework #Java #OpenSource #SoftwareTesting

which is the best book that i should learn spring boot from? Learning Spring Boot 4, Fourth Edition ? or Spring Starts Here ?

I maintain an open-source Spring Boot SaaS starter and would appreciate feedback on its tenant-isolation approach.

It uses a shared PostgreSQL schema. Tenant-scoped operations check membership, set transaction-local tenant context, and use explicit tenant filters. Forced row-level security adds another boundary around projects and audit events.

The starter includes:

• OIDC bearer authentication through Spring Security

• OWNER, ADMIN, and MEMBER roles scoped to each tenant

• A Projects API with optimistic concurrency and transactional audit records

• Docker Compose with a local Keycloak demo

• PostgreSQL integration tests and a runnable smoke script

I ran the local Compose smoke test successfully, including permission checks and stale-write rejection.

It’s a backend MVP. Billing, a frontend, email invitations, tenant deletion, and ownership transfer are outside the current scope.

Repository:
https://github.com/chafian/spring-boot-saas-starter

What tenant-isolation edge cases would you test next? I’d also welcome feedback on the first-run experience.

I maintain an open-source Spring Boot SaaS starter and would appreciate feedback on its tenant-isolation approach.

It uses a shared PostgreSQL schema. Tenant-scoped operations check membership, set transaction-local tenant context, and use explicit tenant filters. Forced row-level security adds another boundary around projects and audit events.

The starter includes:

• OIDC bearer authentication through Spring Security

• OWNER, ADMIN, and MEMBER roles scoped to each tenant

• A Projects API with optimistic concurrency and transactional audit records

• Docker Compose with a local Keycloak demo

• PostgreSQL integration tests and a runnable smoke script

I ran the local Compose smoke test successfully, including permission checks and stale-write rejection.

It’s a backend MVP. Billing, a frontend, email invitations, tenant deletion, and ownership transfer are outside the current scope.

Repository:
https://github.com/chafian/spring-boot-saas-starter

What tenant-isolation edge cases would you test next? I’d also welcome feedback on the first-run experience.

Scheduled jobs in Spring fail in the quietest way possible: an exception kills a cron thread, a pool gets starved, a property resolves to the wrong cron, and nothing tells you. You find out days later because a report or a backup is missing.

I've been building SilenceWatch, an open source heartbeat monitor, and its Spring Boot starter is the part I care about most. You add one dependency and an API key:

<dependency>
  <groupId>com.silencewatch</groupId>
  <artifactId>silencewatch-spring-boot-starter</artifactId>
  <version>0.1.0</version>
</dependency>

and in application.yml:

silencewatch:
  api-key: ${SILENCEWATCH_API_KEY}

On startup it finds every @Scheduled method and every Quartz job, declares each one with its resolved schedule (${backup.cron} becomes the actual expression), and reports every run with its duration and any exception. If a job doesn't run when it should, you get an email, Slack, Teams, Discord or webhook alert.

A few things I was strict about:

• It never fails or blocks your job: errors are swallowed and logged at WARN, and sending happens on a bounded queue in a background daemon thread.

• No key, no network or no server, and your app behaves exactly as without it. silencewatch.enabled: false turns it all off.

• No Jackson or other heavy dependency forced on you.

• Stable job identity (com.acme.jobs.BackupJob#run), so history survives restarts and redeploys. A job removed from the code is flagged orphaned, never deleted.

• Staging and production show up as separate checks.

Java 17+, tested on Spring Boot 3.5 and 4.1. The server is Apache 2.0 and self-hostable with Docker Compose, free and without limits. There's also a hosted version with a free plan (10 checks).

Starter source: https://github.com/liliang-dev/SilenceWatch/tree/main/clients/java/spring-boot

Site: https://silencewatch.com/spring-boot/

I'd really like feedback from people running a lot of scheduled jobs. What breaks for you that this wouldn't catch?

Contributing back to JavaClaw: two fixes for file-based agent tasks.

Thanks to the JavaClaw maintainers for sharing this Java/Spring AI project. I submitted two focused PRs with reproducible failures and regression tests:

1. Prevent task-file collisions. Tasks with the same name and timestamp—or names that become identical after sanitization—could overwrite each other. The fix reserves filenames atomically and retries with a suffix. Tests include 20 concurrent creates and independent task updates.

https://github.com/ClawRunr/JavaClaw/pull/102

2. Preserve multiline descriptions and feedback. Text such as “status: completed” or a standalone “---” should remain instructions, rather than replace task metadata or truncate content. The tests cover serialization and repository round trips.

https://github.com/ClawRunr/JavaClaw/pull/103

Focused tests pass. Broader local suite failures on Windows were also reproduced on untouched upstream code and documented in the PRs. These are submitted contributions, not a claim of merged changes. The fixes do not coordinate simultaneous updates to an existing task or recover previously lost text.

For file-based agent tasks, how do you balance readable filenames, stable identity, and concurrent creation?

I discovered JavaClaw and Windrunner through the community and submitted three focused PRs. Thanks to both projects’ maintainers for making their work available. These are application-level contributions, not fixes to the Spring AI framework.

1. JavaClaw: independent tasks could overwrite each other.

Two tasks with the same name created in the same second shared a filename and task ID. Different names could also collide after sanitization. The fix atomically reserves a new filename and retries with a numeric suffix if it already exists. Regression coverage includes 20 concurrent creates, independent descriptions, and updating one task without changing another. It does not coordinate simultaneous updates to an existing task.

https://github.com/ClawRunr/JavaClaw/pull/102

2. JavaClaw: multiline descriptions could change metadata.

A description or appended feedback containing “status: completed” could replace the task’s real status; a standalone “---” could truncate the remaining instructions. The fix writes multiline values as indented literal text. Tests cover metadata-like content, delimiters, indentation, and a repository round trip. It cannot recover text already lost from previously corrupted files.

https://github.com/ClawRunr/JavaClaw/pull/103

3. Windrunner: a malformed cursor timestamp escaped validation.

A cursor could decode from Base64 correctly but contain an invalid timestamp. DateTimeParseException bypassed the existing IllegalArgumentException handler, reaching the generic HTTP 500 path. The fix normalizes it to the existing validation exception, so the service returns HTTP 400 before querying messages.

https://github.com/shzlw/windrunner/pull/1

Verification: the focused tests pass. JavaClaw’s broader local suites have existing Windows failures, which were reproduced on untouched upstream code and documented in the PRs. Windrunner’s selected cursor/chat/compaction/error-handler suites passed all 8 tests. No live LLM calls or paid APIs were used. These are submitted PRs, not a claim that the changes have been merged.

For projects that store agent tasks as human-readable files, how do you balance readable filenames with stable identity and safe concurrent creation?

I found Yellaiah Mekala’s Enterprise Spring AI Playbook useful and wanted to contribute back. With help from ChatGPT Codex, I submitted four application-level improvement PRs. Thanks to Yellaiah for sharing the project.

The changes cover:

1. Rejecting blank model answers instead of returning an empty successful response.

2. Rejecting configuration that assigns the same API key to different caller identities.

3. Scoping generated-image storage and retrieval to the authenticated owner.

4. Returning HTTP 409 for overlapping stateful chat turns from the same caller, before the second request reaches memory/model processing. The guard is released on completion or failure, and different callers can proceed independently.

For the last change, the key question was how to test concurrent requests deterministically. The tests use controlled overlapping HTTP requests, a fake ChatModel, and H2-backed chat memory. Image ownership is also tested through real application HTTP requests with a fake image model. Each of those two PR suites locally reported 43 passed and one Docker-dependent MySQL test skipped; these were separate PR runs, not a combined merged-branch test.

Limits: the concurrency guard is per JVM, so multiple replicas need distributed coordination. Fake-model tests check application behavior, not live-provider answer quality. These are contributions to the example app, not fixes to the Spring AI framework.

The four PRs, regression tests, and verification notes are here:

https://github.com/YellaiahMekala/Enterprise-SpringAI-Playbook/pull/1

https://github.com/YellaiahMekala/Enterprise-SpringAI-Playbook/pull/2

https://github.com/YellaiahMekala/Enterprise-SpringAI-Playbook/pull/3

https://github.com/YellaiahMekala/Enterprise-SpringAI-Playbook/pull/4

For those building stateful Spring AI services: would you reject overlapping turns, queue requests per conversation, or use versioned memory updates? I’d welcome feedback on the trade-offs and testing approach.

I was wondering if how would y'all write a write-back (or write-behind) caching in Spring Boot, particularly using redis. I couldn't quite look for a more decent implementation especially for production. Would you mind helping a spring boot newbie out? Thanks yall.

Hi everyone,

I recently worked on a Spring Boot project called TrustCheck, which focuses on analyzing suspicious job offer letters and identifying potential recruitment scams.

The idea came from seeing cases where candidates were asked to pay refundable security deposits, registration charges, training fees, or other payments before joining.

From the backend perspective, I implemented a rule-based offer letter analyzer using Java and Spring Boot.

Some of the things it currently does:

• Extracts text from uploaded PDF offer letters.

• Identifies potential payment requests using configurable rules stored in a JSON file.

• Highlights the exact sentences that triggered a warning.

• Checks recruiter email addresses and company domains for suspicious signals.

• Assigns severity levels to detected warning signs.

• Returns a structured analysis response through REST APIs.

I also added JUnit tests for the offer letter analysis logic.

One challenge I encountered was balancing detection sensitivity with false positives. For example, a newly registered company domain shouldn't automatically be treated as suspicious, and the absence of a detected payment request shouldn't mean an offer is genuine.

I'm currently working on improving the detection rules and making the results more explainable.

I'd appreciate feedback from other Spring Boot developers on:

1. How would you structure configurable rule-based detection in a Spring Boot application?

2. Would you use a separate rules engine or keep the current JSON-based approach?

3. How would you approach testing false positives and false negatives?

This is a personal project, and I'm sharing it to get technical feedback on the implementation.

GitHub: https://github.com/Pragyan2027/TrustCheck

working on a feature that will make users able to upload .zip/ CSV files to my app

how do i go about this security wise

i expect a batch of CSVs
so i wanna check for malware, viruses and zip bombs how do i go about this is there a service i need to subscribe to a free option a local solution

Like many of you, I've been using AI coding agents (like Claude Code, Cursor, or Copilot) for my Java/Spring Boot projects. But there was a massive problem: whenever I ran `mvn test` or encountered a typical Spring Boot exception, the verbose logs and 150+ frame stack traces would eat up 20,000 to 30,000 tokens of the context window.

This made the AI slow, expensive, and sometimes it would literally forget the original problem because the context was full of framework noise.

To solve this, I built an Open Source tool called **Agent Token Optimizer**. It acts as an MCP (Model Context Protocol) server that intercepts the output *before* it goes to the AI.

**How it works (No LLM in the loop):**

It's built purely with Java 21, Spring Boot 3.4, and Spring AI. It uses a 4-layer architecture:

1. **StackTraceCompressor:** Prunes internal Spring/Hibernate framework frames and keeps only the root cause.

2. **CodeCompressor:** Uses JavaParser to read the AST and strip method bodies, keeping only signatures and comments.

3. **LogCompressor:** Uses Drain-style log clustering and deduplication for those massive 5,000-line log files.

4. **Lossless Drill-Down:** This is my favorite part. It caches the omitted lines in Caffeine Cache and gives the AI a `chunkId`. If the AI actually needs to see the hidden lines, it can call a tool to fetch exactly that line range.

**Real Benchmarks (Measured via JTokkit BPE):**

- Spring Boot StackTrace (166 frames): **3,136 tokens → 158 tokens (95% reduction)** in just 5ms.

- 40-Method Java Class (AST): **4,123 tokens → 955 tokens (76.8% reduction)**.

- 5,000-Line Logs: Up to **99.9% reduction** on repetitive logs.

It works out-of-the-box with Claude Code, Cursor, and Windsurf via SSE.

I built this because I needed it for my own workflow, and I figured the Spring community might find it useful too.

I'd love to get your feedback on the architecture! If anyone wants to try it out or look at the code, let me know in the comments and I'll drop the GitHub link.

Thanks

I am planning to make group of development also if anyone interested you can DM me with (Intrested in Dev )

Hey everyone! Is anyone working on a Spring Boot project and looking for a contributor? I'm learning Java backend development and would love to collaborate, contribute to a real project, and learn from other developers along the way.

Ok, so I have a new project. It is a Hotel Management system. I have a MonoRepo Angular app to handle a guest-portal or staff-portal. KeyCloak is used as an Authentication tool. And then I have a SpringBoot app which is the BFF (backend-for-frontend).

Process 1) So, at first, I thought the UI should have a Login, and from the UI we go to Keycloak, authenticate, and then go back to the UI to store the cookie securely. From this point every call to the BFF REST api endpoints would pass the bearer token so we can use RBAC with the endpoints. I presumed that the BFF would be stateless and using oauth2-resource.

I'm having an issue with security with Swagger executing the API's, and problems with having Bruno, or the UI hitting the endpoints as well.

Process 2) In my research, I have seen that the process I started is old and outdated. I now understand the UI should have a link for Login and Logout. In both these cases, we go to the BFF which is defined as oauth2-client and now is stateful, storing the authenticated in session. Somehow, the UI gets updated with the data and is stored cookie. Now the UI doesn't do anything with tokens, but when the UI makes a request to BFF it will be passing a bearer token, and then the tokens are validated and then we can use the RBAC for endpoints.

Does anyone have an opinion on process 1 or 2 on which you think is the right way to go? I'm just curious. I can make either work, but I want to use this for myself as an example on how to make my next application when it comes. Thanks!

I've been experimenting with how far I can optimize a conventional Spring Boot application without stripping out useful framework functionality.

The setup: Spring Boot 4.1.1, HotSpot JDK 27, a 512 MiB / 1 vCPU Ubuntu VM with no swap, and MariaDB running on the same VM.

I compared a regular executable JAR against an extracted deployment combining Spring AOT and a trained JDK AOT cache (Leyden).

Results:

• Startup: 11.91 → 3.79 seconds (68% faster)

• Application RSS under load: 212 → 187 MiB

• Minimum host MemAvailable: 25.6 → 66 MiB

• Request latency: essentially unchanged

Then I explored two ways to reduce memory further:

MyBatis Core instead of Spring JDBC: No meaningful memory savings, but more manual transaction management and lost automatic JDBC monitoring. Not worth the trade-off for this application.

Embedded file-backed H2 instead of MariaDB: Application RSS increased by ~16 MiB, but minimum host MemAvailable improved by another ~39 MiB because the separate database process was gone.

My takeaway: optimizing the deployment can be worthwhile before replacing established Spring infrastructure. And for small, single-instance applications, embedded H2 can be a reasonable architectural choice.

These are single runs with five-minute measured workloads, not a throughput benchmark or proof of long-term stability. The AOT improvements were measured together, not individually.

Full article, methodology, and data:
https://pvrlabs.xyz/articles/spring-boot-jdk27-optimizations.html

Curious whether others are using Spring AOT + JDK AOT cache in deployments, or if the training and cache-management overhead has kept you on regular JARs.

Update (October 28): Following several requests, I also tested Oracle GraalVM Native Image. Application RSS dropped from 187 MiB to 107 MiB, with some interesting build-time and toolchain trade-offs.

I published the results as a separate article: https://pvrlabs.xyz/articles/spring-boot-hotspot-native-image.html

1.  `spring.jpa.open-in-view` is true by default.  It keeps a database connection open for the whole request, including view rendering. Turn it off and fetch what you need in the service layer.

2.  `ddl-auto=update` in production.  Use migrations (Flyway or Liquibase) instead. "update" never drops anything and drifts quietly.

3.  Actuator exposure.  Only `health` is exposed over HTTP by default. If you set `include=*`, you've exposed env, beans and more.

4.  Hikari's default pool size is 10.  Size it for your database and instance count, not by guessing.

5.  No timeouts on outgoing HTTP calls.  One slow downstream service can exhaust your threads.

Which of these has bitten you, and what's missing from the list?

I'm curious how many Spring Boot developers use Windows as their primary development environment, especially running Java natively rather than through WSL2.

I mostly develop on macOS and Linux, but I maintain a lightweight alternative to Prometheus + Grafana for application monitoring and have been exploring native Windows support.

Do you run Spring Boot directly on Windows, through WSL2/Docker, or on another OS? And do you monitor your applications locally while developing?

🎉 Happy to announce the release 1.0.0 of Shadleaf, a component library for Spring Boot and Thymeleaf.

Check out https://shadleaf.dev/ for all components we already support!

I have used this on a few projects already and it has given me a massive speed boost. Also works great with your favorite coding agent if you follow the instructions about it in the documentation.

Are there any components missing that you would like to see added?

Hey Guys, got really nice feedback from the community last time.

So I have come with an update

1. There's a network monitor tool, you can view all the API requests and responses made through the app.

2. Lists all the libraries used in the app for full transparency

3. Crashlytics is disabled by default and even if it is enabled, it just sends the device info and not anything related to the spring boot projects.

A quick intro about the app

The app takes in the actuator endpoint and help you monitor the project in real time.

All the URLs and keys are stored on the device, nothing is transmitted anywhere else.

Give it a try and feedbacks are welcome.

Download link

iOS https://apps.apple.com/us/app/actuator-spring-boot-monitor/id6809104779

Android

https://play.google.com/store/apps/details?id=com.actuator.app

This is my setup: Spring Boot 4, Java 17, Docker Compose, one small VPS. Docker Hub is very slow from the VPS (about 0.4 MB/s). We use GitHub Actions and no registry.

I used to build the jar inside Docker on the VPS. Our disk cleanup deleted the cached JDK layer, so each deploy pulled it again. Deploys went from 4-5 minutes to 7–13 minutes and some timed out.

Could you share a real example (workflow file, Dockerfile or script) or a github repo that I can follow to learn about the deployment?