Hello Word from C++ client to Java service returns "(null)", huh??
Hello Gentle-people,
I have been going through the exercise of getting axis-c++ to work.
I am using the axis-c-1.5.0-linux-bin distribution. I have created a
Java 'helloworld' echo service.
A simple service, you pass it a string and it returns to you the same
string prepended with an ack string.
I used axis to build the stub and header files for my serice. I then
run my serice the java axis service gets the string (as evidenced by
the log output) and then returns. The client returns "(null)".
Why is that? Why does it not return the echo string sent by the service?
I have been reading the list and have set multiRef to false in the axis
service-config.wsdd file:
value="org.apache.axis.attachments.AttachmentsImpl"/>
I am using resin-3.0.14 as my service container...
My service side code (java) is:
...
public java.lang.String request( java.lang.String msg ) {
if(msg == null) msg = "";
System.out.println("some thing: "+msg);
return "This is the hello world! - \""+msg+"\"";
}
...
My client side code (c++) is:
...
int
main (int argc, char *argv[])
{
char endpoint[256];
char original[256];
const char *server = "localhost";
const char *port = "1595";
const char *inputString = "";
const char *resultString = "";
// Set default service URL
sprintf (endpoint, "http://localhost:1595/NaracWS/services/HelloModel";);
sprintf (original, endpoint);
try{
if (argc < 1)
{
usage (argv[0], endpoint);
return 2;
}
cout << endl << " Using service at " << endpoint << endl << endl;
cout << "Instantiating remote endpoint stub... ";
HelloModel ws(endpoint);
cout << "[OK]" << endl;
cout << "attempting to send the string [cpp test]" <
printf ("Before remote call - Result: %s\n", resultString);
resultString = ws.request("cpp test");
printf ("After remote call - Result: %s\n", resultString);
}
catch (AxisException & e){printf ("\nException : %s\n", e.what ());}
catch (exception & e){printf ("\nUnknown exception has occured\n");}
catch (...) { printf ("\nUnknown exception has occured\n");}
return 0;
}
C++ client output:
Using service at http://localhost:1595/NaracWS/services/HelloModel
Instantiating remote endpoint stub... Warning - The WSDDFilePath file
(/home/obj/etc/server.wsdd) in the AXISCPP.CONF file does not exist.
[OK]
attempting to send the string [cpp test]
Before remote call - Result:
After remote call - Result: (null)
To build it:
g++ *.cpp -I/home/cue/workbench/axis-c-1.5.0-linux-bin/include
-L/home/cue/workbench/axis-c-1.5.0-linux-bin/lib/ -ldl -l axis_client
-ohello_echo
I am at my wit's end. Please, any help would be appreciated.
(I have attached the generated stub and header file)
--
--
Gavin M. Bell
Computer Science Research Scientist
Computing Applications and Research Dept.
Lawrence Livermore National Labs
L-103
[EMAIL PROTECTED]
---
"I'm trying real hard to be the shepherd."
-Samuel Jackson (Pulp Fiction)
/*
* This file was auto-generated by the Axis C++ Web Service Generator (WSDL2Ws)
* This file contains Client Stub implementation for remote web service.
*/
#include "HelloModel.hpp"
#include
#include
using namespace std;
HelloModel::HelloModel(const char* pchEndpointUri, AXIS_PROTOCOL_TYPE eProtocol)
:Stub(pchEndpointUri, eProtocol)
{
}
HelloModel::HelloModel()
:Stub(" ", APTHTTP1_1)
{
m_pCall->setEndpointURI("http://localhost:1595/NaracWS/services/HelloModel";);
}
HelloModel::~HelloModel()
{
}
/*Methods corresponding to the web service methods*/
/*
* This method wrap the service method request
*/
xsd__string HelloModel::request(xsd__string Value0)
{
xsd__string Ret;
memset(&Ret,0,sizeof(xsd__string));
const char* pcCmplxFaultName;
try
{
if (AXIS_SUCCESS != m_pCall->initialize(CPP_RPC_PROVIDER))
return Ret;
if (NULL==m_pCall->getTransportProperty("SOAPAction",false))
{
m_pCall->setTransportProperty(SOAPACTION_HEADER , "");
}
m_pCall->setSOAPVersion(SOAP_VER_1_1);
m_pCall->setOperation("request", "http://localhost:1595/NaracWS/services/HelloModel";);
applyUserPreferences();
m_pCall->addParameter((void*)Value0, "msg", XSD_STRING);
if (AXIS_SUCCESS == m_pCall->invoke())
{
if(AXIS_SUCCESS == m_pCall->checkMessage("requestResponse", "http://localhost:1595/NaracWS/services/HelloModel";))
{
Ret = m_pCall->getElementAsString("requestReturn", 0);
}
}
m_pCall->unInitialize();
return Ret;
}
catch(AxisException& e)
{
int iExceptionCode = e.getExceptionCode();
if(AXISC_NODE_VALUE_MISMATCH_EXCEPTION != iExceptionCode)
{
throw SoapFaultException(e);
}
ISoapFault* pSoapFault = (ISoapFault*)
m_pCall->checkFault("Fault","http://localhost:1595/NaracWS/services/HelloModel"; );
if(pSoapFault)
{
m_pCall->unInitialize();
throw SoapFaultException(e);
}
else throw;
}
}
/*
* This file was auto-g
RE: Two build questions
Oh I did not know that. In fact I never tried without conf file entry. -Original Message- From: John Hawkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 1:39 PM To: Apache AXIS C User List Subject: RE: Two build questions If you do not specify the lib names in conf then Axis relies on defaults which should get picked up from lib path. "Samisa Abeysinghe" <[EMAIL PROTECTED]> 24/08/2005 05:34 Please respond to "Apache AXIS C User List" To "Apache AXIS C User List" cc Subject RE: Two build questions Hi Kevin, > -Original Message- > From: Kevin Rogers [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 24, 2005 3:20 AM > To: Apache AXIS C User List > Subject: Re: Two build questions > > > Hey Samisa, thanks for the response. See my notes below: > > Samisa Abeysinghe wrote: > > >We seem to have few problems with Xerces 2.6 with some test cases. > >However, I was able to run the samples both on Linux and Windows using > >Xerces 2.6 > > > > > I am, unfortunately, unable to upgrade to 2.6 at this time because of > dependencies of other tools in my work envirnoment on Xerces. I'll keep > trying, or maybe try to set up my environment to fall back to the 2.2 > version that Axis 1.5.0 was built against. Xerces 2.0 doe not seem to have any problems at the moment. Hence you will have fewer issues with it. > > >axisapp.conf file is not pointing to the Xerces parser. Rather it is > >ponting to the Axis C++ implementation of the Xerces based paser > >abstraction layer lib. > > > > > >The libs such as Xerces are infact are picked from the lib path. We > >need the axiscpp.conf file to specify the location of the paser, > >transport and cannel abstraction implementations. > > > > > > Yes, this is true. However, isn't this why you copy libaxis_xercesc.so > (the default parser library) to libaxis_xmlparser.so (or create a > simlink to accomplish the same thing)? Am I misunderstanding in thinking > that these two libs are supposed to be exactly the same, only with > different names? Well you do not have to have different names. You can use libaxis_xercesc.so directly in axiscpp.conf file > > If I am understanding correctly, this requires a step (post-build) on > the user's part to make sure that they have either copied or linked the > appropriate XML parser lib so that it is represented by the name > 'axis_xmlparser', which is just an abstraction you have placed on top of > it. If this is the case, why not just do the same thing for the > transport and channel libs? Meaning, why don't you provide generic lib > names as an abstraction on top of the libraries, and then rely on the > user to either copy or link them post-build? This would do away with the > need for the conf file, correct? The only reason that I can think of to have a conf file is to have the possibility of switching the transport and parser libs. However, as we build shared libs, as you are suggesting, we would be able to pick the libs from the lib path and use it. I have never tried it but you have a valid point here. As of now the code is written to locate it from conf file and load it - may be this can be changed, but someone needs to look into the viability. Thanks, Samisa... > > >>Second, for right now, I need to have the axiscpp.conf file located > >>somewhere other that /etc, and was wondering what needs to be done to > >>make that happen? > >> > >> > > > >You do not need to have the conf file in /etc. All that you have to do > >is to define the AXISCPP_DEPLOY environment variable. Then both the > >server and clients will try to locate the conf file from > >$AXISCPP_DEPLOY/etc. > > > >Obviously, if AXISCPP_DEPLOY is not set, it will look in /etc. > > > > > > Thanks! That hint just helped me track that down to the > common/AxisConfig.cpp file. I'll try that out now. > > Best, > Kevin > > -- > Kevin Rogers > PDI / Dreamworks > ext.29163 | 650.562.9163 > [EMAIL PROTECTED]
RE: Two build questions
If you do not specify the lib names in conf then Axis relies on defaults which should get picked up from lib path. "Samisa Abeysinghe" <[EMAIL PROTECTED]> 24/08/2005 05:34 Please respond to "Apache AXIS C User List" To "Apache AXIS C User List" cc Subject RE: Two build questions Hi Kevin, > -Original Message- > From: Kevin Rogers [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 24, 2005 3:20 AM > To: Apache AXIS C User List > Subject: Re: Two build questions > > > Hey Samisa, thanks for the response. See my notes below: > > Samisa Abeysinghe wrote: > > >We seem to have few problems with Xerces 2.6 with some test cases. > >However, I was able to run the samples both on Linux and Windows using > >Xerces 2.6 > > > > > I am, unfortunately, unable to upgrade to 2.6 at this time because of > dependencies of other tools in my work envirnoment on Xerces. I'll keep > trying, or maybe try to set up my environment to fall back to the 2.2 > version that Axis 1.5.0 was built against. Xerces 2.0 doe not seem to have any problems at the moment. Hence you will have fewer issues with it. > > >axisapp.conf file is not pointing to the Xerces parser. Rather it is > >ponting to the Axis C++ implementation of the Xerces based paser > >abstraction layer lib. > > > > > >The libs such as Xerces are infact are picked from the lib path. We > >need the axiscpp.conf file to specify the location of the paser, > >transport and cannel abstraction implementations. > > > > > > Yes, this is true. However, isn't this why you copy libaxis_xercesc.so > (the default parser library) to libaxis_xmlparser.so (or create a > simlink to accomplish the same thing)? Am I misunderstanding in thinking > that these two libs are supposed to be exactly the same, only with > different names? Well you do not have to have different names. You can use libaxis_xercesc.so directly in axiscpp.conf file > > If I am understanding correctly, this requires a step (post-build) on > the user's part to make sure that they have either copied or linked the > appropriate XML parser lib so that it is represented by the name > 'axis_xmlparser', which is just an abstraction you have placed on top of > it. If this is the case, why not just do the same thing for the > transport and channel libs? Meaning, why don't you provide generic lib > names as an abstraction on top of the libraries, and then rely on the > user to either copy or link them post-build? This would do away with the > need for the conf file, correct? The only reason that I can think of to have a conf file is to have the possibility of switching the transport and parser libs. However, as we build shared libs, as you are suggesting, we would be able to pick the libs from the lib path and use it. I have never tried it but you have a valid point here. As of now the code is written to locate it from conf file and load it - may be this can be changed, but someone needs to look into the viability. Thanks, Samisa... > > >>Second, for right now, I need to have the axiscpp.conf file located > >>somewhere other that /etc, and was wondering what needs to be done to > >>make that happen? > >> > >> > > > >You do not need to have the conf file in /etc. All that you have to do > >is to define the AXISCPP_DEPLOY environment variable. Then both the > >server and clients will try to locate the conf file from > >$AXISCPP_DEPLOY/etc. > > > >Obviously, if AXISCPP_DEPLOY is not set, it will look in /etc. > > > > > > Thanks! That hint just helped me track that down to the > common/AxisConfig.cpp file. I'll try that out now. > > Best, > Kevin > > -- > Kevin Rogers > PDI / Dreamworks > ext.29163 | 650.562.9163 > [EMAIL PROTECTED]
