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

• Key: WODEN-86
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: John Kaputin
• Reporter: John Kaputin
• Component/s: Parser
• Fix Version/s: M7

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.

Comments

[John Kaputin]

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

[John Kaputin]

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

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).

[John Kaputin]

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.

[John Kaputin]

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

[John Kaputin]

r495555 Removed the redundant method getLocationSubstituted.

[Keith Godwin Chapman]

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

[John Kaputin]

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.

[John Kaputin]

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