axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Jellinghaus <>
Subject Re: Default values for SOAPAction
Date Wed, 20 Jun 2001 17:55:01 GMT
At 09:42 AM 6/20/2001 -0400, Sam Ruby wrote:
>The concrete proposal is to provide an overload to HTTPTransport which does
>not require an action, and to dynamically compute a default if one is not
>provided.  This will also be of value when a ServiceClient is created based
>simply on an endpointURL.  I also propose updating a number of samples to


I spent yesterday chasing down a wide range of issues around SOAPAction.
I'm looking for feedback on the issues & my resolutions before I check in
later today.  Pardon my verbosity, but I'm not sure if any of this is a red
flag for any of you.


- If there were no SOAPAction set in the message, the HTTPSender would emit:

SOAPAction: ""

This seems wrong.  I've changed it to emit no SOAPAction header at all if
there is no MC_HTTP_SOAPACTION value set.

- The HTTPActionHandler *requires* there to be a SOAPAction set.  Is this
the correct spec???  It certainly makes it awkward to test body dispatch
:-/  I have changed it to do nothing, rather than fault, if there is no

- It turns out the JWS test was *not testing JWS at all* because the
HTTPActionHandler came before the JWSHandler on the chain.  If an incoming
request had a SOAPAction defined, the HTTPActionHandler would set the
target service, and the JWSHandler would then do nothing!  This was not
noticed in the functional tests because 1) other tests had already deployed
a stock quote service, which would get silently used instead; and 2) the
JWS test should have tested for a different return value, to distinguish
the JWS stock service from the non-JWS.

I have addressed this by:
  - having the JWSHandler *always* set the service to JWSProcessor if the
URL ends in .jws
  - running the JWS test first, before any other services are deployed
  - changing the JWS test to look for a unique (66.25) return value

- The Admin service did not support dispatching based on the body.  This
means the Admin service could not be reached except via a transport that
supports either SOAPAction-like dispatch or URL-like dispatch.  I know Glen
wants us to use the URLMapper in such cases, but what if (for instance) you
want to send an admin request via SMTP or some other service which has
neither SOAPAction *nor* URL dispatch?  I can't see why we wouldn't want to
support body dispatch for the Admin service.

It's easy:  just change <deploy> to <m:deploy xmlns:m="AdminService">,
patch to look only at the local name, and it works.  I have
verified this.  (And of course SOAPAction dispatching still works, too.)
What do we think?

I also tried applying the namespace prefix & namespace URI when creating
the message in, but it didn't work the way I was
expecting.  Any suggestions?

- I am splitting AdminClient into an abstract superclass and (very small)
transport-specific subclasses, to make it easy to write AdminClients which
work over transports other than HTTP.

- All this shook out a bug in our sending of AxisFaults.  Currently, the
following is what goes over the wire when JWSProcessor throws a

<SOAP-ENV:Envelope xmlns:xsd=""
axis/StockQuoteService.jws (The system cannot find the path specified)
	at Method)
	at org.apache.axis.handlers.JWSProcessor.invoke(
	at org.apache.axis.handlers.soap.SOAPService.invoke(
	at org.apache.axis.server.AxisServer.invoke(

Note the <init> strings!  This is what is *on the wire*, and it crashes the
client when the client's parser hits the (obviously unclosed) <init> tags.

I patched this hackishly, but my question is: why is the AxisFault string
not getting character-escaped?  (i.e. why is it
"<init>..." instead of

- I have removed the SOAPAction hack (as stated in the code :-) from the
file transport.  (These changes also allow us to test real service
deployment via the now-sampleified TCP transport.)


View raw message