Skip to content

feat(server): allow injecting custom A2AHttpClient for push notificat… - #1029

Open
malladinagarjuna2 wants to merge 2 commits into
a2aproject:mainfrom
malladinagarjuna2:feat-pluggable-http-client
Open

feat(server): allow injecting custom A2AHttpClient for push notificat…#1029
malladinagarjuna2 wants to merge 2 commits into
a2aproject:mainfrom
malladinagarjuna2:feat-pluggable-http-client

Conversation

@malladinagarjuna2

Copy link
Copy Markdown

Overview

This PR introduces the ability to plug in a custom A2AHttpClient implementation on the server side by natively supporting CDI injection in the BasePushNotificationSender.

Fixes #135

The Problem

When server-related code was extracted from core into server-common (in #129), the Push Notification sender was modified to hardcode its usage of JdkA2AHttpClient via A2AHttpClientFactory.create(). This prevented developers from replacing the underlying HTTP client on the server side (e.g. replacing the JDK client with the Vert.x HTTP client, or providing a custom client with specific interceptors/auth mechanisms).

The Solution

  1. Added Instance<A2AHttpClient> to CDI Constructor: The @Inject constructor in BasePushNotificationSender now accepts an Instance<A2AHttpClient>.
  2. Graceful Fallback: If the DI framework (like Quarkus or Spring) has a custom A2AHttpClient bean available (!httpClientInstance.isUnsatisfied()), it will use it. Otherwise, it gracefully falls back to A2AHttpClientFactory.create(), ensuring 100% backwards compatibility for users who don't provide a custom bean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feat]: Make it possible to plug in other A2AHttpClient implements for the server side

1 participant