12 Replies Latest reply on Jun 12, 2012 4:02 PM by dward

    Message level headers in Switchyard

    splatch

      Hey,

      I have question about headers in Switchyard. At this moment we don't have any API to access data different than message payload. By this way we can't propagate some useful stuff like headers. They often are used for routing purposes. Most of protocols we support have a way to specify headers - http, jms and soap too. Will we support this in future?

       

      Best regards,

      Lukasz

        • 1. Re: Message level headers in Switchyard
          dward

          Protocol-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

          1 of 1 people found this helpful
          • 2. Re: Message level headers in Switchyard
            rcernich

            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

              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.

              • 4. Re: Message level headers in Switchyard
                splatch

                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

                • 5. Re: Message level headers in Switchyard
                  erhard
                  • 6. Re: Message level headers in Switchyard
                    dward

                    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

                      I will be closing this jira, as it is not a bug.

                      • 8. Re: Message level headers in Switchyard
                        splatch

                        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

                          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

                            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

                              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

                                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.