axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject RE: Default values for SOAPAction
Date Wed, 20 Jun 2001 18:51:15 GMT
Yes - please do _not_ create multiple Admin clients.
This has been stated before but it keep getting
ignored.  8-)

Glen Daniels <> on 06/20/2001 02:34:10 PM

Please respond to

To:   "''" <>
Subject:  RE: Default values for SOAPAction

Hi Rob!

Comments inline:

> - 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.

Change that back. :)  SOAP 1.1 requires SOAPAction on ALL http soap

> - 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
> SOAPAction.

HTTPActionHandler shouldn't be in your transport chain if you don't want to
do dispatch on SOAPAction.  You'll also note that the AxisServlet faults
(correctly) if there's no SOAPAction HTTP header.

> - 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

This is a little tricky, but I think I'm OK with it.

>   - 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 not that I have a problem with body dispatch, it's that I think things
are much more efficient when you can do some kind of transport-based
dispatch.  Also, on another note, I don't expect the Admin service will end
up being open to any transport you happen to install.

> 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?

This should absolutely be done.  The current deployment stuff is still
fairly hackish because we were expecting WSDD to come along any minute and
replace it.  At this point, I believe (personally - this needs to be voted
on officially) that we should spruce up the current stuff a little and just
use it for at least the initial Axis "0.5" release.

> 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.

I'd like to see a single AdminClient which picks a transport based on the
URL you pass in (default is

> - All this shook out a bug in our sending of AxisFaults.
> Currently, the
> following is what goes over the wire when JWSProcessor throws a
> FileNotFoundException:
> [...]
> 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
> ";init&gt;..."?)

It should be - we need to be better about this in general.  You want to
this task?

> - 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