feat(eventhubs): add single-event send to EventHubProducerClient and EventHubProducerAsyncClient

[j7nw4r]

Fixes #41395

Summary

EventHubProducerClient and EventHubProducerAsyncClient contain send(EventData) and send(EventData, SendOptions). All four methods are package-private. To publish one event, a caller must wrap it in an EventDataBatch or pass a one-element Iterable to send(Iterable). This change makes the four methods public. The implementations do not change.

Motivation

PR #6257 made the single-event, Iterable, and Flux send overloads package-private in 2019. The methods waited on architecture board review. The 2020 review (Azure/azure-sdk#1259) approved the multi-event form, and PR #10528 restored send(Iterable) only. The single-event form stayed package-private, and no one revisited it.

Two problems follow. The class Javadoc and the README show only the EventDataBatch workflow, so send(Iterable) is hard to find. send(Iterable) is also awkward for one event.

Other Azure SDKs ship the same API. azure-eventhub for Python added send_event in 5.11.0. This library exposes single-event enqueueEvent(EventData) on EventHubBufferedProducerAsyncClient.

One send(EventData) call makes one network round trip. The new Javadoc and the README both state this, and they point high throughput callers to EventDataBatch and send(Iterable).

Changes

• EventHubProducerClient.send(EventData) and send(EventData, SendOptions) become public.
• EventHubProducerAsyncClient.send(EventData) and send(EventData, SendOptions) become public. Both get @ServiceMethod(returns = ReturnType.SINGLE), which the sync pair already has.
• Javadoc on the four methods gets @throws NullPointerException, @throws AmqpException, a code snippet, and a line that points high throughput callers to EventDataBatch.
• EventHubsJavaDocCodeSamples gets four snippets.
• The README gets a new section, "Publish a single event".
• The CHANGELOG gets an entry under 5.22.0-beta.1.
• Both producer test classes get null-argument tests.
• eng/lintingconfigs/revapi/track2/revapi.json gets one exclusion. Revapi reports java.method.visibilityIncreased for the four methods and fails the build. The change adds API surface and removes none, so callers stay source and binary compatible. A regex limits the exclusion to these four methods.

The send(Flux<EventData>) overloads stay package-private. The 2020 review examined a Flux overload and did not approve it.

Test plan

• mvn -f sdk/eventhubs/azure-messaging-eventhubs/pom.xml clean install -DskipTests passes. This runs checkstyle, spotless, revapi, javadoc, and codesnippet verification.
• mvn -f sdk/eventhubs/azure-messaging-eventhubs/pom.xml test -Dtest='EventHubProducerClientTest,EventHubProducerAsyncClientTest' passes. 50 tests, 0 failures, 0 errors.
• The integration tests need live Event Hubs credentials and did not run locally. They called these methods before this change.

Note for reviewers

This adds public API to a GA library, so it needs API review sign-off before merge. The ApiView diff shows four new methods and no other change to the surface.

The PR closes two defects. The public API is one. The docs are the other. If API review declines the overloads, the README, Javadoc, and CHANGELOG changes still fix the discoverability problem in #41395, which is the root cause of the report. The docs never showed that send(Iterable) exists.

/cc @anuchandy @conniey

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
33 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
33 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR makes the existing single-event send overloads on Event Hubs producer clients publicly accessible, improving ergonomics for low-volume publishing while adding supporting docs, samples, tests, and a Revapi allowance for the intentional visibility increase.

Changes:

• Promote send(EventData) / send(EventData, SendOptions) to public on EventHubProducerClient and EventHubProducerAsyncClient (and add missing @ServiceMethod annotations on async).
• Add Javadoc + README guidance and new JavaDoc snippet samples for single-event sends.
• Add null-argument tests for the new public overloads and update Revapi config to allow the visibility change.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
sdk/eventhubs/azure-messaging-eventhubs/src/test/java/com/azure/messaging/eventhubs/EventHubProducerClientTest.java	Adds sync producer null-argument tests for single-event send overloads.
sdk/eventhubs/azure-messaging-eventhubs/src/test/java/com/azure/messaging/eventhubs/EventHubProducerAsyncClientTest.java	Adds async producer null-argument tests for single-event send overloads.
sdk/eventhubs/azure-messaging-eventhubs/src/samples/java/com/azure/messaging/eventhubs/EventHubsJavaDocCodeSamples.java	Adds four new code snippets demonstrating single-event sends (sync + async, with/without SendOptions).
sdk/eventhubs/azure-messaging-eventhubs/src/main/java/com/azure/messaging/eventhubs/EventHubProducerClient.java	Makes single-event send overloads public and expands their Javadoc.
sdk/eventhubs/azure-messaging-eventhubs/src/main/java/com/azure/messaging/eventhubs/EventHubProducerAsyncClient.java	Makes single-event send overloads public and annotates them as service methods; expands Javadoc.
sdk/eventhubs/azure-messaging-eventhubs/README.md	Adds a “Publish a single event” section and TOC entry.
sdk/eventhubs/azure-messaging-eventhubs/CHANGELOG.md	Adds a feature entry for the new public overloads.
eng/lintingconfigs/revapi/track2/revapi.json	Adds an exclusion for the intentional java.method.visibilityIncreased changes (scoped to these methods).

[EldertGrootenboer]

The code looks good.
Clean symmetric promotion, the revapi exclusion is scoped to just these four signatures, and the null-argument tests cover both branches of the two-arg overload.

One thing to sort out before API review: the parity framing.
Only Python ships a single-event send today (send_event, 5.11.0).
.NET, JS, and Go are all batch-only by design:

• .NET (the messaging reference): SendAsync(IEnumerable<EventData>) and SendAsync(EventDataBatch), no single-event overload.
• JS: createBatch() plus sendBatch().
• Go: NewEventDataBatch() plus SendEventDataBatch().

So this follows Python and diverges from .NET and two of the three siblings.
That is fine as a call, but the board should see it as a "follow Python vs follow .NET" decision, not a parity win.
Worth a follow-up on whether .NET, JS, and Go pick up the overload too, so the split is deliberate.

One doc nit: the async send(EventData) is missing the "for high throughput use EventDataBatch / send(Iterable)" pointer its three siblings got.