[jira] Updated: (AXIS2C-209) Cannot invoke a service from within a service
[ http://issues.apache.org/jira/browse/AXIS2C-209?page=all ] Dinesh Premalal updated AXIS2C-209: --- Attachment: test_service.tar.gz attached sample service for this scenario... when client invokes the service, it calls math ( which is a sample service in Axis2c) service and send that (math) response to client. AXIS2_SVC_CLIENT_FREE worked fine with me. BTW there are some memory leaks in Axis2c , we are in a process of fixing them. Cannot invoke a service from within a service - Key: AXIS2C-209 URL: http://issues.apache.org/jira/browse/AXIS2C-209 Project: Axis2-C Issue Type: Bug Affects Versions: 0.92 Reporter: Andrew Borley Priority: Critical Fix For: 0.94 Attachments: test_service.tar.gz Using Axis2C 0.92 and trying to call a service on another server from within a service. The call to the final service works correctly but then the intermediary service fails when Axis2C tries to return the response to the original client. This happens after my skeleton invoke method returns. The problem can be fixed by commenting out the AXIS2_SVC_CLIENT_FREE call in the intermediary service, but then I have memory leaks. It would be good to have a sample that shows this operation, as it seems a likely user-scenario to me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-311) axis2_engine_invoke_phases(engine, env, global_out_phase, msg_ctx) method executes without checking whether global_out_phase is null.
axis2_engine_invoke_phases(engine, env, global_out_phase, msg_ctx) method
executes without checking whether global_out_phase is null.
-
Key: AXIS2C-311
URL: http://issues.apache.org/jira/browse/AXIS2C-311
Project: Axis2-C
Issue Type: Bug
Reporter: manjula peiris
axis2_engine_invoke_phases(engine, env, global_out_phase, msg_ctx) method
executes without checking whether global_out_phase is null.The patch below will
fix this problem.
--- /home/manjula/axis2/c/modules/core/engine/engine.c (revision 450856)
+++ /home/manjula/axis2/c/modules/core/engine/engine.c (working copy)
@@ -285,7 +285,8 @@
if (conf)
{
axis2_array_list_t *global_out_phase =
AXIS2_CONF_GET_OUT_PHASES(conf, env);
-axis2_engine_invoke_phases(engine, env, global_out_phase,
msg_ctx);
+if(global_out_phase)
+axis2_engine_invoke_phases(engine, env, global_out_phase,
msg_ctx);
}
}
}
@@ -305,7 +306,9 @@
if (conf)
{
axis2_array_list_t *global_out_phase =
AXIS2_CONF_GET_OUT_PHASES(conf, env);
-axis2_engine_invoke_phases(engine, env, global_out_phase,
msg_ctx);
+if(global_out_phase)
+axis2_engine_invoke_phases(engine, env, global_out_phase,
msg_ctx);
+
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
i am not able get structure values from webservice
HI ,
i am using axis1.6b (D:\axis-c-1.6b-Win32-trace-src) for C++ client
creation .i am using axis web service deployed with java.my client request
is going to server.response values i am not able to print .it is giving
NULL(0x00) values.
what i need to check please suggest. from one method i am returning string
,that am getting . but for Holder objects which are costum objects
(Structures) i am not able to get the vlues from server. is it
deserilization problem.
plese suggest me some thing for this .
my object deserializer code:::
xsd__int* p_country=NULL;p_country = (pIWSDZ-getElementAsInt(country,0));
if(NULL!=p_country){
param-country = *p_country;
}
delete p_country;
xsd__int* p_street =NULL;p_street=
(pIWSDZ-getElementAsInt(street,0));
if (NULL!=p_street) {
param-street = *p_street;
}
delete p_street;
return pIWSDZ-getStatus();
Regards,
Eswar S
--
View this message in context:
http://www.nabble.com/i-am-not-able-get-structure-values-from-webservice-tf2357229.html#a6566161
Sent from the Axis - C++ - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-312) remove fixed paths from code
remove fixed paths from code Key: AXIS2C-312 URL: http://issues.apache.org/jira/browse/AXIS2C-312 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux), core/deployment Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch As per this thread on the user mailing list, I've found that one can't actually use the --libdir, --includedir, etc. options to the autoconf configure program: http://marc.theaimsgroup.com/?l=axis-c-userm=115956538314942w=2 Here's the crux of the problem: hard-coded paths. While I appreciate that these are easier to write than a fully-configurable package, the documentation in the INSTALL file and the use of autoconf implies that one can customize the installation. For example, the INSTALL file says: Please run './configure --help' in samples folder for more information on configure options. As it happens, when I discovered that the package was going to install about 15 libraries and 375 header files, I purposefully used the standard autoconf configure options to put these in subdirectories: ./configure --prefix=$(INSTALL_PATH) --enable-tests \ --bindir=$(INSTALL_PATH)/bin/axis2 \ --includedir=$(INSTALL_PATH)/include/axis2 \ --libdir=$(INSTALL_PATH)/lib/axis2 \ With the appropriate CFLAGS and LDFLAGS and a little Makefile tuning, this all compiles OK and installs OK. It's also a fairly standard Apache way of doing things -- the APR and httpd projects use the apr-majorversion and apache2 subdirectories, for example, to keep their headers and libraries from polluting the user's --includedir location. Alas, in axis2_conf_builder_process_transport_senders(), we have this code: repos_name = AXIS2_DEP_ENGINE_GET_REPOS_PATH(conf_builder- desc_builder-engine, env); temp_path = AXIS2_STRACAT(repos_name, AXIS2_PATH_SEP_STR, env); temp_path2 = AXIS2_STRACAT(temp_path, AXIS2_LIB_FOLDER, env); temp_path3 = AXIS2_STRACAT(temp_path2, AXIS2_PATH_SEP_STR, env); path_qualified_dll_name = AXIS2_STRACAT(temp_path3, dll_name, env); This means that, in effect, the --libdir option to configure is useless, because the code is going to ignore whatever the specified installation locations were and go looking in the $AXIS2C_HOME/lib location regardless. What I'll do for now, I guess, is creating a symlink from $AXIS2C_HOME/lib to my $INSTALL_PATH/lib/axis2 location, and this does indeed work OK. However, it's a workaround caused by what I'd suggest is a pair of bugs. First, I'd suggest that there should be no hard-coded paths like the ones I see in modules/core/deployment/conf_builder.c, desc_builder.c, and arch_reader.c. These are just the ones using AXIS2_DEP_ENGINE_GET_REPOS_PATH(); there may well be other similar functions I'm not aware of, though. Such paths should be determined from configuration parameters. For example, programs could look for axis2.xml $AXIS2C_HOME, then in a directory specified at compile time using an option to ./configure, and finally in the current directory. The axis2.xml file would then, in turn, include the paths to the directories used for logs, libraries, services, modules, etc. It would also be nice if at compile time and run time one could specify a different name for the axis2.xml file -- for example, Apache httpd accepts an -f run-time option to use a non-standard configuration file. Second, whole autoconf system for axis2c needs some work. I'll put details into a second enhancement request, but as far as this particular bug is concerned, I'd suggest that since --libdir does correctly install the libraries into a given location, it's wrong to then go looking in $AXIS2C_HOME/lib despite what the user requested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-313) improve autoconf support
improve autoconf support Key: AXIS2C-313 URL: http://issues.apache.org/jira/browse/AXIS2C-313 Project: Axis2-C Issue Type: Improvement Components: build system (Unix/Linux) Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch The autoconf system really isn't being used effectively for the axis2c package. First, as noted in another bug report, some of the code searches for libraries in $AXIS2C_HOME/lib regardless of what is specified by the user when using the --libdir configure option. Second, it would be better if include files were installed in, say, $includedir/axis2, the way the APR project installs them in $includedir/apr-$majorversion and httpd installs them in $includedir/apache2. Given that 375 files are installed, this is otherwise a major source of pollution in a common location. Third, if one uses --libdir, --includedir, and --bindir, then each successive installation of an axis2c sub-project (like xml_schema or woden) and the main axis2c installation itself should use these locations to search for dependencies. As it is, the util sub-project installs quite neatly, but then all the others require patches to their Makefiles and/or specific CFLAGS and LDFLAGS settings so that they can locate the previous sub-projects' headers and libraries. This really shouldn't be necessary; they should look in --libdir and --includedir automatically. Fourth, the various test suites that run when make check is used fail in a wide variety of ways. Many of the test suites depend on libcutest.a -- but this isn't something the CuTest package provides! Instead, you have to dig out a posting to the mailing list: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile (An alternative would be the derived version that the APR test suite uses.) Other tests depend on data files that aren't in the distribution; for example, the xml_schema tests seem to require the files from https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ in a resources directory. The woden tests require a Calculator.wsdl file that I found in https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl, but it required that the xmlns:wsdl=http://schemas.xmlsoap.org/wsdl; attribute *not* have a trailing slash and WODEN_WSDL10_DESC_GET_INTERFACES() be used. The util/test/util/test_util.c file calls run_test_string(env) after freeing the env variable, producing a segfault. And so forth. Fifth, while I realize this would be a pain, it would be really superb if one could control the layout of the $AXIS2C_HOME location using the kinds of options provided by the config.layout file in the httpd package. More, instead of requiring directories under $AXIS2C_HOME named logs, services, modules, and so forth, and requiring that the libraries in the services and modules directories be accompanied by XML files, it would be great if you could ask for a layout like this: $prefix = $MY_INSTALL_DIR $bindir = $prefix/bin (by default, use --bindir to change) $includedir = $prefix/include/axis2 (by default, use --includedir to change) $libdir = $prefix/lib/axis2 (by default, use --libdir to change) $sysconfdir = $prefix/etc/axis2 (by default, use --sysconfdir to change) $localstatedir = $prefix (by default, use --localstatedir to change) $logfiledir = $localstatedir/logs (by default, use config.layout or axis2.xml to change) $servicesdir = $libdir/services (by default, use config.layout or axis2.xml to change) $modulesdir = $libdir/modules (by default, use config.layout or axis2.xml to change) The axis2.xml file would be expected to reside in $sysconfdir. There would be runtime options (like httpd's -f option) that would allow the user to point to another non-standard file, though. This file would could then contain logsDir, servicesDir, modulesDir to point to non-standard directories for those things, if the user wanted a different layout. Among other things, this kind of framework allows for easy switching between different versions of the same services and modules for testing purposes. Sorry to sound negative about all this -- the axis2c package looks to be ideal for my purposes (combining it with mod_dbd inside httpd); I've just had to struggle with the installation process quite a bit to get things laid out the way I want them. Thanks for listening! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
