3 Replies Latest reply on Jun 1, 2009 3:33 PM by scottdawson

    XsltAction

    beve

      I'm starting work on https://jira.jboss.org/jira/browse/JBESB-2584 and wanted to gather requirements/requests.

      A suggested sample config could look like this:

      <action name="xslt-transform" class="org.jboss.soa.esb.actions.transformation.xslt.XsltAction">
       <property name="templateFile" value="/sample.xsl"/>
       <property name="failOnWarning" value="true"/>
      </action>

      I was thinking that we also should support the ability to add TranformerFactoryFeatures and attributes. For example, adding a feature could look like this:
      <property name="factory.feature.http://javax.xml.XMLConstants/feature/secure-processing" value="true"/>

      The same things would then apply to attributes but the prefix would be 'factory.attribute'.
      Also the ability to specify a URIResolver (http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/transform/URIResolver.html) to make things flexible.

      Suggestion from TomF:
      I think the impl should support multiple Source types, defaulting to StreamSource

      So the message payload could be a File, an InputStream, or Reader (String payload would be a StringReader in which case a a StreamSource would be used). The message payload could also be a DOMSource or a SAXSource. Are there any others ?
      The same options should exist for the result as well then right?

      All suggestions are welcome!

      Thanks,

      /Daniel




        • 1. Re: XsltAction
          scottdawson

          Hi Daniel,
          A configuration option you might consider supporting is the dynamic specification of the XSLT file used for the transformation. Multiple XSLT files could be packaged in the .esb archive and dynamic selection happens for each incoming message. One possible selection method is an XPath expression that computes the XSLT filename from the incoming XML. The configuration might look something like this:

          <property name="templateFileXPathSelector" value="concat(/someElement/text(),'.xslt')" />
          


          Thanks,
          Scott

          • 2. Re: XsltAction
            beve

            Hi Scott,

            thanks for your suggestion!

            Just a thought, could we have a content based router that does the xpath stuff and routes to a service which would then have the dedicated XsltAction. This would keep the XsltAction simple which I think would be an advantage. What do you think?

            Now the xpath router stuff is not there yet but should be soon:
            Forum thread:http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154882
            Jira:https://jira.jboss.org/jira/browse/JBESB-2583

            Regards,

            /Daniel

            • 3. Re: XsltAction
              scottdawson

              Daniel - yes, I think the XPath CBR would be sufficient for lots of use cases. So the XPath CBR action could be configured to route, for example, all messages containing an "order" element to the order-xslt service which would contain an action specifying the XSLT file for transforming orders. You would need a service for each required XSLT transformation. As you said, it keeps the XsltAction simple, which is typically a good thing.

              Thanks for the quick response.

              Regards,
              Scott