9 Replies Latest reply on Jul 10, 2013 7:15 PM by kcbabo

    jaxb transformation in a camel route

    jbride

      Hi,

        This post is in reference to my SY app  with a couple of java bean components (BeanOne and BeanTwo) that could either be invoked directly from a corresponding SOAP service gw or via a camel route component (CamelChoice).

         Appropriate JAXB transformations are in place and do get invoked just fine if the originating SOAP call is to either IBeanOne or IBeanTwo SOAP service gateways.

       

        when the originating SOAP call is to IBeanCombo, the CamelChoice camel component does route appropriately.

        However, it invokes the java bean components with a null message body.

        This behavior is due to line 66 of CamelMessageComposer.java in the SY master branch.

         The logic in the composer assumes that if the target URI is a java bean component, the message body will also already be a java object.

         explicity executing SOAP-->java tranformations as part of the camel route solves the problem.

       

        couple of questions/observations :

       

      1)  SY does a nice job of implicitly invoking needed transformations  when the SOAP call originates from either my IBeanOne or IBeanTwo SOAP service gateways.

            of course i got greedy and assumed this special sauce would be applied for me anywhere I would need it :-)  .... to include somewhere between my camel route component and my target java bean component.

            so the null message body threw me for a loop until I reviewed the CamelMessageComposer code.

            I'm fine with explicitly handling the message transformations in the camel route.

            it may be helpful however to post a nice WARN log message explaining the cause/rationale of the null message body

       

       

      2)  what's the recommended approach to explicitly invoke a transformation from a camel route ??

           keith:  you already recommended use of the Camel jaxb marshaller .... and yes, that does work well  ( i had to add the camel-jaxb.jar as a jboss module and add that module as a dependency in my SY app )

            however, my SY app already defines JAXB transformations.   Is introducing the camel-jaxb.jar library the only option to explict do a jaxb transform in my camel route ?

           Is there a way that existing SY java and jaxb transformers can be referenced in a camel route via their URI  ?

            ie:  the URI to an xslt transform would be:    <to  uri="xslt:path/to/my/xslt" /> .     what is the equivalent uri  to my existing jaxb and java transformers  ?

       

       

      thank you!   jeff

        • 1. Re: jaxb transformation in a camel route
          kcbabo

          Are you sure this exists in master?  I would expect this type of issue to exist in 0.8, but should have been fixed with this:

          https://issues.jboss.org/browse/SWITCHYARD-1385

           

          Camel implementations shouldn't actually use composers as it tends to conflate the concerns of gateways and implementations inside a single class.  That's one of the clean up items for 1.0.

           

          Any invocation from a Camel route through a reference is eligible for declarative transformation.  There actually was a recent discussion about this in the forum about invoking a transformation between two bean components; the principle is the same with a Camel implementation invoking a bean service through a reference.

           

          We don't have a mechanism for programmatically invoking a transformation defined in switchyard.xml.  Based on the above reasons, however, I don't think this will be required for your scenario.  Could you attach a test app that I can use to reproduce the issue and make a suggestion?  The fix I mentioned is present in nightlies and will be included in 1.0.  If your target is 0.8, then a jaxb data format is your best bet to work around it if that worked in your situation.

          • 2. Re: jaxb transformation in a camel route
            ruchitel123

            Can you post details on how you managed to use jaxb transformation in camel route (installing camel-jaxb as module, any changes to switchard project, etc.)?

            Thanks.

            • 3. Re: jaxb transformation in a camel route
              splatch

              2)  what's the recommended approach to explicitly invoke a transformation from a camel route ??

              Since 1.0 you can use JAXB transformation inside camel routes in following way:

               

              <route>
                  <from uri="switchyard://foo"/>
                  <unmarshal>
                      <jaxb contextPath="my.jaxb.pkg"/>
                  </unmarshal>
              </route>
              

               

              The unmarshal gets xml contents and creates Java object, marshal writes object in XML representation.

              • 4. Re: jaxb transformation in a camel route
                ruchitel123

                When I tried that I got error that jaxb format can not be found.

                • 5. Re: jaxb transformation in a camel route
                  kcbabo

                  Are you using 1.0?

                  • 6. Re: jaxb transformation in a camel route
                    ruchitel123

                    No, I am using 0.8, do not see 1.0 on download page. Is it released already?

                    • 7. Re: jaxb transformation in a camel route
                      kcbabo

                      It is scheduled to be released this month.  There are nightly builds available if you want to try a SNAPSHOT build.  Lukasz mentioned above that this feature is only available in 1.0 , which is why it's not working for you on 0.8.

                      • 8. Re: jaxb transformation in a camel route
                        ruchitel123

                        Any updates on when 1.0 will be available? =

                        • 9. Re: jaxb transformation in a camel route
                          kcbabo

                          Very soon.  The runtime bits are ready, the artifacts are deployed to Nexus, and the codeline is tagged.  We are in the process of updating docs and going through the tooling one last time before announcing the release.