-
1. Re: Message level headers in Switchyard
dward Jun 11, 2012 12:36 PM (in response to splatch)1 of 1 people found this helpfulProtocol-specific headers get turned into and out-of SwitchYard Context properties by ContextMappers (an aspect of Message Composition). You can read about it here:
https://docs.jboss.org/author/display/SWITCHYARD/Message+Composition
-
2. Re: Message level headers in Switchyard
rcernich Jun 11, 2012 12:46 PM (in response to dward)I had an issue using MessageComposer a while back, SWITCHYARD-590. I'm not sure if that's still an issue, but it might be related.
-
3. Re: Message level headers in Switchyard
erhard Jun 12, 2012 1:29 PM (in response to rcernich)There seems to be a problem at least with Camel headers. I tried a Camel route like this:
{code}
public void configure() {
from("switchyard://FileService")
.log("Received message for FileService : ${body}")
.to("switchyard://OutputFile")
.to("file://target/output1");
}
{code}
where FileService is bound to a Camel file endpoint and OutputFile is bound to a Camel file as well. When I put a file "test.txt" into the input folder, I get a file with name test.txt in target/output1 (as expected), but in the directory from the switchyard endpoint I just get a generated filename.
In Camel the filename is saved in the header property CamelFileName. So appearently this header is passed correctly into the camel route from switchyard://FileService, but seems to be lost on the way out to switchyard://OutputFile.
This is the switchyard.xml:
{code}
<?xml version="1.0" encoding="UTF-8"?><switchyard xmlns="urn:switchyard-config:switchyard:1.0">
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="CamelFileTest" targetNamespace="urn:switchyard:application:">
<service name="FileService" promote="FileService">
<interface.java interface="at.objectbay.tests.FileService" />
<binding.camel xmlns="urn:switchyard-component-camel:config:1.0" configURI="file://target/input"/>
</service>
<reference multiplicity="1..1" name="OutputFile" promote="OutputFile">
<binding.camel xmlns="urn:switchyard-component-camel:config:1.0" configURI="file://target/output"/>
</reference>
<component name="FileServiceBuilder">
<reference name="OutputFile" >
<interface.java interface="at.objectbay.tests.FileService" />
</reference>
</component>
</composite>
</switchyard>
{code}
Attached a test case.
-
camel-file-test.zip 10.4 KB
-
-
4. Re: Message level headers in Switchyard
splatch Jun 12, 2012 2:00 PM (in response to erhard)Hey Erhard,
This is a bug in Switchyard Producer which doesn't copy headers. It creates always new camel message, so inbound headers are not copied to outbound message. Could you please create JIRA for that to track issue?
Best regards,
Lukasz
-
-
6. Re: Message level headers in Switchyard
dward Jun 12, 2012 2:48 PM (in response to splatch)Please be more sure before proclaiming something is a bug. It is, in fact, not a bug in SwitchYardProducer. The bug is in the test case itself. The test case's switchyard.xml fails to add <contextMapper includes=".*"/> in the camel bindings. If you don't specify a context mapper, no properties will get copied over. This is expected behavior. I was able to get the test case to work just by adding that element to the camel bindings.
-
7. Re: Message level headers in Switchyard
dward Jun 12, 2012 2:49 PM (in response to erhard)I will be closing this jira, as it is not a bug.
-
8. Re: Message level headers in Switchyard
splatch Jun 12, 2012 3:39 PM (in response to dward)I am not aware of your strategy, but with camel all headers are copied by default. Camel components propagate headers all the time. So from my point of view if some header is lost in camel flow it is a bug. Shouldn't we consider to have <contextMapper includes=".*"/> by default for camel bindings?
-
9. Re: Message level headers in Switchyard
erhard Jun 12, 2012 3:43 PM (in response to dward)Hi David,
Thanx a lot for the help. Its working now. Actually it was enough to add the context mapper to the outfile.
I just wanted to mention that expectations might differ depending how much you know from a system So here a the expectations from a switchyard newbie:
First I thought, when the headers go in, shey should go out as well.
I also red the documentation you mentioned. From
"... a CamelContextMapper, and a HornetQContextMapper. These default implementations are used by their associated bindings, but can be overridden by the user."
and from
"... When processing an outgoing CamelMessage, it takes the SwitchYard Scope.OUT Context properties and maps them into the CamelMessage as headers,"
I didn't expext that that one has to include headers explicitly. This could be a reasonable default.
But certainly I don't expect bugfree software and perfect documentation at this early stage of the project and I really like the idea behind switchyard
Best regards
Erhard
-
10. Re: Message level headers in Switchyard
dward Jun 12, 2012 3:55 PM (in response to splatch)It's not a bug since the expected behavior for all bindings is that no context properties get copied over by default. I can see how that is not clear in the documentation, however. You have to specify your includes and/or includesNamespaces.
I might be swayed into changing the default includes for the camel context mapper to be <contextMapper includes="Camel.*"/>, however I would suggest starting a new discussion thread about that, and once people have had a chance to provide feedback, THEN create a feature request jira (not a bug jira) for it.
-
11. Re: Message level headers in Switchyard
dward Jun 12, 2012 3:57 PM (in response to erhard)Please see my most recent response to Lukasz above. I think all camel headers start with "Camel", right? Perhaps a reasonable default would be <contextMapper includes="Camel.*"/> then. But I think a fresh discussion thread would be good for this as I described above.
-
12. Re: Message level headers in Switchyard
dward Jun 12, 2012 4:02 PM (in response to dward)I might want to also add some filters to the generic contextMapper handling of properties... Maybe includesLabels="" would be good too... 'cause then we can use the binding-specific property labels, like CamelComposition.CAMEL_MESSAGE_HEADER or CamelComposition.CAMEL_EXHANGE_PROPERTY, for example.