ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enquire <>
Subject SOAP- ENV :Fault = Protocol ???
Date Wed, 13 Nov 2002 19:46:48 GMT
Hi All,

I have a problem with a SOAP invocation of an ATL COM
object which I have deployed (I feel imperfectly on
the Apache SOAP Server.
I however, do not have any problems with my other
deployed SOAP WebServices at the same SOAP RPCRouter

The SOAP Response returns a text/html format error as
the Apache Xerces DOMWriter/DOMFaultListener is not
happy with the format of the SOAP ENV– more
importantly both the Java SOAP Client and the Apache
SOAP Server complain about a ‘NullPointerReference’.
This leads me more to believe that it basically is a
problem with the way I have registered the SOAP
WebService using the XML deployment Descriptor.

I could not find anyone better source than here to
follow this line of enquiry to possible programmatic

In the meantime, I have sparingly tried something with
the ATL COM DLL which I thought I may report to you:

i) First up, I don’t think that I have registered the
ATL COM DLL properly with the SOAP Server. I need a
proper way of naming the Object (preferably a fully
qualified name); this can be noted in the XML file
which is used as a deployment descriptor for the SOAP
WebService . To extrapolate an earlier experience with
Microsoft based COM DLLs { what I had done with the
Visual Basic COM DLL } -> I had to register the
Project Name and the Class Module name in the VB COM
DLL SOAP WebService Deployment Descriptor(XML file
again) .I need the ‘progid’ value (please note the
relevant portions under). Could you guide me in this

Visual Basic COM DLL            

<!--Apache SOAP specific deployment descriptor (ie
loads this service into Apache SOAP.-->






    <isd:java class="required not needed for

    <isd:option key="progid" value="Project1.Class1"





Visual C++ ATL Com DLL

<!--Apache SOAP specific deployment descriptor (ie
loads this service into Apache SOAP.-->



      scope="Application" methods="DllMain">

    <isd:java class="required not needed for

    <isd:option key="progid"
value="Day1Server.MyFirstATLObject" />

    <!-- <isd:option key="threadmodel"

    <isd:option key="threadmodel"

    <isd:option key="threadmodel"



        <isd:option key="threadmodel"








ii) Next, I was able to register an ATL COM DLL which
is not using a BSTR (tried int*, char*…successfully
with minor though ‘telling’ code tweaking), but the
STL Registration process requires that a pointer be
used due to the constraints imposed by the ‘atl.h’
header file (standard) – btw can we change this header
so that it accepts non-pointer based datatypes? (I
foresee that there might be more code other than the
header which we may need to update in the ‘Microsoft’
implementation of ATL).



iii) Further, I was considering the reverse approach
-> ATL COM Client to non-Microsoft SOAP WebService,
say, Java.


iv) As of time=now, I haven’t tried testing a separate
box(computer)->>[ Client on one box and server on
another box ] scenario (memory heap allocation problem


v) Also, Java handles BSTR; it refers to it as

To conclude, IMHO, I feel that the Java
NullPointerException is being thrown mainly due to the
fact that the fully qualified object name is not

Please respond ASAP.

<->{ R2D2 }<->








Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

View raw message