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 Glen Daniels <gd...@macromedia.com> on 2003/08/08 20:27:22 UTC

RE: cvs commit: xml-axis/java/docs developers-guide.html referenc e.html

> Which servlet init-param are you talking about?  I don't see anything
> in the axis web.xml that says "http" is "the" transport. I 
> agree it makes
> sense that something like that is needed.

Look in AxisServlet, you'll see the "transportName" field, which is what you should be using instead of hardcoding "http".  It gets initialized via an init-parameter, and defaults to "http", which is why the default web.xml doesn't specify it.

> My concern with the additional parameter is that it doesn't move
> us closer to the goal of just checking the params on that transport.
> It introduces another parameter that we'll need to support 
> for backwards
> compatibility.  If we had the notion of deprecation then this param
> would be deprecated at the same time it would be introduced.
> While funny, I don't think its ideal.

The only case in which you need to turn off query strings is when you want no query strings (to disambiguate from the default) - otherwise you specify exactly what you want.  Enabling the name="qs:wsdl" value="" pattern doesn't really buy us anything except confusion, I think - it shouldn't mean "shut this one off" because then that breaks the rule that "if query strings are specified don't use the defaults"... and if it means "turn everything off" then it's an odd syntax for that.  Backwards compatibility is a fact of life, and it's why we're discussing the default idea in the first place - I'd rather see a clear parameter indicating what's going on than an overloaded syntax that could confuse people as to semantics.  I'm open to other ideas too, I just don't like the value="" because I think it has bad implications.

Oh, also, could we change the colon to a dot in the "qs" parameter name prefixing?  Dots imply scoping, and colons (to me anyway) imply QNames - I think this could be confusing, especially if we ever did decide to make parameter names QNames.

--Glen