axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Huebbers (JIRA)" <>
Subject [jira] Commented: (AXIS2C-1040) Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build
Date Thu, 06 Mar 2008 23:42:58 GMT


Frank Huebbers commented on AXIS2C-1040:


I was finally able to get a complete static build of the axis2/c engine with static http sender
and receiver libraries working. I should also note that I compiled the code with the static
runtime libraries for windows for easier deployment (\MT option). As I understand it, however,
there is currently no native support to also create static libraries of the axis2 sender and
receiver libraries, so, I made some changes to the axis util library to get this to work.

I'm going to start with the fixes that are necessary to get the axis2/c engine compiled statically
with guththila support:

1. As Senaka suggested earlier, we need to fix the issue in axutil_utils_defines.h.
2. A similar problem exists for guththila in guththila_defines.h

This should be enough to get a static axis2/c engine to work. Note that this required me to
define two preprocessors (AXIS2_STATIC_DEPLOY and AXIS2_DECLARE_STATIC). I didn't stop here
because I wanted everything statically compiled, so I had to introduce the following additional

1. In the axis2_http_transport_sender.h I added

    AXIS2_EXPORT int axis2_http_transport_sender_get_instance(
            struct axis2_transport_sender **inst,
            const axutil_env_t * env);

    AXIS2_EXPORT int axis2_http_transport_sender_remove_instance(
        axis2_transport_sender_t * inst,
        const axutil_env_t * env);

2. I added a new header file axis2_http_receiver.h with:

    AXIS2_EXPORT int axis2_http_receiver_get_instance(
            struct axis2_transport_receiver **inst,
            const axutil_env_t * env);

    AXIS2_EXPORT int axis2_http_receiver_remove_instance(
        axis2_transport_receiver_t * inst,
        const axutil_env_t * env);

3.a In the http_receiver.c file, I changed




3.b and I changed 




4.a In class_loader.c I added:

#include <axis2_http_receiver.h>
#include <axis2_http_transport_sender.h>

4.b and I added 

    // create reference to proper create/delete methods
    if (0 == strcmp(axutil_param_get_name(impl_info_param, env), "axis2_http_receiver"))
        create_funct = (CREATE_FUNCT) axis2_http_receiver_get_instance;        
        delete_funct = (DELETE_FUNCT) axis2_http_receiver_remove_instance;        
    else if (0 == strcmp(axutil_param_get_name(impl_info_param, env), "axis2_http_sender"))
        create_funct = (CREATE_FUNCT) axis2_http_transport_sender_get_instance;
        delete_funct = (DELETE_FUNCT) axis2_http_transport_sender_remove_instance;       

        obj = NULL;

    if (NULL != create_funct)
        axutil_dll_desc_set_create_funct(dll_desc, env, create_funct);
        axutil_dll_desc_set_delete_funct(dll_desc, env, delete_funct);

        create_funct(&obj, env);
    return obj;

Now, I understand that the above is somewhat of a hack because it locks me down currently
to use the http transports, however, this allows me to statically link in everything into
my final executable. Now, the reason why I need to do this is many fold but the most important
ones are:

1. I am only interested in client side deployment and thus need the simplest deployment method
2. Deployment is simplified since I reduced the number of files I need to ship by 7
3. My application is more secure as people cannot simply change the web service dlls with
their own version to hack my application or even change the whole transport dlls to something
else through the xml file
4. I can statically link in the runtime libraries with minimal penalty, and thus further simplify
deployment (since I don't need to install them on a user's machine if they don't have it)

While I understand that some people may disagree with on this, I strongly believe in the necessity
of being able to link everything into the final application when it's shipped out to customers.
However, I do see that this is not as critical when axis2/c is used on our servers.

Having said that, I think that my hack is actually easily extendable to provide users with
the ability to create a complete static set of axis libraries without locking them into using
http, for example. What it would require is probably some type of static_config.h file which
users can manipulate to define whether they want http or tcp with the appropriate settings
otherwise found in the axis2.xml file. Which brings me to the final issue that my solution
above does not yet solve: I'm still required to send out the axis2.xml file and set a home

Anyway, those are my thoughts.


> Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in static build
> -----------------------------------------------------------------------------------------
>                 Key: AXIS2C-1040
>                 URL:
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: util
>            Reporter: Frank Huebbers
>            Assignee: Senaka Fernando
> I have seen a few places where the typedef AXIS2_EXPORT is used instead of AXIS2_EXTERN.
Doing a simple search, I have seen this in the following fiels:
> - axis2_msg_recv.h
> - msg_recv.c
> - raw_xml_in_out_msg_recv.c
> - svr_callback.c
> - mod_addr.c
> - http_transport_sender.c
> - http_receiver.c
> - http_svr_thread.c
> - tcp_transport_sender.c
> - tcp_svr_thread.c
> - tcp_receiver.c
> Note that the definitions are correct in the header files.
> Frank

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message