You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Sahan Gamage <sa...@wso2.com> on 2006/02/02 06:41:16 UTC
Re: [Axis2] API in the client Stub (to be generated) exposed to the
user
Samisa Abeysinghe wrote:
> Hi All,
> Currently we have the following 2 APIs in the client stub for
> creating a stub:
> 1.
> AXIS2_DECLARE(axis2_stub_t *)
> axis2_echo_stub_create_with_endpoint_ref_and_client_home(axis2_env_t
> **env,
> axis2_endpoint_ref_t
> *endpoint_ref,
> axis2_char_t *client_home);
> 2.
> AXIS2_DECLARE(axis2_stub_t *)
> axis2_echo_stub_create_with_endpoint_uri_and_client_home(axis2_env_t
> **env,
> axis2_char_t *endpoint_uri,
> axis2_char_t *client_home);
>
> In userability perspective, given that we expose the above two to the
> user, I think it is too long and a bit confusing.
> I propose that we drop signature 1 altogether and rename 2 to
> 'axis2_echo_stub_create'.
> To cover up for 1, we have AXIS2_STUB_SET_ENDPOINT_REF in stub.h.
>
> Thoughts please...
> Samisa...
>
>
+1;
I don't see a common use case where user creates an epr and then creates
a stub. A uri in the string format is the most logical. For the uncommon
"user epr create" scenario can be still catered by
AXIS2_STUB_SET_ENDPOINT_REF. In this case shouldn't we allow the
'axis2_echo_stub_create' to accept NULL uri ?
- Sahan
Re: [Axis2] Threading issues with log
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Hi Nadir,
Your input is very useful. We will try this.
Many thanks.
Samisa...
Nadir Amra wrote:
>Correction would need to be made for thread id in sprintf, the code below
>assumes it is long long, but on 32 but systems it is int.
>
> tid = pthread_getthreadid_np();
>
> sprintf(myfmt, "<%s.%03ld %016llx> %s", tempTimeStr, t.tv_usec/1000,
>*((long long *)&tid), fmt);
>
>Nadir K. Amra
>
>
>Nadir Amra/Rochester/IBM@IBMUS wrote on 02/05/2006 11:28:07 AM:
>
>
>
>>Note I have not looked at axis2 code, so I am talking canceptually....
>>
>>I am assuming there is a point where there is some initialization going
>>
>>
>on
>
>
>>prior to anyone using the trace that is tied to configuration. At that
>>time, one can set a global file handle to the log file by calling
>>trace_init() which simply contains the following code:
>>
>> FILE * traceFp = fopen(logFile, "w+");
>> setvbuf(traceFp, NULL, _IOFBF, (size_t)(8*1024));
>>
>>The above assumes trace records are no longer than 8K. This will ensure
>>
>>
>no
>
>
>>buffering takes place.
>>
>>Then, in the actual routine that performs the trace:
>>
>>#include <stdlib.h>
>>#include <stdio.h>
>>#include <stdarg.h>
>>#include <pthread.h>
>>
>>void trace(const char *fmt, ... )
>>{
>> char tempTimeStr[200];
>> struct timeval t;
>> struct tm *lTime;
>> pthread_id_np_t tid;
>> va_list args;
>> char myfmt[8*1024];
>>
>> if (traceFp == NULL)
>> return;
>>
>> gettimeofday(&t, NULL);
>> lTime = localtime((const time_t *)&t.tv_sec);
>> strftime(tempTimeStr, 100, "%d/%b/%Y %H:%M:%S", lTime);
>>
>> tid = pthread_getthreadid_np();
>>
>> sprintf(myfmt, "<%s.%03ld %016llx> %s", tempTimeStr, t.tv_usec/1000,
>>
>>
>
>
>
>>*((long long *)&tid), fmt);
>>
>> va_start(args, fmt);
>> vfprintf(traceFp, myfmt, args);
>> va_end(args);
>> fflush(traceFp);
>>}
>>
>>
>>The above code is thread-safe and not only prints out the date and time
>>(included milli-seconds), but the thread ID also.
>>
>>
>>Nadir K. Amra
>>
>>
>>Samisa Abeysinghe <sa...@gmail.com> wrote on 02/03/2006
>>10:51:11 PM:
>>
>>
>>
>>>Hi All,
>>> Once we have the threads in place, we have to ensure that our
>>>logging mechanism is thread safe.
>>> May be we can learn some stuff from Apache httpd code.
>>>
>>> Unfortunately, we are not lucky as much as Java guys, we do not
>>>
>>>
>have
>
>
>>>a log4j equivalent. We have log4c http://log4c.sourceforge.net/. But I
>>>
>>>
>
>
>
>>>am not convinced of its maturity and licence.
>>> Thoughts please...
>>>Thanks,
>>>Samisa...
>>>
>>>
>
>
>
>
Re: [Axis2] Threading issues with log
Posted by Nadir Amra <am...@us.ibm.com>.
Correction would need to be made for thread id in sprintf, the code below
assumes it is long long, but on 32 but systems it is int.
tid = pthread_getthreadid_np();
sprintf(myfmt, "<%s.%03ld %016llx> %s", tempTimeStr, t.tv_usec/1000,
*((long long *)&tid), fmt);
Nadir K. Amra
Nadir Amra/Rochester/IBM@IBMUS wrote on 02/05/2006 11:28:07 AM:
> Note I have not looked at axis2 code, so I am talking canceptually....
>
> I am assuming there is a point where there is some initialization going
on
> prior to anyone using the trace that is tied to configuration. At that
> time, one can set a global file handle to the log file by calling
> trace_init() which simply contains the following code:
>
> FILE * traceFp = fopen(logFile, "w+");
> setvbuf(traceFp, NULL, _IOFBF, (size_t)(8*1024));
>
> The above assumes trace records are no longer than 8K. This will ensure
no
> buffering takes place.
>
> Then, in the actual routine that performs the trace:
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <stdarg.h>
> #include <pthread.h>
>
> void trace(const char *fmt, ... )
> {
> char tempTimeStr[200];
> struct timeval t;
> struct tm *lTime;
> pthread_id_np_t tid;
> va_list args;
> char myfmt[8*1024];
>
> if (traceFp == NULL)
> return;
>
> gettimeofday(&t, NULL);
> lTime = localtime((const time_t *)&t.tv_sec);
> strftime(tempTimeStr, 100, "%d/%b/%Y %H:%M:%S", lTime);
>
> tid = pthread_getthreadid_np();
>
> sprintf(myfmt, "<%s.%03ld %016llx> %s", tempTimeStr, t.tv_usec/1000,
> *((long long *)&tid), fmt);
>
> va_start(args, fmt);
> vfprintf(traceFp, myfmt, args);
> va_end(args);
> fflush(traceFp);
> }
>
>
> The above code is thread-safe and not only prints out the date and time
> (included milli-seconds), but the thread ID also.
>
>
> Nadir K. Amra
>
>
> Samisa Abeysinghe <sa...@gmail.com> wrote on 02/03/2006
> 10:51:11 PM:
>
> > Hi All,
> > Once we have the threads in place, we have to ensure that our
> > logging mechanism is thread safe.
> > May be we can learn some stuff from Apache httpd code.
> >
> > Unfortunately, we are not lucky as much as Java guys, we do not
have
>
> > a log4j equivalent. We have log4c http://log4c.sourceforge.net/. But I
> > am not convinced of its maturity and licence.
> > Thoughts please...
> > Thanks,
> > Samisa...
>
Re: [Axis2] Threading issues with log
Posted by Nadir Amra <am...@us.ibm.com>.
Note I have not looked at axis2 code, so I am talking canceptually....
I am assuming there is a point where there is some initialization going on
prior to anyone using the trace that is tied to configuration. At that
time, one can set a global file handle to the log file by calling
trace_init() which simply contains the following code:
FILE * traceFp = fopen(logFile, "w+");
setvbuf(traceFp, NULL, _IOFBF, (size_t)(8*1024));
The above assumes trace records are no longer than 8K. This will ensure no
buffering takes place.
Then, in the actual routine that performs the trace:
#include <stdlib.h>
#include <stdio.h>
#include <stdarg.h>
#include <pthread.h>
void trace(const char *fmt, ... )
{
char tempTimeStr[200];
struct timeval t;
struct tm *lTime;
pthread_id_np_t tid;
va_list args;
char myfmt[8*1024];
if (traceFp == NULL)
return;
gettimeofday(&t, NULL);
lTime = localtime((const time_t *)&t.tv_sec);
strftime(tempTimeStr, 100, "%d/%b/%Y %H:%M:%S", lTime);
tid = pthread_getthreadid_np();
sprintf(myfmt, "<%s.%03ld %016llx> %s", tempTimeStr, t.tv_usec/1000,
*((long long *)&tid), fmt);
va_start(args, fmt);
vfprintf(traceFp, myfmt, args);
va_end(args);
fflush(traceFp);
}
The above code is thread-safe and not only prints out the date and time
(included milli-seconds), but the thread ID also.
Nadir K. Amra
Samisa Abeysinghe <sa...@gmail.com> wrote on 02/03/2006
10:51:11 PM:
> Hi All,
> Once we have the threads in place, we have to ensure that our
> logging mechanism is thread safe.
> May be we can learn some stuff from Apache httpd code.
>
> Unfortunately, we are not lucky as much as Java guys, we do not have
> a log4j equivalent. We have log4c http://log4c.sourceforge.net/. But I
> am not convinced of its maturity and licence.
> Thoughts please...
> Thanks,
> Samisa...
[Axis2] Threading issues with log
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Hi All,
Once we have the threads in place, we have to ensure that our
logging mechanism is thread safe.
May be we can learn some stuff from Apache httpd code.
Unfortunately, we are not lucky as much as Java guys, we do not have
a log4j equivalent. We have log4c http://log4c.sourceforge.net/. But I
am not convinced of its maturity and licence.
Thoughts please...
Thanks,
Samisa...
[Axis2] make dist error
Posted by Samisa Abeysinghe <sa...@gmail.com>.
I tried 'make dist' and build the resulting package.
I get an error when I try to run make on the created package:
Making all in ides
make[2]: Entering directory `/home/samisa/temp/axis2-1.0.0/ides'
Making all in anjuta
make[3]: Entering directory `/home/samisa/temp/axis2-1.0.0/ides/anjuta'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/samisa/temp/axis2-1.0.0/ides/anjuta'
make[3]: Entering directory `/home/samisa/temp/axis2-1.0.0/ides'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/samisa/temp/axis2-1.0.0/ides'
make[2]: Leaving directory `/home/samisa/temp/axis2-1.0.0/ides'
make[2]: Entering directory `/home/samisa/temp/axis2-1.0.0'
make[2]: *** No rule to make target `samples/server/axis2.xml', needed
by `all-am'. Stop.
make[2]: Leaving directory `/home/samisa/temp/axis2-1.0.0'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/samisa/temp/axis2-1.0.0'
make: *** [all] Error 2
It cannot find axis2.xml
Also, why does it try to run make in ides? It does not make sense.
Thanks,
Samisa...
Re: [Axis2] API in the client Stub (to be generated) exposed to the
user
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Sahan Gamage wrote:
>Samisa Abeysinghe wrote:
>
>
>
>>Hi All,
>> Currently we have the following 2 APIs in the client stub for
>>creating a stub:
>>1.
>>AXIS2_DECLARE(axis2_stub_t *)
>>axis2_echo_stub_create_with_endpoint_ref_and_client_home(axis2_env_t
>>**env,
>> axis2_endpoint_ref_t
>>*endpoint_ref,
>> axis2_char_t *client_home);
>>2.
>>AXIS2_DECLARE(axis2_stub_t *)
>>axis2_echo_stub_create_with_endpoint_uri_and_client_home(axis2_env_t
>>**env,
>> axis2_char_t *endpoint_uri,
>> axis2_char_t *client_home);
>>
>>In userability perspective, given that we expose the above two to the
>>user, I think it is too long and a bit confusing.
>>I propose that we drop signature 1 altogether and rename 2 to
>>'axis2_echo_stub_create'.
>>To cover up for 1, we have AXIS2_STUB_SET_ENDPOINT_REF in stub.h.
>>
>>Thoughts please...
>>Samisa...
>>
>>
>>
>>
>+1;
>I don't see a common use case where user creates an epr and then creates
>a stub. A uri in the string format is the most logical. For the uncommon
>"user epr create" scenario can be still catered by
>AXIS2_STUB_SET_ENDPOINT_REF. In this case shouldn't we allow the
>'axis2_echo_stub_create' to accept NULL uri ?
>
>
I think it is OK to allow NULL for URI. We can check if URI is NULL b4
making the connection.
If user tries to invoke, keeping the URI NULL, then it is a user error.
Samisa...
>- Sahan
>
>
>