Dinesh Premalal wrote:
> Please recheck followings ..
>
> AXIS2C_HOME = "to deployment directory"
> LD_LIBRARY_PATH = $AXIS2C_HOME/lib:$LD_LIBRARY_PATH:
Alas, I fear it's not that simple a fix. :-( I definitely have
AXIS2C_HOME set properly; without it, the sample client programs just
segfault and die. I can see from the echo.log and other log files
that axis2.xml is being found and the services and modules directories
are being scanned, e.g.:
[debug] svc_builder.c(364) dll path is :
/usr/local/.../samples/services/echo/libecho.so
[debug] phase_resolver.c(268) svc name is:echo
and so forth. The libraries are found as well; ldd shows they've
all been linked in correctly and after all, the binaries wouldn't run
without them.
> IIRC AXIS2_OPTIONS_GET_USE_SEPERATE_LISTENER() , use with dual channel
> scenario, (separate channels for receiver and sender). For simple echo
> client has nothing to do with it. It operates only in single channel.
That helps a bit; thank you. I was able to dig down to find the
problem once I had a sense of which code paths was supposed to execute.
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 -- fortunately,
this does indeed work to make the echo client run -- and I'll
log this in JIRA as a bug. Sorry!
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
