2 Replies Latest reply on Mar 25, 2011 7:27 AM by tfennelly

    Transformation Selection

    tfennelly

      At the moment, BaseTransformerRegistry.getTransformer(QName from, QName to) stores Transformer instances in a Map, keyed off a composite of the to and from QNames.  The lookup is a straightforward Map.get(key) operation.  If there's a Transformer there that exactly matches the key then we get it, otherwise we get nothing.  That's fine.

       

      A bit of a problem arrises out of the fact that there's an obvious type hierarchy in Java, so the above mechansim (strightforward keyed Map lookup) doesn't allow us to easily define a transformer for a family of Java types e.g. java.io.Reader or a generalised Exception type transformer.  I came across this before with Exceptions, but punted it.  Running into it again now with SWITCHYARD-185.  Of course we could work around it by defining <transformer> configs for all possible types in a given type hierarchy, but that's obviously a totally horrible solution.

       

      So to clarify with an example... I want the following transformer to work for any Reader type....

       

      <trfm:transform.java from="java:java.io.Reader" to="java:org.w3c.dom.Document" class="org.switchyard.transform.ootb.xml.BasicDOMTransformer"/>
      

       

      So no mater if the Message payload contained an InputStreamReader, or a FileReader, or a StringReader etc, the above transfomer would be returned if there was not an exact match.  Taking a concrete example of where a Message contains a FileReader instance and a Message.getContent(Document.class) call was made.  BaseTransformerRegistry.getTransformer(QName from, QName to) would be called with from and to QNames of "java:java.io.FileReader" and "java:org.w3c.dom.Document" respectively.  A lookup on the Transformer Map would be constructed from both of these and nothing would be found.  In this situation (for "java:*" types) we understand that a type hierarchy is in place, so the getTransfomer method should be able to fall back to and return the above transformer (where the from QName is "java:java.io.Reader").

       

      I'm knocking out a first pass on this as part of SWITCHYARD-185, but just wanted to throw it out there so others could think about it too.

        • 1. Transformation Selection
          kcbabo

          This seems reasonable to me.  So the registry can look at the type name and if it's "java:", it can load the class and pick through the inheritance hierarchy (bottom to top) as part of its lookup for a transfomer.

          • 2. Transformation Selection
            tfennelly

            Exactly   Nothing too complex and only on the "from" part.  The "to" will need to be an exact match.  At least that's how the first version of it will be working.