Samisa,
Thanks for the response. I mentioned the _t because when I posted the message, the ONLY difference between the two services was their names. One has the _t and the other does not. So it seemed likely to me that the different behavior was related to their different names. This is not a big problem for me because I think I have a workaround. I guessed that the Axis2/C team would either recognize what's happening here, or would want to understand it sometime.
Best regards,
George
Thanks for the response. I mentioned the _t because when I posted the message, the ONLY difference between the two services was their names. One has the _t and the other does not. So it seemed likely to me that the different behavior was related to their different names. This is not a big problem for me because I think I have a workaround. I guessed that the Axis2/C team would either recognize what's happening here, or would want to understand it sometime.
Best regards,
George
-------------- Forwarded Message: --------------
From: Samisa Abeysinghe <sam...@wso2.com>
To: Apache AXIS C User List <axis-c-user@ws.apache.org>
Subject: Re: DLL path for libTestCases_t.so is set to libTestCases.so
Date: Fri, 04 Dec 2009 17:19:58 +0000
AFAICT, _t has nothing to do with the problem you are facing.Samisa...On Wed, Oct 28, 2009 at 5:19 AM, <gsherw...@att.net> wrote:
I have set up two services which (for now) are identical except for their names, TestCases and TestCases_t. The choice of the suffix _t is historical and has nothing to do with type names. libTestCases.so and libTestCases_t.so are placed in their respective directories:
/usr/local/www/64.232.245.115/axis2c/services/TestCases and
/usr/local/www/64.232.245.115/axis2c/services/TestCases_t
However, log entries indicate the DLL path for libTestCases_t.so is not getting set correctly. Relevant entries include the following.
[Tue Oct 27 19:22:33 2009] [debug] svc_builder.c(318) DLL path is : /usr/local/www/64.232.245.115/axis2c/services/TestCases/libTestCases.so
[Tue Oct 27 19:22:33 2009] [debug] om_element.c(1114) There are no child elements for the node
[Tue Oct 27 19:22:33 2009] [debug] svc_builder.c(318) DLL path is : /usr/local/www/64.232.245.115/axis2c/services/TestCases_t/libTestCases.so
[Tue Oct 27 19:22:33 2009] [debug] om_element.c(1114) There are no child elements for the node
...
[Tue Oct 27 19:22:33 2009] [error] class_loader.c(162) Loading shared library /usr/local/www/64.232.245.115/axis2c/services/TestCases_t/libTestCases.so Failed. DLERROR IS /usr/local/www/64.232.245.115/axis2c/services/TestCases_t/libTestCases.so: cannot open shared object file: No such file or directory
If I depart from the usual naming convention (i.e. libTestCases_t.so for TestCases_t), and use the name in the DLL path instead (libTestCases.so), then the service works.
Can anyone help with answers to these questions?
1. Is this behavior (dropping the _t suffix) a bug or a feature?
2. Is setting the name to the DLL path indicated in the log a legitimate workaround?
3. Am I likely to encounter future trouble with a service name ending in _t?
Thanks,
George Sherwood
Testcover.com
--
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.
http://www.wso2.com/ - "The Open Source SOA Company"
