DLL path for libTestCases_t.so is set to libTestCases.so

[gsherwood]

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