Can you provide the app to reproduce, with an example message.

Created attachment 785622 [details]
Reproducer

See modified camel-binding quickstart - there is a logging service added

Run the quickstart - be careful with directory settings, it needs to be changed
Then run the REST request

{"expression": "SELECT act FROM RPCActivityType act LEFT JOIN FETCH act.context LEFT JOIN FETCH act.properties" } 

on url http://localhost:8080/overlord-rtgov/activity/query

The answer should contain
   {
    "type":"RequestSent",
    "serviceType":"{
    urn:switchyard-quickstart:camel-binding:0.1.0
}GreetingService/LoggingService",
    "operation":"log",
    "messageType":"java:java.lang.String",
    "timestamp":1376298336203,
    "unitId":"872766c6-c858-449b-b82b-83421c1fcc2e",
    "unitIndex":1,
    "context":[{
    "value":"ID-jpechane-34089-1376298164800-3-5",
    "type":"Message"
}]
},
    {
    "type":"RequestReceived",
    "serviceType":"{
    urn:switchyard-quickstart:camel-binding:0.1.0
}GreetingService/LoggingService",
    "operation":"log",
    "messageType":"java:java.lang.String",
    "timestamp":1376298336203,
    "unitId":"872766c6-c858-449b-b82b-83421c1fcc2e",
    "unitIndex":2,
    "context":[{
    "value":"ID-jpechane-34089-1376298164800-3-5",
    "type":"Message"
}]
},
    {
    "type":"RequestSent",
    "serviceType":"{
    urn:switchyard-quickstart:camel-binding:0.1.0
}GreetingService/LoggingService",
    "operation":"log",
    "messageType":"java:java.lang.String",
    "timestamp":1376298336210,
    "unitId":"872766c6-c858-449b-b82b-83421c1fcc2e",
    "unitIndex":3,
    "context":[{
    "value":"ID-jpechane-34089-1376298164800-3-7",
    "type":"Message"
}]
},
    {
    "type":"RequestReceived",
    "serviceType":"{
    urn:switchyard-quickstart:camel-binding:0.1.0
}GreetingService/LoggingService",
    "operation":"log",
    "messageType":"java:java.lang.String",
    "timestamp":1376298336210,
    "unitId":"872766c6-c858-449b-b82b-83421c1fcc2e",
    "unitIndex":4,
    "context":[{
    "value":"ID-jpechane-34089-1376298164800-3-7",
    "type":"Message"
}

Note the missing intefrace field

Marked as not a bug, as this information is not provided, on 'inbound' exchanges between services, by switchyard. Therefore it is not possible for rtgov to log this.

As a workaround, for two way interactions, the interface on the 'outbound' exchange is applied to the activity events representing the inbound interaction, after the fact.

Just to be clear, this is not an rtgov bug, which is why I closed it - however I believe this information should be provided, so possibly needs to be raised as bug against switchyard.

RTGov currently uses the org.apache.camel.management.event.ExchangeCreatedEvent, although the same problem exists with org.switchyard.runtime.event.ExchangeInitiatedEvent.

I am re-opening the bug and making it a dependency on SY bug that should provide the necessary information. If the SY issue will solve the problem we can close it together.

Have found a workaround for this, that sets the interface and also scopes the oneway interaction (i.e. records response sent/received events).

So you may want to close the switchyard issue. I'm testing the fix currently, but looks like it will be fine, so should apply to product branch shortly.

It's not clear to me what exactly is missing on the SwitchYard side.  At the point the exchange is initiated, the consumer has been identified, but the provider has not (that's assigned in the addressing handler).  This means the consumer's contract information *is* present on the exchange.  This holds true inbound or outbound, in-only or in-out.

This bug seems to talk about what's missing on the RTGov side and the SY bug that was created merely references this one.  Can someone point out the exact information which should be there that is missing?

The problem was that when handling the request in the event listener, the provider (i.e. org.switchyard.Service) interface property is null.

I had worked around this for two way ops by setting the interface in the activity event when handling the response, but this bug was because it wasn't being handled for one-way ops. So the fix was to basically do the same workaround for one-way ops.

OK, provider will always be null in that scenario.  Happy to hear that you have a workaround from the rtgov side.  Let me know if you run into any other issues.

Verified in ER2

Gary Brown <gary> updated the status of jira RTGOV-248 to Closed