You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Alexis Midon (JIRA)" <ji...@apache.org> on 2008/07/22 19:53:31 UTC
[jira] Created: (ODE-344) Support element for headers and query
strings
Support element for headers and query strings
---------------------------------------------
Key: ODE-344
URL: https://issues.apache.org/jira/browse/ODE-344
Project: ODE
Issue Type: Improvement
Components: Axis2 Integration
Reporter: Alexis Midon
So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
This improvement aims at support elements too.
So for a given part A, if A as a text-node, take the content of that node ;
else check if a child element exists and take the text content of that element.
Which can be sum up in: take the content of the first encountered text node.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (ODE-344) Support element for headers and query strings
Posted by Alexis Midon <mi...@intalio.com>.
ok, we were on the same page from the beginning so.
sorry for unprecise wording.
On Tue, Jul 22, 2008 at 2:25 PM, Assaf Arkin <ar...@intalio.com> wrote:
> On Tue, Jul 22, 2008 at 12:09 PM, Alexis Midon <mi...@intalio.com> wrote:
> > The initial question was: should the REST connector use element (of a
> simple
> > type) or simple type for header parts in the wsdl?
> >
> > <part name="headerA" type="xs:string"/>
> > or
> > <xs:element type="xs:string" name="foo" />
> > ...
> > <part name="headerA" element="foo"/>
> >
> > So in the message, I could get:
> > <message>
> > <headerA>a-string</headerA>
> > or
> > <headerA><foo>a-string</foo></headerA>
> > </message>
> >
> > My goal was to support both. If the part element has a child element
> > (<foo>), get its text content, else get the text content of the part
> > element. If none thow an exception.
> > (not a really deep recursion)
> >
> > Using elements make the life easier on the designer side -- every part
> will
> > have an element (but it does not mean that the user must provide one) --
> and
> > allows to use default values. But for hand-written wsdls, having an
> element
> > for every simple type is quite cumbersome.
> >
> > So the idea was to support both. Which will you go for?
>
> Both!
>
> I was specifically commenting on:
>
> "take the content of the first encountered text node."
>
> That would fail in two case. First, the simple type element could
> have multiple text nodes (something to do with entity expansion), so
> you're only reading half the value. Second, it's actually a complex
> type and instead of detecting and failing, you're silently swallowing
> the error.
>
> <foo>
> <bar>bad!</bar>
> </foo>
>
> You end up reading the first encountered text node, which is the
> whitespace leading up to the bar element, instead of detecting and
> failing because foo is not a simple type.
>
> Assaf
>
>
> >
> >
> >
> > On Tue, Jul 22, 2008 at 11:21 AM, Assaf Arkin (JIRA) <ji...@apache.org>
> > wrote:
> >
> >>
> >> [
> >>
> https://issues.apache.org/jira/browse/ODE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615710#action_12615710
> ]
> >>
> >> Assaf Arkin commented on ODE-344:
> >> ---------------------------------
> >>
> >> Mixed content is the root of all unexplained bugs.
> >>
> >> If the element is simple type, we can say that mapping that element is
> the
> >> same as mapping its content (i.e. all its text nodes). If the element
> is
> >> complex type, something is wrong, throw a selection fault. If someone
> >> really meant to discard the element contents except for the text nodes,
> they
> >> can say so explicitly using XPath.
> >>
> >> > Support element for headers and query strings
> >> > ---------------------------------------------
> >> >
> >> > Key: ODE-344
> >> > URL: https://issues.apache.org/jira/browse/ODE-344
> >> > Project: ODE
> >> > Issue Type: Improvement
> >> > Components: Axis2 Integration
> >> > Reporter: Alexis Midon
> >> >
> >> > So far, parts bound to HTTP headers or encoding withe
> >> url-encoded/x-www-form-urlencoded must be simple types.
> >> > This improvement aims at support elements too.
> >> > So for a given part A, if A as a text-node, take the content of that
> node
> >> ;
> >> > else check if a child element exists and take the text content of that
> >> element.
> >> > Which can be summed up in: take the content of the first encountered
> text
> >> node.
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> You can reply to this email to add a comment to the issue online.
> >>
> >>
> >
>
Re: [jira] Commented: (ODE-344) Support element for headers and query strings
Posted by Assaf Arkin <ar...@intalio.com>.
On Tue, Jul 22, 2008 at 12:09 PM, Alexis Midon <mi...@intalio.com> wrote:
> The initial question was: should the REST connector use element (of a simple
> type) or simple type for header parts in the wsdl?
>
> <part name="headerA" type="xs:string"/>
> or
> <xs:element type="xs:string" name="foo" />
> ...
> <part name="headerA" element="foo"/>
>
> So in the message, I could get:
> <message>
> <headerA>a-string</headerA>
> or
> <headerA><foo>a-string</foo></headerA>
> </message>
>
> My goal was to support both. If the part element has a child element
> (<foo>), get its text content, else get the text content of the part
> element. If none thow an exception.
> (not a really deep recursion)
>
> Using elements make the life easier on the designer side -- every part will
> have an element (but it does not mean that the user must provide one) -- and
> allows to use default values. But for hand-written wsdls, having an element
> for every simple type is quite cumbersome.
>
> So the idea was to support both. Which will you go for?
Both!
I was specifically commenting on:
"take the content of the first encountered text node."
That would fail in two case. First, the simple type element could
have multiple text nodes (something to do with entity expansion), so
you're only reading half the value. Second, it's actually a complex
type and instead of detecting and failing, you're silently swallowing
the error.
<foo>
<bar>bad!</bar>
</foo>
You end up reading the first encountered text node, which is the
whitespace leading up to the bar element, instead of detecting and
failing because foo is not a simple type.
Assaf
>
>
>
> On Tue, Jul 22, 2008 at 11:21 AM, Assaf Arkin (JIRA) <ji...@apache.org>
> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/ODE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615710#action_12615710]
>>
>> Assaf Arkin commented on ODE-344:
>> ---------------------------------
>>
>> Mixed content is the root of all unexplained bugs.
>>
>> If the element is simple type, we can say that mapping that element is the
>> same as mapping its content (i.e. all its text nodes). If the element is
>> complex type, something is wrong, throw a selection fault. If someone
>> really meant to discard the element contents except for the text nodes, they
>> can say so explicitly using XPath.
>>
>> > Support element for headers and query strings
>> > ---------------------------------------------
>> >
>> > Key: ODE-344
>> > URL: https://issues.apache.org/jira/browse/ODE-344
>> > Project: ODE
>> > Issue Type: Improvement
>> > Components: Axis2 Integration
>> > Reporter: Alexis Midon
>> >
>> > So far, parts bound to HTTP headers or encoding withe
>> url-encoded/x-www-form-urlencoded must be simple types.
>> > This improvement aims at support elements too.
>> > So for a given part A, if A as a text-node, take the content of that node
>> ;
>> > else check if a child element exists and take the text content of that
>> element.
>> > Which can be summed up in: take the content of the first encountered text
>> node.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>
Re: [jira] Commented: (ODE-344) Support element for headers and query strings
Posted by Alexis Midon <mi...@intalio.com>.
The initial question was: should the REST connector use element (of a simple
type) or simple type for header parts in the wsdl?
<part name="headerA" type="xs:string"/>
or
<xs:element type="xs:string" name="foo" />
...
<part name="headerA" element="foo"/>
So in the message, I could get:
<message>
<headerA>a-string</headerA>
or
<headerA><foo>a-string</foo></headerA>
</message>
My goal was to support both. If the part element has a child element
(<foo>), get its text content, else get the text content of the part
element. If none thow an exception.
(not a really deep recursion)
Using elements make the life easier on the designer side -- every part will
have an element (but it does not mean that the user must provide one) -- and
allows to use default values. But for hand-written wsdls, having an element
for every simple type is quite cumbersome.
So the idea was to support both. Which will you go for?
On Tue, Jul 22, 2008 at 11:21 AM, Assaf Arkin (JIRA) <ji...@apache.org>
wrote:
>
> [
> https://issues.apache.org/jira/browse/ODE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615710#action_12615710]
>
> Assaf Arkin commented on ODE-344:
> ---------------------------------
>
> Mixed content is the root of all unexplained bugs.
>
> If the element is simple type, we can say that mapping that element is the
> same as mapping its content (i.e. all its text nodes). If the element is
> complex type, something is wrong, throw a selection fault. If someone
> really meant to discard the element contents except for the text nodes, they
> can say so explicitly using XPath.
>
> > Support element for headers and query strings
> > ---------------------------------------------
> >
> > Key: ODE-344
> > URL: https://issues.apache.org/jira/browse/ODE-344
> > Project: ODE
> > Issue Type: Improvement
> > Components: Axis2 Integration
> > Reporter: Alexis Midon
> >
> > So far, parts bound to HTTP headers or encoding withe
> url-encoded/x-www-form-urlencoded must be simple types.
> > This improvement aims at support elements too.
> > So for a given part A, if A as a text-node, take the content of that node
> ;
> > else check if a child element exists and take the text content of that
> element.
> > Which can be summed up in: take the content of the first encountered text
> node.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Commented: (ODE-344) Support element for headers and query
strings
Posted by "Assaf Arkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615710#action_12615710 ]
Assaf Arkin commented on ODE-344:
---------------------------------
Mixed content is the root of all unexplained bugs.
If the element is simple type, we can say that mapping that element is the same as mapping its content (i.e. all its text nodes). If the element is complex type, something is wrong, throw a selection fault. If someone really meant to discard the element contents except for the text nodes, they can say so explicitly using XPath.
> Support element for headers and query strings
> ---------------------------------------------
>
> Key: ODE-344
> URL: https://issues.apache.org/jira/browse/ODE-344
> Project: ODE
> Issue Type: Improvement
> Components: Axis2 Integration
> Reporter: Alexis Midon
>
> So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
> This improvement aims at support elements too.
> So for a given part A, if A as a text-node, take the content of that node ;
> else check if a child element exists and take the text content of that element.
> Which can be summed up in: take the content of the first encountered text node.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-344) Support element for headers and query
strings
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexis Midon resolved ODE-344.
------------------------------
Resolution: Fixed
patch submitted in trunk and 1.X
> Support element for headers and query strings
> ---------------------------------------------
>
> Key: ODE-344
> URL: https://issues.apache.org/jira/browse/ODE-344
> Project: ODE
> Issue Type: Improvement
> Components: Axis2 Integration
> Reporter: Alexis Midon
>
> So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
> This improvement aims at support elements too.
> So for a given part A, if A as a text-node, take the content of that node ;
> else check if a child element exists and take the text content of that element.
> ignore the next sentence plz.
> [Which can be summed up in: take the content of the first encountered text node.]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-344) Support element for headers and query
strings
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexis Midon updated ODE-344:
-----------------------------
Description:
So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
This improvement aims at support elements too.
So for a given part A, if A as a text-node, take the content of that node ;
else check if a child element exists and take the text content of that element.
ignore the next sentence plz.
[Which can be summed up in: take the content of the first encountered text node.]
was:
So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
This improvement aims at support elements too.
So for a given part A, if A as a text-node, take the content of that node ;
else check if a child element exists and take the text content of that element.
Which can be summed up in: take the content of the first encountered text node.
> Support element for headers and query strings
> ---------------------------------------------
>
> Key: ODE-344
> URL: https://issues.apache.org/jira/browse/ODE-344
> Project: ODE
> Issue Type: Improvement
> Components: Axis2 Integration
> Reporter: Alexis Midon
>
> So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
> This improvement aims at support elements too.
> So for a given part A, if A as a text-node, take the content of that node ;
> else check if a child element exists and take the text content of that element.
> ignore the next sentence plz.
> [Which can be summed up in: take the content of the first encountered text node.]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-344) Support element for headers and query
strings
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexis Midon updated ODE-344:
-----------------------------
Description:
So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
This improvement aims at support elements too.
So for a given part A, if A as a text-node, take the content of that node ;
else check if a child element exists and take the text content of that element.
Which can be summed up in: take the content of the first encountered text node.
was:
So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
This improvement aims at support elements too.
So for a given part A, if A as a text-node, take the content of that node ;
else check if a child element exists and take the text content of that element.
Which can be sum up in: take the content of the first encountered text node.
> Support element for headers and query strings
> ---------------------------------------------
>
> Key: ODE-344
> URL: https://issues.apache.org/jira/browse/ODE-344
> Project: ODE
> Issue Type: Improvement
> Components: Axis2 Integration
> Reporter: Alexis Midon
>
> So far, parts bound to HTTP headers or encoding withe url-encoded/x-www-form-urlencoded must be simple types.
> This improvement aims at support elements too.
> So for a given part A, if A as a text-node, take the content of that node ;
> else check if a child element exists and take the text content of that element.
> Which can be summed up in: take the content of the first encountered text node.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.