Woden
  1. Woden
  2. WODEN-86

MessageTest-1G, Woden lacks support for IRI with variable substitution used by HTTP location

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: M7
    • Component/s: Parser
    • Labels:
      None

      Description

      MessageTest-1G contains the XML:

      whttp:location="?op=EchoInt;int=

      {int};">

      This is a valid IRI, but Woden currently handles URIs only so it does not create a URI to represent this value in the model and issues the error message:

      Woden[Error],0:0,WSDL506,Could not create a URI from the string "?op=EchoInt;int={int}

      ;".,java.net.URISyntaxException:Illegal character in query at index 16: ?op=EchoInt;int=

      {int}

      ;

      For HTTP location, a new Woden class is required, instead of java.net.URI. to represent this IRI and handle the variable substitution curly braces syntax described for this property in the Part 2 Adjucts spec. This class could convert the IRI to a URI per the conversion described in RFC 3987 'IRI' (at least, convert the curly braces) then use the URI ctor to check that it is a valid URI, then store it internally in whatever format is appropriate (e.g. seperate fields, string, ...) and expose the IRI via the public methods of this new class. This class probably needs a toString method to return the original IRI string value.

        Activity

        Hide
        John Kaputin added a comment -

        Posted to mailing list 19th December:

        I have committed a fix for HTTP location which supports the use of template
        IRIs, as used in MessageTest1G and MessageTest2G. I still need to determine
        what further methods are required to aid template substitution - see Class
        javadoc comments. For the time being there is a method that takes a String
        array and substitutes these values into the template and returns the
        substituted string.

        Also, still need to fix compile errors introduced to the CM Writer when
        http location changed from a URI to the new HTTPLocation class. Will look
        into this later today.

        regards,
        John Kaputin

        Posted to mailing list 18th December:

        Chinthaka/Keith,
        I have create a class HTTPLocation to represent the

        {http location} value
        and I'm currently refactoring it into the existing code to replace the use
        of java.net.URI before committing it to SVN.

        Currently it returns the original value of this property as defined in the
        WSDL (with any curly brace template syntax) and it also checks to see if
        the format of this value is valid (i.e. if it can be converted into a URI
        after the curly braces are eliminated by substitution).

        I also have in mind some methods for accessing and substituting the
        templated local names with instance data values and returning the
        substituted string, but before creating these methods I would like to
        confirm that this is what you are expecting. Or do you expect to do just
        get the {http location}

        template from Woden and do the substitution within
        your Axis2 code?

        regards,
        John Kaputin

        Show
        John Kaputin added a comment - Posted to mailing list 19th December: I have committed a fix for HTTP location which supports the use of template IRIs, as used in MessageTest1G and MessageTest2G. I still need to determine what further methods are required to aid template substitution - see Class javadoc comments. For the time being there is a method that takes a String array and substitutes these values into the template and returns the substituted string. Also, still need to fix compile errors introduced to the CM Writer when http location changed from a URI to the new HTTPLocation class. Will look into this later today. regards, John Kaputin Posted to mailing list 18th December: Chinthaka/Keith, I have create a class HTTPLocation to represent the {http location} value and I'm currently refactoring it into the existing code to replace the use of java.net.URI before committing it to SVN. Currently it returns the original value of this property as defined in the WSDL (with any curly brace template syntax) and it also checks to see if the format of this value is valid (i.e. if it can be converted into a URI after the curly braces are eliminated by substitution). I also have in mind some methods for accessing and substituting the templated local names with instance data values and returning the substituted string, but before creating these methods I would like to confirm that this is what you are expecting. Or do you expect to do just get the {http location} template from Woden and do the substitution within your Axis2 code? regards, John Kaputin
        Hide
        John Kaputin added a comment -

        Initial commit of HTTPLocation class and refactoring to make use of it via rev. 488539

        Show
        John Kaputin added a comment - Initial commit of HTTPLocation class and refactoring to make use of it via rev. 488539
        Hide
        John Kaputin added a comment -

        r492571.
        Added behaviour to instantiate an object from
        a string, parse and validate the string and to
        derive a new location string based on the current
        state of the object. Work-in-progress with 'get'
        and 'substitute' methods declared but not yet implemented.

        When these remaining methods have been implementetd I intend to remove the existing method
        String getLocationSubstituted(String[] values), as this is will be replaced by various 'substitute'
        methods which substitute values for local names and a toString() method which returns the
        location derived from the substituted values.

        For example, the methods substitute(String[] values) and toString() together will replace the
        behaviour of this existing method, getLocationSubtituted(String[] values).

        Show
        John Kaputin added a comment - r492571. Added behaviour to instantiate an object from a string, parse and validate the string and to derive a new location string based on the current state of the object. Work-in-progress with 'get' and 'substitute' methods declared but not yet implemented. When these remaining methods have been implementetd I intend to remove the existing method String getLocationSubstituted(String[] values), as this is will be replaced by various 'substitute' methods which substitute values for local names and a toString() method which returns the location derived from the substituted values. For example, the methods substitute(String[] values) and toString() together will replace the behaviour of this existing method, getLocationSubtituted(String[] values).
        Hide
        John Kaputin added a comment -

        r493645.
        The remaining methods have now been implemented. The class is now complete. As per the previous comment I intend to remove the original method:

        getLocationSubstituted(String[] values)

        prior to the M7 release, but I will post to the woden-dev list first to check if it is being used yet for the w3c interop testing and if so, advise the new methods to use instead.

        Show
        John Kaputin added a comment - r493645. The remaining methods have now been implemented. The class is now complete. As per the previous comment I intend to remove the original method: getLocationSubstituted(String[] values) prior to the M7 release, but I will post to the woden-dev list first to check if it is being used yet for the w3c interop testing and if so, advise the new methods to use instead.
        Hide
        John Kaputin added a comment -

        Issue now resolved. Closure pending removal of a redundant method from HTTPLocation after confirmation via mailing list.

        Show
        John Kaputin added a comment - Issue now resolved. Closure pending removal of a redundant method from HTTPLocation after confirmation via mailing list.
        Hide
        John Kaputin added a comment -

        r495555 Removed the redundant method getLocationSubstituted.

        Show
        John Kaputin added a comment - r495555 Removed the redundant method getLocationSubstituted.
        Hide
        Keith Godwin Chapman added a comment -

        Hi John,

        The HttpLocation class is very handy indeed. We use on the client side to substitute the URI with values given by the user. Do u hav any intention of adding methods that would do the reverse too? (Given a substituded URI obtain name value pairs)

        Thanks,
        Keith

        Show
        Keith Godwin Chapman added a comment - Hi John, The HttpLocation class is very handy indeed. We use on the client side to substitute the URI with values given by the user. Do u hav any intention of adding methods that would do the reverse too? (Given a substituded URI obtain name value pairs) Thanks, Keith
        Hide
        John Kaputin added a comment -

        Hi Keith,
        I'm pleased you find the HTTPLocation class useful. It provides quite a few different getter and substitute methods for accessing and modifying the element templates, so can you tell me which methods in particular are useful to you and if any are not particularly useful? This 'usage' feedback will help us refine the API to make it more generally useful.

        Regarding your latest requirement, consider the location template whttp:location="op=EchoInt,value=

        {int}" and the actual substituted location string "op=EchoInt,value=2" used to build the message (assuming the value of element 'int' is 2).

        When we did the substitution we had the curly brace syntax in the template to tell us what could be changed. To change the actual location "op=EchoInt,value=2" back to the original template we don't have any syntactical clues in the string to tell us which bits were represented as curly brace syntax and which were literals in the original template. We can't rely on the equals sign '=' as the clue, because in this example only the second '=' corresponds to an element template. For example, we can't tell if this substituted string was originally templated as "op=EchoInt,value={int}

        " or "op=

        {someName},value={int}" or "op={someName}

        ,value=2". In other examples there may not be an '=' character (e.g. "/temperature/

        {town}

        ").

        I assume your requirement is to do with a Java2WSDL scenario - generating WSDL from java objects and serializing the WSDL documents. I guess we could add methods that allow you to specify two strings; one string is some element value substring from the actual location (e.g. "2") and the second is the local name of the element this value represents (e.g. "int"). With that information we could possibly reconstruct the template from an actual location string. For example, given the actual location "op=EchoInt,value=2" we could construct the template "op=EchoInt,value=

        {int}

        ". I say "possibly" because there are issues to do with duplicate value strings being present in the actual location and so on.

        If these new methods were to take further information like the start position within the actual location string, then it's so close the the java.lang.String class that it might be better to simply use that within your own code.

        I think any approach to reconstruct the template from an actual location string will assume that your code has knowledge of which bits of the actual location correspond to elements in the instance data. Is this assumption correct? Please let me know your thoughts on my analysis above.

        regards,
        John.

        Show
        John Kaputin added a comment - Hi Keith, I'm pleased you find the HTTPLocation class useful. It provides quite a few different getter and substitute methods for accessing and modifying the element templates, so can you tell me which methods in particular are useful to you and if any are not particularly useful? This 'usage' feedback will help us refine the API to make it more generally useful. Regarding your latest requirement, consider the location template whttp:location="op=EchoInt,value= {int}" and the actual substituted location string "op=EchoInt,value=2" used to build the message (assuming the value of element 'int' is 2). When we did the substitution we had the curly brace syntax in the template to tell us what could be changed. To change the actual location "op=EchoInt,value=2" back to the original template we don't have any syntactical clues in the string to tell us which bits were represented as curly brace syntax and which were literals in the original template. We can't rely on the equals sign '=' as the clue, because in this example only the second '=' corresponds to an element template. For example, we can't tell if this substituted string was originally templated as "op=EchoInt,value={int} " or "op= {someName},value={int}" or "op={someName} ,value=2". In other examples there may not be an '=' character (e.g. "/temperature/ {town} "). I assume your requirement is to do with a Java2WSDL scenario - generating WSDL from java objects and serializing the WSDL documents. I guess we could add methods that allow you to specify two strings; one string is some element value substring from the actual location (e.g. "2") and the second is the local name of the element this value represents (e.g. "int"). With that information we could possibly reconstruct the template from an actual location string. For example, given the actual location "op=EchoInt,value=2" we could construct the template "op=EchoInt,value= {int} ". I say "possibly" because there are issues to do with duplicate value strings being present in the actual location and so on. If these new methods were to take further information like the start position within the actual location string, then it's so close the the java.lang.String class that it might be better to simply use that within your own code. I think any approach to reconstruct the template from an actual location string will assume that your code has knowledge of which bits of the actual location correspond to elements in the instance data. Is this assumption correct? Please let me know your thoughts on my analysis above. regards, John.
        Hide
        John Kaputin added a comment -

        Closed as MessageTest-1G is passing. Will open new JIRA to support the new EBNF grammar for http location.

        Show
        John Kaputin added a comment - Closed as MessageTest-1G is passing. Will open new JIRA to support the new EBNF grammar for http location.

          People

          • Assignee:
            John Kaputin
            Reporter:
            John Kaputin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development