1) No provider information available
The provider information is determined in the addressing phase. This is the first element in the handler chain (org.switchyard.internal.LocalExchangeBus).
As far as I know, there is now event published, when the provider information is set in the message exchange.
1) When I started experimenting with the new event listener being registered via JMX, I tried establishing an observer for ExchangeCompletionEvent, but didn't receive any. So I debugged the Event Manager and noticed the camel Exchange created and completed events. As I need to be informed when the exchange starts, as well as completes, I thought it would be useful to subscribe for these events instead. I need start and completed events, to identify the scope in which other activities occur.
So if the switchyard ExchangeCompletionEvent is available (I might need to try this out again), and an equivalent ExchangeCreatedEvent can also be emitted (including the Provider information), then that would be ideal. Should I raise a jira for this? in the meantime continuing to use the camel events?
2) A pity - I guess the decision making can still be done using the existing mechanism (i.e. rules triggered from the intercepted activity events), but the effect of the decision (i.e. blocking the invocation) would need to be made by an auditor, so it is a two phase process, with the user having to install something into their app to make it work.
For #1, there was an oversight in the Camel bus refactor that left out exchange completion events. There's a pull request in the queue to fix it, so should be in within the next 24 hours.
I'm not a fan of an exchange creation event as I don't think it represents a meaningful state of execution in SwitchYard. We could add an ExchangeInitiatedEvent, which is fired at the time an in message is sent on an exchange. The reason I don't like ExchangeCreation as an event is that there is processing that happens before and after an exchange is created and then you don't have a boundary for measuring that time. If a gateway provided a time a message was received, for example, then you could combine the elapsed time between exchange initiated and completed to determine the service invocation time. If you add a gateway complete timestamp (i.e. when a message has been returned to the consumer), then you can measure the execution time of the gateway using received/initiated and completed/returned.
For #2, it's crossing concerns to allow the event listeners to control flow. For example, does this apply to all types of events (e.g. deployment rollback) or just a subset? Also, it prevents us from moving to async notification of event listeners if we choose to do so.
1) An ExchangeInitiatedEvent sounds fine to me - and I guess by that point it would have the provider info. Created jira: https://issues.jboss.org/browse/SWITCHYARD-1466
2) Totally understand - it just complicates this particular usecase.