In This Section
Overview
The platform's loopback binding can be used to send to other applications running in the same process. The loopback binding is often used for unit testing in which several applications may be launched in the same process for easy debugging.When you configure a bus binding to use a loopback bus, a LoopbackBus instance is statically created on demand using the address provided by the binding. Two applications that connect to a loopback bus with the same name may exchange messages with one another.
Bus Descriptor Format
A loopback message bus can be configured via a descriptor string as follows which uses the address to indicate the loopback bus instance to which to connect followed by a list of provider properties.
loopback://<busname>&prop1=val1&propN=valN
An example bus descriptor for solace would like like:
loopback://<busname>&topic_starts_with_channel=false&set_bus_and_channel_on_receipt=true
DDL
In a DDL config file a solace bus can equivalently be configured in one two ways
Decomposed
The descriptor form is useful in cases where the descriptor name may be supplied as an external configuration property that is substituted at runtime, but defaults to loopback for testing:
As A Descriptor
Working with Loopback Buses
Loopback Bus Naming
When working with loopback buses it is sometimes useful to be able to look up a loopback by name. So if you have configured a loopback bus via loopback://my-bus, you can look up the bus as follows:
Port Numbers and the Loopback Bus
A loopback bus does not require a port to be specified in its configuration. If you do configure a Loopback bus with a port, the name of the loopback bus will include the port name. If you specify "loopback://my-bus:80" the name of the bus will be "my-bus:80". One consequence of this is that "loopback://my-bus:80" and "loopback://my-bus:90" represent 2 separate buses which cannot communicate with one another.
Other than contributing to the name of the bus, the port is not used by the bus.