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 <[EMAIL PROTECTED]> 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" > <[EMAIL PROTECTED]>]"Thilina Gunarathne" <[EMAIL PROTECTED]> > > > > *"Thilina Gunarathne" <[EMAIL PROTECTED]>* > > 09/26/2007 11:41 PM > Please respond to > [email protected] > > > To > > [email protected] > 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" > <[EMAIL PROTECTED]>]"Thilina Gunarathne" <* [EMAIL PROTECTED]<[EMAIL > PROTECTED]> > > > > *"Thilina Gunarathne" <[EMAIL PROTECTED] <[EMAIL PROTECTED]> > *>* > > 09/25/2007 09:17 PM > Please respond > to* > [EMAIL PROTECTED] <[email protected]> > To > * > [EMAIL PROTECTED] <[email protected]> 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 <[EMAIL PROTECTED] <[EMAIL PROTECTED]>> > 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: [EMAIL PROTECTED]<[EMAIL PROTECTED]> > For additional commands, e-mail: [EMAIL PROTECTED]<[EMAIL PROTECTED]> > > > > > > > -- > Thilina Gunarathne - > *http://thilinag.blogspot.com*<http://thilinag.blogspot.com/> > > > -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/
<<inline: ecblank.gif>>
<<inline: 25421793.gif>>
<<inline: graycol.gif>>
<<inline: 25196254.gif>>
