1. Overview

MCP (Model Context Protocol) is an open-source, JSON-RPC-based (JavaScript Object Notation-Remote Procedure Call) protocol. It provides a standardized way for AI (Artificial Intelligence) applications to connect to external tools, services, and data sources. Therefore, it eliminates the need for custom integrations.

Logging in MCP gives servers a standardized way to send structured, severity-tagged log messages to clients. This might be especially useful while debugging an MCP server.

In this tutorial, we’ll discuss MCP logging in Spring AI. Firstly, we’ll give brief information about MCP logging. Then, we’ll discuss logging both in an MCP server and client.

2. Basic Information About MCP Logging

An MCP server pushes log messages to an MCP client as notifications/message JSON-RPC notifications. This one-way notification message from the server to the client contains a severity level, an optional logger name, and the log message.

The MCP client can send the logging/setLevel JSON-RPC request to the server to configure log-message verbosity. Consequently, the server only sends log messages that meet or exceed the requested severity level. The client can dynamically adjust log verbosity by issuing another logging/setLevel.

An important caveat is that the July 2026 spec revision (2026-07-28) formally deprecated the logging feature along with other features, in favor of newer mechanisms. However, existing implementations will continue to work for at least a year. It’s recommended that newer implementations migrate to using stderr (standard error) for the stdio (standard input/output) transport and OpenTelemetry for structured observability.

3. Maven Dependencies

Let’s start by adding the necessary Maven dependencies to our pom.xml:

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-server</artifactId>
</dependency>

The MCP client starter dependency enables a Spring AI application to connect to MCP servers and use their tools. On the other hand, we use the MCP server starter dependency to turn a Spring Boot application into an MCP server. The dependency lets the application expose tools and resources to other LLM (Large Language Model) applications.

We use the Spring AI BOM (Bill of Materials) to avoid the risk of version conflicts between Spring AI dependencies:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-bom</artifactId>
            <version>${spring-ai.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Therefore, we don’t have to specify the versions of MCP starters explicitly.

4. Logging on the Server Side

Let’s start by discussing logging in the MCP server. The server we’ll discuss exposes a tool that an MCP client can run whenever a user requests a password strength evaluation.

4.1. Tool Implementation

The PasswordStrengthService class holds the actual tool implementation, the checkStrength() method exposed by the @McpTool server annotation. It’s a Spring bean since it’s annotated with @Service:

@Service
public class PasswordStrengthService {
    ...
    @McpTool(name = "check_password_strength", 
      description = "Evaluates password strength and returns a score with recommendations.")
    public PasswordStrengthResult checkStrength(
        @McpToolParam(description = "The password to evaluate", required = true) String password,
	  McpSyncRequestContext ctx) {
        ...
    }
}

The checkStrength() method, i.e., the tool, takes two parameters. The first one is the password to be evaluated. The tool checks whether the password is at least 12 characters long, contains at least one uppercase letter, and contains at least one digit. It also checks whether the password matches common passwords such as “123456” or “qwerty”.

The second parameter is of type McpSyncRequestContext, which we’ll use for logging. The Spring AI MCP annotations framework injects it automatically. An MCP server uses an object of this special type to log messages. It doesn’t write the log messages directly to the stdout (standard output) stream. Instead, it packages them into standard MCP protocol notification payloads and sends them over the transport layer, like stdio or SSE (Server-Sent Events), to the client. We use the stdio transport in our example.

The McpSyncRequestContext interface provides several logging methods such as debug(), info(), warn(), and error(). For example, if the password matches a common password, we log it using the ctx.error(“Password found in common-password list”) call in our example:

if (COMMON_PASSWORDS.contains(password.toLowerCase())) {
    ctx.error("Password found in common-password list");
    issues.add("commonly used");
}

Therefore, on the server side, we can choose the logging level per call.

4.2. MCP Server

The McpLoggingServerApplication class provides the Spring Boot entry point for the MCP server process:

@SpringBootApplication
public class McpLoggingServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(McpLoggingServerApplication.class, args);
    }
}

When the server process starts, Spring AI’s MCP server auto-configuration scans for methods annotated with @McpTool. Then, it registers and exposes the detected tools over the stdio transport. A connected client can therefore discover and call them.

We need to enable the stdio transport in the server’s configuration file, application-server.properties:

spring.ai.mcp.server.stdio=true

Besides, we must prevent the server application from printing logs to stdout. The stdout stream is dedicated to exchanging the MCP protocol’s JSON-RPC messages:

spring.main.web-application-type=none
spring.main.banner-mode=off
logging.pattern.console=

Setting spring.main.web-application-type to none prevents Spring Boot from starting a web server. This means that no web-related startup logs are emitted. Setting spring.main.banner-mode to off suppresses the Spring Boot banner that is normally printed to stdout on startup. Finally, logging.pattern.console= strips the pattern formatting in logs.

5. Handling Logs on the Client Side

Let’s now discuss logging in the MCP client.

5.1. MCP Client

Similar to McpLoggingServerApplication, the McpLoggingClientApplication class provides the Spring Boot entry point for the MCP client process:

@SpringBootApplication
public class McpLoggingClientApplication {
    public static void main(String[] args) {
        SpringApplication.run(McpLoggingClientApplication.class, args);
    }
}

On startup, the client boot starter reads the spring.ai.mcp.client.stdio.connections.* properties in the application-client.properties file and launches the server as a child process. For example, the configuration property spring.ai.mcp.client.stdio.connections.password-strength-logging-server.args specifies which arguments the client passes to the server when spawning it. The stdio segment in these configuration properties selects the stdio transport for the named connection, password-strength-logging-server.

The spring.ai.mcp.client.type=SYNC configuration property selects the synchronous client implementation, i.e., McpSyncClient. Therefore, client calls block until the server responds.

5.2. Logging Handler

To capture the notification logs sent by the server on the client side, we have to use the @McpLogging client annotation:

@Component public class PasswordStrengthMcpClientHandlers {
    ...
    @McpLogging(clients = "password-strength-logging-server")
    public void handleLoggingMessage(McpSchema.LoggingMessageNotification notification) {
        LOGGER.info("Received server logging notification [{}]: {}"
          , notification.level(), notification.data());
        receivedLogs.add(notification);
    }
    ...
} 

@McpLogging is a Spring AI MCP annotation that registers a method as a notification handler for a specific MCP client connection. The handler’s name is handleLoggingMessage() in our example. The connection’s name is password-strength-logging-server, which matches the ID configured for the stdio connection in the server’s configuration file, application-server.properties:

spring.ai.mcp.server.name= password-strength-logging-server

The handler’s parameter, notification, is the deserialized payload of an MCP logging notification. Its level() method prints the log severity (e.g., DEBUG, ERROR). Its data() method, on the other hand, contains the actual log sent by the server.

We’ve already seen that the server can choose the logging level per call since the McpSyncRequestContext interface provides several logging methods such as warn() and error(). However, the client can set the server’s logging level. Therefore, the server can filter out notification messages at a specific level and below:

mcpSyncClient.setLoggingLevel(McpSchema.LoggingLevel.WARNING);

Here, this client-side call instructs the server to filter out anything below WARNING. For example, the server doesn’t send notifications with DEBUG or INFO levels.

6. An Example

When we send “weak“ as the password to be evaluated by the MCP server, the logging handler prints the following list of log messages:

Received server logging notification [WARNING]: Password shorter than recommended 12 characters
Received server logging notification [WARNING]: Password missing uppercase letters
Received server logging notification [WARNING]: Password missing digits
Received server logging notification [INFO]: Final score: 25

This is expected since the password “weak“ is shorter than 12 characters and doesn’t contain uppercase letters and digits. It only satisfies the common password criterion. Therefore, it gets a final score of 25 out of 100.

Our example consists of only an MCP server and client. But if the client were an LLM-orchestrated agent, a list of transactions similar to the following list would have occurred:

• User -> Client: The user asks the following question: “How strong is the password weak?”
• Client -> LLM: The client sends the user’s message to the LLM together with the tool information received from the MCP server at session start
• LLM -> Client: The LLM doesn’t call the server itself. Instead, it returns a response that indicates that it wants to call the tool checkStrength with password=weak
• Client -> Server: The client issues the actual JSON-RPC request over the stdio transport
• Server -> Client: The server returns the response we saw earlier as a JSON-RPC response
• Client -> LLM: The client forwards the tool result back to the conversation and asks the LLM to continue
• LLM –> User: The LLM generates a natural-language answer synthesizing the structured result from the tool, something like: “That password is very weak. It’s only 4 characters long — you’ll need at least 12 — and it doesn’t include any uppercase letters or digits. I can make suggestions if you like.“

7. Conclusion

In this article, we discussed MCP logging in Spring AI. Firstly, we learned about how logging works within the MCP ecosystem. Then, we examined the details of MCP logging on an MCP server evaluating a password’s strength. We saw that we can use the logging methods in the McpSyncRequestContext interface to print log messages at different severity levels.

Then, we discussed logging on the MCP client. We learned that we can use a handler annotated with @McpLogging for handling logs. Finally, we saw an example using the server and client and discussed the interaction between an LLM, the client, and the server when a user asks for an evaluation of a password’s strength.

As usual, the complete source code for the examples is available over on GitHub.

The post MCP Logging in Spring AI first appeared on Baeldung.

       

1. Spring and Java

>> Project Loom in IntelliJ IDEA: Virtual Threads, Scoped Values, and Structured Concurrency [jetbrains.com]

A hands-on tour of the three Loom pillars: virtual threads, scoped values, and structured concurrency. This show you exactly what each feature buys and the tooling coming along with it. Solid stuff.

Also worth reading:

• >> Post-Quantum Cryptography in Spring Boot: Four Patterns You Can Ship This Sprint [infoq.com]
• >> The Grails Plugin Has a New Home: Apache Grails [jetbrains.com]
• >> Module Imports [javaspecialists.eu]

Webinars and presentations:

• >> Episode 68 “Operator Overloading with Type Classes” [AtA] [inside.java]
• >> A Bootiful Podcast: Joe Grandja on Spring Authorization Server, OAuth, and so much more [spring.io]
• >> Spring Office Hours Podcast: S5E21 – Pro Spring Boot 4 with Felipe Gutierrez [spring.io]

Time to upgrade:

• >> IntelliJ IDEA 2026.2.2 Is Out! [jetbrains.com]
• >> Compose Multiplatform 1.12.0 Released [jetbrains.com]
• >> Quarkus Flow 1.0.0 released [quarkus.io]
• >> Quarkus 3.39 – Post-quantum cryptography support in TLS registry [quarkus.io]
• >> WildFly 41.0.1 is released! [wildfly.org]
• >> JHipster v9.3.0 [github.com/jhipster]
• >> Vert.x 4.5.33 and 5.1.7 [github.com/eclipse-vertx]
• >> Elasticsearch 9.4.6 and 8.19.21 [github.com/elastic]
• >> Zuul v4.1.5 [github.com/Netflix]
• >> Micronaut Core 5.1.13 [github.com/micronaut-projects]
• >> Helidon 4.5.4 [github.com/helidon-io]

2. Technical & Musings

>> Maybe We Shouldn’t Be Reviewing All This Code [martinfowler.com]

PR sizes really are ballooning, but the fix isn’t automating review away, it’s noticing that we’d been leaning on review to carry things that belongs much earlier in the flow. An interesting weekend read.

Also worth reading:

• >> AI-assisted genealogy [frankel.ch]
• >> DuckDB and the changing physics of analytics [allthingsdistributed.com]
• >> Making Your Data Ready for Agentic AI [martinfowler.com]
• >> An Accidental Blackboard [martinfowler.com]
• >> MAPS: Netflix’s Multimodal Asset Personalization at Scale [netflixtechblog.com]
• >> Running Apache Spark experiments in my sleep (and on a plane) [netflixtechblog.com]
• >> You Can’t “Vibe Code” Love [codinghorror.com]

3. Pick of the Week

And from last week, the free, fully virtual conference for our ecosystem:

>> IntelliJ IDEA Conf 2026 [jetbrains.com]

The post Java Weekly, Issue 662 first appeared on Baeldung.

       

1. Overview

LLM streaming delivers output token by token as it’s generated. This reduces latency, as users see the first results in the UI within milliseconds instead of waiting seconds for a complete answer.

For agents with structured output and reasoning-aware agents, streaming should enable incremental processing:

• parsing responses into Java objects as they arrive, and
• processing thinking blocks as they arrive as well

However, current major frameworks don’t support these functionalities.

In this tutorial, we’ll:

• briefly review the limitations of these frameworks
• and show how to use the Embabel Agentic AI Framework to process objects and thinking blocks incrementally, as they arrive in a stream

We’ll cover four cases:

• one object without reasoning
• multiple objects without reasoning
• multiple objects with reasoning but without tool calls
• multiple objects with both reasoning and tool calls

2. Structured Streaming: Framework Limitations

The major Java frameworks for LLM integration, Spring AI and LangChain4j, support streaming at a limited level. We can get a live stream of text as the model generates it, but neither framework turns that stream into a collection of typed objects out of the box.

The Spring AI’s entity() method, which converts model output into a Java object, works with the blocking call() method but not with stream(). The ChatClient API reference spells this out directly: “In the future, we will offer a convenience method that will let you return a Java entity with the reactive stream() method. In the meantime, you should use the Structured Output Converter.” 

LangChain4j has the same limitation. Its AiServices allows returning custom POJOs, lists, and enums only for non-streaming calls. For streaming, the return type must be a TokenStream, which gives us raw text as it arrives, plus rich callback hooks, but doesn’t provide typed objects as stream output.

In practice, anyone who wants a stream of structured objects with reasoning has to build that functionality themselves, as in this Baeldung’s article. This means choosing an NL-delimited format like JSONL, buffering tokens until a full line is available, parsing each line as JSON, and filtering out any thinking blocks along the way. Implementing this takes time away from the actual project.

This is where Embabel Agentic AI comes in handy. It natively provides the desired functionality, which we further explore.

3. Setup

First, let’s define the necessary Embabel dependencies:

<dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-starter-anthropic</artifactId>
    <version>${embabel-agent.version}</version>
</dependency>
<dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-test-internal</artifactId>
    <version>${embabel-agent.version}</version>
    <scope>test</scope>
</dependency>

The embabel-agent-starter-anthropic dependency provides the core classes we need to use Anthropic models with Embabel. In the examples in this tutorial, we use the Anthropic model claude-sonnet-4-5.

Additionally, we include embabel-agent-test-internal to use the AgentTestApplication test support class with @SpringBootTest.

3.1. Provider Support in Embabel

Note that model providers differ in how they combine streaming with thinking and tools. Anthropic’s native thinking produces explicit reasoning blocks, but other providers may not surface reasoning in the same way.

Embabel supports over a dozen LLM providers, with examples using OpenAI published on Baeldung in the past.

3.2. ParkingRecommendation

We’ll stream ParkingRecommendation objects in all tests throughout the article:

The record includes four scalar properties: parking scenario (scenario), chosen option cost (estimatedTotalCost), summary, and chosen option (enumeration Option).

4. Streaming a Single Object

void whenStreaming_thenReceivesParkingRecommendation() {
     streamParkingRecommendations(PARKING_PROMPT);
  }

Flux<ParkingRecommendation> stream = new StreamingPromptRunnerBuilder(runner)
  .streaming()
  .withPrompt(PARKING_PROMPT)
  .createObjectStream(ParkingRecommendation.class);
stream
  .timeout(Duration.ofSeconds(120))
  .doOnNext(rec -> {
    received.add(rec);
    logger.info(
      "Received parking recommendation: scenario={}, option={}, cost={}, summary={}",
      rec.scenario(),
      rec.chosenOption(),
      rec.estimatedTotalCost(),
      rec.summary());
    }).blockLast(Duration.ofSeconds(240));

$ mvn test -pl embabel-streaming -P integration -Dtest=StreamingWithThinkingAndToolingIntegrationTest#whenStreaming_thenReceivesParkingRecommendation

17:34:13.781 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Midtown Manhattan parking for 3-hour client meeting with 30-minute arrival buffer, option=GARAGE, cost=90, summary=Choose garage parking. The meeting duration (3 hours) exceeds the metered parking limit (2 hours), eliminating that option. Street parking in Midtown Manhattan is extremely unreliable and searching could make you late for the meeting. The guaranteed spot and ability to stay for the full meeting duration justifies the $90 cost for this professional context.

void whenStreamingMultipleScenarios_thenReceivesRecommendationPerScenario() {
    streamParkingRecommendations(TIMED_PARKING_PROMPT);
}

$ mvn test -pl embabel-streaming -P integration -Dtest=StreamingWithThinkingAndToolingIntegrationTest#whenStreamingMultipleScenarios_thenReceivesRecommendationPerScenario

18:31:24.200 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Early morning (before 8am), option=STREET, cost=0, summary=Arrive before 8am to take advantage of free street parking. Meters are not enforced until 8am, providing zero-cost parking. Be prepared to feed the meter or move to a garage if your meeting extends past 8am.
18:31:27.354 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Business hours (9am-5pm), option=GARAGE, cost=45, summary=For a 3-hour business meeting with only a 30-minute arrival window, a parking garage is the most reliable option. Street parking in Midtown is extremely competitive during peak hours, and the time spent searching could cause you to miss your meeting. Garage rates typically range $35-55 for 3 hours in Midtown Manhattan.
18:31:28.889 [HttpClient-4-Worker-0] WARN  StreamHelper - Unhandled event type: CONTENT_BLOCK_STOP
18:31:28.895 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Evening (after 6pm), option=STREET, cost=0, summary=Street meters become free after 6pm, making this the best option if you're confident your 3-hour meeting will end before 9pm. However, have a backup plan: identify a 24-hour garage nearby in case your meeting runs late, as many garages close at 9pm and you could be locked in or locked out.

void whenStreamingWithThinking_thenReceivesReasoningAndRecommendation() {
    LlmOptions thinkingOptions = new LlmOptions().withThinking(Thinking.withTokenBudget(8000));
    PromptRunner runner = ai.withDefaultLlm().withLlm(thinkingOptions);
    streamParkingRecommendationsWithThinking(runner, TIMED_PARKING_PROMPT);
}

Flux<StreamingEvent<ParkingRecommendation>> stream = new StreamingPromptRunnerBuilder(runner)
  .streaming()
  .withPrompt(prompt)
  .createObjectStreamWithThinking(ParkingRecommendation.class);

.doOnNext(event -> {
  if (event.isObject()) {
      ParkingRecommendation rec = event.getObject();
      if (rec != null) {
          received.add(rec);
          logger.info("Received recommendation: scenario={}, option={}, cost={}, summary={}",
            rec.scenario(), rec.chosenOption(), rec.estimatedTotalCost(), rec.summary());
      }
  } else if (event.isThinking()) {
      reasoning.add(event.getThinking());
      logger.info("Received reasoning: {}", event.getThinking());
  }
})

$ mvn test -pl embabel-streaming -P integration -Dtest=StreamingWithThinkingAndToolingIntegrationTest#whenStreamingWithThinking_thenReceivesReasoningAndRecommendation

21:34:05.311 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: The user is asking for parking recommendations for Midtown Manhattan across three different time scenarios. I need to analyze each scenario and provide recommendations in JSONL format.
21:34:05.311 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Let me think through each scenario:
...
21:34:13.300 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Early morning (before 8am), option=STREET, cost=0, summary=Street parking is free before 8am in Midtown. Arrive early to secure a spot while meters are not enforced. No cost advantage to using garage or paid meter.
21:34:14.003 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: For business hours, considering reliability vs cost. 30-minute window suggests tight schedule, and 3-hour stay during peak hours means garage offers certainty despite higher cost
21:34:16.867 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Business hours (9am-5pm, 3-hour stay), option=GARAGE, cost=35, summary=During peak business hours with only a 30-minute arrival window, garage parking ($30-40 for 3 hours) provides guaranteed availability and eliminates time spent searching. Street meters ($12-15 for 3 hours) are cheaper but finding spots in Midtown during business hours is challenging and risky given the tight timeline.
21:34:18.275 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: Evening scenario has free street parking but garage closure risk. If arriving at 6pm with 3-hour stay, would exit at 9pm exactly when garages close - cutting it too close. Street parking is free and has no closure risk
21:34:19.337 [HttpClient-4-Worker-0] WARN StreamHelper - Unhandled event type: CONTENT_BLOCK_STOP
21:34:19.359 [boundedElastic-1] INFO StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Evening (after 6pm, 3-hour stay), option=STREET, cost=0, summary=Street meters are free after 6pm, making this the clear choice. Additionally, with garages closing at 9pm and a 3-hour stay, there's significant risk of garage closure before departure. Street parking eliminates both cost and time constraints.

void whenStreamingWithThinkingAndTooling_thenReceivesRecommendationAndReasoning() {
    PromptRunner runner = ai.withDefaultLlm()
      .withToolObject(new ParkingTooling())
      .withToolCallInspectors(new ToolCallLoggingInspector(LogLevel.INFO, logger));
    streamParkingRecommendationsWithThinking(runner, TOOL_PARKING_PROMPT);
}

$ mvn test -pl embabel-streaming -P integration -Dtest=StreamingWithThinkingAndToolingIntegrationTest#whenStreamingWithThinkingAndTooling_thenReceivesRecommendationAndReasoning

12:48:52.342 [HttpClient-4-Worker-0] WARN  StreamHelper - Unhandled event type: CONTENT_BLOCK_STOP
12:48:53.275 [boundedElastic-2] INFO  StreamingWithThinkingAndToolingIntegrationTest - beforeToolCall: tool=reserveGarage, argsLength=28
12:48:53.278 [boundedElastic-2] INFO  Embabel - [suspicious_tharp] calling tool reserveGarage({"arg0":"Midtown Manhattan"})
12:48:53.281 [boundedElastic-2] INFO  Embabel - [suspicious_tharp] tool reserveGarage returned Garage reserved near Midtown Manhattan ($30/hour, guaranteed) in 2ms with payload {"arg0":"Midtown Manhattan"}
12:48:53.284 [boundedElastic-2] INFO  StreamingWithThinkingAndToolingIntegrationTest - afterToolCall: tool=reserveGarage, status=Text, resultLength=61, durationMs=6
12:48:55.299 [boundedElastic-3] INFO  StreamingWithThinkingAndToolingIntegrationTest - beforeToolCall: tool=findStreetParking, argsLength=38
12:48:55.299 [boundedElastic-3] INFO  Embabel - [suspicious_tharp] calling tool findStreetParking({"arg1":30,"arg0":"Midtown Manhattan"})
12:48:55.300 [boundedElastic-3] INFO  Embabel - [suspicious_tharp] tool findStreetParking returned Street parking found near Midtown Manhattan (free) in 1ms with payload {"arg1":30,"arg0":"Midtown Manhattan"}
12:48:55.300 [boundedElastic-3] INFO  StreamingWithThinkingAndToolingIntegrationTest - afterToolCall: tool=findStreetParking, status=Text, resultLength=50, durationMs=1
12:48:56.953 [boundedElastic-4] INFO  StreamingWithThinkingAndToolingIntegrationTest - beforeToolCall: tool=findMeterParking, argsLength=38
12:48:56.954 [boundedElastic-4] INFO  Embabel - [suspicious_tharp] calling tool findMeterParking({"arg1":30,"arg0":"Midtown Manhattan"})
12:48:56.954 [boundedElastic-4] INFO  Embabel - [suspicious_tharp] tool findMeterParking returned No metered parking found within 30 minutes in 0ms with payload {"arg1":30,"arg0":"Midtown Manhattan"}
12:48:56.954 [boundedElastic-4] INFO  StreamingWithThinkingAndToolingIntegrationTest - afterToolCall: tool=findMeterParking, status=Text, resultLength=42, durationMs=1
12:48:58.801 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: I'll help you find the best parking options for your client meeting in Midtown Manhattan. Let me check all available parking options for you.Based on the parking options available, here are my three recommendations with the best option first:
12:49:00.945 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Advisor needs guaranteed parking for 3-hour meeting in 30 minutes, option=GARAGE, cost=90, summary=Reserve garage parking at $30/hour for 3 hours ($90 total). This is the BEST option because it's guaranteed and ensures you won't be late for your client meeting. With only 30 minutes until the meeting, reliability is critical.
12:49:03.093 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Advisor needs guaranteed parking for 3-hour meeting in 30 minutes, option=STREET, cost=0, summary=Free street parking is available but highly risky. While it costs nothing, finding a spot is uncertain and time-consuming in Midtown Manhattan. Given that arriving late is not acceptable and you only have 30 minutes, this option could jeopardize your meeting.
12:49:03.706 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received recommendation: scenario=Advisor needs guaranteed parking for 3-hour meeting in 30 minutes, option=METER, cost=0, summary=Metered parking is NOT available within your 30-minute timeframe in Midtown Manhattan. This option is not viable for your situation.
12:49:05.244 [HttpClient-4-Worker-0] WARN  StreamHelper - Unhandled event type: CONTENT_BLOCK_STOP
12:49:05.247 [boundedElastic-1] INFO  StreamingWithThinkingAndToolingIntegrationTest - Received reasoning: **Strong Recommendation: Choose the garage parking.** With only 30 minutes before your client meeting and the absolute requirement not to be late, the $90 guaranteed garage spot is the only responsible choice. The cost is a small price compared to the professional consequences of arriving late to a client meeting.

The post LLM Streaming in the Embabel Agentic AI Framework first appeared on Baeldung.

       

1. Spring and Java

>> JDK 27 and JDK 28: What We Know So Far [infoq.com]

JDK 27 has reached its first RC with compact object headers on by default, G1 as the default collector everywhere, and structured concurrency marching through its seventh preview. The JDK 28 train is already loading up, starting with an incubating Simple JSON API

Also worth reading:

• >> Security Baked Into the JVM: sixteen Subjects on the wire [frankel.ch]
• >> Scripting in small apps: you don’t need a container for a macro [foojay.io]
• >> The Third-Generation GUI Builder: One Workspace for Every Form [foojay.io]
• >> Value Classes Still Need Compiler Sympathy [johan-sjolen.github.io]
• >> Quality Outreach Heads-up – JDK 28: Named Group Information Captured in the TLSHandshake JFR Event [inside.java]
• >> Spring Boot Configuration Management Best Practices [jetbrains.com]

Webinars and presentations:

• >> Episode 67 “Keeping Up With the Java Release Train” [I/O] [inside.java]
• >> A Bootiful Podcast: JRuby lead Charles Nutter [spring.io]

Time to upgrade:

• >> Spring Boot 4.1.1 available now and 4.0.8 [spring.io]
• >> Spring AI 2.0.1 Available Now [spring.io]
• >> Spring Cloud 2025.1.3 (aka Oakwood) has been released [spring.io]
• >> Spring Batch 6.0.5 and 6.1.0-M1 available now [spring.io]
• >> Spring Modulith 2.2 M1, 2.1.1, 2.0.8, and 1.4.13 released [spring.io]
• >> BoxLang 1.16.0 Released! [foojay.io]
• >> Announcing Oracle Jipher 10.37: FIPS 140-3 Cryptography for Java [inside.java]
• >> GraalVM Community 25 Innovation 3 (graal 25.3.4.1) [github.com/graalvm]
• >> Quarkus 3.39.1 and 3.39.0 [github.com/quarkusio]
• >> Elasticsearch 9.5.2 [github.com/elastic]
• >> Grails 7.2.3, 7.1.6 and 7.0.16 [github.com/apache]
• >> Micronaut Core 5.1.12 [github.com/micronaut-projects]
• >> Azul Payara Community 7.2026.8 [github.com/payara]
• >> Micrometer 1.17.1 and 1.16.7 [github.com/micrometer-metrics]

2. Technical & Musings

>> Netflix Conductor: The Next Chapter [netflixtechblog.com]

Netflix open-sourced Conductor back in 2016, and this post traces its evolution into a mature orchestration engine — plus what’s next for the project now that it has a dedicated maintainer team and a renewed roadmap. Good context for anyone running workflow orchestration at scale.

Also worth reading:

• >> Fast and Hard Code [pocoo.org]
• >> Your First Virtual Machine: Write yourself a compiler, Part IV [nurkiewicz.com]
• >> Human-in-the-loop Authorization Patterns for Agents [christianposta.com]
• >> Find Git Commits by Commit Message Text [hamvocke.com]
• >> This Fact About KPIs May Surprise You [satisfice.com]
• >> Why agentic AI starts with legacy modernisation by Suzanne Angell [scottlogic.com]
• >> A Tale of Two Flink Autoscalers [netflixtechblog.com]
• >> Some reflections after a year with AI [tfnico.com]
• >> Migrating a Synology NAS to a UniFi UNAS Pro 8 with Robocopy, SMB Multichannel, and Surprising Performance Traps [hanselman.com]
• >> A Cautionary Tale About Data Breach Claims, Verification and Carhartt [troyhunt.com]

3. Pick of the Week

JetBrains is bringing IntelliJ IDEA Conf back in just one week, on September 8–9, 2026.

A free, fully virtual conference for developers working across the Java and JVM ecosystem:

>> IntelliJ IDEA Conf 2026 [jetbrains.com]

The post Java Weekly, Issue 661 first appeared on Baeldung.

       

1. Overview

When working with JSON in Java, Jackson usually handles Java 8 date and time types without much configuration. Yet, we can still encounter problems such as one of the common deserialization parse errors:

JSON parse error: Can not construct instance of java.time.LocalDate:
no String-argument constructor/factory method to deserialize from String value

In newer Jackson versions, the error text takes another form:

Cannot deserialize value of type java.time.LocalDate from String

Although the wording differs slightly, both errors indicate that Jackson is unable to convert the JSON value into a LocalDate or LocalDateTime.

In this tutorial, we’ll explore the JSON deserialization exception and ways around it. First, we demonstrate the issue with an example. After that, we go through different reasons for the problem at hand and how they can be addressed.

2. Understanding the Problem

Let’s write a basic User class:

public class User {
    private String name;
    private LocalDate dob;
    // getters and setters
}

Now, let’s assume we receive a matching JSON:

{
  "name": "x",
  "dob": "2006-06-06"
}

Instead of successfully deserializing the JSON, Jackson throws an exception similar to:

Can not construct instance of java.time.LocalDate:
no String-argument constructor/factory method to deserialize from String value

Notably, the JSON data appears to be valid, because the date already follows the ISO-8601 format expected by LocalDate. The problem usually isn’t the JSON itself but the configuration of Jackson. In fact, the root cause may be a missing Java Time module, an unsupported date format, or using the wrong Java date-time type for the incoming JSON.

3. Verify Jackson Version

Support for the Java Time API has evolved considerably across Jackson releases. Before delving into specific technical issues and code changes, we might consider the versions we’re using.

In Jackson 2.x, Java Time support is provided by the separate jackson-datatype-jsr310 module. In Jackson 3.x, this support is built into jackson-databind, so separate module registration isn’t required.

If the project uses an outdated Jackson version, upgrading Jackson may resolve deserialization issues without any code changes. When it comes to Jackson 2.x, we should also verify that the Java Time module is present and properly configured.

4. Ensure Java Time Support

The most common cause for the JSON error is that the Jackson configuration doesn’t support the Java 8 Date and Time API.

Unlike older types such as java.util.Date, classes like LocalDate, LocalDateTime, and Instant are provided through the Jackson Java Time module.

If this module is missing, Jackson attempts to instantiate LocalDate like a regular Java object. Since LocalDate has no default constructor or string constructor, deserialization fails.

So, assuming we decide on Jackson 2.x, let’s include the Java Time module dependency:

<dependency>
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-jsr310</artifactId>
    <version>2.22.1</version>
</dependency>

If an ObjectMapper is created manually, it should register the module:

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JavaTimeModule());

Still, Spring Boot performs this registration automatically when the module is present on the classpath.

5. Match JSON Date Format

Another common cause for JSON deserialization errors is the exact date format. If the incoming JSON doesn’t use the default ISO-8601 format expected by LocalDate and LocalDateTime, we might see an error.

For example, let’s see a JSON string that can’t be parsed automatically:

{
  "time": "10/20/2020 10:00:10 AM"
}

With the Java Time module registered, Jackson expects an ISO-8601 date-time for a LocalDateTime field by default:

2020-10-20T10:00:10

In such cases, when the JSON data uses another format, the field should specify the expected pattern:

public class ImportTrans {
    @JsonFormat(pattern = "M/d/yyyy h:mm:ss a")
    private LocalDateTime time;
}

However, this example also contains another hint. The JSON data can actually contain both a date and a time, while Java LocalDate fields only store a date.

6. Correct Java Time Type

LocalDate represents only a calendar date. In particular, it doesn’t contain any information about time of the day.

If the JSON data includes hours, minutes, or seconds, LocalDate is no longer the appropriate target type:

private LocalDate time;

Instead, we should probably use LocalDateTime:

private LocalDateTime time;

Furthermore, the matching format can then be declared with @JsonFormat:

@JsonFormat(pattern = "M/d/yyyy h:mm:ss a")
private LocalDateTime time;

Choosing the Java type that accurately represents the JSON payload is often the simplest solution.

7. LocalDateTime Has Similar Requirements

The same type of exception frequently appears when using LocalDateTime:

Can not deserialize value of type
java.time.LocalDateTime from String

Let’s consider the following JSON:

{
  "creationTime": "2016-06-16 06:56:00"
}

Same as before, since this format differs from the default ISO-8601 representation, Jackson requires an explicit pattern:

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
private LocalDateTime creationTime;

The ObjectMapper must also have the Java Time module registered, while the explicit pattern is still required for this non-ISO format.

8. Comparison

Now that we know different reasons for errors around parsing JSON with date-time values with Jackson, let’s see an overview of what we found out:

So, we can check the reference table whenever we encounter an unexpected error.

9. Conclusion

In this article, we explored the error stating that Jackson can’t construct an instance of LocalDate or LocalDateTime.

Specifically, we established that it generally indicates Jackson can’t determine how to convert the incoming JSON into a Java date-time object.

In conclusion, once the Java type, JSON payload format, and Jackson configuration are aligned, such deserialization errors should disappear and Java Time types should be handled transparently.

The post How to Fix Jackson JSON Parse Error Can not construct instance of java.time.LocalDate first appeared on Baeldung.

       

1. Introduction

In this tutorial, we’ll look at Microcks, an open-source, Kubernetes-native platform for turning API and microservices contracts into live mocks. We’ll also see how to reuse the same contracts to run conformance tests against a real implemenation.

We’ll cover the core concepts first, then use the Testcontainers integration to spin up Microcks inside a JUnit5 test, import an OpenAPI contract, call the generated mock, and validate a running service against it.

2. What Is Microcks?

Microcks is a CNCF (Cloud Native Computing Foundation) project for API mocking and testing. It consumes API and microservice artifacts, such as OpenAPI specs, AsyncAPI specs, gRPC protobuf files, GraphQL schemas, Postman collections, and SoapUI projects. Then, it turns them into live, stateful mocks in seconds.

Beyond mocking, Microcks reuses these same artifacts to run contract conformance and non-regression tests against a real API implementation. It also integrates with Jenkins, GitHub Actions and Tekton pipelines through a CLI, so both mocking and testing can be automated across the whole delivery chain.

We can run Microcks as a standalone server, using Docker Compose or a Kubernetes/Helm deployment. For local development and CI, though, it’s more convenient to embed it directly inside a test using the Testcontainers module.

Microcks isn’t limited to synchronous REST APIs, either. Through its ensemble mode, it can also mock and contract-test SOAP, GraphQL, and gRPC services, as well as event-driven APIs described with AsyncAPI, over brokers like Kafka, SQS or SNS. That means the same tool and the same workflow can cover most of the API styles a typical microservices architecture is likely to use.

3. Setting Up Microcks With Testcontainers

The microcks-testcontainers library lets us start a lightweight, throwaway Microcks instance for the lifetime of a test class.

First, let’s add the Maven dependency:

<dependency>
    <groupId>io.github.microcks</groupId>
    <artifactId>microcks-testcontainers</artifactId>
    <version>0.4.4</version>
</dependency>

Next, let’s create and start a MicrocksContainer, pointing it to an OpenAPI contract for our API:

MicrocksContainer microcks = new MicrocksContainer(
  DockerImageName.parse("quay.io/microcks/microcks-uber:1.14.0"))
  .withMainArtifacts("apipastries-openapi.yaml");
microcks.start();

The uber image bundles everything Microcks needs without an external MongoDB dependency, which keeps startup fast. We can also import artifacts after startup, using importAsMainArtifact() or importAsSecondaryArtifact() on the running container.

4. Mocking the API

Once the container has imported the contract, Microcks automatically exposes a mock endpoint for every operation. We can retrieve the base URL and call it like any real API:

String baseApiUrl = microcks.getRestMockEndpoint("API Pastries", "0.0.1");
HttpResponse<String> response = client.send(
  HttpRequest.newBuilder(URI.create(baseApiUrl + "/pastries/Millefeuille")).GET().build(),
  HttpResponse.BodyHandlers.ofString());
assertEquals(200, response.statusCode());

Microcks generates realistic responses straight from the examples defined in the OpenAPI contract. Then, it cycles through them so repeated calls don’t always return the same payload. This means consumers can be developed and tested against a dependency that doesn’t exist yet, or isn’t reacheable from a test environment.

Furthermore, there are ways we can confirm a mock was actually called. We’ll do this by either calling microcks.verify(“API Pastries”,”0.0.1″), or by checking the exact invocation count through microcks.getServiceInvocationsCount(“API Pastries”,”0.0.1″).

5. Running Contract Tests

The same contract can validate a real implementation running on our machine. First, we need to expose the port with Testcontainers.exposeHostPorts() before starting the container, not after. We do this since the Microcks container needs to reach back out to our host:

Testcontainers.exposeHostPorts(port);
microcks.start();

Then, let’s launch a conformance test against our locally running server:

TestRequest testRequest = new TestRequest.Builder()
  .serviceId("API Pastries:0.0.1")
  .runnerType(TestRunnerType.OPEN_API_SCHEMA.name())
  .testEndpoint("http://host.testcontainers.internal:" + port)
  .filteredOperations(List.of("GET /pastries/{name}"))
  .timeout(Duration.ofSeconds(2))
  .build();
TestResult testResult = microcks.testEndpoint(testRequest);
assertTrue(testResult.isSuccess());

We scoped the test to a single operation with filteredOperations(). Without it, Microcks also replays the GET /pastries and PATCH /pastries/{name} examples from the contract, which fail against an implementation that doesn’t cover them yet.

Here, Microcks replays every example from the OpenAPI contract against our running application and checks each response against the schema. For a more JUnit-friendly failure report, we can use the Assertions helper instead, Assertions.assertSuccess(testResult);

This single call runs the same conformance check that a CI pipeline would run against a live deployment, only locally and in milliseconds.

6. Conclusion

In this article, we introduced Microcks as a tool for turning API contracts into live mocks and reusing those same contracts for conformance testing. We used its Testcontainers integration to start a throwaway Microcks instance inside a JUnit test, import an OpenAPI contract, call the generated mock, and run a contract test against a live implementation.

Because mocks and tests are dervide from the same source contract, both stay in sync with the API definition. That removes a common source of drift between what an API promises and what it actually does.

As always, the code is available over on Github.

The post API Mocking and Testing With Microcks first appeared on Baeldung.

       

1. Introduction

It’s sometimes useful to limit the remote addresses that an HTTP client is permitted to call. It helps prevent applications from connecting to unintended destinations and provides an effective defense against Server-Side Request Forgery (SSRF) attacks. To limit the address that an HTTP client can call, we can use an InetAddressFilter. The filter determines which addresses are allowed for outgoing requests. In this tutorial, we’ll explore how to use the InetAddressFilter class in a Spring-based application.

2. Understanding SSRF in the Context of HTTP Clients

SSRF is a critical security vulnerability that allows an attacker to force a server to make requests to unintended locations. These requests may target internal systems, cloud metadata endpoints, or loopback addresses. To demonstrate how SSRF can occur in an HTTP client, let’s consider a simple endpoint that accepts a URL and uses RestClient to retrieve its contents:

@GetMapping("/fetch")
public String fetch(@RequestParam String url) {
    return restClient.get()
      .uri(url)
      .retrieve()
      .body(String.class);
}

The endpoint accepts a URL as a request parameter and forwards it to RestClient. The intention is to allow users to retrieve content from public URLs. For example, a legitimate request might look like:

curl --location http://127.0.0.1:8080/fetch?url=https://www.baeldung.com

However, an attacker could provide a URL that points to an internal resource instead:

curl --location http://127.0.0.1:8080/fetch?url=admin

Instead of contacting a public website, our server now makes requests to its own internal network. This can expose internal admin APIs, databases, Kubernetes services, etc. This class of vulnerability is known as SSRF. Historically, mitigating SSRF in Spring Boot applications required custom ClientHttpRequestInterceptor implementations or complex network-level firewalls. Spring Boot 4.1.0 introduces first-class support for SSRF mitigation via the InetAddressFilter interface.

3. Maven Dependency

Let’s start by importing the spring-boot-starter-restclient dependency to our pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-restclient</artifactId>
    <version>4.1.1-SNAPSHOT</version>
</dependency>

4. Introducing InetAddressFilter

The InetAddressFilter interface is a functional interface. Unlike validating the hostname or URL, InetAddressFilter performs its checks after DNS resolution. Spring Boot provides several built-in filters for common scenarios, such as allowing only public addresses (InetAddressFilter.externalAddresses()) or blocking special-purpose network ranges (InetAddressFilter.internalAddresses()). We can combine these filters using logical operators:

InetAddressFilter.of("192.168.0.0/16")
  .andNot("192.168.1.100");

The API also supports and(), or(), and negate() for composing more complex rules:

InetAddressFilter.externalAddresses()
  .or(InetAddressFilter.of("10.20.0.0"));

This enables expressive allowlists and blocklists without custom networking code.

5. Applying the Filter Globally

The simplest and most common approach is to declare an InetAddressFilter bean. Spring Boot then automatically applies it to every auto-configured HTTP client builder (RestClient, WebClient, RestTemplate, etc.). Let’s configure the InetAddressFilter to allow connections only to external IP addresses:

@Configuration(proxyBeanMethods = false)
public class HttpClientSecurityConfig {
    @Bean
    public InetAddressFilter httpClientInetAddressFilter() {
        return InetAddressFilter.externalAddresses();
    }
}

With this single bean, any client created from the auto-configured builders will reject requests whose resolved address is not external. Now, we can create a RestClient without any additional security configuration:

@Bean
RestClient restClient(RestClient.Builder builder) {
    return builder.build();
}

Because the RestClient.Builder has already been customized by Spring Boot, the resulting RestClient automatically uses the configured InetAddressFilter. As a result, any request whose resolved destination is not an external address—for example, a loopback or private IP address—is rejected before a connection is established. This approach centralizes the application’s outbound network policy in a single place and ensures that all auto-configured HTTP clients consistently enforce the same SSRF protection.

6. Applying the Filter Per-Client

In some scenarios, applying a global InetAddressFilter may be too restrictive. For example, an application might communicate with both public APIs and specific internal services, each requiring different outbound access rules. In such cases, we can apply an InetAddressFilter to an individual HTTP client by configuring the underlying HttpClientSettings when creating the client. Let’s create a RestClient that only allows requests to external addresses:

@Bean
RestClient restClient(RestClient.Builder builder) {
    InetAddressFilter onlyExternalAddresses = InetAddressFilter.externalAddresses();
    HttpClientSettings settings = HttpClientSettings.defaults()
      .withInetAddressFilter(onlyExternalAddresses);
    ClientHttpRequestFactory requestFactory = ClientHttpRequestFactoryBuilder
      .jdk().build(settings);
    return builder
      .requestFactory(requestFactory)
      .build();
}

Here, the filter is attached only to this specific RestClient instance. Other HTTP clients in the application can use different security policies or remain unaffected. This approach is useful when different integrations have different network requirements. For example, a client used to call third-party APIs can be restricted to public addresses, while another client used for communication with trusted internal services can use a more specific allowlist. By configuring the filter at the client level, we can apply fine-grained outbound request controls without changing the behavior of the entire application.

7. Test

To verify that the configured InetAddressFilter is applied, we can write a unit test that uses the configured RestClient bean to access a loopback address. The application is configured with InetAddressFilter.externalAddresses(), which permits only publicly routable IP addresses. Since 127.0.0.1 is a loopback address, the request is rejected before an HTTP connection is established. Let’s create a test case:

@Test
void whenCallingLoopbackAddress_thenFilteredHostExceptionIsThrown() {
    assertThatThrownBy(() ->
        restClient.get()
          .uri("https://127.0.0.1:8080")
          .retrieve()
          .toBodilessEntity()
    ).isInstanceOf(FilteredHostException.class)
     .hasMessageContaining("127.0.0.1");
}

When the test executes, the RestClient resolves the destination host and passes the resulting InetAddress to the configured InetAddressFilter. Because the address does not satisfy the externalAddresses() policy, Spring Boot throws a FilteredHostException and aborts the request before opening a network connection.

8. Conclusion

In this tutorial, we explored how SSRF can affect applications that make outbound HTTP requests based on user-controlled input. We also looked at how Spring Boot 4.1 simplifies SSRF mitigation with InetAddressFilter. It allows applications to validate the resolved destination address before establishing an outbound connection. The feature integrates with Spring’s HTTP client infrastructure, including both blocking and reactive clients, and provides a flexible API for composing allowlists and blocklists. By applying InetAddressFilter, we can enforce outbound network access policies at the HTTP client level. This reduces the risk of unauthorized access to internal resources while keeping the application code clean and maintainable.

As always, the source code is available over on GitHub.

The post HTTP Client SSRF Mitigation with InetAddressFilter in Spring Boot first appeared on Baeldung.

       

1. Introduction

In this tutorial, we’ll take a look at db-scheduler, a simpler alternative to Quartz. We’ll see what it is, how to use it and what we can do with it.

2. What Is DB-Scheduler?

DB-Scheduler is a cluster-aware, persistent scheduling library. It’s designed to be simple to include in our application. Our only requirements are Java 17+ and a JDBC connection to a database with a single database table in which we store and manage our tasks.

Using db-scheduler, we can easily support:

• One-time tasks: tasks that are scheduled to run once at a specific point in time
• Simple recurring tasks: tasks that are set up to run on a statically defined regular schedule
• Dynamic recurring tasks: tasks that run on a regular schedule, but that we can schedule dynamically at runtime

The db-scheduler library will then handle everything for us. This includes ensuring that these jobs run correctly across a cluster of services without dropping them or running them multiple times.

3. Setting Up

Before we can use db-scheduler, we need to first set it up in our application. This includes adding it to our project and getting it running.

3.1. Dependencies

Before using db-scheduler, we need to include the latest version in our build, which is 16.12.0 at the time of writing.

If we’re using Maven, we can include this dependency in our pom.xml file:

<dependency>
    <groupId>com.github.kagkarlsson</groupId>
    <artifactId>db-scheduler</artifactId>
    <version>16.12.0</version>
</dependency>

This will bring in everything that we need to be able to use it in our application. The only required dependencies are JSpecify and SLF4J – everything else is self-contained.

3.2. Database Schema

In order to work, db-scheduler needs a single database table in the database we connect it to. DDL scripts are provided for most major RDBMS engines, though it might work on others as well. For example, to use with PostgreSQL, we’d use DDL like this:

CREATE TABLE scheduled_tasks (
  task_name TEXT NOT NULL,
  task_instance TEXT NOT NULL,
  task_data BYTEA,
  execution_time TIMESTAMP WITH TIME ZONE NOT NULL,
  picked BOOLEAN NOT NULL,
  picked_by TEXT,
  last_success TIMESTAMP WITH TIME ZONE,
  last_failure TIMESTAMP WITH TIME ZONE,
  consecutive_failures INT,
  last_heartbeat TIMESTAMP WITH TIME ZONE,
  version BIGINT NOT NULL,
  priority SMALLINT,
  PRIMARY KEY (task_name, task_instance)
);
CREATE INDEX execution_time_idx ON scheduled_tasks (execution_time);
CREATE INDEX last_heartbeat_idx ON scheduled_tasks (last_heartbeat);
CREATE INDEX priority_execution_time_idx on scheduled_tasks (priority desc, execution_time asc);

This creates our scheduled_tasks table with the expected structure, ready for db-scheduler to use.

3.3. Scheduler

Finally, before we can use db-scheduler, we need to actually set up a Scheduler instance. This is the central class that manages scheduling all of our jobs.

We create an instance of this by providing a DataSource pointing to the database containing our scheduled_tasks table, and a collection of all the tasks that we want to manage. We’ll see later how to create these:

Scheduler scheduler = Scheduler.create(dataSource)
  .startTasks(tasks)
  .registerShutdownHook()
  .build();

This comes with a reasonable set of default configuration values:

• Poll every 10 seconds
• Heartbeat every 5 minutes
• Consider a task dead if it misses 6 heartbeats
• Run jobs across 10 worker threads

And many more. We can configure all of these when we create our scheduler:

Scheduler scheduler = Scheduler.create(dataSource)
  .startTasks(tasks)
  .registerShutdownHook()
  .pollingInterval(Duration.ofSeconds(2))
  .heartbeatInterval(Duration.ofMinutes(2))
  .missedHeartbeatsLimit(10)
  .threads(5)
  .build();

It’s important that multiple instances in the same cluster use at least the same heartbeat settings. If not, db-scheduler might incorrectly consider some jobs to be dead.

Once we have a scheduler, we need to start it running:

scheduler.start();

At this point, the scheduler will now manage all of the tasks assigned to it. This includes ensuring they’re correctly scheduled and running them at the appropriate times.

4. Simple Recurring Tasks

The easiest tasks to work with are simple recurring tasks. For these, we need a unique name, a frequency at which the task runs, and the task itself:

RecurringTask<Void> task = Tasks.recurring("my-hourly-task", FixedDelay.ofHours(1))
  .execute((instance, context) -> {
    LOG.info("Executed!");
  });

If this is a new task that the scheduler has never seen before, it will be scheduled to run immediately. After that, the scheduler will run it according to the provided schedule. In this case, that means 1 hour after the previous iteration finished. We can also use Daily for running at a particular time every day, and CronSchedule for using a more complicated cron expression.

Our task itself is provided as an instance of VoidExecutionHandler<T>, which is itself a functional interface and can be implemented by a lambda if we wish. The only method of this interface takes two parameters:

• TaskInstance<T> instance – Details about this instance of the task. Useful if we’ve got multiple schedules using the same task implementation.
• ExecutionContext context – Details about the executor itself. Useful if we want to access the scheduler itself from within our task.

Note that we have VoidExecutionHandler and RecurringTask<Void> here. This is because our example task is stateless. We can also support stateful tasks, which have an initial state that can be updated as a result of the task executing. However, these are out of the scope of this article.

5. One-Time Tasks

One-time tasks work a bit differently. In this case, we need to distinguish between the task itself and a descriptor that identifies the task:

TaskDescriptor<String> taskDescriptor = TaskDescriptor.of("my-onetime-task", String.class);
Task<String> task = Tasks.oneTime(taskDescriptor)
  .execute((inst, ctx) -> {
    LOG.info("Executed! Custom data {}, Instance {}", inst.getData(), inst.getId());
  });

This task definition accepts some data that we provide when we schedule the task, and can act on that data as appropriate. In this case, the data is a String, but it can be any type that db-scheduler is able to serialize. By default, this uses Java Serialization but db-scheduler also supports other mechanisms, such as Jackson and Gson.

We then need to register the task with our scheduler. However, we do this by passing the task to the Scheduler.create() method so that db-scheduler knows about it but doesn’t immediately start running it:

Scheduler scheduler = Scheduler.create(dataSource, task)
  .build();

At this point, we can run our task at any time using our scheduler and task descriptor:

scheduler.schedule(taskDescriptor.instance(UUID.randomUUID().toString())
  .data("Hello")
  .scheduledTo(Instant.now().plusSeconds(5))
);

Here we have to provide a unique instance ID for our task, and indicate when the task should run. We’ve also provided some data for our task to act on. The scheduler will then ensure that this task runs correctly at the desired time.

6. Dynamic Recurring Tasks

Dynamic recurring tasks are tasks that are registered dynamically at runtime, similar to our one-time tasks. However, once registered, they’ll continue to run on a schedule similar to our simple recurring tasks.

We create and start these exactly the same as for our one-time task, only using Tasks.recurring() instead:

TaskDescriptor<String> taskDescriptor = TaskDescriptor.of("my-dynamic-recurring-task", String.class);
Task<String> task = Tasks.recurring(taskDescriptor, new CronSchedule("*/5 * * * * ?", ZoneId.of("UTC")))
  .execute((inst, ctx) -> {
    LOG.info("Executed! Custom data {}, Instance {}", inst.getData(), inst.getId());
  });
scheduler.schedule(taskDescriptor.instance(UUID.randomUUID().toString())
  .data("Hello")
  .scheduledTo(Instant.now().plusSeconds(15))
);

This will now start our task at the given time and then, once started, it’ll run at the given schedule. In this case, it first runs 15 seconds after the current time, and then every 5 seconds after that.

If we wish, we can schedule as many different instances of these as we need, and they’ll all run on their own schedule without interfering with each other.

7. Use With Spring Boot

If we’re using Spring Boot, db-scheduler provides a starter dependency that we can use:

<dependency>
    <groupId>com.github.kagkarlsson</groupId>
    <artifactId>db-scheduler-spring-boot-4-starter</artifactId>
    <version>16.12.0</version>
</dependency>

If we’re using Spring Boot 4.x then we need to use db-scheduler-spring-boot-4-starter. If we’re still on Spring Boot 3.x then instead it’s db-scheduler-spring-boot-starter.

This will automatically create and start our Scheduler instance as a Spring bean. On doing this, it’ll also automatically discover any tasks that have been created as Spring beans and register them with this scheduler. This means that the only thing we need to do is create the tasks themselves.

If we want to configure the Scheduler in any way, we can do this using properties in our standard way:

db-scheduler.enabled=true
db-scheduler.polling-interval=5s
db-scheduler.heartbeat-interval=2m
db-scheduler.missed-heartbeats-limit=10
db-scheduler.threads=5

Everything else about using db-scheduler, including how we create and schedule tasks, is exactly the same as before. The starter just makes it simpler to get started in the first place.

8. Conclusion

In this article, we took a very quick look at db-scheduler, including how to schedule recurring and one-time tasks. There’s a lot more that we can do with this. Next time we need to manage scheduled jobs for your applications, why not give it a try?

As always, all the code from this article is available over on GitHub.

The post DB-Scheduler: A Persistent, Cluster-Friendly Scheduler for Java first appeared on Baeldung.

       

1. Spring and Java

>> When @Immutable Made All the Difference: A 3.2x Speedup with Hibernate Second-Level Cache [relation.to]

Hibernate’s second-level cache jumps from 286 seconds to 90 seconds when @Immutable, @Cache(READ_ONLY), and field-level @Mutability(Immutability.class) work together. This case study also shows why omitting the JSONB field annotation caused an 8.1x slowdown. Interesting read.

>> JEP 540 Proposed to Target JDK 28 with a Simple JSON API [infoq.com]

JEP 540 is moving toward JDK 28 with an incubating, dependency-free, deliberately-small JSON API for straightforward parsing and generation.

Also worth reading:

• >> Solving Gradle metadata and Renovate integration [frankel.ch]
• >> Introducing BoxLang AI Explorer: A Local Catalog for Every AI Pattern [foojay.io]
• >> Vibe Coding, Maven, and the Dependencies You Didn’t Choose [foojay.io]
• >> Preparing for Change: Safe Switching over Sealed APIs [inside.java]
• >> JDK 21 approaches end-of-permissive license [oracle.com]
• >> Exploring Compose HTML for Server Side Rendering [jetbrains.com]
• >> Renovate: teaching an old dog new tricks [marcphilipp.de]
• >> Writing a Thymeleaf component library – part 4 [wimdeblauwe.com]

Webinars and presentations:

• >> Build Secure AI Chat Applications with BoxLang, RAG, Ollama, and Amazon Bedrock with Dan Card [foojay.io]
• >> Episode 66 “JSON API, Valhalla Progress, LTS PQC” [IJN] [inside.java]
• >> JSON API, Valhalla Progress, LTS PQC – Inside Java Newscast #114 [nipafx.dev]
• >> Spring Office Hours Podcast: S5E20 – The Developer’s Guide to AI with Danny Thompson [spring.io]
• >> A Bootiful Podcast: Redouble AI CTO and founder Andrey Santrosyan [spring.io]

Time to upgrade:

• >> Quarkus 3.38.3 – Maintenance release [quarkus.io]
• >> A2A Java SDK 1.2.0.Final released [quarkus.io]
• >> Quarkus 3.38.2 – Maintenance release [quarkus.io]
• >> Stubborn Contract 0.1.0 released! [toomuchcoding.com]
• >> Apache Hive 4.2.1 [github.com/apache]
• >> Micronaut Core 5.1.11 [github.com/micronaut-projects]
• >> LangChain4j 1.19.0 [github.com/langchain4j]
• >> Helidon 4.5.3 and 3.2.20 [github.com/helidon-io]

2. Technical & Musings

>> Citizens Build, Agents Execute, Experts Govern [martinfowler.com]

AI agents are making it dramatically easier to build working software, but enterprise delivery still depends on engineering judgment. Of course it does.

Also worth reading:

• >> What Is Reasoning [pocoo.org]
• >> Compiling to intermediate representation: Write yourself a compiler, Part III [nurkiewicz.com]
• >> Idempotent Write Paths: Keeping an Integration Pipeline Correct When Messages Repeat [foojay.io]
• >> Lessons Learned from Fixing Flaky Tests with Claude [henrikwarne.com]
• >> Practitioner Voice: The Writing Category Nobody has Named Yet [martinfowler.com]
• >> How to take incremental steps towards data democratisation by Andy Scotland [scottlogic.com]
• >> AI success depends on data foundations by James Heward [scottlogic.com]
• >> Behind the Scenes: Evolving Netflix’s Ads Event Pipeline for Live – Part II [medium.com]

3. Pick of the Week

>> The Bedrock of Software Design [alex.draftist.io]

The post Java Weekly, Issue 660 first appeared on Baeldung.

       

1. Spring and Java

>> Evolving a Java MCP Server During MCP Specification Upgrades [inside.java]

A practical guide to evolving a Helidon-based Java MCP server to the stateless. Header-based routing and a temporary adapter keep older clients working while tests exercise both protocol paths. Good stuff.

>> Project Valhalla’s First Preview: JEP 401 Redefines == for Java Objects [infoq.com]

JEP 401 brings identity-free value classes and records to preview, changing == for value objects while identity classes retain reference semantics. Good weekend read.

Also worth reading:

• >> Security Baked Into the JVM: two Subjects, one call [frankel.ch]
• >> DuckDB in Spring Batch: Replace In-Memory Java Loops with One SQL Statement [foojay.io]
• >> Push V3: One Message From Your Server to Every Surface [foojay.io]
• >> Embedding DuckDB in a Maven App (and Using It for Things That Aren’t Databases) [foojay.io]
• >> The Power of JDK Flight Recorder: Efficient Profiling and Troubleshooting for Java Applications [inside.java]
• >> Post-Quantum Cryptography in Long-Term Support JDK Releases [inside.java]
• >> How to Use AI Agents in IntelliJ IDEA With ACP [jetbrains.com]
• >> Top 5 AI Features in IntelliJ IDEA [jetbrains.com]
• >> Agent Skills in IntelliJ IDEA [jetbrains.com]
• >> Writing a Thymeleaf component library – part 3 [wimdeblauwe.com]

Webinars and presentations:

• >> Episode 65 “Embracing Virtual Threads with Helidon” [I/O] [inside.java]
• >> Quarkus Insights #256: What is Floci? [quarkus.io]
• >> A Bootiful Podcast: Data guru Gregory Green on RabbitMQ, Valkey, Gemfire, Data Flow, and more [spring.io]

Time to upgrade:

• >> IntelliJ IDEA 2026.2.1 Is Out! [jetbrains.com]
• >> Gradle 9.7.0 [github.com/gradle]
• >> Eclipse Vert.x 4.5.32 [github.com/eclipse-vertx]
• >> Elasticsearch 9.5.1 and 9.4.5 and 8.19.20 [github.com/elastic]
• >> Netflix Zuul 4.1.4 [github.com/Netflix]
• >> Apache Camel 4.18.4 and 4.14.9 and 4.22.0 [github.com/apache]

2. Technical & Musings

>> Informing HTTP Extension Design with Data [mnot.net]

Mark Nottingham tests HTTP extensions against 120 million Common Crawl responses. The results show how invisible failures and weak migration incentives undermine adoption, yielding a practical lesson: design for repeatable deployment, make errors visible, and study real usage before extending a protocol.

Also worth reading:

• >> Programming Language Migration 2025: Why Developers Switch [jetbrains.com]
• >> One required check to rule them all [marcphilipp.de]
• >> Vertical slices, their ownership and external dependencies [event-driven.io]
• >> TDD inside the agent loop – theater or actual value? [martinfowler.com]
• >> Unlocking your data: the value is in collaboration [scottlogic.com]
• >> Agile Leadership [scottlogic.com]
• >> How to accelerate agentic adoption [scottlogic.com]
• >> How and Why Netflix Built a Real-Time Distributed Graph: Part 3 – Querying the graph with gRPC [netflixtechblog.com]

3. Pick of the Week

>> Things you didn’t know about indexes [jon.chrt.dev]

The post Java Weekly, Issue 659 first appeared on Baeldung.

       

Comments

• In reply to Vincent. Hey, Vincent. Thanks for the feedback. ... by Ulisses Lima
• You have encoding prolem on your URL : with Helidon†... by Vincent

 

1. Spring and Java

>> Virtual Threads after JDK 24: What Changed for Production Java [infoq.com]

If you haven’t looked at virtual threads in a while, this is the update you need. Benchmarks, code, and a repo you can run, plus concrete Spring Boot 3 adoption guidance.

Also worth reading:

• >> Idempotent Spring Boot: Safe REST with One Annotation [foojay.io]
• >> Introduction to Spring MockMvc [petrikainulainen.net]
• >> Writing a Thymeleaf component library – part 2 [wimdeblauwe.com]
• >> How to Create a Spring Boot Fraud Scoring Service [foojay.io]
• >> Jakarta Agentic AI Hits Its First Milestone [foojay.io]
• >> Transitioning Java to More Frequent Security Updates [inside.java]
• >> IntelliJ IDEA Goes LSP: Java and Kotlin Intelligence Comes to VS Code, Cursor, and Agentic Flows [jetbrains.com]
• >> Embabel Agent Framework Reaches 1.0 [infoq.com]
• >> The Codename One JavaScript Port Is Now Free and Open Source [foojay.io]
• >> Reflecting on STF support and looking ahead [marcphilipp.de]
• >> Custom ASCII-art startup banners for Quarkus [quarkus.io]

Webinars and presentations:

• >> Under the HAT: Empowering GPU Acceleration for Java [inside.java]
• >> Episode 64 “JIT Compiler From the Ground Up” [AtA] [inside.java]
• >> A Bootiful Podcast: Spring Boot founder and lead Phil Webb [spring.io]
• >> Quarkus Insights #255: Faster, Leaner, Predictable — Quarkus in the Real World [quarkus.io]
• >> WebAssembly on the JVM: Feature Evolution, Performance, and the Transition to Endive [infoq.com]
• >> Automatically Retrofitting JIT Compilers [infoq.com]
• >> The Free-Lunch Guide to Idea Circularity [infoq.com]

Time to upgrade:

• >> Quarkus 3.38.1 and 3.33.3.1 and 3.27.5.1 [quarkus.io]
• >> Jetty 12.1.12 and 12.0.38 [github.com/jetty]
• >> Vert.x 5.1.6 [github.com/eclipse-vertx]
• >> Helidon 4.5.2 [github.com/helidon-io]
• >> Elasticsearch 9.5.0 [github.com/elastic]
• >> Qodana 2026.2: More Security, Better Coverage, Less Configuration [jetbrains.com]
• >> Oracle Java Platform Extension for Visual Studio Code – Version 26.0.1 Is Now Available [inside.java]

2. Technical & Musings

>> The Economic Benefit of Refactoring [martinfowler.com]

We have always known that clean code pays for itself; here is someone putting a number on it in the agentic era. Giles Edwards-Alexander took a bloated 17,155-line data-access layer, refactored it systematically, and then measured what a representative feature change cost an AI agent before and after: input tokens dropped from 159,564 to 27,360, an 83% cut. Definitely a weekend read.

Also worth reading:

• >> The Conductor Developer [martinfowler.com]
• >> Fixing bugs in Event Sourcing is hard, for real? [event-driven.io]
• >> On building scalable control planes [allthingsdistributed.com]
• >> TimeSeries Tiered Storage Journey: Kafka/Flink Streams to Native Cassandra Cold Reads [netflixtechblog.com]
• >> GenRec: Towards LLM-Native Recommendation at Netflix [netflixtechblog.com]
• >> Credential Brokering Patterns for AI Agents Part 2: Protecting the Token Vault with AWS KMS [christianposta.com]
• >> Confidence Techniques for Guiding AI Migration [scottlogic.com]
• >> GitHub agentic workflows and Renovate [frankel.ch]
• >> Use Task Runners for Common Coding Tasks [hamvocke.com]
• >> Modeling Device Capabilities for Analytics [netflixtechblog.com]
• >> Four pillars of agentic AI success [scottlogic.com]

3. Pick of the Week

>> Life is Short [paulgraham.com]

The post Java Weekly, Issue 658 first appeared on Baeldung.

      

1. Introduction

The generative AI landscape is evolving rapidly, pushing framework maintainers to rethink how applications connect to diverse large language models (LLMs). With the release of Spring AI, Java developers gained a unified, portable interface to interact with cognitive services.

However, as the ecosystem matured, integrating multiple foundational models within a single runtime classpath introduced configuration conflicts. To solve this, Spring AI introduced major architectural updates. These include the specialized spring-ai-starter-model-google-genai starter module and an explicit model selection paradigm.

In this tutorial, we’ll explore how to integrate Google’s Gemini models into a Spring Boot application using the Gemini Developer API (via Google AI Studio). We’ll walk through a streamlined project setup, dive into text generation patterns using both low-level and high-level APIs, apply prompt templates, enable live web grounding, and stream tokens reactively with WebFlux.

2. Project Setup

To get started, we need a standard Spring Boot 3.x application. Because Spring AI modules are actively updated, it’s highly recommended to manage dependency versions using the Spring AI Bill of Materials (BOM).

2.1. Maven Dependencies

First, let’s configure the Spring AI Starter Google GenAI and Spring AI BOM in our pom.xml file. Since Spring AI artifacts are hosted in the Spring Milestones repository during release cycles, we ensure both the repository and dependency management blocks are properly declared:

<project>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.ai</groupId>
                <artifactId>spring-ai-bom</artifactId>
                <version>2.0.0</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-starter-model-google-genai</artifactId>
        </dependency>
    </dependencies>
</project>

2.2. Activating the Chat Provider via spring.ai.model.chat

In the latest versions of Spring AI, dropping a starter module onto the classpath no longer automatically activates it. This prevents runtime configuration conflicts when your application references multiple LLM providers.

We must explicitly declare our active chat provider inside our application.properties file:

spring.ai.model.chat=google-genai
spring.ai.google.genai.chat.model=gemini-2.5-flash
spring.ai.google.genai.api-key=${SPRING_AI_GOOGLE_GENAI_API_KEY}

Obtain an API key from the Google AI Studio. Using this placeholder syntax explicitly documents the application’s external runtime dependency while preventing hardcoded secrets from leaking into our source control repository.

2.3. Environment Setup

We can satisfy the property placeholder defined above without writing any custom Java decryption or binding code. We’ll simply export the credentials directly into our environment. The auto-configuration engine will automatically resolve the placeholder value at startup:

export SPRING_AI_GOOGLE_GENAI_API_KEY="YourActualSecureGoogleAIStudioKeyHere"

Once this environment variable is set, Spring Boot seamlessly bridges the variable to the properties file placeholder, making the GoogleGenAiChatModel ready for injection.

3. Core Text and Content Generation Strategies

Spring AI gives us two primary abstraction layers for communicating with Gemini models: the foundational ChatModel bean and the highly configurable, fluent ChatClient API. We isolate our interaction logic into a dedicated service layer to follow enterprise design patterns and keep code clean. Then, we expose these capabilities through standard Spring REST controllers.

3.1. Injecting and Using GoogleGenAiChatModel

The GoogleGenAiChatModel represents the foundational, low-level client abstraction. It handles request serialization, HTTP execution against Google’s RPC endpoints, and raw response parsing.

Let’s look at our ChatService, where we inject this bean along with a ChatClient.Builder to initialize our operational layers:

@Service
public class ChatService {
    private final GoogleGenAiChatModel chatModel;
    private final ChatClient defaultChatClient;
    private final ChatClient fluentChatClient;
    public ChatService(GoogleGenAiChatModel chatModel, ChatClient.Builder chatClientBuilder) {
        this.chatModel = chatModel;
        this.defaultChatClient = chatClientBuilder.build();
        this.fluentChatClient = chatClientBuilder
          .defaultSystem("You are a concise technical writer summarizing software concepts.")
          .build();
    }
    public String simplifiedPrompt(String message) {
        return chatModel.call(message);
    }
}

When we invoke chatModel.call(message), the framework packages the raw string into a default prompt context. It then sends this to the configured model variant, extracts the text block from the response payload, and returns it. We expose this in our ChatController:

@RestController
public class ChatController {
    private final ChatService chatService;
    public ChatController(ChatService chatService) {
        this.chatService = chatService;
    }
    @GetMapping("/v1/chat/simple")
    public String simplifiedPrompt(@RequestParam(defaultValue = "Hello") String message) {
        return chatService.simplifiedPrompt(message);
    }
}

This establishes a simple string-in, string-out endpoint. It uses the lowest-level model client abstraction available to verify basic connectivity with the Gemini engine.

3.2. Constructing Prompts With the Fluent ChatClient API

While working directly with the model handles quick operations, production architectures favor the fluent ChatClient API. The ChatClient acts as a facade layer that simplifies prompt assembly and attaches default configuration baselines.

As shown in our service constructor, we pre-configured a specialized fluentChatClient with system instructions. Let’s add the corresponding execution method to ChatService:

public String fluentPrompt(String prompt) {
    return this.fluentChatClient.prompt()
      .user(prompt)
      .call()
      .content();
}

By routing requests through this pre-configured instance, every user query automatically appends the target system instructions before execution. We expose this endpoint in the controller:

@GetMapping("/v1/chat/fluent")
public String fluentPrompt(@RequestParam String prompt) {
    return chatService.fluentPrompt(prompt);
}

This allows us to encapsulate recurring personas or systemic behavior directly within the client wrapper instance. As a result, we don’t need to modify individual incoming text arguments manually.

3.3. Handling Dynamic Inputs via Prompt Templates

Hardcoding parameter logic directly inside strings leads to messy string concatenation and fragile codebases. Spring AI solves this with structured prompt templates, separating instructions from user variables.

Let’s implement a code review capability inside our ChatService using a multiline text block placeholder layout:

public String reviewCode(String language, String codeSnippet) {
    String template = """
            Analyze the following {language} code snippet for memory leaks or inefficiencies.
            Provide an optimized version.
            Code:
            {code}
            """;
    return this.defaultChatClient.prompt()
      .user(u -> u.text(template).params(Map.of("language", language, "code", codeSnippet)))
      .call()
      .content();
}

The client replaces the target tags ({language}, {code}) at runtime, formatting the text cleanly before submission. We expose this via a POST request wrapper in our controller:

@PostMapping("/v1/chat/review")
public String reviewCode(@RequestParam(defaultValue = "Java") String language, @RequestBody String codeSnippet) {
    return chatService.reviewCode(language, codeSnippet);
}

This pattern cleanly decouples structural prompt engineering boundaries from volatile business data, producing a highly reusable, parameter-driven invocation pattern.

3.4. Grounding Responses With Live Google Search Retrieval

LLMs naturally suffer from training cut-off windows and knowledge gaps regarding live, real-world developments. The Google GenAI module exposes an explicit grounding property to seamlessly connect our model with live Google Search indexing.

To activate live search grounding across our entire application, we need to toggle the grounding flag to true inside our configuration properties:

spring.ai.google.genai.chat.google-search-retrieval=true

When this property is enabled, queries regarding current events or breaking news are automatically grounded using fresh search results. Let’s write an endpoint to handle real-time informational requests:

public String searchGroundedPrompt(String currentEventQuery) {
    return this.defaultChatClient.prompt()
      .user(currentEventQuery)
      .call()
      .content();
}

We map this method to our HTTP layer inside our controller configuration:

@GetMapping("/v1/chat/grounded")
public String searchGroundedPrompt(@RequestParam String currentEventQuery) {
    return chatService.searchGroundedPrompt(currentEventQuery);
}

If we pass a request like “Who won the most recent football tournament match yesterday?”, the model uses live Google Search indexing to anchor its response in verified facts, drastically reducing hallucinations. This configuration bridges the gap between static training cutoffs and live, real-world events.

3.5. Processing Real-Time Streaming Responses With Flux

For user-facing interfaces, waiting for a long text block to fully generate on the server results in noticeable latency. Instead, we can stream chunks back to the user, token by token, using Spring Boot’s WebFlux integration.

Let’s add a streaming method to our ChatService that returns a reactive Flux<String> structure:

public Flux<String> streamChatTokens(String prompt) {
    return this.defaultChatClient.prompt()
      .user(prompt)
      .stream()
      .content();
}

We’ll create a specialized StreamingChatController to deliver these tokens cleanly over an open connection pipeline. This controller explicitly produces a text/event-stream media response:

@RestController
public class StreamingChatController {
    private final ChatService chatService;
    public StreamingChatController(ChatService chatService) {
        this.chatService = chatService;
    }
    @GetMapping(value = "/v1/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<String> streamChatTokens(@RequestParam String prompt) {
        return chatService.streamChatTokens(prompt);
    }
}

When hitting this endpoint, consumers read token data reactively.  This establishes a non-blocking execution pipeline that builds an interactive, low-latency UI flow chunk by chunk.

4. Testing

Testing applications that rely on external generative AI endpoints requires a clear separation of concerns. Running tests shouldn’t trigger external network calls, hit rate limits, or exhaust API quotas during local compilation. To prevent this, we isolate our HTTP layer using Spring Boot’s slice testing along with @MockitoBean.

4.1. Unit Testing via WebLayer MockMvc Mocking

Since our implementation encapsulates all LLM communications within ChatService, we can completely mock this business component. This permits us to cleanly assert controller routing, request parameters, response body expectations, and stream-handling patterns.

Let’s write an isolated test using MockMvc to verify all text-based, template-driven, and reactive stream endpoints without triggering an actual network handshake. First, we set up our simple prompt test to verify basic GET parameter routing and raw response mapping:

@SpringBootTest(properties = {
    "spring.ai.model.chat=google-genai",
    "spring.ai.google.genai.chat.model=gemini-2.5-flash",
    "spring.ai.google.genai.api-key=test-key"
})
@AutoConfigureMockMvc
class ChatControllerUnitTest {
    @Autowired
    private MockMvc mockMvc;
    @MockBean
    private ChatService chatService;
    @Test
    void whenSimpleEndpointIsInvoked_thenReturnsMockedModelResponse() throws Exception {
        when(chatService.simplifiedPrompt(anyString())).thenReturn("Mocked Gemini Response");
        mockMvc.perform(get("/v1/chat/simple").param("message", "Hello"))
          .andExpect(status().isOk())
          .andExpect(content().string("Mocked Gemini Response"));
        verify(chatService).simplifiedPrompt("Hello");
    }
}

Next, we confirm that our fluent prompt endpoint forwards query parameters accurately to the underlying service. Then it returns the configured system-prompt-backed response:

@Test
void whenFluentEndpointIsInvoked_thenReturnsModelContent() throws Exception {
    when(chatService.fluentPrompt(anyString())).thenReturn("Fluent Response");
    mockMvc.perform(get("/v1/chat/fluent").param("prompt", "Explain DI"))
      .andExpect(status().isOk())
      .andExpect(content().string("Fluent Response"));
    verify(chatService).fluentPrompt("Explain DI");
}

For our template-driven endpoint, we validate that the controller correctly processes a multipart payload consisting of query parameters and a text/plain request body:

@Test
void whenReviewEndpointIsInvoked_thenReturnsModelContent() throws Exception {
    when(chatService.reviewCode(anyString(), anyString())).thenReturn("Optimized Code");
    mockMvc.perform(post("/v1/chat/review")
        .param("language", "Java")
        .contentType(MediaType.TEXT_PLAIN)
        .content("class A { }"))
      .andExpect(status().isOk())
      .andExpect(content().string("Optimized Code"));
    verify(chatService).reviewCode("Java", "class A { }");
}

We’ll now verify that search-grounded queries pass their parameters cleanly through the controller layer without parameter binding errors:

@Test
void whenGroundedEndpointIsInvoked_thenReturnsModelContent() throws Exception {
    when(chatService.searchGroundedPrompt(anyString())).thenReturn("Grounded Response");
    mockMvc.perform(get("/v1/chat/grounded").param("currentEventQuery", "latest match winner"))
      .andExpect(status().isOk())
      .andExpect(content().string("Grounded Response"));
    verify(chatService).searchGroundedPrompt("latest match winner");
}

Finally, we test our reactive endpoint to ensure Spring MVC properly negotiates the text/event-stream media type. It will also format the reactive Flux elements into standard Server-Sent Event (data:) frames:

@Test
void whenStreamEndpointIsInvoked_thenReturnsEventStreamContent() throws Exception {
    when(chatService.streamChatTokens(anyString()))
      .thenReturn(reactor.core.publisher.Flux.just("token-1", "token-2"));
    mockMvc.perform(get("/v1/chat/stream").param("prompt", "Stream tokens"))
      .andExpect(status().isOk())
      .andExpect(content().contentTypeCompatibleWith(MediaType.TEXT_EVENT_STREAM))
      .andExpect(content().string("data:token-1\n\ndata:token-2\n\n"));
    
    verify(chatService).streamChatTokens("Stream tokens");
}

By leveraging the modern @MockBean annotation, we inject our mock definitions directly into the application context wrapper, replacing the real bean configuration. This allows us to stub out standard synchronous operations as well as complex reactive Flux stream responses safely and reliably without network overhead.

5. Conclusion

In this tutorial, we configured a Spring Boot application using Spring AI’s updated spring-ai-starter-model-google-genai engine to interact directly with Google AI Studio.

We saw how explicitly defining spring.ai.model.chat=google-genai resolves modern multi-model classpath dependencies. From there, we established a clean architecture using a dedicated ChatService. We built out flexible prompt workflows with the fluent ChatClient API and isolated dynamic parameters using templates. Finally, we enabled live web grounding and streamed responsive outputs via WebFlux Flux.

As always, the complete code samples used in this article are available over on GitHub.

The post Introduction to Google GenAI Chat and Spring AI first appeared on Baeldung.