1 2 Previous Next 21 Replies Latest reply on May 11, 2012 6:57 PM by David Ward Go to original post
      • 15. Re: How to set a SOAP message header?
        Keith Babo Master

        Well, this seems to have come along nicely.  Aiming for flexibility in the context mapper via configuration sounds great.  Gives us an option to have a sensible default which users can override as necessary.


        One point on the prefix - the reason I've seen a prefix employed before is to create a separate namespace for header/property keys.  You can imagine how name collision could be a problem if a message comes in via SOAP gateway and picks up SOAP headers, then hits a Camel routes and picks up message/exchange headers there, then exits via a HornetQ binding (which maps properties to a JMS message and/or drives processing off of property values).  So whatever mechanism we come up with, I agree that it should not be specific to SOAP and it should also be configurable.


        We should tune the defaults over time to match the most common usage patterns.

        • 16. Re: How to set a SOAP message header?
          Ivo Bek Newbie

          I agree with it, I have just wanted to point, how It could work and It may help you to do the SWITCHYARD-710. I think that we should have the prefixes because we need to specify which property belongs to SOAP header, but as you said it could be configurable.


          I worry how I could change the configuration or call the include or exclude methods to set them if I'm not able to change contextMapper from the Exchange instance (maybe I only don't about the way how to get a MessageComposer) because I need to set it in BPEL component.

          • 17. Re: How to set a SOAP message header?
            David Ward Master

            Ivo, I do appreciate the suggestion on how to make it work. Thanks you.


            Regarding your concern described in your second paragraph, I don't fully understand what you mean. If you're asking how to set the includes and excludes, then the answer is that you have to add a <contextMapper/> element in your switchyard.xml yourself (in src/main/resources/META-INF/switchyard.xml). By default, it's not there and no properties will get mapped. When your project builds, the configuration in that file will get merged into the resulting configuration (in target/classes/META-INF/switchyard.xml).  This is done by the switchyard maven plugin.  You don't have to do any of it programatically.

            • 18. Re: How to set a SOAP message header?
              Ivo Bek Newbie

              But this have to be done in the user's project switchyard.xml, don't have to? Thus, every BPEL project would require to set the configuration and includes. But the configuration must be set e.g. to use Nodes because BPEL component requires this and nothing else. From the user point of view, they wouldn't know why is there this property and why cannot be set to another. The same issue is when the user only wants to have a BPEL process which invokes WS requiring WS-AtomicTransaction so there must be transaction context in the SOAP header, BUT user has to set the includes to make it work and the user maybe don't know why he has to do it. I hope that I'm wrong. I still thinks that all header parts should be mapped to or from the context only for the excludes I would filter them, because in another case I think that there will be a lot of issues that something doesn't work.

              • 19. Re: How to set a SOAP message header?
                Keith Babo Master

                Well, every BPEL project that wants to use SOAP headers would have to do it.  That's an important distinction.  The user is making a conscious decision that transport data (i.e. SOAP headers) is going to propagate to the component and they need to specify what form that should take.

                One thing we all need to agree on here is that there will *not* be a one size fits all solution to the problem.  I absolutely agree that the configuration should be simple and it's possible that behavior could change between specific context mappers (e.g. SOAP context mapper could propagate by default as Node, while Camel context mapper does not).  Before we go there, we should start with a sensible default which can be tuned via configuration.  If it's a pain in the butt to specify the config, users will tell us.  We then use that feedback to update defaults, simplify configuration, and add specific behavior to a given context mapper as appropriate.

                1 2 Previous Next