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]> > > > > *"Thilina Gunarathne" <[EMAIL PROTECTED]>* > > 09/25/2007 09:17 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, > 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 <[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 > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- Thilina Gunarathne - http://thilinag.blogspot.com
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
