[Lyin-OTTF]

Fixes #5226.

The client/server examples in docs/a2a-protocol/ call new A2AProtocolTransportObject(...), but that type is not part of the public SDK: in the code it only exists as the private inner class SimpleA2AProtocolTransportObject inside EnhancedA2AProtocolAdaptor, so the snippet cannot compile as written.

This PR replaces the examples with the path used by the shipped example eventmesh-examples/src/main/java/org/apache/eventmesh/a2a/demo/mcp/McpCaller.java and by section 5.1.3 of docs/feature/a2a.md:

• client: wrap the JSON-RPC payload in a CloudEvent whose type is org.apache.eventmesh.a2a.tools.call.req and which carries the protocol=A2A extension, then producer.publish(event);
• server: publish the JSON-RPC response the same way with type org.apache.eventmesh.a2a.common.response, and document the ingress mapping the adaptor performs (mcptype=response, collaborationid=<request id>, per EnhancedA2AProtocolAdaptor).

Also fixes the broken Java string concatenation in the Chinese server example and adds a note that A2AProtocolTransportObject is an internal adaptor type.

[qqeasonchen]

LGTM

[qqeasonchen]

@Lyin-OTTF what about develop branch?

[Copilot]

🟡 Changes recommended

The examples omit required publishing fields and incorrectly rely on automatic A2A metadata conversion.

2 open issues

• Set required CloudEvent extensions and clarify ingress conversion · New
• Add required content type, subject, and topic to README builders · New

What changed in this PR

Updates the bilingual A2A usage guides to address #5226 by replacing unavailable SDK type usage with CloudEvent publishing examples.

Changes:

• Rewrites client and server publishing snippets.
• Repairs malformed Java in the Chinese examples.
• Adds internal-type and response-mapping explanations.

File	Description
docs/​a2a-protocol/​README.md	Updates Chinese examples and adaptor notes.
docs/​a2a-protocol/​README_EN.md	Updates English examples and response guidance.

_{Review effort: Balanced}

[Lyin-OTTF]

develop has the same problem: docs/feature/a2a.md lines 754 and 779 still call new A2AProtocolTransportObject(mcpRequest) / (mcpResponse), which is the private inner class SimpleA2AProtocolTransportObject in EnhancedA2AProtocolAdaptor and cannot compile as written. The a2a-protocol/ directory only exists on master, so this PR fixes the master copy.

I can either retarget this PR to develop and fix docs/feature/a2a.md there instead, or keep this one for master and open a second PR against develop for a2a.md. Which do you prefer?

I'll also go through the Copilot suggestions on the missing mcptype extensions and getDataContentType() in the builders — will push a follow-up commit once I've verified them against McpCaller.

[Lyin-OTTF]

Pushed a follow-up commit for both Copilot threads (82253de).

Both points check out against the code:

• McpProvider.handleCallback dispatches on the mcptype extension, and mcptype, a2amethod, targetagent and collaborationid are only filled in by EnhancedA2AProtocolAdaptor while it converts JSON-RPC to a CloudEvent. Code that publishes the CloudEvent itself never goes through that conversion, so it has to set them. The examples now do, on both the request and the response side.
• CloudEventProducer.buildCommonPostParam calls EventFormatProvider.resolveFormat(cloudEvent.getDataContentType()) and throws when that returns null. The examples now set application/cloudevents+json, the same value as ExampleConstants.CLOUDEVENT_CONTENT_TYPE used by McpCaller, and the subject carries the topic on both builders.

The sentence claiming the adaptor adds mcptype=response and collaborationid on ingress only holds for the JSON-RPC path, so I replaced it with a note that direct publishers have to set these extensions themselves.

[qqeasonchen]

LGTM，need to fix in develop branch alsl

[xwm1992]

LGTM

[Lyin-OTTF]

The three workflows (Continuous Integration, License Check, Code Scanning) report "No jobs were run" on this PR and on #5431. None of them has path filters in .github/workflows (ci.yml triggers on pull_request for all branches), so this looks like the first-time-contributor approval gate rather than a skipped run.

Could someone with write access approve the runs? Everything else is in place here: three approvals, and the Copilot findings are addressed in 82253de.

[Lyin-OTTF]

Thanks for the approvals. One heads-up: the workflows still have not run on this PR. The Actions runs are waiting on first-contributor approval, so there is no CI result to merge against yet. Could someone approve the workflow runs when convenient? The change is docs-only (two files under docs/a2a-protocol/), so I do not expect it to affect any build.