CAMEL-23173: Add camel-event component for subscribing to Camel events

[gnodet]

Summary

• Adds a new camel-event component (URI scheme: event) that allows users to subscribe to Camel internal events via routes
• The component is consumer-only and leverages Camel's existing EventNotifier mechanism
• Supports subscribing to any combination of event types (RouteStarted, RouteStopped, ExchangeCompleted, ExchangeFailed, etc.)
• Supports filtering by route ID via the filter query parameter
• Includes thread-local guard to prevent recursive event notification when processing exchange events

Example Usage

// Subscribe to route lifecycle events
from("event:RouteStarted,RouteStopped")
    .log("Route ${header.CamelEventRouteId} event: ${header.CamelEventType}");

// Subscribe to exchange events filtered by route ID
from("event:ExchangeCompleted?filter=myRoute")
    .log("Exchange completed on route myRoute");

Test plan

• Unit tests for subscribing to route events (RouteStarted/RouteStopped)
• Unit tests for subscribing to exchange events (ExchangeCompleted)
• Unit tests for filtering by route ID
• Unit tests for multiple event types in a single consumer
• Unit tests for invalid event type handling
• Unit tests for consumer-only validation (cannot produce)

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using build-all, build-dependents, skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[Croway]

Nice, I might be overthinking it, @davsclaus @oscerd what about adding a kafka backed camel-event implementation? would that make sense?

[gnodet]

@Croway Good question! We considered this, but the route-based approach already covers the distributed use case naturally:

// Publish events to Kafka (or any other transport)
from("event:RouteStarted,RouteStopped,ExchangeFailed")
    .setBody(simple("${header.CamelEventType}: ${header.CamelEventRouteId}"))
    .to("kafka:camel-events");

// Consume from another instance
from("kafka:camel-events")
    .to("log:distributed-events");

A built-in Kafka-backed implementation would face a fundamental problem: CamelEvent objects are not serializable — they hold live JVM references (Route, Exchange, CamelContext). Any Kafka integration would need to flatten events into DTOs, giving a fundamentally different object on the consuming side.

Using standard routes instead:

• Gives users full control over serialization format
• Is transport-agnostic (works with Kafka, JMS, AMQP, NATS, etc.)
• Follows Camel's composability principle
• Requires zero additional code

We'll add documentation examples showing this pattern.

[davsclaus]

One note is that the processing of the event is synchronous and using the same thread that the route is using. So this will then extend the total processing time if you route the events to something that takes longer time. You can of course just use wireTap in the camel route to route it async.

[gnodet]

Good point @davsclaus — that's an important caveat. Since the EventNotifierSupport dispatches synchronously, any slow downstream processing in the route will block the event-producing thread.

We should add a documentation note highlighting this, with a wireTap example:

from("event:ExchangeCompleted")
    .wireTap("kafka:camel-events")  // async - won't block the exchange thread
    .end();

I'll add this to the component docs.