You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by Vladimir Brezhnev <bv...@portalsoft.ru> on 2004/11/09 15:12:02 UTC

Re[2]: please, help with "no deserializer found ..." message

Hello Scott,

Tuesday, November 9, 2004, 4:36:15 PM, you wrote:

SN> When a service uses the RPC API, the SOAP request is parsed
SN> into parameters for the service method call.  Each parameter has a
SN> Java type specified by the method signature.  Apache SOAP normally
SN> uses the XML Schema type of an element in the request to determine
SN> the Java type of the parameter using a type map defined in the
SN> Apache SOAP code, but which the programmer can also extend.  In
SN> your case, the parameters do not have an XML Schema type
SN> specified, so Apache SOAP uses the element name instead.  However,
SN> you have not specified a mapping for this type.  For the service,
SN> Apache SOAP type mapping are specified in the deployment
SN> descriptor.

SN> The Apache SOAP 2.3.1 documentation for type mapping is at
SN> http://ws.apache.org/soap/docs/guide/serializer.html.

I specify type mappings in a deployment descriptor.
But i get now this error:

"
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Exception while handling service request: com.ericsson.services.mms.sdk.vasp.samples.sim.MMCRelay.SubmitReq(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,javax.activation.DataHandler) -- no signature match</faultstring>
<faultactor>/vaspsubmit/servlet/rpcrouter</faultactor>
<detail>
<stackTrace>java.lang.NoSuchMethodException: com.ericsson.services.mms.sdk.vasp.samples.sim.MMCRelay.SubmitReq(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,javax.activation.DataHandler) -- no signature match

  at org.apache.soap.util.MethodUtils.getEntryPoint(MethodUtils.java:154)
[...skipped...]"

SOAP tries to call method with many java.lang.String parameters.

There is the deploy.xml:
<?xml version="1.0"?>
  <isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
    id="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
    > 

      <isd:provider type="java"
                    scope="Application"
        methods="SubmitReq CancelReq">
        <isd:java class="com.ericsson.services.mms.sdk.vasp.samples.sim.MMCRelay"
                         static="false"/>
      </isd:provider>
      <isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultListener>
  <isd:mappings>
                {skipped}
  </isd:mappings>
  </isd:service>



What i must change in the client code or in the deploy.xml to get success
answer? I could not change server code (MMCRelay).

There is a class, which was set in deploy.xml.
                         
MMCRelay class:

package com.ericsson.services.mms.sdk.vasp.samples.sim;

import com.ericsson.services.mms.sdk.vasp.api.*;
import java.io.*;
import java.util.*;
import javax.mail.MessagingException;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import org.apache.soap.*;
import org.apache.soap.encoding.SOAPMappingRegistry;
import org.apache.soap.rpc.SOAPContext;
import org.w3c.dom.*;

// Referenced classes of package com.ericsson.services.mms.sdk.vasp.samples.sim:
//            VASPSenderThread

public class MMCRelay
{

    public MMCRelay()
    {
    }

    private MultiMediaSubmitResponse MultiMediaSubmitProcess(MultiMediaApplication multimediaapplication, MultiMediaMessage multimediamessage)
        throws SOAPException
    {
        String s = TransactionManager.genTransactionID();
        MultiMediaSubmitResponse multimediasubmitresponse = null;
        try
        {
            if(multimediamessage.getSubject() != null && multimediamessage.getSubject().length() > 32)
            {
                multimediasubmitresponse = new MultiMediaSubmitResponse(2001, "Subject Too Long");
                throw new IllegalArgumentException();
            }
            Date date = new Date();
            if(multimediamessage.getTimeofExpiry() == null && multimediamessage.getRelativeTimeofExpiry() != 0L)
                multimediamessage.setTimeofExpiry(new Date(date.getTime() + 1000L * multimediamessage.getRelativeTimeofExpiry()));
            if(multimediamessage.getTimeofExpiry() != null && date.after(multimediamessage.getTimeofExpiry()))
            {
                multimediasubmitresponse = new MultiMediaSubmitResponse(2002, "Invalid Expiry");
                throw new IllegalArgumentException();
            }
            if(multimediamessage.getEarliestDeliveryTime() == null && multimediamessage.getRelativeEarliestDeliveryTime() != 0L)
                multimediamessage.setEarliestDeliveryTime(new Date(date.getTime() + 1000L * multimediamessage.getRelativeEarliestDeliveryTime()));
            if(multimediamessage.getEarliestDeliveryTime() != null && multimediamessage.getTimeofExpiry() != null && multimediamessage.getEarliestDeliveryTime().after(multimediamessage.getTimeofExpiry()))
            {
                multimediasubmitresponse = new MultiMediaSubmitResponse(2004, "Earliest Delivery clashed with Expiry");
                throw new IllegalArgumentException();
            }
            if(multimediamessage.getFrom() != null && multimediamessage.getFrom().length() > 12)
            {
                multimediasubmitresponse = new MultiMediaSubmitResponse(2002, "Origination address error");
                throw new IllegalArgumentException();
            }
            if(multimediamessage.getNumberDestinationAddress() > 10)
            {
                multimediasubmitresponse = new MultiMediaSubmitResponse(2002, "Invalid Number of Destinationsr");
                throw new IllegalArgumentException();
            }
            multimediasubmitresponse = new MultiMediaSubmitResponse(s);
        }
        catch(IllegalArgumentException illegalargumentexception)
        {
            throw new SOAPException(Constants.FAULT_CODE_CLIENT, multimediasubmitresponse == null ? "Submit" : multimediasubmitresponse.getSubmitResultDescription());
        }
        if(multimediasubmitresponse != null && multimediasubmitresponse.isSuccess())
        {
            MultiMediaApplication multimediaapplication1 = new MultiMediaApplication();
            ArrayList arraylist = new ArrayList();
            arraylist.addAll(multimediamessage.getAllDestination());
            for(int i = 0; i < arraylist.size(); i++)
            {
                Object obj = null;
                Address address = (Address)arraylist.get(i);
                if(multimediamessage.getDeliveryReport())
                {
                    MultiMediaDeliveryReport multimediadeliveryreport = new MultiMediaDeliveryReport();
                    multimediadeliveryreport.setRecipient(address.toString());
                    multimediadeliveryreport.setFrom(multimediamessage.getFrom());
                    multimediadeliveryreport.setReportStatus("Delivered");
                    multimediadeliveryreport.setMessageID(multimediasubmitresponse.getMessageID());
                    multimediadeliveryreport.setReportTime(new Date());
                    VASPSenderThread vaspsenderthread = new VASPSenderThread(multimediamessage.getReportAddress(), multimediaapplication1, multimediadeliveryreport);
                    vaspsenderthread.start();
                    vaspsenderthread = null;
                }
                if(multimediamessage.getReadReport())
                {
                    MultiMediaReadReport multimediareadreport = new MultiMediaReadReport();
                    multimediareadreport.setRecipient(address.toString());
                    multimediareadreport.setFrom(multimediamessage.getFrom());
                    multimediareadreport.setMessageID(multimediasubmitresponse.getMessageID());
                    multimediareadreport.setReportTime(new Date());
                    VASPSenderThread vaspsenderthread1 = new VASPSenderThread(multimediamessage.getReportAddress(), multimediaapplication1, multimediareadreport);
                    vaspsenderthread1.start();
                    vaspsenderthread1 = null;
                }
            }

        }
        return multimediasubmitresponse;
    }

    public void SubmitReq(Envelope envelope, SOAPContext soapcontext, SOAPContext soapcontext1)
        throws SOAPException
    {
        System.out.println("SubmitReq Entered");
        MultiMediaMessage multimediamessage = new MultiMediaMessage();
        try
        {
            multimediamessage.unmarshall(envelope);
            MultiMediaSubmitResponse multimediasubmitresponse = new MultiMediaSubmitResponse(1000, "Successfull message submission");
            multimediasubmitresponse.setMessageID("1");
            multimediasubmitresponse.setSubmitResultDescription("Successfull message submission");
            multimediasubmitresponse.setTransactionId("12345");
            multimediasubmitresponse.setTransactionID(multimediamessage.getTransactionId());
            Envelope envelope1 = multimediasubmitresponse.marshall();
            StringWriter stringwriter = new StringWriter();
            envelope1.marshall(stringwriter, new SOAPMappingRegistry(), soapcontext1);
            soapcontext1.setRootPart(stringwriter.toString(), "text/xml");
        }
        catch(Exception exception)
        {
            throw new SOAPException(Constants.FAULT_CODE_SERVER, exception.getMessage(), exception);
        }
        finally
        {
            System.out.println("SubmitReq Exited");
        }
    }

    /**
     * @deprecated Method MultiMediaSubmit is deprecated
     */

    public void MultiMediaSubmit(Envelope envelope, SOAPContext soapcontext, SOAPContext soapcontext1)
        throws SOAPException, MessagingException, IOException
    {
        System.out.println("MultiMediaSubmit Entered");
        MultiMediaMessage multimediamessage = new MultiMediaMessage();
        try
        {
            multimediamessage.unmarshall(envelope);
            MultiMediaSubmitResponse multimediasubmitresponse = new MultiMediaSubmitResponse(1000, "Successfull message submission");
            multimediasubmitresponse.setMessageID("1");
            multimediasubmitresponse.setSubmitResultDescription("Successfull message submission");
            multimediasubmitresponse.setTransactionId("12345");
            multimediasubmitresponse.setTransactionID(multimediamessage.getTransactionId());
            Envelope envelope1 = marshall(multimediasubmitresponse);
            StringWriter stringwriter = new StringWriter();
            envelope1.marshall(stringwriter, new SOAPMappingRegistry(), soapcontext1);
            soapcontext1.setRootPart(stringwriter.toString(), "text/xml");
        }
        catch(Exception exception)
        {
            throw new SOAPException(Constants.FAULT_CODE_SERVER, exception.getMessage(), exception);
        }
        finally
        {
            System.out.println("MultiMediaSubmit Exited");
        }
    }

    [some code skipped]
}

  
  
-- 
Best regards,
 Vladimir


Re: please, help with "no deserializer found ..." message

Posted by Scott Nichol <sn...@scottnichol.com>.
The response from your server looks great, except that it never specifies the encodingStyle attribute.  For example,

 <fcl:asp_fv_mile_listResponse SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Nige White" <ni...@forward-comp.co.uk>
To: <so...@ws.apache.org>
Sent: Wednesday, November 10, 2004 4:31 AM
Subject: Re: please, help with "no deserializer found ..." message


> Hi all, first time poster, been lurking for a while.
> 
> We develop a freight forwarding application in the proprietary Synergy 
> DBL language which is a rather primitive procedural language with its 
> roots in the 1970s!
> 
> It's been updated to include TCP/IP routines, HTTP handling routnies, 
> and a (very) rudimentary XML parser etc,
> 
> I've written a series of XSLT transformations to generate a DBL SOAP 
> server, and matching Java client classes from the XML interface 
> description that our system uses (A very primitive analogue of WSDL 
> which just specifies compound data types built of DBL primitives, 
> followed by method declarations).
> 
> All is working well. Except for one thing. When one of the compound data 
> types which I send back to Apache SOAP contains a Date.
> 
> The compound data types generate Java Beans on the client side, and I'm 
> using the default Apache BeanSerializer to marshal/unmarshal them:
> 
>         
> soapmappingregistry.mapTypes("http://schemas.xmlsoap.org/soap/encoding/",
>             new QName("urn:forward-comp.co.uk", "Trkmil_011"),
>             Trkmil_011.class, beanserializer, beanserializer);
> 
> I copied how I serialize the Beans from examining the packets created by 
> Apache SOAP; when I pass a Parameter like this:
> 
>             String EncURI = null;
>             asp_wt_listParams.addElement(new Parameter("bar", 
> java.util.Date.class, bar, EncURI));
> 
> Apache Soap creates an element like this:
> 
> <bar xsi:type="xsd:dateTime">2004-07-17T00:00:00.000Z</bar>
> 
> But when on the DBL server size, I serialize a Date attribute of one of 
> our compound data types like this:
> 
> <SOAP-ENV:Envelope
>     xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>     xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
>     xmlns:xsd="http://www.w3.org/1999/XMLSchema"
>     xmlns:xse="http://schemas.xmlsoap.org/soap/encoding/"
>     xmlns:fcl="urn:forward-comp.co.uk">
>   <SOAP-ENV:Body>
>     <fcl:asp_fv_mile_listResponse>
>       <return xsi:type="xsd:int">1</return>
>       <trkmil_011 xsi:type="fcl:Trkmil_011">
>         <status xsi:type="xsd:byte">0</status>
>         <sequencer_date_d8 
> xsi:type="xsd:dateTime">2004-06-08T00:00:00.000Z</sequencer_date_d8>
>       </trkmil_011>
>     </fcl:asp_fv_mile_listResponse>
>   </SOAP-ENV:Body>
> </SOAP-ENV:Envelope
>  
> I get the following Exception:
> 
> [SOAPException: faultCode=SOAP-ENV:Client; msg=No Deserializer found to 
> deserialize a &apos;http://www.w3.org/1999/XMLSchema:dateTime&apos; 
> using encoding style &apos;null&apos;.; 
> targetException=java.lang.IllegalArgumentException: No Deserializer 
> found to deserialize a 'http://www.w3.org/1999/XMLSchema:dateTime' using 
> encoding style 'null'.]
>         at org.apache.soap.rpc.Call.invoke(Call.java, Compiled Code)
>         at com.fcl.aspclasses.asp.asp_fv_mile_list(asp.java, Compiled Code)
>         at 
> org.apache.jsp.AspFvTrkmilList_jsp._jspService(AspFvTrkmilList_jsp.java, 
> Compiled Code)
>         at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java, Compiled 
> Code)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java, 
> Compiled Code)
>         at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java, 
> Compiled Code)
> 
> 
> I'm doing exactly what Apache SOAP does! How come it can't deserialize 
> that back into a java.util.Date?
> 
> Thanks for any help,
> 
> Nige
> 
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
> 
> 
> 

Re: Compressing SOAP requests and using SSL

Posted by Nige White <ni...@forward-comp.co.uk>.
Scott Nichol wrote:

>The "nightly" build can gzip and will un-gzip a gzipped response.  The most recent one was posted 6/22/2004 at http://cvs.apache.org/dist/soap/nightly/2004-06-22/.
>
>To use SSL from the client, your only code change is to use the new endpoint URL (with https).  However, as has been pointed out, you must also have your JVM configuration set up for SSL, with cert authorities, keystore, etc.
>
>Scott Nichol
>
>  
>

Thanks for the helpful responses! I've downloaded the latest nightly 
build, and yes, it has setGzip(). Fantastic. Bandwidth is my first 
hurdle with the bosses here, in my quest to drag them out of the 1970s.

I've added the encodingStyle, I'm just about to test it. No doubt you'll 
hear from me if I can't get it to work.

Regards,

Nigel

_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk



Re: Compressing SOAP requests

Posted by Scott Nichol <sn...@scottnichol.com>.
Your compressed response should have HTTP headers

Content-Type: text/xml
Content-Encoding: gzip

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Nige White" <ni...@forward-comp.co.uk>
To: <so...@ws.apache.org>
Sent: Monday, November 15, 2004 1:22 PM
Subject: Re: Compressing SOAP requests


> Scott Nichol wrote:
> 
> >FYI, deflate follows Zlib as described in RFC 1950 (http://www.ietf.org/rfc/rfc1950.txt?number=1950).  The Zlib DEFLATE method of compression is described in RFC 1951, while gzip is described in RFC 1952 (http://www.ietf.org/rfc/rfc1952.txt?number=1952).  RFC 1952 looks like it specifies 10 bytes for the header, so I am not sure why 8 bytes works....
> >
> >  
> >
> Well, I've been battling with it.
> 
> Why 8 bytes works...
> 
> zlib already has a 2 byte flag prefix which the gzip compressed data 
> (after its 10 byte header) does not use, so it *looks* like it works 
> appending the 8 bytes.
> 
> Here's what I do:
> 
> When recieving gzip data:
> 
> Remove the first 10 bytes, they are the gzip-specific 10 byte header
> Remove the last 8 bytes, they consist of a CRC-32 checksum of the 
> original data, and original data length
> Prepend the zlib 2 byte flag: 0x78 0x9c
> Call zlib-inflate, and ignore error -5. THis is probably because the 
> buffer ends abruptly with no Adler checksum
> 
> When sending data as gzip:
> 
> Call zlib-deflate
> Remove the 2 zlib flag prefix bytes.
> Prepend the 10 byte gzip-specific header
> Append a CRC-32 checksum of the original data (Calculated in "DBL" which 
> has no unsigned arithmetic, and no bit-shift operators!)
> Append the original data length
> 
> This works in that I can compress data, and output it to a file which 
> gunzip will happily inflate to the original data.
> 
> I can also see (in my logfile) the correctly inflated SOAP packets 
> coming in to my DBL server.
> 
> There does seem to be a problem when SOAP receives by compressed packet. 
> It is throwing "Content is not allowed in prolog."
> 
> I still set the Content-Type header to "text/html". Should I change this 
> to indicate to SOAP that it is gzip data coming back?
> 
> I'll be back tomorrow, home time now.
> 
> Cheers,
> 
> Nigel
> 
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
> 
> 
> 

Re: Compressing SOAP requests

Posted by Nige White <ni...@forward-comp.co.uk>.
Scott Nichol wrote:

>FYI, deflate follows Zlib as described in RFC 1950 (http://www.ietf.org/rfc/rfc1950.txt?number=1950).  The Zlib DEFLATE method of compression is described in RFC 1951, while gzip is described in RFC 1952 (http://www.ietf.org/rfc/rfc1952.txt?number=1952).  RFC 1952 looks like it specifies 10 bytes for the header, so I am not sure why 8 bytes works....
>
>  
>
Well, I've been battling with it.

Why 8 bytes works...

zlib already has a 2 byte flag prefix which the gzip compressed data 
(after its 10 byte header) does not use, so it *looks* like it works 
appending the 8 bytes.

Here's what I do:

When recieving gzip data:

Remove the first 10 bytes, they are the gzip-specific 10 byte header
Remove the last 8 bytes, they consist of a CRC-32 checksum of the 
original data, and original data length
Prepend the zlib 2 byte flag: 0x78 0x9c
Call zlib-inflate, and ignore error -5. THis is probably because the 
buffer ends abruptly with no Adler checksum

When sending data as gzip:

Call zlib-deflate
Remove the 2 zlib flag prefix bytes.
Prepend the 10 byte gzip-specific header
Append a CRC-32 checksum of the original data (Calculated in "DBL" which 
has no unsigned arithmetic, and no bit-shift operators!)
Append the original data length

This works in that I can compress data, and output it to a file which 
gunzip will happily inflate to the original data.

I can also see (in my logfile) the correctly inflated SOAP packets 
coming in to my DBL server.

There does seem to be a problem when SOAP receives by compressed packet. 
It is throwing "Content is not allowed in prolog."

I still set the Content-Type header to "text/html". Should I change this 
to indicate to SOAP that it is gzip data coming back?

I'll be back tomorrow, home time now.

Cheers,

Nigel

_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk



Re: Compressing SOAP requests

Posted by Scott Nichol <sn...@scottnichol.com>.
FYI, deflate follows Zlib as described in RFC 1950 (http://www.ietf.org/rfc/rfc1950.txt?number=1950).  The Zlib DEFLATE method of compression is described in RFC 1951, while gzip is described in RFC 1952 (http://www.ietf.org/rfc/rfc1952.txt?number=1952).  RFC 1952 looks like it specifies 10 bytes for the header, so I am not sure why 8 bytes works....

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@ws.apache.org>
Sent: Friday, November 12, 2004 1:08 PM
Subject: Re: Compressing SOAP requests


Try it without any CRC: I think gzip may be willing to decompress it, anyway.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Nige White" <ni...@forward-comp.co.uk>
To: <so...@ws.apache.org>
Sent: Friday, November 12, 2004 12:48 PM
Subject: Re: Compressing SOAP requests


> Scott Nichol wrote:
> 
> >The magic header is 8 bytes: "\x1f\x8b\x08\x00\x00\x00\x00\x00".
> >
> >  
> >
> Interesting. I've read elsewhere that the header is 10 bytes, but...
> 
> I've tried writing those 8 bytes followed by the zlib-deflated data, 
> followed by 32 bits of zero.
> 
> Now, where gunzip -t  used to say "invalid compressed data--format violated"
> 
> it says "invalid compressed data--crc error"
> 
> Any idea how to calculate the CRC?
> 
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
> 
> 
> 


Re: Compressing SOAP requests

Posted by Scott Nichol <sn...@scottnichol.com>.
Try it without any CRC: I think gzip may be willing to decompress it, anyway.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Nige White" <ni...@forward-comp.co.uk>
To: <so...@ws.apache.org>
Sent: Friday, November 12, 2004 12:48 PM
Subject: Re: Compressing SOAP requests


> Scott Nichol wrote:
> 
> >The magic header is 8 bytes: "\x1f\x8b\x08\x00\x00\x00\x00\x00".
> >
> >  
> >
> Interesting. I've read elsewhere that the header is 10 bytes, but...
> 
> I've tried writing those 8 bytes followed by the zlib-deflated data, 
> followed by 32 bits of zero.
> 
> Now, where gunzip -t  used to say "invalid compressed data--format violated"
> 
> it says "invalid compressed data--crc error"
> 
> Any idea how to calculate the CRC?
> 
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
> 
> 
> 

Re: Compressing SOAP requests

Posted by Nige White <ni...@forward-comp.co.uk>.
Scott Nichol wrote:

>The magic header is 8 bytes: "\x1f\x8b\x08\x00\x00\x00\x00\x00".
>
>  
>
Interesting. I've read elsewhere that the header is 10 bytes, but...

I've tried writing those 8 bytes followed by the zlib-deflated data, 
followed by 32 bits of zero.

Now, where gunzip -t  used to say "invalid compressed data--format violated"

it says "invalid compressed data--crc error"

Any idea how to calculate the CRC?

_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk



Re: Compressing SOAP requests

Posted by Scott Nichol <sn...@scottnichol.com>.
The magic header is 8 bytes: "\x1f\x8b\x08\x00\x00\x00\x00\x00".

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@ws.apache.org>
Sent: Friday, November 12, 2004 11:44 AM
Subject: Re: Compressing SOAP requests


Standard Zlib is equivalent to HTTP Content-Encoding header value 'deflate'.  This differs from 'gzip', in that gzip includes some extra bytes (a header and checksum) in the compressed data.  Apache SOAP does not support deflate right now.  My experience working with PHP Zlib is that many (most?) gzip are satisfied with 4 0x00 bytes as the checksum, and some constant string of (I think) 10 bytes at the start for the header.  I don't recall the values, but you might poke around php.net for the gzinflate/gzdeflate/gzcompress/gzuncompress functions for clues (they would be in the notes after the "formal" documentation), or check the IEFT RFCs.

In short, I *think* Zlib can inflate a gzip payload if the first ten (I think) bytes of the payload are stripped, as well as the last 4.  You can package up a Zlib deflate buffer as a gzip payload if you prepend the magic 10 bytes and stick an all-zero dummy checksum at the end.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Nige White" <ni...@forward-comp.co.uk>
To: <so...@ws.apache.org>
Sent: Friday, November 12, 2004 11:11 AM
Subject: Compressing SOAP requests


> I've specified setGzip(true), and the incoming data is encoded.
> 
> I'm having trouble uncompressing it using the zlib library from 
> http://www.gzip.org/zlib/ (I can call C routines from this "DBL" language)
> 
> I can compress and decompress data in DBL using the zlib inflateInit(), 
> inflate(), and inflateEnd() routines, and I get back the data I started 
> with, so the zlib routines I have are consistent with themselves. The 
> good news is that they produce a 3:1 compression ratio on my test string!
> 
> Unfortunately, they won't uncompress the data I'm receiving from Apache 
> SOAP. Although if I write the data I receive out to a .gz file, then 
> gunzip will see it just fine.
> 
> So my question is, why won't the zlib routines from http://www.gzip.org/ 
> work? Is there an older version with a different compression algorithm I 
> should use? Should I do anything to the data before sending it into the 
> inflate() routine?
> 
> Hope you can help!
> 
> Nigel
> 
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
> 
> 
> 

Re: Compressing SOAP requests

Posted by Scott Nichol <sn...@scottnichol.com>.
Standard Zlib is equivalent to HTTP Content-Encoding header value 'deflate'.  This differs from 'gzip', in that gzip includes some extra bytes (a header and checksum) in the compressed data.  Apache SOAP does not support deflate right now.  My experience working with PHP Zlib is that many (most?) gzip are satisfied with 4 0x00 bytes as the checksum, and some constant string of (I think) 10 bytes at the start for the header.  I don't recall the values, but you might poke around php.net for the gzinflate/gzdeflate/gzcompress/gzuncompress functions for clues (they would be in the notes after the "formal" documentation), or check the IEFT RFCs.

In short, I *think* Zlib can inflate a gzip payload if the first ten (I think) bytes of the payload are stripped, as well as the last 4.  You can package up a Zlib deflate buffer as a gzip payload if you prepend the magic 10 bytes and stick an all-zero dummy checksum at the end.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Nige White" <ni...@forward-comp.co.uk>
To: <so...@ws.apache.org>
Sent: Friday, November 12, 2004 11:11 AM
Subject: Compressing SOAP requests


> I've specified setGzip(true), and the incoming data is encoded.
> 
> I'm having trouble uncompressing it using the zlib library from 
> http://www.gzip.org/zlib/ (I can call C routines from this "DBL" language)
> 
> I can compress and decompress data in DBL using the zlib inflateInit(), 
> inflate(), and inflateEnd() routines, and I get back the data I started 
> with, so the zlib routines I have are consistent with themselves. The 
> good news is that they produce a 3:1 compression ratio on my test string!
> 
> Unfortunately, they won't uncompress the data I'm receiving from Apache 
> SOAP. Although if I write the data I receive out to a .gz file, then 
> gunzip will see it just fine.
> 
> So my question is, why won't the zlib routines from http://www.gzip.org/ 
> work? Is there an older version with a different compression algorithm I 
> should use? Should I do anything to the data before sending it into the 
> inflate() routine?
> 
> Hope you can help!
> 
> Nigel
> 
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
> 
> 
> 

Compressing SOAP requests

Posted by Nige White <ni...@forward-comp.co.uk>.
I've specified setGzip(true), and the incoming data is encoded.

I'm having trouble uncompressing it using the zlib library from 
http://www.gzip.org/zlib/ (I can call C routines from this "DBL" language)

I can compress and decompress data in DBL using the zlib inflateInit(), 
inflate(), and inflateEnd() routines, and I get back the data I started 
with, so the zlib routines I have are consistent with themselves. The 
good news is that they produce a 3:1 compression ratio on my test string!

Unfortunately, they won't uncompress the data I'm receiving from Apache 
SOAP. Although if I write the data I receive out to a .gz file, then 
gunzip will see it just fine.

So my question is, why won't the zlib routines from http://www.gzip.org/ 
work? Is there an older version with a different compression algorithm I 
should use? Should I do anything to the data before sending it into the 
inflate() routine?

Hope you can help!

Nigel

_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk



Re: Compressing SOAP requests and using SSL

Posted by Scott Nichol <sn...@scottnichol.com>.
The "nightly" build can gzip and will un-gzip a gzipped response.  The most recent one was posted 6/22/2004 at http://cvs.apache.org/dist/soap/nightly/2004-06-22/.

To use SSL from the client, your only code change is to use the new endpoint URL (with https).  However, as has been pointed out, you must also have your JVM configuration set up for SSL, with cert authorities, keystore, etc.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Nige White" <ni...@forward-comp.co.uk>
To: <so...@ws.apache.org>
Sent: Wednesday, November 10, 2004 10:40 AM
Subject: Re: Compressing SOAP requests and using SSL


> Daniel Zhang wrote:
> 
> > Yes you can use SSL but it is a different story. You have to configure 
> > SSL for both Client and Server side, install the CA certificate, 
> > configure the keystore etc.  For example, look at Tomcat SSL how-to at 
> > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html.
> >
> >
> I'm not using Tomcat as the server.
> 
> The back end logic is in Synergy DBL - that can't be called from any 
> other language, the whole server is in DBL. Their HTTP API does offer 
> use of SSL. I'll look into configuring the Java client side when I get 
> that far.
> 
> The most important thing right now is implementnig compression.
> 
> (And getting rid of my "no deserializer found.." message!)
> 
> Nige
> 
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
> 
> 
> 

Re: Compressing SOAP requests and using SSL

Posted by Nige White <ni...@forward-comp.co.uk>.
Daniel Zhang wrote:

> Yes you can use SSL but it is a different story. You have to configure 
> SSL for both Client and Server side, install the CA certificate, 
> configure the keystore etc.  For example, look at Tomcat SSL how-to at 
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html.
>
>
I'm not using Tomcat as the server.

The back end logic is in Synergy DBL - that can't be called from any 
other language, the whole server is in DBL. Their HTTP API does offer 
use of SSL. I'll look into configuring the Java client side when I get 
that far.

The most important thing right now is implementnig compression.

(And getting rid of my "no deserializer found.." message!)

Nige

_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk



Re: Compressing SOAP requests and using SSL

Posted by Daniel Zhang <zh...@clinicaltools.com>.
Yes you can use SSL but it is a different story. You have to configure 
SSL for both Client and Server side, install the CA certificate, 
configure the keystore etc.  For example, look at Tomcat SSL how-to at 
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html.

Daniel Z
 
Nige White wrote:

> My boss has just looked at the SOAP client/server system I wrote. I 
> substituted my generated SOAP java client classes in for the 
> Synergy-created java client classes, (I made sure all the method 
> signatures were identical) and ran the web app. It talked to my SOAP 
> server just fine.
>
> Looking at the network traffic, it's obvious that SOAP is quite 
> bandwidth-intensive. The Synergy RPC protocol is primitive but very 
> compact, and my boss has basically vetoed the move to SOAP because of 
> the bandwidth constraints (We host our customers' web apps in-house, 
> and those web apps use RPC back to the customer's servers to access 
> their data!!! Weird... don't ask - it's the way "they" want it)
>
> My question is, is it possible to tell Apache SOAP to compress the 
> HTTP request? With it being textual data, we could achieve quite good 
> compression rates.
>
> Also, can Apache SOAP use SSL? Can I just specify an "https://..." URL 
> in my Call.invoke()?
>
> Thanks for any help.
>
> Nige
>
> _____________________________________________________________________
> This message has been checked for all known viruses. Virus scanning
> powered by Messagelabs http://www.messagelabs.com For more information
> e-mail : hostmaster@forward-comp.co.uk
>


Compressing SOAP requests and using SSL

Posted by Nige White <ni...@forward-comp.co.uk>.
My boss has just looked at the SOAP client/server system I wrote. I 
substituted my generated SOAP java client classes in for the 
Synergy-created java client classes, (I made sure all the method 
signatures were identical) and ran the web app. It talked to my SOAP 
server just fine.

Looking at the network traffic, it's obvious that SOAP is quite 
bandwidth-intensive. The Synergy RPC protocol is primitive but very 
compact, and my boss has basically vetoed the move to SOAP because of 
the bandwidth constraints (We host our customers' web apps in-house, and 
those web apps use RPC back to the customer's servers to access their 
data!!! Weird... don't ask - it's the way "they" want it)

My question is, is it possible to tell Apache SOAP to compress the HTTP 
request? With it being textual data, we could achieve quite good 
compression rates.

Also, can Apache SOAP use SSL? Can I just specify an "https://..." URL 
in my Call.invoke()?

Thanks for any help.

Nige

_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk



Re: please, help with "no deserializer found ..." message

Posted by Nige White <ni...@forward-comp.co.uk>.
Hi all, first time poster, been lurking for a while.

We develop a freight forwarding application in the proprietary Synergy 
DBL language which is a rather primitive procedural language with its 
roots in the 1970s!

It's been updated to include TCP/IP routines, HTTP handling routnies, 
and a (very) rudimentary XML parser etc,

I've written a series of XSLT transformations to generate a DBL SOAP 
server, and matching Java client classes from the XML interface 
description that our system uses (A very primitive analogue of WSDL 
which just specifies compound data types built of DBL primitives, 
followed by method declarations).

All is working well. Except for one thing. When one of the compound data 
types which I send back to Apache SOAP contains a Date.

The compound data types generate Java Beans on the client side, and I'm 
using the default Apache BeanSerializer to marshal/unmarshal them:

        
soapmappingregistry.mapTypes("http://schemas.xmlsoap.org/soap/encoding/",
            new QName("urn:forward-comp.co.uk", "Trkmil_011"),
            Trkmil_011.class, beanserializer, beanserializer);

I copied how I serialize the Beans from examining the packets created by 
Apache SOAP; when I pass a Parameter like this:

            String EncURI = null;
            asp_wt_listParams.addElement(new Parameter("bar", 
java.util.Date.class, bar, EncURI));

Apache Soap creates an element like this:

<bar xsi:type="xsd:dateTime">2004-07-17T00:00:00.000Z</bar>

But when on the DBL server size, I serialize a Date attribute of one of 
our compound data types like this:

<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/1999/XMLSchema"
    xmlns:xse="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:fcl="urn:forward-comp.co.uk">
  <SOAP-ENV:Body>
    <fcl:asp_fv_mile_listResponse>
      <return xsi:type="xsd:int">1</return>
      <trkmil_011 xsi:type="fcl:Trkmil_011">
        <status xsi:type="xsd:byte">0</status>
        <sequencer_date_d8 
xsi:type="xsd:dateTime">2004-06-08T00:00:00.000Z</sequencer_date_d8>
      </trkmil_011>
    </fcl:asp_fv_mile_listResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope
 
I get the following Exception:

[SOAPException: faultCode=SOAP-ENV:Client; msg=No Deserializer found to 
deserialize a &apos;http://www.w3.org/1999/XMLSchema:dateTime&apos; 
using encoding style &apos;null&apos;.; 
targetException=java.lang.IllegalArgumentException: No Deserializer 
found to deserialize a 'http://www.w3.org/1999/XMLSchema:dateTime' using 
encoding style 'null'.]
        at org.apache.soap.rpc.Call.invoke(Call.java, Compiled Code)
        at com.fcl.aspclasses.asp.asp_fv_mile_list(asp.java, Compiled Code)
        at 
org.apache.jsp.AspFvTrkmilList_jsp._jspService(AspFvTrkmilList_jsp.java, 
Compiled Code)
        at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java, Compiled 
Code)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java, 
Compiled Code)
        at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java, 
Compiled Code)


I'm doing exactly what Apache SOAP does! How come it can't deserialize 
that back into a java.util.Date?

Thanks for any help,

Nige

_____________________________________________________________________
This message has been checked for all known viruses. Virus scanning
powered by Messagelabs http://www.messagelabs.com For more information
e-mail : hostmaster@forward-comp.co.uk



Re[6]: please, help with "no deserializer found ..." message

Posted by Vladimir Brezhnev <bv...@portalsoft.ru>.
Hello Scott,

Tuesday, November 9, 2004, 8:01:55 PM, you wrote:

SN> Sorry, I forgot to add the most important thing: your client
SN> must use an endpoint URL for messagerouter instead of rpcrouter,
SN> for example, http://localhost:8080/soap/servlet/messagerouter.

It works. :) Thank you very much!

-- 
Best regards,
 Vladimir


Re: Re[4]: please, help with "no deserializer found ..." message

Posted by Scott Nichol <sn...@scottnichol.com>.
Sorry, I forgot to add the most important thing: your client must use an endpoint URL for messagerouter instead of rpcrouter, for example, http://localhost:8080/soap/servlet/messagerouter.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Vladimir Brezhnev" <bv...@portalsoft.ru>
To: "Scott Nichol" <so...@ws.apache.org>
Sent: Tuesday, November 09, 2004 10:13 AM
Subject: Re[4]: please, help with "no deserializer found ..." message


> Hello Scott,
> 
> Tuesday, November 9, 2004, 5:49:03 PM, you wrote:
> 
> SN> Your service class is written to use the messaging API:
> 
> SN>    public void SubmitReq(Envelope envelope, SOAPContext
> SN> soapcontext, SOAPContext soapcontext1)
> 
> SN> Your deployment descriptor should read
> 
> SN>    <isd:service
> SN> xmlns:isd="http://xml.apache.org/xml-soap/deployment"
> SN>     
> SN> id="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
> SN>      type="message"
> SN>      > 
> 
> SN> You do not need the type mappings in the deployment
> SN> descriptor, since your code will be responsible for interpretting
> SN> the XML.
> 
> Does not work. Looks like there is no type="message" attribute in
> deploy.xml.
> 
> SOAP answer:
> <faultstring>No  Deserializer  found  to  deserialize                a
> &apos;http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2:MM7Version&apos;
> using encoding style &apos;http://schemas.xmlsoap.org/soap/encoding/&apos;.</faultstring>
> 
> SOAP version 2.3.1 last build.
> 
> deploy.xml:
> <?xml version="1.0"?>
>      <isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
>      id="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
>      type="message"> 
>       <isd:provider type="java"
>                     scope="Application"
>                     methods="SubmitReq CancelReq">
>         <isd:java class="com.ericsson.services.mms.sdk.vasp.samples.sim.MMCRelay"
>                          static="false"/>
>       </isd:provider>
>       <isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultListener>
>   </isd:service>
> 
> -- 
> Best regards,
>  Vladimir
> 
> 

Re[4]: please, help with "no deserializer found ..." message

Posted by Vladimir Brezhnev <bv...@portalsoft.ru>.
Hello Scott,

Tuesday, November 9, 2004, 5:49:03 PM, you wrote:

SN> Your service class is written to use the messaging API:

SN>    public void SubmitReq(Envelope envelope, SOAPContext
SN> soapcontext, SOAPContext soapcontext1)

SN> Your deployment descriptor should read

SN>    <isd:service
SN> xmlns:isd="http://xml.apache.org/xml-soap/deployment"
SN>     
SN> id="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
SN>      type="message"
SN>      > 

SN> You do not need the type mappings in the deployment
SN> descriptor, since your code will be responsible for interpretting
SN> the XML.

Does not work. Looks like there is no type="message" attribute in
deploy.xml.

SOAP answer:
<faultstring>No  Deserializer  found  to  deserialize                a
&apos;http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2:MM7Version&apos;
using encoding style &apos;http://schemas.xmlsoap.org/soap/encoding/&apos;.</faultstring>

SOAP version 2.3.1 last build.

deploy.xml:
<?xml version="1.0"?>
     <isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
     id="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
     type="message"> 
      <isd:provider type="java"
                    scope="Application"
                    methods="SubmitReq CancelReq">
        <isd:java class="com.ericsson.services.mms.sdk.vasp.samples.sim.MMCRelay"
                         static="false"/>
      </isd:provider>
      <isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultListener>
  </isd:service>

-- 
Best regards,
 Vladimir


Re: Re[2]: please, help with "no deserializer found ..." message

Posted by Scott Nichol <sn...@scottnichol.com>.
Your service class is written to use the messaging API:

   public void SubmitReq(Envelope envelope, SOAPContext soapcontext, SOAPContext soapcontext1)

Your deployment descriptor should read

   <isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
     id="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
     type="message"
     > 

You do not need the type mappings in the deployment descriptor, since your code will be responsible for interpretting the XML.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Vladimir Brezhnev" <bv...@portalsoft.ru>
To: <so...@ws.apache.org>
Sent: Tuesday, November 09, 2004 9:12 AM
Subject: Re[2]: please, help with "no deserializer found ..." message


> Hello Scott,
> 
> Tuesday, November 9, 2004, 4:36:15 PM, you wrote:
> 
> SN> When a service uses the RPC API, the SOAP request is parsed
> SN> into parameters for the service method call.  Each parameter has a
> SN> Java type specified by the method signature.  Apache SOAP normally
> SN> uses the XML Schema type of an element in the request to determine
> SN> the Java type of the parameter using a type map defined in the
> SN> Apache SOAP code, but which the programmer can also extend.  In
> SN> your case, the parameters do not have an XML Schema type
> SN> specified, so Apache SOAP uses the element name instead.  However,
> SN> you have not specified a mapping for this type.  For the service,
> SN> Apache SOAP type mapping are specified in the deployment
> SN> descriptor.
> 
> SN> The Apache SOAP 2.3.1 documentation for type mapping is at
> SN> http://ws.apache.org/soap/docs/guide/serializer.html.
> 
> I specify type mappings in a deployment descriptor.
> But i get now this error:
> 
> "
> <?xml version='1.0' encoding='UTF-8'?>
> <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
> <SOAP-ENV:Body>
> <SOAP-ENV:Fault>
> <faultcode>SOAP-ENV:Server</faultcode>
> <faultstring>Exception while handling service request: com.ericsson.services.mms.sdk.vasp.samples.sim.MMCRelay.SubmitReq(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,javax.activation.DataHandler) -- no signature match</faultstring>
> <faultactor>/vaspsubmit/servlet/rpcrouter</faultactor>
> <detail>
> <stackTrace>java.lang.NoSuchMethodException: com.ericsson.services.mms.sdk.vasp.samples.sim.MMCRelay.SubmitReq(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.lang.String,javax.activation.DataHandler) -- no signature match
> 
>   at org.apache.soap.util.MethodUtils.getEntryPoint(MethodUtils.java:154)
> [...skipped...]"
> 
> SOAP tries to call method with many java.lang.String parameters.
> 
> There is the deploy.xml:
> <?xml version="1.0"?>
>   <isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
>     id="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2"
>     > 
> 
>       <isd:provider type="java"
>                     scope="Application"
>         methods="SubmitReq CancelReq">
>         <isd:java class="com.ericsson.services.mms.sdk.vasp.samples.sim.MMCRelay"
>                          static="false"/>
>       </isd:provider>
>       <isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultListener>
>   <isd:mappings>
>                 {skipped}
>   </isd:mappings>
>   </isd:service>
> 
> 
> 
> What i must change in the client code or in the deploy.xml to get success
> answer? I could not change server code (MMCRelay).
> 
> There is a class, which was set in deploy.xml.
>                          
> MMCRelay class:
> 
> package com.ericsson.services.mms.sdk.vasp.samples.sim;
> 
> import com.ericsson.services.mms.sdk.vasp.api.*;
> import java.io.*;
> import java.util.*;
> import javax.mail.MessagingException;
> import javax.xml.parsers.DocumentBuilder;
> import javax.xml.parsers.DocumentBuilderFactory;
> import org.apache.soap.*;
> import org.apache.soap.encoding.SOAPMappingRegistry;
> import org.apache.soap.rpc.SOAPContext;
> import org.w3c.dom.*;
> 
> // Referenced classes of package com.ericsson.services.mms.sdk.vasp.samples.sim:
> //            VASPSenderThread
> 
> public class MMCRelay
> {
> 
>     public MMCRelay()
>     {
>     }
> 
>     private MultiMediaSubmitResponse MultiMediaSubmitProcess(MultiMediaApplication multimediaapplication, MultiMediaMessage multimediamessage)
>         throws SOAPException
>     {
>         String s = TransactionManager.genTransactionID();
>         MultiMediaSubmitResponse multimediasubmitresponse = null;
>         try
>         {
>             if(multimediamessage.getSubject() != null && multimediamessage.getSubject().length() > 32)
>             {
>                 multimediasubmitresponse = new MultiMediaSubmitResponse(2001, "Subject Too Long");
>                 throw new IllegalArgumentException();
>             }
>             Date date = new Date();
>             if(multimediamessage.getTimeofExpiry() == null && multimediamessage.getRelativeTimeofExpiry() != 0L)
>                 multimediamessage.setTimeofExpiry(new Date(date.getTime() + 1000L * multimediamessage.getRelativeTimeofExpiry()));
>             if(multimediamessage.getTimeofExpiry() != null && date.after(multimediamessage.getTimeofExpiry()))
>             {
>                 multimediasubmitresponse = new MultiMediaSubmitResponse(2002, "Invalid Expiry");
>                 throw new IllegalArgumentException();
>             }
>             if(multimediamessage.getEarliestDeliveryTime() == null && multimediamessage.getRelativeEarliestDeliveryTime() != 0L)
>                 multimediamessage.setEarliestDeliveryTime(new Date(date.getTime() + 1000L * multimediamessage.getRelativeEarliestDeliveryTime()));
>             if(multimediamessage.getEarliestDeliveryTime() != null && multimediamessage.getTimeofExpiry() != null && multimediamessage.getEarliestDeliveryTime().after(multimediamessage.getTimeofExpiry()))
>             {
>                 multimediasubmitresponse = new MultiMediaSubmitResponse(2004, "Earliest Delivery clashed with Expiry");
>                 throw new IllegalArgumentException();
>             }
>             if(multimediamessage.getFrom() != null && multimediamessage.getFrom().length() > 12)
>             {
>                 multimediasubmitresponse = new MultiMediaSubmitResponse(2002, "Origination address error");
>                 throw new IllegalArgumentException();
>             }
>             if(multimediamessage.getNumberDestinationAddress() > 10)
>             {
>                 multimediasubmitresponse = new MultiMediaSubmitResponse(2002, "Invalid Number of Destinationsr");
>                 throw new IllegalArgumentException();
>             }
>             multimediasubmitresponse = new MultiMediaSubmitResponse(s);
>         }
>         catch(IllegalArgumentException illegalargumentexception)
>         {
>             throw new SOAPException(Constants.FAULT_CODE_CLIENT, multimediasubmitresponse == null ? "Submit" : multimediasubmitresponse.getSubmitResultDescription());
>         }
>         if(multimediasubmitresponse != null && multimediasubmitresponse.isSuccess())
>         {
>             MultiMediaApplication multimediaapplication1 = new MultiMediaApplication();
>             ArrayList arraylist = new ArrayList();
>             arraylist.addAll(multimediamessage.getAllDestination());
>             for(int i = 0; i < arraylist.size(); i++)
>             {
>                 Object obj = null;
>                 Address address = (Address)arraylist.get(i);
>                 if(multimediamessage.getDeliveryReport())
>                 {
>                     MultiMediaDeliveryReport multimediadeliveryreport = new MultiMediaDeliveryReport();
>                     multimediadeliveryreport.setRecipient(address.toString());
>                     multimediadeliveryreport.setFrom(multimediamessage.getFrom());
>                     multimediadeliveryreport.setReportStatus("Delivered");
>                     multimediadeliveryreport.setMessageID(multimediasubmitresponse.getMessageID());
>                     multimediadeliveryreport.setReportTime(new Date());
>                     VASPSenderThread vaspsenderthread = new VASPSenderThread(multimediamessage.getReportAddress(), multimediaapplication1, multimediadeliveryreport);
>                     vaspsenderthread.start();
>                     vaspsenderthread = null;
>                 }
>                 if(multimediamessage.getReadReport())
>                 {
>                     MultiMediaReadReport multimediareadreport = new MultiMediaReadReport();
>                     multimediareadreport.setRecipient(address.toString());
>                     multimediareadreport.setFrom(multimediamessage.getFrom());
>                     multimediareadreport.setMessageID(multimediasubmitresponse.getMessageID());
>                     multimediareadreport.setReportTime(new Date());
>                     VASPSenderThread vaspsenderthread1 = new VASPSenderThread(multimediamessage.getReportAddress(), multimediaapplication1, multimediareadreport);
>                     vaspsenderthread1.start();
>                     vaspsenderthread1 = null;
>                 }
>             }
> 
>         }
>         return multimediasubmitresponse;
>     }
> 
>     public void SubmitReq(Envelope envelope, SOAPContext soapcontext, SOAPContext soapcontext1)
>         throws SOAPException
>     {
>         System.out.println("SubmitReq Entered");
>         MultiMediaMessage multimediamessage = new MultiMediaMessage();
>         try
>         {
>             multimediamessage.unmarshall(envelope);
>             MultiMediaSubmitResponse multimediasubmitresponse = new MultiMediaSubmitResponse(1000, "Successfull message submission");
>             multimediasubmitresponse.setMessageID("1");
>             multimediasubmitresponse.setSubmitResultDescription("Successfull message submission");
>             multimediasubmitresponse.setTransactionId("12345");
>             multimediasubmitresponse.setTransactionID(multimediamessage.getTransactionId());
>             Envelope envelope1 = multimediasubmitresponse.marshall();
>             StringWriter stringwriter = new StringWriter();
>             envelope1.marshall(stringwriter, new SOAPMappingRegistry(), soapcontext1);
>             soapcontext1.setRootPart(stringwriter.toString(), "text/xml");
>         }
>         catch(Exception exception)
>         {
>             throw new SOAPException(Constants.FAULT_CODE_SERVER, exception.getMessage(), exception);
>         }
>         finally
>         {
>             System.out.println("SubmitReq Exited");
>         }
>     }
> 
>     /**
>      * @deprecated Method MultiMediaSubmit is deprecated
>      */
> 
>     public void MultiMediaSubmit(Envelope envelope, SOAPContext soapcontext, SOAPContext soapcontext1)
>         throws SOAPException, MessagingException, IOException
>     {
>         System.out.println("MultiMediaSubmit Entered");
>         MultiMediaMessage multimediamessage = new MultiMediaMessage();
>         try
>         {
>             multimediamessage.unmarshall(envelope);
>             MultiMediaSubmitResponse multimediasubmitresponse = new MultiMediaSubmitResponse(1000, "Successfull message submission");
>             multimediasubmitresponse.setMessageID("1");
>             multimediasubmitresponse.setSubmitResultDescription("Successfull message submission");
>             multimediasubmitresponse.setTransactionId("12345");
>             multimediasubmitresponse.setTransactionID(multimediamessage.getTransactionId());
>             Envelope envelope1 = marshall(multimediasubmitresponse);
>             StringWriter stringwriter = new StringWriter();
>             envelope1.marshall(stringwriter, new SOAPMappingRegistry(), soapcontext1);
>             soapcontext1.setRootPart(stringwriter.toString(), "text/xml");
>         }
>         catch(Exception exception)
>         {
>             throw new SOAPException(Constants.FAULT_CODE_SERVER, exception.getMessage(), exception);
>         }
>         finally
>         {
>             System.out.println("MultiMediaSubmit Exited");
>         }
>     }
> 
>     [some code skipped]
> }
> 
>   
>   
> -- 
> Best regards,
>  Vladimir
> 
>