You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Michael Rheinheimer <ro...@us.ibm.com> on 2007/10/02 18:40:56 UTC
Re: [axis2] propose configuration option to prefer specific builder for
text/xml content-type
Hi Thilina,
You sent me down the right path, I think. I explored a little more the
check for Constants.Configuration.SOAP_RESPONSE_MEP. How about if I move
the check up to the outer 'if' conditional, and it would be the
responsibility of the MessageContext creator (the servlet.doPost(),
perhaps?) to set that property? Thoughts? Objections? See patch2 in the
JIRA.
Thanks for your input!
mike
Mike Rheinheimer
(512) 838-0086 t/l 678-0086
WebSphere WebService Core Engine Team
"Thilina
Gunarathne"
<csethil@gmail.co To
m> axis-dev@ws.apache.org
cc
09/26/2007 11:41
PM Subject
Re: [axis2] propose configuration
option to prefer specific builder
Please respond to for text/xml content-type
axis-dev@ws.apach
e.org
Hi Mike,
In the problem I describe, however, adding another messageBuilder element
for text/xml won't help. The code changes the string passed to the
selector to application/xml before the selector is called.
Yeah... I knew... In an ideal world without these "text/xml" ambiguities,
it would have been simple as that :)..
Also, I did add the suggested check
"!msgContext.isPropertyTrue(Constants.Configuration.SOAP_RESPONSE_MEP)"
as an attempted fix. In this failure case, this check evaluated to true
(with the '!') and the problem remained.
Ohh... Looks like another bug... :(
I'm certainly open to suggestions for a better fix. Now that I see the
configuration parameters in the axis2.xml, I like my fix a little bit
less. Not quite sure how to get around the problem other than to increase
the precedence of the settings from the axis2.xml. In other words, how
about the settings override the check for "Some services send REST
responces as text/xml"?
Yeah... I was also thinking down the same lines.. But the problem with that
would be, then we will support only SOAP or only POX in the configured
Axis2 server. May be we can think of a way to give that precedence as well
as to keep the existing "hacky" solution of changing the type to the
"application/xml" to take effect when nothing about text/xml is mentioned
in axis2.xml.
thanks,
Thilina
PS: sorry for coming up with just the suggestions, rather than implementing
it.. I'm bit tied up with my studies these days.. Please bear with me :).
Thanks!
Mike Rheinheimer
(512) 838-0086 t/l 678-0086
WebSphere WebService Core Engine Team
Inactive hide details for "Thilina Gunarathne" <cs...@gmail.com>
"Thilina Gunarathne" < csethil@gmail.com>
"Thilina
Gunarath
ne" <
csethil@
gmail.co To
m>
axis-dev@ws.apache.org
09/25/20 cc
07 09:17
PM
Subject
Please respond to Re: [axis2] propose
axis-dev@ws.apache.org configuration option to prefer
specific builder for text/xml
content-type
Hi,
Ideally user should be able to override the builder mapping for any
content type using the axis2.xml. But it becomes bit tricky in this
case as text/xml is improperly used by two types of messages.
eg: to substitute text/xml to use ApplicationXMLBuilder.
<messageBuilder contentType="text/xml"
class="org.apache.axis2.builder.ApplicationXMLBuilder"/>
Did you check the value of the
"!msgContext.isPropertyTrue(Constants.Configuration.SOAP_RESPONSE_MEP)"
in the failing case. If it is "true" then we can simply get away by
adding that to the if condition which checks "isServerSide". Notice
the !.
I'm fine with going ahead with a fix similar to what you proposed as
the last resort if we cannot find any better solutions(*KEITH* might
be able to help us in here).. But even in that case we should be able
to specify the new parameter from the axis2.xml and may be through a
messageContext property giving priority for the property.
Also I see few issues with the current patch[1] you have attached to the
JIRA.
1. Who is going to set the "builderForTextXML" in the
AxisConfiguration? If we are putting this, we should be able to
configure this using axis2.xml as well.
2.
>- // Some services send REST responces as text/xml. We
should convert it to
>- // application/xml if its a REST response, if not it
will try to use the >SOAPMessageBuilder.
>- if (HTTPConstants.MEDIA_TYPE_TEXT_XML.equals(type)) {
.....
>- }
>- Builder builder =
BuilderUtil.getBuilderFromSelector(type, msgContext);
>- if (log.isDebugEnabled()) {
>- log.debug("createSOAPEnvelope using Builder (" +
>- builder.getClass() + ") selected from type
(" + type +")");
>- }
>+ Builder builder =
BuilderUtil.getBuilderForTextXML(msgContext);I
strongly disagree with encapsulating all the builder selection logic
to a method called "getBuilderForTextXML".. It does not look right to
call that method when we are looking for a builder for MIME/Multipart
or any other content-type.
3. Also the new "getBuilderForTextXML" method seems to be trying to
make a shortcut in the case of text/xml.. But whatever the text/xml
code will get evaluated every time axis2 receives a message(duplicated
code), even with different content-type. We need to restructure that
method if we are going to commit it..
thanks,
Thilina
[1]https://issues.apache.org/jira/secure/attachment/12366543/patch.txt
On 9/25/07, Michael Rheinheimer <ro...@us.ibm.com> wrote:
>
>
> All,
>
> (This email may be a dup for some of you... I forgot the [axis2] in
the
> subject... oops. :)
>
>
> I recently ran into a bug where the ApplicationXMLBuilder was the
preferred
> builder chosen by the TransportUtils.createDocumentElement,
> even though the needed builder was SOAP11Builder.
>
> The content-type "text/xml" in the http header is somewhat arbitrary
in
> that the specs do not align it with REST vs. SOAP11. This seems to have
> caused quite a bit of back-and-forth change in the code that results in
REST
> or SOAP11 being preferred over the other. To resolve this, I propose a
> configuration solution. An axis2 user may configure a
"builderForTextXML"
> that would take precedence over the smart builder chooser logic in
> TransportUtils.
>
> This new configuration parameter would insure that servers that only
> support REST or SOAP11 for content-type "text/xml" would always use the
> right builder. Currently, the code will pick the ApplicationXMLBuilder
on
> the client async response (see Jira for more detailed description of
this).
>
> Please see jira with patch:
> https://issues.apache.org/jira/browse/AXIS2-3228
>
> If there are no objections, I will be glad to commit this change.
>
> Mike Rheinheimer
> (512) 838-0086 t/l 678-0086
> WebSphere WebService Core Engine Team
>
>
>
--
Thilina Gunarathne - http://thilinag.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
--
Thilina Gunarathne - http://thilinag.blogspot.com
Re: [axis2] propose configuration option to prefer specific builder for
text/xml content-type
Posted by Michael Rheinheimer <ro...@us.ibm.com>.
Keith,
Thank you! I'll watch for your update.
mike
Mike Rheinheimer
(512) 838-0086 t/l 678-0086
WebSphere WebService Core Engine Team
"keith chapman"
<keithgchapman@gm
ail.com> To
axis-dev@ws.apache.org
10/02/2007 12:29 cc
PM
Subject
Re: [axis2] propose configuration
Please respond to option to prefer specific builder
axis-dev@ws.apach for text/xml content-type
e.org
Hi Micheal,
The Constants.Configuration.SOAP_RESPONSE_MEP property is used to track
whether the response is SOAP. That is when an operation uses the
SAOP_RESPONSE_MEP the request is REST and the response is SOAP. The above
property was used to capture this behaviour on the client side and use the
correct builder. Hence I dont think that it can help us in sorting out
whether the request was SOAP 1.1 or REST. I'll try to see if there is a
hook to see whether the response received was an async response. If so we
can use that as another condition when taking this decision.
Thanks,
Keith.
On 10/2/07, Michael Rheinheimer <ro...@us.ibm.com> wrote:
Hi Thilina,
You sent me down the right path, I think. I explored a little more the
check for Constants.Configuration.SOAP_RESPONSE_MEP. How about if I move
the check up to the outer 'if' conditional, and it would be the
responsibility of the MessageContext creator (the servlet.doPost(),
perhaps?) to set that property? Thoughts? Objections? See patch2 in the
JIRA.
Thanks for your input!
mike
Mike Rheinheimer
(512) 838-0086 t/l 678-0086
WebSphere WebService Core Engine Team
Inactive hide details for "Thilina Gunarathne" <cs...@gmail.com>
"Thilina Gunarathne" < csethil@gmail.com>
"Thilina
Gunarath
ne" <
csethil@ To
gmail.co
m> axis-dev@ws.apache.org
cc
09/26/20
07 11:41
PM Subject
Re: [axis2] propose
configuration option to prefer
specific builder for text/xml
content-type
Please respond to
axis-dev@ws.apache.org
Hi Mike,
In the problem I describe, however, adding another messageBuilder
element for text/xml won't help. The code changes the string passed
to the selector to application/xml before the selector is called.
Yeah... I knew... In an ideal world without these "text/xml" ambiguities,
it would have been simple as that :)..
Also, I did add the suggested check
"!msgContext.isPropertyTrue(Constants.Configuration.SOAP_RESPONSE_MEP)"
as an attempted fix. In this failure case, this check evaluated to
true (with the '!') and the problem remained.
Ohh... Looks like another bug... :(
I'm certainly open to suggestions for a better fix. Now that I see
the configuration parameters in the axis2.xml, I like my fix a
little bit less. Not quite sure how to get around the problem other
than to increase the precedence of the settings from the axis2.xml.
In other words, how about the settings override the check for "Some
services send REST responces as text/xml"?
Yeah... I was also thinking down the same lines.. But the problem with
that would be, then we will support only SOAP or only POX in the
configured Axis2 server. May be we can think of a way to give that
precedence as well as to keep the existing "hacky" solution of changing
the type to the "application/xml" to take effect when nothing about
text/xml is mentioned in axis2.xml.
thanks,
Thilina
PS: sorry for coming up with just the suggestions, rather than
implementing it.. I'm bit tied up with my studies these days.. Please
bear with me :).
Thanks!
Mike Rheinheimer
(512) 838-0086 t/l 678-0086
WebSphere WebService Core Engine Team
Inactive hide details for "Thilina Gunarathne" <cs...@gmail.com>
"Thilina Gunarathne" < csethil@gmail.com>
"Thilina Gunarathne" <
csethil@gmail.com>
To
09/25/2007 09:17 PM
axis-dev@ws.apache.org
cc
Please respond to Subject
axis-dev@ws.apache.org
Re: [axis2] propose
configuration option to
prefer specific builder
for text/xml content-type
Hi,
Ideally user should be able to override the builder mapping for any
content type using the axis2.xml. But it becomes bit tricky in this
case as text/xml is improperly used by two types of messages.
eg: to substitute text/xml to use ApplicationXMLBuilder.
<messageBuilder contentType="text/xml"
class="org.apache.axis2.builder.ApplicationXMLBuilder"/>
Did you check the value of the
"!msgContext.isPropertyTrue(Constants.Configuration.SOAP_RESPONSE_MEP)"
in the failing case. If it is "true" then we can simply get away
by
adding that to the if condition which checks "isServerSide". Notice
the !.
I'm fine with going ahead with a fix similar to what you proposed
as
the last resort if we cannot find any better solutions(*KEITH*
might
be able to help us in here).. But even in that case we should be
able
to specify the new parameter from the axis2.xml and may be through
a
messageContext property giving priority for the property.
Also I see few issues with the current patch[1] you have attached
to the JIRA.
1. Who is going to set the "builderForTextXML" in the
AxisConfiguration? If we are putting this, we should be able to
configure this using axis2.xml as well.
2.
>- // Some services send REST responces as text/xml. We
should convert it to
>- // application/xml if its a REST response, if not it
will try to use the >SOAPMessageBuilder.
>- if (HTTPConstants.MEDIA_TYPE_TEXT_XML.equals(type)) {
.....
>- }
>- Builder builder =
BuilderUtil.getBuilderFromSelector(type, msgContext);
>- if (log.isDebugEnabled()) {
>- log.debug("createSOAPEnvelope using Builder (" +
>- builder.getClass() + ") selected from
type
(" + type +")");
>- }
>+ Builder builder =
BuilderUtil.getBuilderForTextXML(msgContext);I
strongly disagree with encapsulating all the builder selection
logic
to a method called "getBuilderForTextXML".. It does not look right
to
call that method when we are looking for a builder for
MIME/Multipart
or any other content-type.
3. Also the new "getBuilderForTextXML" method seems to be trying to
make a shortcut in the case of text/xml.. But whatever the text/xml
code will get evaluated every time axis2 receives a
message(duplicated
code), even with different content-type. We need to restructure
that
method if we are going to commit it..
thanks,
Thilina
[1]
https://issues.apache.org/jira/secure/attachment/12366543/patch.txt
On 9/25/07, Michael Rheinheimer <rott@us.ibm.com > wrote:
>
>
> All,
>
> (This email may be a dup for some of you... I forgot the [axis2]
in the
> subject... oops. :)
>
>
> I recently ran into a bug where the ApplicationXMLBuilder was
the preferred
> builder chosen by the TransportUtils.createDocumentElement,
> even though the needed builder was SOAP11Builder.
>
> The content-type "text/xml" in the http header is somewhat
arbitrary in
> that the specs do not align it with REST vs. SOAP11. This seems
to have
> caused quite a bit of back-and-forth change in the code that
results in REST
> or SOAP11 being preferred over the other. To resolve this, I
propose a
> configuration solution. An axis2 user may configure a
"builderForTextXML"
> that would take precedence over the smart builder chooser logic
in
> TransportUtils.
>
> This new configuration parameter would insure that servers that
only
> support REST or SOAP11 for content-type "text/xml" would always
use the
> right builder. Currently, the code will pick the
ApplicationXMLBuilder on
> the client async response (see Jira for more detailed description
of this).
>
> Please see jira with patch:
> https://issues.apache.org/jira/browse/AXIS2-3228
>
> If there are no objections, I will be glad to commit this
change.
>
> Mike Rheinheimer
> (512) 838-0086 t/l 678-0086
> WebSphere WebService Core Engine Team
>
>
>
--
Thilina Gunarathne - http://thilinag.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
--
Thilina Gunarathne - http://thilinag.blogspot.com
--
Keith Chapman
WSO2 Inc.
Oxygen for Web Services Developers.
http://wso2.org/
Re: [axis2] propose configuration option to prefer specific builder for text/xml content-type
Posted by keith chapman <ke...@gmail.com>.
Hi Micheal,
The Constants.Configuration.SOAP_RESPONSE_MEP property is used to track
whether the response is SOAP. That is when an operation uses the
SAOP_RESPONSE_MEP the request is REST and the response is SOAP. The above
property was used to capture this behaviour on the client side and use the
correct builder. Hence I dont think that it can help us in sorting out
whether the request was SOAP 1.1 or REST. I'll try to see if there is a hook
to see whether the response received was an async response. If so we can
use that as another condition when taking this decision.
Thanks,
Keith.
On 10/2/07, Michael Rheinheimer <ro...@us.ibm.com> wrote:
>
> Hi Thilina,
>
> You sent me down the right path, I think. I explored a little more the
> check for Constants.Configuration.SOAP_RESPONSE_MEP. How about if I move
> the check up to the outer 'if' conditional, and it would be the
> responsibility of the MessageContext creator (the servlet.doPost(),
> perhaps?) to set that property? Thoughts? Objections? See patch2 in the
> JIRA.
>
> Thanks for your input!
> mike
>
> Mike Rheinheimer
> (512) 838-0086 t/l 678-0086
> WebSphere WebService Core Engine Team
>
> [image: Inactive hide details for "Thilina Gunarathne"
> <cs...@gmail.com>]"Thilina Gunarathne" <cs...@gmail.com>
>
>
>
> *"Thilina Gunarathne" <cs...@gmail.com>*
>
> 09/26/2007 11:41 PM
> Please respond to
> axis-dev@ws.apache.org
>
>
> To
>
> axis-dev@ws.apache.org
> cc
>
>
> Subject
>
> Re: [axis2] propose configuration option to prefer specific builder for
> text/xml content-type
>
>
> Hi Mike,
>
> In the problem I describe, however, adding another messageBuilder
> element for text/xml won't help. The code changes the string passed to the
> selector to application/xml before the selector is called.
>
>
> Yeah... I knew... In an ideal world without these "text/xml" ambiguities,
> it would have been simple as that :)..
>
> Also, I did add the suggested check "!msgContext.isPropertyTrue(
> Constants.Configuration.SOAP_RESPONSE_MEP)" as an attempted fix. In
> this failure case, this check evaluated to true (with the '!') and the
> problem remained.
>
>
> Ohh... Looks like another bug... :(
>
> I'm certainly open to suggestions for a better fix. Now that I see
> the configuration parameters in the axis2.xml, I like my fix a
> little bit less. Not quite sure how to get around the problem other than to
> increase the precedence of the settings from the axis2.xml. In other
> words, how about the settings override the check for "Some services
> send REST responces as text/xml"?
>
>
> Yeah... I was also thinking down the same lines.. But the problem with
> that would be, then we will support only SOAP or only POX in the configured
> Axis2 server. May be we can think of a way to give that precedence as well
> as to keep the existing "hacky" solution of changing the type to the
> "application/xml" to take effect when nothing about text/xml is mentioned in
> axis2.xml.
>
> thanks,
> Thilina
>
> PS: sorry for coming up with just the suggestions, rather than
> implementing it.. I'm bit tied up with my studies these days.. Please bear
> with me :).
>
>
> Thanks!
>
> Mike Rheinheimer
> (512) 838-0086 t/l 678-0086
> WebSphere WebService Core Engine Team
>
> [image: Inactive hide details for "Thilina Gunarathne"
> <cs...@gmail.com>]"Thilina Gunarathne" <* csethil@gmail.com*<cs...@gmail.com>
> >
>
> *"Thilina Gunarathne" <**csethil@gmail.com* <cs...@gmail.com>
> *>*
>
> 09/25/2007 09:17 PM
> Please respond
> to*
> **axis-dev@ws.apache.org* <ax...@ws.apache.org>
> To
> *
> **axis-dev@ws.apache.org* <ax...@ws.apache.org> cc
> Subject
>
> Re: [axis2] propose configuration option to prefer specific builder
> for text/xml content-type
> Hi,
> Ideally user should be able to override the builder mapping for any
> content type using the axis2.xml. But it becomes bit tricky in this
> case as text/xml is improperly used by two types of messages.
>
> eg: to substitute text/xml to use ApplicationXMLBuilder.
> <messageBuilder contentType="text/xml"
>
> class="org.apache.axis2.builder.ApplicationXMLBuilder"/>
>
> Did you check the value of the
> "!msgContext.isPropertyTrue(
> Constants.Configuration.SOAP_RESPONSE_MEP)"
> in the failing case. If it is "true" then we can simply get away by
> adding that to the if condition which checks "isServerSide". Notice
> the !.
>
> I'm fine with going ahead with a fix similar to what you proposed as
> the last resort if we cannot find any better solutions(*KEITH* might
> be able to help us in here).. But even in that case we should be
> able
> to specify the new parameter from the axis2.xml and may be through a
> messageContext property giving priority for the property.
>
> Also I see few issues with the current patch[1] you have attached to
> the JIRA.
> 1. Who is going to set the "builderForTextXML" in the
> AxisConfiguration? If we are putting this, we should be able to
> configure this using axis2.xml as well.
>
> 2.
> >- // Some services send REST responces as text/xml. We
> should convert it to
> >- // application/xml if its a REST response, if not it
> will try to use the >SOAPMessageBuilder.
> >- if (HTTPConstants.MEDIA_TYPE_TEXT_XML.equals(type)) {
> .....
> >- }
> >- Builder builder =
> BuilderUtil.getBuilderFromSelector(type, msgContext);
> >- if (log.isDebugEnabled()) {
> >- log.debug("createSOAPEnvelope using Builder (" +
> >- builder.getClass() + ") selected from
> type
> (" + type +")");
> >- }
> >+ Builder builder = BuilderUtil.getBuilderForTextXML
> (msgContext);I
>
> strongly disagree with encapsulating all the builder selection logic
> to a method called "getBuilderForTextXML".. It does not look right
> to
> call that method when we are looking for a builder for
> MIME/Multipart
> or any other content-type.
>
> 3. Also the new "getBuilderForTextXML" method seems to be trying to
> make a shortcut in the case of text/xml.. But whatever the text/xml
> code will get evaluated every time axis2 receives a
> message(duplicated
> code), even with different content-type. We need to restructure that
> method if we are going to commit it..
>
> thanks,
> Thilina
>
> [1]*
> https://issues.apache.org/jira/secure/attachment/12366543/patch.txt*<https://issues.apache.org/jira/secure/attachment/12366543/patch.txt>
>
>
> On 9/25/07, Michael Rheinheimer <*rott@us.ibm.com* <ro...@us.ibm.com>>
> wrote:
> >
> >
> > All,
> >
> > (This email may be a dup for some of you... I forgot the [axis2]
> in the
> > subject... oops. :)
> >
> >
> > I recently ran into a bug where the ApplicationXMLBuilder was the
> preferred
> > builder chosen by the TransportUtils.createDocumentElement,
> > even though the needed builder was SOAP11Builder.
> >
> > The content-type "text/xml" in the http header is somewhat
> arbitrary in
> > that the specs do not align it with REST vs. SOAP11. This seems to
> have
> > caused quite a bit of back-and-forth change in the code that
> results in REST
> > or SOAP11 being preferred over the other. To resolve this, I
> propose a
> > configuration solution. An axis2 user may configure a
> "builderForTextXML"
> > that would take precedence over the smart builder chooser logic in
> > TransportUtils.
> >
> > This new configuration parameter would insure that servers that
> only
> > support REST or SOAP11 for content-type "text/xml" would always
> use the
> > right builder. Currently, the code will pick the
> ApplicationXMLBuilder on
> > the client async response (see Jira for more detailed description
> of this).
> >
> > Please see jira with patch:
> > *https://issues.apache.org/jira/browse/AXIS2-3228*<https://issues.apache.org/jira/browse/AXIS2-3228>
> >
> > If there are no objections, I will be glad to commit this change.
> >
> > Mike Rheinheimer
> > (512) 838-0086 t/l 678-0086
> > WebSphere WebService Core Engine Team
> >
> >
> >
>
>
> --
> Thilina Gunarathne - *http://thilinag.blogspot.com*<http://thilinag.blogspot.com/>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: *axis-dev-unsubscribe@ws.apache.org*<ax...@ws.apache.org>
> For additional commands, e-mail: *axis-dev-help@ws.apache.org*<ax...@ws.apache.org>
>
>
>
>
>
>
> --
> Thilina Gunarathne - *http://thilinag.blogspot.com*<http://thilinag.blogspot.com/>
>
>
>
--
Keith Chapman
WSO2 Inc.
Oxygen for Web Services Developers.
http://wso2.org/