Thanks, I will look at these. Are we in agreement that the getTagName() should be replaced with getLocalName()? If so what is the best way to have this fixed?
Thanks again, Bhushan -----Original Message----- From: Scott Nichol [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 11:47 AM To: [EMAIL PROTECTED] Subject: Re: More on QName problem Also, http://www.apache.org/~rubys/ApacheClientInterop.html has wire dumps of messages from interop tests using the Axis client against a variety of servers. This helps you see in practice how people are constructing messages. Scott Nichol ----- Original Message ----- From: "Bhushan Khanal" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 22, 2002 2:29 PM Subject: RE: More on QName problem > Just to give you some background, I using my own soap implementation to > create the message. I trying to write a non servlet container to implement > SOAP services and I was creating mock messages that represented incoming > requests. In addition, I am not using Tomcat or Axis(have my own http and > tcp implementation), so I am quite the Black Sheep of this family. Therefore > its possible that the message could be non confirming to SOAP standards. > Here is my earlier posting that contains the incoming message > http://marc.theaimsgroup.com/?l=soap-dev&m=102704360007200&w=2. > > I was qualifying my parameters with the name space, that was the reason I > ran into this problem in the first place. Do you mean that there should be > an additional attribute that specifies the type? Does that also mean, all > the type information needs to be transmitted with the SOAP message? Could > you point me to an example of a valid SOAP message, that would be very > helpful. > > Thanks, > Bhushan > > > -----Original Message----- > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > Sent: Saturday, July 20, 2002 11:25 PM > To: [EMAIL PROTECTED] > Subject: Re: More on QName problem > > > I would guess it has not been a problem because "name" is only used in the > interop extension branch. Specifically, for parameters with xsi:type > specified or with an href attribute, the code does not rely on "name" in any > way. Most SOAP implementations provide xsi:type for parameters. The most > notable exception is Microsoft, which chose to rely on WSDL for typing. The > "name" variable is used in the branch of code added to attempt to interop > with implementations from Microsoft (and others?) that do not provide > xsi:type. I presume that Apache SOAP users have only exercised this code to > interop with Microsoft, which does not qualify parameters with namespaces. > > I agree that this code should use the local name. I am curious, however, > what SOAP implementation you are using that has namespace qualifiers on the > parameter elements. > > Scott Nichol > > ----- Original Message ----- > From: "Bhushan Khanal" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, July 19, 2002 6:46 PM > Subject: More on QName problem > > > > Hello again, > > > > Here are some more information that I found on the problem that I have > been > > having with QName and their local names. Please look at the following > > function inside class ParameterSerializer. > > > > public Bean unmarshall(String inScopeEncStyle, QName elementType, Node > src, > > XMLJavaMappingRegistry xjmr, SOAPContext ctx) > > throws IllegalArgumentException > > { > > Element paramEl = (Element)src; > > String name = paramEl.getTagName(); <<---- > > Bean bean = null; > > . > > . > > . > > } > > > > The method getTagName() returns the name of the tag with the name space > > alias. Shouldn't you be extracting the name using getLocalName() instead? > I > > am surprised that this has not been a problem for others. Am I missing > > anything? > > > > Happy Friday! > > > > Bhushan Khanal > > WRQ, Inc. > > 206.217.7636 > > [EMAIL PROTECTED] > > > > WRQ has 21 years of experience providing integration software and services > > for host-intensive environments. To learn more about our Reflection and > > Verastream products, visit http://www.wrq.com/products/. > > > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
