Camel
  1. Camel
  2. CAMEL-201

allow expressions such as XQuery to be used as a transformer

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4.0
    • Component/s: camel-core
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      e.g.

      <route>
        <from uri="activemq:Foo.Bar"/>
         <transform>
           <xquery>....</xquery>
        </transform>
      </route>
      

      This basically means renaming the DSL's setOutBody() to be transform(Expression)

      1. camel-201-2.patch
        20 kB
        Jonathan Anstey
      2. camel-201.patch
        18 kB
        Jonathan Anstey

        Issue Links

          Activity

          Hide
          Jonathan Anstey added a comment -

          I finally got around to doing this one up. There are no XQuery specific tests (mainly because of not knowing where to put them ), but it is generic enough to work for any expression language. Let me know if you have any questions!

          Show
          Jonathan Anstey added a comment - I finally got around to doing this one up. There are no XQuery specific tests (mainly because of not knowing where to put them ), but it is generic enough to work for any expression language. Let me know if you have any questions!
          Hide
          Claus Ibsen added a comment -

          Johathan. The patch looks great. Only two issues with the ident of the code.
          One @override was not idented properly. And one method parameter was on a new line instead of singleline. Just nitpicking.

          Would love to have it documented on the wiki that we got this new transform DSL now.
          And we should remember to add it to the release notes that setOutBody() is depreacted and replaced with transform()

          And since setOutBody() is to be replaced with transform. Could we have a unit test that verifies a setOutBody() test that is done by transform render the same OUT body?

          Show
          Claus Ibsen added a comment - Johathan. The patch looks great. Only two issues with the ident of the code. One @override was not idented properly. And one method parameter was on a new line instead of singleline. Just nitpicking. Would love to have it documented on the wiki that we got this new transform DSL now. And we should remember to add it to the release notes that setOutBody() is depreacted and replaced with transform() And since setOutBody() is to be replaced with transform. Could we have a unit test that verifies a setOutBody() test that is done by transform render the same OUT body?
          Hide
          Jonathan Anstey added a comment -

          Hey Claus,

          Nitpick away I fixed up the indentations and added a test that verifies the deprecated setOutBody method still behaves. Yeah, the wiki will need to be updated once this feature gets in.

          Show
          Jonathan Anstey added a comment - Hey Claus, Nitpick away I fixed up the indentations and added a test that verifies the deprecated setOutBody method still behaves. Yeah, the wiki will need to be updated once this feature gets in.
          Hide
          Hadrian Zbarcea added a comment - - edited

          Patch applied. Excellent contribution, thanks Jon. I will leave this issue open until we update the documentation.

          Show
          Hadrian Zbarcea added a comment - - edited Patch applied. Excellent contribution, thanks Jon. I will leave this issue open until we update the documentation.
          Hide
          Jonathan Anstey added a comment -

          Updated the docs for this at: http://cwiki.apache.org/confluence/display/CAMEL/Message+Translator

          Unfortunately, it doesn't look as nice as it should because confluence is barfing all over the place with the following message:
          "An error occurred: Connection refused. The system administrator has been notified."

          Show
          Jonathan Anstey added a comment - Updated the docs for this at: http://cwiki.apache.org/confluence/display/CAMEL/Message+Translator Unfortunately, it doesn't look as nice as it should because confluence is barfing all over the place with the following message: "An error occurred: Connection refused. The system administrator has been notified."
          Hide
          james strachan added a comment -

          Jonathan: btw there's some XQuery tests in components/camel-saxon where the XQuery implementation lives, for example XQueryFilterTest.java

          Show
          james strachan added a comment - Jonathan: btw there's some XQuery tests in components/camel-saxon where the XQuery implementation lives, for example XQueryFilterTest.java
          Hide
          Jonathan Anstey added a comment -

          IIRC one of my issues for putting a spring transform test in camel-saxon was that the public camel xsd did not contain the transform element yet and so it failed to resolve. The camel-spring module has some magic in there to use a locally built xsd, so the transform element could be tested there fine. Since putting an XQuery test in camel-spring is a bad idea (circular dependency!), I opted for a test case using the "simple" expression language. Make sense?

          Show
          Jonathan Anstey added a comment - IIRC one of my issues for putting a spring transform test in camel-saxon was that the public camel xsd did not contain the transform element yet and so it failed to resolve. The camel-spring module has some magic in there to use a locally built xsd, so the transform element could be tested there fine. Since putting an XQuery test in camel-spring is a bad idea (circular dependency!), I opted for a test case using the "simple" expression language. Make sense?
          Hide
          james strachan added a comment -

          Got it.

          BTW when running unit tests using the Spring XSD, Spring will use the XSD thats on the classpath by default. So the XSD will validate in camel-saxon as it'll use the latest/greatest XSD generated by camel-spring.

          The only time it won't validate is in your IDE when editing the XML

          But then you can fudge your IDE to take the XSD from your generated XSD in camel-spring/target/schema/camel-*.xsd

          Show
          james strachan added a comment - Got it. BTW when running unit tests using the Spring XSD, Spring will use the XSD thats on the classpath by default. So the XSD will validate in camel-saxon as it'll use the latest/greatest XSD generated by camel-spring. The only time it won't validate is in your IDE when editing the XML But then you can fudge your IDE to take the XSD from your generated XSD in camel-spring/target/schema/camel-*.xsd
          Hide
          Jonathan Anstey added a comment -

          Oh, neat! I could swear I hit the case where it wasn't using the locally built xsd though... perhaps I'm going crazy

          I was just gonna try it out again but it seems apache svn is down... grumble grumble...

          Show
          Jonathan Anstey added a comment - Oh, neat! I could swear I hit the case where it wasn't using the locally built xsd though... perhaps I'm going crazy I was just gonna try it out again but it seems apache svn is down... grumble grumble...
          Hide
          james strachan added a comment -

          You've gotta make sure your project is using the latest/greatest built camel-spring jar though! Sometimes IDE based maven projects have a tendency to pick a different version

          Show
          james strachan added a comment - You've gotta make sure your project is using the latest/greatest built camel-spring jar though! Sometimes IDE based maven projects have a tendency to pick a different version
          Hide
          Jonathan Anstey added a comment -

          Yeah, I know... because of this I still don't trust Eclipse based results when it comes to multi-module maven projects. When multiple modules are involved I always run the maven build from the command line just to be sure!

          Show
          Jonathan Anstey added a comment - Yeah, I know... because of this I still don't trust Eclipse based results when it comes to multi-module maven projects. When multiple modules are involved I always run the maven build from the command line just to be sure!

            People

            • Assignee:
              Jonathan Anstey
              Reporter:
              james strachan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development