By default, all headers are not carried over, unless you explicitly specify it in the message composer includes, either with .* or with the name.

I guess that in your case, you'll have to take resubmissions into account on service development, which is not desirable, so that means that original service should have in the includes something like rtgov.*  or you can raise a JIRA to allow to have some properties to be passed always (although I don't you'll get good feedback on this).

Maybe, in this case, a switchyard property can be created, as some properties are always carried along, but nothing without changes into switchyard core.

There are two pieces involved here:

• The implementation that connects the SCA binding to the JMS binding needs to propagate the message property.  This behavior tends to be implementation-specific.  Camel implementations will propagate properties on reference invocations by default because that's how Camel works.  Bean implementations, on the other hand, will not automatically propagate.
• Once the property is propagated by the implementation on the reference, the binding must be configured to pass it on the wire.  Some components (e.g. SOAP, HTTP) will automatically be picked up if they have the appropriate EndpointLabel, but after a quick review of the code for Camel and JCA bindings it doesn't appear to be supported for those.

The main reason for this behavior is so that we don't bleed properties between service invocations without explicit configuration on the part of the user.  Your best bet here is to use a custom context mapper to add the properties.  I think it would be a desirable feature for 3.0 to make sure that all bindings behave like SOAP/HTTP and pick up a property if it has the associated EndpointLabel defined.

Hi,

I think that for the ressubmission use case, making the service developer take such considerations into account, like a custom context mapper is not the best option.

As this is for rtgov integration, maybe exploring the option of the rtgov extension providing this modified behavior could do, although not maintainable.

I think there are some Jiras plus many questions related to why implementations doesnt behave in the same way as Keith described above, and to which I do agree, although not easily addresable ATM.

But even if you could set labels, headers are not carried if not belonging both ends to the same label type, so a jms reference will put back in the message headers that came via jms service, and thus, having same endpoint label, if I recall correctly.

Bottom line, not easy to implement today, but good timing to find a good solution for FUTURE features planning. I would recommend you describe the usecase in an RFE type of Jira, so the team thinks about it.

Cheers,

Hi,

I am using the RTGov resubmit feature and actually triggered that discussion.

As long as the service implementation configures the context mapper to pass the RTGov property, the resubmit feature works fine. However, this requires us to change the setup of several Context Mappers for the RTGov internal property '_rtogv_resubmittedSituationId'.

We currently have some Context Mappers with "Include Namespaces" set. '_rtogv_resubmittedSituationId' has no namespace. So I would have to add an empty namespace. How do you do that? My solution was to add the regex '^$', but this looks rather clumsy. In adiiton, it now maps all properties with an empty namespace. To solve this, you would need to add '_rtogv_resubmittedSituationId' and all required property names (from all namespaces) to the "Includes" parameter. (This is still gives you potentially more than expected.)

I also strongly agree with Jorge's comment that the mapping of internal properties (like '_rtogv_resubmittedSituationId') should be transparent to application developers and not be controlled by the application's setting of context mappers or their parameters.

Werner