And it was the application/xml encoding - switched it to text/xml and
the js client
script works exactly as the java client.
Cheers and thanks
Demetris wrote:
One of the reasons I was asking is because using a java-based client I
wrote
I can access the remote Axis2 service with no issues.
One of the reasons I was asking is because using a java-based client I wrote
I can access the remote Axis2 service with no issues. Doing the same using
the IBM ws.js lib and a javascript client I getting a fault string of:
The endpoint reference (EPR) for the Operation not found is
/axis2/servi
Super - thanks for verifying this.
Andreas Veithen wrote:
On Mon, Apr 26, 2010 at 07:57, Demetris wrote:
Would the Axis2 engine accept proper SOAP messages (Envelope + Body) that do
not carry the
?
Yes. If I remember correctly the SOAP specs even say that the message
should not hav
On Mon, Apr 26, 2010 at 07:57, Demetris wrote:
>
> Would the Axis2 engine accept proper SOAP messages (Envelope + Body) that do
> not carry the
> ?
Yes. If I remember correctly the SOAP specs even say that the message
should not have an XML declaration. The reason is that the encoding is
already
Would the Axis2 engine accept proper SOAP messages (Envelope + Body)
that do not carry the
?
Also is the soapenv: prefix for the Envelope and the Body tags required?
Thanks again
Demetris wrote:
OK I think I got it. Thanks Andreas
Andreas Veithen wrote:
All this is by design:
* toStrin
OK I think I got it. Thanks Andreas
Andreas Veithen wrote:
All this is by design:
* toString is designed to produce an XML fragment that is valid with
respect to namespaces. Thus, when applied to the SOAP body, it needs
to add a namespace declaration for the
http://schemas.xmlsoap.org/soap/env
All this is by design:
* toString is designed to produce an XML fragment that is valid with
respect to namespaces. Thus, when applied to the SOAP body, it needs
to add a namespace declaration for the
http://schemas.xmlsoap.org/soap/envelope/ namespace.
* getText returns the results as specified i
