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/01 11:47:27 UTC
[Axis2]Fixing AXIS2C-40
Forwarding with correct prefix
=====================================================
Hi
I have given a solution to
http://issues.apache.org/jira/browse/AXIS2C-40
I changed param_free method to look like following
axis2_status_t AXIS2_CALL
axis2_param_free(axis2_param_t *param,
axis2_env_t **env)
{
void *param_value = NULL;
AXIS2_FUNC_PARAM_CHECK(param, env, AXIS2_FAILURE);
param_value = AXIS2_PARAM_GET_VALUE(param, env);
if(param_value)
{
if(param->ops && param->ops->value_free)
{
param->ops->value_free(param_value, env);
}
else /* we assume that param value is axis2_char_t* */
{
AXIS2_FREE((*env)->allocator, param_value);
}
}
AXIS2_FREE((*env)->allocator, param->ops);
AXIS2_FREE((*env)->allocator, AXIS2_INTF_TO_IMPL(param));
return AXIS2_SUCCESS;
}
Now param_container.h has the following function pointer type
/**
* each type which is passed as a param value to a parameter, must have this
* type of function implemented. When the param value is set this function
* should also be assigned to param free function
*/
typedef axis2_status_t (*AXIS2_PARAM_VALUE_FREE) (void *param,
axis2_env_t **env);
Now suppose we set the axis2_dll_desc_t type struct as a param value. We
need
to have a axis2_dll_desc_as_param_value_free function implemented in
dll_desc.c
axis2_status_t AXIS2_CALL
axis2_dll_desc_as_param_value_free (void *as_param_value,
axis2_env_t **env)
{
axis2_dll_desc_t *dll_desc = NULL;
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
dll_desc = (axis2_dll_desc_t *) as_param_value;
return axis2_dll_desc_free(dll_desc, env);
}
Now we need to assign this to value_free function of param as callback when
value is assigned to parameter.
status = AXIS2_PARAM_SET_VALUE(impl_info_param, env, dll_desc);
impl_info_param->ops->value_free = axis2_dll_desc_as_param_value_free;
What I want to say here is that we need to implement the free function as in
dll_desc.c for all the types set as param values. Otherwise param value
is assumed to be axis2_char_t * in the param free function.
thanks
damitha
[Axis2] method name prefixes for service skeletons
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Hi All,
We need to have a consensus on the method name prefixes for service
skeletons
I would like to propose axis2_[SKELETON_NAME]_method_name.
Thoughts please.
Samisa...
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
>
>
>
Re: [Axis2] API in the client Stub (to be generated) exposed to the
user
Posted by Sahan Gamage <sa...@wso2.com>.
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
[Axis2] API in the client Stub (to be generated) exposed to the user
Posted by Samisa Abeysinghe <sa...@gmail.com>.
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...