[
https://issues.apache.org/jira/browse/AXIS2C-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575956#action_12575956
]
Frank Huebbers commented on AXIS2C-1040:
----------------------------------------
Hi,
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 "fixes":
1. In the axis2_http_transport_sender.h I added
#ifdef AXIS2_STATIC_DEPLOY
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);
#endif
2. I added a new header file axis2_http_receiver.h with:
#ifdef AXIS2_STATIC_DEPLOY
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);
#endif
3.a In the http_receiver.c file, I changed
AXIS2_EXPORT int
axis2_get_instance(
to
AXIS2_EXPORT int
#ifndef AXIS2_STATIC_DEPLOY
axis2_get_instance(
#else
axis2_http_receiver_get_instance(
#endif
3.b and I changed
AXIS2_EXPORT int
axis2_remove_instance(
to
AXIS2_EXPORT int
#ifndef AXIS2_STATIC_DEPLOY
axis2_remove_instance(
#else
axis2_http_receiver_remove_instance(
#endif
4.a In class_loader.c I added:
#include <axis2_http_receiver.h>
#include <axis2_http_transport_sender.h>
4.b and I added
#ifdef AXIS2_STATIC_DEPLOY
// 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;
}
else
{
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;
#endif
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 dir.
Anyway, those are my thoughts.
Frank
> Use of AXIS2_EXPORT instead of AXIS2_EXTERN in a few places causes errors in
> static build
> -----------------------------------------------------------------------------------------
>
> Key: AXIS2C-1040
> URL: https://issues.apache.org/jira/browse/AXIS2C-1040
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
