[overlord-issues] [JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty

[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ] Gary Brown edited comment on RTGOV-566 at 9/16/14 12:58 PM: ------------------------------------------------------------ Was initially thinking that may be the relevant header values could be extracted individually using the existing mechanism in the ip.json definition. However the xpath type processor is limited, as it was implemented to extract the attribute values, rather than intended to represent xml doc fragments - so a patch would be required anyway. Therefore rather than trying to use the existing mechanism, I'm thinking it may be better to leverage the use of 'serialize' transformer as an indication that header values are also required - or having a configuration property on this transformer (e.g. 'includeHeaders') to enable message content only serialization to also be supported? So essentially the main approach would be, * leave the property mechanism as is, to extract specific information from the message content or header values * if 'serialize' (with includeHeaders=true) is defined for the 'transformer', then encode relevant values in a special map property May need to limit the types that can be serialized initially to string and DOM? SwitchYard security context would be handled as a special case, after deciding best approach. was (Author: objectiser): Was initially thinking that may be the relevant header values could be extracted individually using the existing mechanism in the ip.json definition. However the xpath type processor is limited, as it was implemented to extract the attribute values, rather than intended to represent xml doc fragments - so a patch would be required anyway. Therefore rather than trying to use the existing mechanism, I'm thinking it may be better to leverage the use of 'serialize' transformer as an indication that header values are also required - or having a variation (e.g. 'serializeWithHeaders') to enable message content only serialization to be supported? So essentially the main approach would be, * leave the property mechanism as is, to extract specific information from the message content or header values * if 'serialize' or 'serializeWithHeaders' is defined for the 'transformer', then encode relevant values in a special map property May need to limit the types that can be serialized initially to string and DOM? SwitchYard security context would be handled as a special case, after deciding best approach. -- This message was sent by Atlassian JIRA (v6.3.1#6329)