Java adoption

Integrate MyServiceBus with an existing Java container.

Choose the integration depth that fits the host: use MyServiceBus's small DI and logging abstractions with their included implementations, materialize those contracts through an adapter, or keep application objects in an existing Java container and connect them at the consumer boundary.

New project: decorator style

Start with the MyServiceBus service abstractions when the application does not already have a competing composition model. Decorators provide the Java equivalent of the extension-method structure used by the C# client.

Small Java-platform abstractions for DI and logging

MyServiceBus publishes myservicebus-di and myservicebus-logging as separate foundational artifacts. The DI contracts—ServiceCollection, ServiceProvider, ServiceScope, descriptors, and lifetimes—give the Java client one stable composition vocabulary corresponding to the .NET client. ServiceCollection.create() supplies the included Guice-backed implementation, while createAot() selects a factory-only implementation without reflective constructor activation. These are MyServiceBus integration contracts, not an attempt to replace Spring, CDI, Dagger, Guice, or another application container.

The logging contracts are similarly narrow: Logger and LoggerFactory isolate the bus runtime from a particular logging backend and are designed to participate in dependency injection. No logging setup is required: console logging is the fallback when an application does not register a factory. Optionally, applications using the common Java logging ecosystem can select the included SLF4J adapter and retain their existing backend and configuration.

Optional: select the logging provider

Optional: inject the abstraction into application code

MyServiceBus services receive the selected factory through constructor injection and create a logger for their own type. Application services can do the same when using the MyServiceBus DI container, although this is not required:

The logging abstraction is primarily an internal portability boundary for MyServiceBus. Application code does not have to use it: keep using SLF4J, Log4j, JUL, or the logging API supplied by the host framework unless sharing this abstraction is useful. Hook into it when bus diagnostics should use the application's provider, or replace LoggerFactory when a different backend or policy is required.

The bus-factory path can instead accept a LoggerFactory directly. A container adapter may implement the DI contracts, or application-managed consumers can stay entirely in the host container through ConsumerFactory. In both cases the abstractions keep MyServiceBus infrastructure portable without claiming that Java's wider DI and logging ecosystems are interchangeable.

Existing application: bus factory

The consumer factory is the class-activation seam. MyServiceBus supplies the registered consumer type and a continuation representing the rest of the consumer pipeline. The adapter resolves that type from the application container and passes it to the continuation.

The bus factory still builds a private MyServiceBus provider for transport and pipeline services. The adapter may ignore that provider; it does not need to connect the application container to Guice.

endpoint.consumer(messageType, consumerType) is an explicit mapping. It adds the consumer to bus topology without registering the consumer class in the bus's private provider. RabbitMQ and Azure Service Bus expose the same Java factory pattern.

Adapt the application container

ConsumerFactory owns activation for one pipeline execution. This example uses placeholder ApplicationContainer and ApplicationScope types; an integration supplies the equivalent operations from Spring, CDI, Dagger, Micronaut, or application code.

The continuation is important: the native scope remains alive for consumer execution, filters that run after it, and asynchronous work. Closing the scope immediately after next.send(...) would dispose dependencies too early.

Use a direct handler when a class factory is unnecessary

For a singleton or framework-managed proxy, inject the object into messaging configuration and pass a method reference. Constructor injection has already happened before MyServiceBus sees the handler.

A captured consumer may receive messages concurrently, so the target must be safe for that lifetime. Prefer the typed consumer-factory path when each delivery needs a native container scope.

Provider and factory types

Use the provider type native to the host framework at the composition boundary:

• Spring can inject a normal singleton directly or expose an ObjectProvider<T> when the configured scope supports per-delivery lookup.
• Jakarta CDI can resolve through Instance<T> and use a handle when explicit dependent-instance destruction is required.
• Dagger can expose Provider<T> or a generated component method.
• An application without a framework can use Supplier<T> or its own scope factory.

A Provider<T> or Supplier<T> creates or locates an object; it does not by itself describe scope cleanup. When the container returns short-lived objects, adapt both resolution and release inside ConsumerFactory.

Materialize the collection with another container

A deeper adapter can implement the neutral MyServiceBus collection and provider contracts, translate registrations produced by the decorators, and return a provider backed by another container. Choose this path when the application wants the decorator programming model across its composition root, rather than only a bus-factory integration.

Such an adapter must preserve the target container's lifetime, scope, cleanup, and multi-binding semantics:

• SINGLETON maps to one instance across the root provider and message scopes.
• SCOPED maps to one instance per MyServiceBus message scope.
• TRANSIENT maps to a new instance per resolution under the framework's ownership rules.
• A native scope closes only after asynchronous consumption completes.
• Multi-bindings and provider-aware factories retain the active scoped provider.

This is an alternative adoption path, not a requirement for using the bus factory.

Framework references: Spring container, Jakarta CDI, and Dagger components.