Petals ESB Container

MessageExchange defines three methods to specify who will receive an exchange before it is sent.
From the more specific to the less: setEndpoint(), setService() and setInterfaceName().

Before the exchange is first sent, an incoherence between these is not a problem, since the router will take them in their specificity order and that's all.
Once the exchange has been first sent, the JBI specification says that the elected endpoint can't change ANYMORE.

What happens if:

• The elected endpoint is not the one that was set with setEndpoint()?
• The elected endpoint service name is not the one that was set with setService()?
• The elected endpoint interfaces does not contain the one that was set with setInterfaceName()?

Currently the behaviour is unclear and the information returned by the getXXX methods are not coherent with the elected endpoint.
Worse, a component calling setEndpoint() can actually change the endpoint of the provider after it was elected.

The following behaviour will fix this situation (i.e., after the endpoint election has happened):

• getEndpoint() returns the elected endpoint except if there was one set manually (and that is not the elected one, for example when a fake endpoint is used).
• getService() returns the elected endpoint's service name (even if setService() is called by a component again later).
• getInterfaceName() returns
  • the interface set with setInterfaceName() if it is one of the endpoint's interfaces or if the endpoint has no interfaces.
  • the first interface of the endpoint if not (or if the interface name wasn't set with setInterfaceName()).

Like this there can't be any incoherence. It is the responsibility of the component implementation not to expect the getXXX method to change their output even if it calls the setXXX methods after endpoint election has happened.