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

[Samisa Abeysinghe-4]

AFAICT, _t has nothing to do with the problem you are facing. 

Samisa...

On Wed, Oct 28, 2009 at 5:19 AM, <gsherwood@...> 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"

[gsherwood]

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

-------------- Forwarded Message: --------------
From: Samisa Abeysinghe <samisa@...>
To: Apache AXIS C User List <axis-c-user@...>
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, <gsherwood@...> 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"

[Samisa Abeysinghe-4]

On Sat, Dec 5, 2009 at 7:46 AM, <gsherwood@...> wrote:

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.

Thank you for the input. I think there might be a bug/issue in handling the service names with special characters such as '_'. Need to look into this. If you could raise a Jira, that might be useful.

Samisa...

[Selvaratnam Uthaiyashankar]

On Sun, Dec 13, 2009 at 3:24 PM, Samisa Abeysinghe <samisa@...> wrote:

>
>
> On Sat, Dec 5, 2009 at 7:46 AM, <gsherwood@...> wrote:
>>
>> 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.
>
> Thank you for the input. I think there might be a bug/issue in handling the
> service names with special characters such as '_'. Need to look into this.
> If you could raise a Jira, that might be useful.

I checked with a service having _t as part of its name. I could not
recreate the problem. I also strongly believe that the problem is not
due to _t.

Can you send the services.xml file if possible? Is there any other
libraries linked to your services?

Regards,
Shankar


> Samisa...
>



--
S.Uthaiyashankar
Software Architect
WSO2 Inc.
http://wso2.com/ - "The Open Source SOA Company"

[gsherwood]

Shankar,
I looked at the services.xml files for the two services. The service names are set correctly to the different names, but I see that the ServiceClass is set to TestCases (without the _t) for both:
<parameter name="ServiceClass" locked="xsd:false">TestCases</parameter>
Could that explain the problem?
Thanks,
George

<service name="TestCases">
 <parameter name="ServiceClass" locked="xsd:false">TestCases</parameter>
 <parameter name="wsdl_path" locked="xsd:false">/usr/local/apache2/conf/TestCases.wsdl</parameter>
 <description>
 Testcover.com TestCases service.
 Access by subscription. Please register at Testcover.com.
 </description>
 <operation name="getTestCases"/>
</service>

<service name="TestCases_t">
 <parameter name="ServiceClass" locked="xsd:false">TestCases</parameter>
 <parameter name="wsdl_path" locked="xsd:false">/usr/local/apache2/conf/TestCases_t.wsdl</parameter>
 <description>
 Testcover.com TestCases service, for internal testing only.
 Access for authorized test staff only.
 </description>
 <operation name="getTestCases"/>
</service>

-------------- Original message from Selvaratnam Uthaiyashankar <uthaiyashankar@...>: --------------

> On Sun, Dec 13, 2009 at 3:24 PM, Samisa Abeysinghe wrote:
> >
> >
> > On Sat, Dec 5, 2009 at 7:46 AM, wrote:
> >>
> >> 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.
> >
> > Thank you for the input. I think there might be a bug/issue in handling the
> > service names with special characters such as '_'. Need to look into this.
> > If you could raise a Jira, that might be useful.
>
> I checked with a service having _t as part of its name. I could not
> recreate the problem. I also strongly believe that the problem is not
> due to _t.
>
> Can you send the services.xml file if possible? Is there any other
> libraries linked to your services?
>
> Regards,
> Shankar
>
>
> > Samisa...
> >
>
>
>
> --
> S.Uthaiyashankar
> Software Architect
> WSO2 Inc.
> http://wso2.com/ - "The Open Source SOA Company"

[gsherwood]

Shankar & Samisa,
I checked Appendix B of the Axis2/C Manual, which explains what happened here. In the services.xml file both the service name and the library name (serviceClass) needed to be changed to have _t appended. I had only changed the service name.
Thank you for the help.
George

-------------- Original message from gsherwood@...: --------------

Shankar,
I looked at the services.xml files for the two services. The service names are set correctly to the different names, but I see that the ServiceClass is set to TestCases (without the _t) for both:
<parameter name="ServiceClass" locked="xsd:false">TestCases</parameter>
Could that explain the problem?
Thanks,
George

<service name="TestCases">
 <parameter name="ServiceClass" locked="xsd:false">TestCases</parameter>
 <parameter name="wsdl_path" locked="xsd:false">/usr/local/apache2/conf/TestCases.wsdl</parameter>
 <description>
 Testcover.com TestCases service.
 Access by subscription. Please register at Testcover.com.
 </description>
 <operation name="getTestCases"/>
</service>

<service name="TestCases_t">
 <parameter name="ServiceClass" locked="xsd:false">TestCases</parameter>
 <parameter name="wsdl_path" locked="xsd:false">/usr/local/apache2/conf/TestCases_t.wsdl</parameter>
 <description>
 Testcover.com TestCases service, for internal testing only.
 Access for authorized test staff only.
 </description>
 <operation name="getTestCases"/>
</service>

-------------- Original message from Selvaratnam Uthaiyashankar <uthaiyashankar@...>: --------------

> On Sun, Dec 13, 2009 at 3:24 PM, Samisa Abeysinghe wrote:
> >
> >
> > On Sat, Dec 5, 2009 at 7:46 AM, wrote:
> >>
> >> 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.
> >
> > Thank you for the input. I think there might be a bug/issue in handling the
> > service names with special characters such as '_'. Need to look into this.
> > If you could raise a Jira, that might be useful.
>
> I checked with a service having _t as part of its name. I could not
> recreate the problem. I also strongly believe that the problem is not
> due to _t.
>
> Can you send the services.xml file if possible? Is there any other
> libraries linked to your services?
>
> Regards,
> Shankar
>
>
> > Samisa...
> >
>
>
>
> --
> S.Uthaiyashankar
> Software Architect
> WSO2 Inc.
> http://wso2.com/ - "The Open Source SOA Company"