[
https://issues.apache.org/jira/browse/WODEN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465176
]
John Kaputin commented on WODEN-86:
-----------------------------------
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.
> MessageTest-1G, Woden lacks support for IRI with variable substitution used
> by HTTP location
> --------------------------------------------------------------------------------------------
>
> Key: WODEN-86
> URL: https://issues.apache.org/jira/browse/WODEN-86
> Project: Woden
> Issue Type: Bug
> Components: Parser
> Reporter: John Kaputin
> Assigned To: John Kaputin
> Fix For: M7
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
