Re: Potential name clashes when using multiple services
Looks like your two wsdls use (may be imported) same schema structure. If so the two adb structures, operations should be identical, so you can delete one set of them and use the same generated files for both services. But if that's not the case but they are independent and just happen to have the same name? Normally in a wsdl, schema is not associated with a service. so we don't have a way to have service name inside adb structure. Maybe it's a good idea to add the option to add a prefix to all files, functions and structs, that can be specified on the wsdl2c command line. That could help to prevent name clashes. On Wed, Jan 7, 2009 at 3:25 PM, Catalina Caloian catalina.calo...@quintiq.com wrote: Hello Scenario: - an application needs to use two services - let's call their respective wsdl files Mapping.wsdl and Geocoding.wsdl - both services use a type called Coordinate - upon generating C code from the wsdl files using WSDL2C, we get two adb_Coordinate.c and two adb_Coordinate.h files (one for each wsdl), with two adb_Coordinate_create(const axutil_env_t* env) functions etc. - this leads to linkage errors I've tried to change CADBBeanTemplateHeader.xsl and CADBBeanTemplateSource.xsl so that the service name is used when creating the name of the structures - so adb_Coordinate_* becomes adb_Mapping_Coordinate_* and adb_Geocoding_Coordinate_* etc. However, it seems that the service name is not available in the intermediate xml file used for code generation - or I haven't been able to find it. The workaround was to manually rename everything. However, it would be nice if the service name would be automatically incorporated in the name of the generated structures and thus avoid potential name clashes between services. Thank you. Catalina-Georgiana Caloian Software Engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 65 247 63 99 E catalina.calo...@quintiq.com I www.quintiq.com Quintiq Conference Quintessence 09 Tuesday May 12th, 2009, Country Estate Duin Kruidberg, near Amsterdam Schiphol, The Netherlands - for more information visit www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding. -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com Quintiq Conference Quintessence 09 Tuesday May 12th, 2009, Country Estate Duin Kruidberg, near Amsterdam Schiphol, The Netherlands - for more information visit www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
[jira] Created: (AXIS2C-1330) Prevent name clashes when using multiple services that happen to have identical named items
Prevent name clashes when using multiple services that happen to have identical named items --- Key: AXIS2C-1330 URL: https://issues.apache.org/jira/browse/AXIS2C-1330 Project: Axis2-C Issue Type: Improvement Components: code generation Affects Versions: Current (Nightly) Reporter: Patrick van Beem Priority: Minor Problem: When using multiple services in one project that happen to have identical named items, identical named structures and functions are generated in identical named files, but with specific content for the different services. This can not be linked. Solution: Add an optional command line option to the generator application that adds a prefix to every filename, structure, function, typedefinition, etc... of a specific code generation session. This allows the developer to generate unique c-code for each service. Example scenario: - an application needs to use two services - let's call their respective wsdl files Mapping.wsdl and Geocoding.wsdl - both services use a type called Coordinate, but it's not the same type - upon generating C code from the wsdl files using WSDL2C, we get two adb_Coordinate.c and two adb_Coordinate.h files (one for each wsdl), with two adb_Coordinate_create(const axutil_env_t* env) functions etc. - this leads to linkage errors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1325) _WIN32 should be used instead of WIN32
_WIN32 should be used instead of WIN32 -- Key: AXIS2C-1325 URL: https://issues.apache.org/jira/browse/AXIS2C-1325 Project: Axis2-C Issue Type: Bug Affects Versions: 1.6.0 Environment: WIN64 Reporter: Patrick van Beem Priority: Minor In several places, the WIN32 macro is used to check if we're running on Windows or not. This macro is defined in the make file (and usually by VS in the any WIN32 project too). However, when users are using the library in a 64-bit windows environment, WIN32 is not defined, so the tests for the WIN32 macro in the axis include files in the distribution, fail (when they should not, because we are in a windows environment). We should either use _WIN32 instead (which is always defined by the MS compiler in both 32-bit and 64-bit) or use something like: #if defined(WIN32) || defined(WIN64) to check for windows. I prefer _WIN32, because that's implicit defined while WIN32 and WIN64 must be defined explicit. This change should be made at least in the public includes (since WIN32 is defined in the makefile, the change would have no effect internally). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Multi-threading
Hello, -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. The current implementation of a thread pool in axis is no thread pool but a collection of thread creation and deletion methods... So no... But when creating environment you can pass your own thread pool. Would that not help? No. The current implementation of axis relies on an infinite number of available threads. It assumes that when it requests a thread, it's getting one and it then starts the thread with a thread method / data. But in reality, a thread pool would have a finite number of (re-used) threads. In the case of axis, this would mean that the thread requesting the new thread would block until a new thread is available. This is not what you want. For axis to work with a finite number of threads, the way it uses threads should change. It should not request a thread, but it should submit a job (probably the thread method and data) to the thread pool. The submitting thread can then continue an the thread pool can decide when the job is performed by which thread. Regards, Quintiq Conference Quintessence 09 Tuesday May 12th, 2009, Country Estate Duin Kruidberg, near Amsterdam Schiphol, The Netherlands - for more information visit www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
[jira] Created: (AXIS2C-1320) default logger not thread-safe = axutil_env_create_with_error_log not thread-safe
default logger not thread-safe = axutil_env_create_with_error_log not thread-safe -- Key: AXIS2C-1320 URL: https://issues.apache.org/jira/browse/AXIS2C-1320 Project: Axis2-C Issue Type: Bug Components: util Affects Versions: Current (Nightly) Reporter: Patrick van Beem Fix For: Current (Nightly) Attachments: Do_not_create_default_logger.diff The current default logger is not thread-safe. That's no problem as long as it's known. One can use his own logger. However, the axutil_env_create_with_error_log() function internally first creates the default logger and then deletes it again to be replaced by the specified logger. Since even creating / deleting the default logger is not thread-safe, this leads to problems (in my case an assertion in the vs runtime dll). When a logger is specified for axutil_env_create_with_error_log(), the default logger should not even be created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1320) default logger not thread-safe = axutil_env_create_with_error_log not thread-safe
[ https://issues.apache.org/jira/browse/AXIS2C-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick van Beem updated AXIS2C-1320: - Attachment: Do_not_create_default_logger.diff default logger not thread-safe = axutil_env_create_with_error_log not thread-safe -- Key: AXIS2C-1320 URL: https://issues.apache.org/jira/browse/AXIS2C-1320 Project: Axis2-C Issue Type: Bug Components: util Affects Versions: Current (Nightly) Reporter: Patrick van Beem Fix For: Current (Nightly) Attachments: Do_not_create_default_logger.diff Original Estimate: 2h Remaining Estimate: 2h The current default logger is not thread-safe. That's no problem as long as it's known. One can use his own logger. However, the axutil_env_create_with_error_log() function internally first creates the default logger and then deletes it again to be replaced by the specified logger. Since even creating / deleting the default logger is not thread-safe, this leads to problems (in my case an assertion in the vs runtime dll). When a logger is specified for axutil_env_create_with_error_log(), the default logger should not even be created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Multi-threading
Hello Supun, First we need to think why we need to execute Axis2/C clients in multiple threads instead of using separate clients in different threads. I had to read that sentence at least three times before I understood it :-) You mail does shine some light on the subject for me. Both the overhead and performance are an issue for us. And since IO is involved when initializing a stub, performance might be more important. We selected axis for our soap interface because of the adb code generation (ease of use while adding more and more soap clients). So writing a lot of code for the mep instead of 'just using the framework' is not really an option for us. I think we stay with the 'use our own thread pool and do sync calls from there' implementation of 'async' calls for now. Thanks for the input. One advantage of using a single client is the overhead associated with multiple clients. A single axis2_svc_client requires multiple axis2 configurations and multiple environments. This is the only reasong comes to my mind right now for not using different axis2_svc_clients in different threads. If you have any other requirements please share with us. If performance is the concern associated with creating multiple clients, there is a solution to the problem. The real entity that do the most important work in the client side is axis2_mep_client. axis2_svc_client is a wrapper around the mep client for make the job easier for the client programmer. But axis2_svc_client is not designed for a multithreaded environment. The problems with axis2_svc_client running in multiple threads is it keep tracks of the various objects from previous invokations. This leads to double free this resources in multiple threading environments. But if we can use the mep client these problems won't be there. The only problem with mep client is it requires quite a bit of coding to make it work. If we can provide a simple thread safe method set for directly accessing the mep client it will be really useful. So devs what do you think? Supun.. -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
Re: RE : Multi-threading
Hello Carl, What Axis does well is freeing resources (once we figure out how to set everything up right!) so I am a little confused as to where exactly the limitations are. You say the callback system provided is not good in terms of freeing resources, but have you tried freeing your resources from another function which itself waits for the callback to occur? (either error callback or success callback) I think this is the way Axis was designed with as implied by Dimuthu: wait in a loop in your main thread while the callbacks are outstanding, do no cleanup in the callback itself, let that thread exit completely and after it is done, then from your main thread detect that the callback ocurred and do the cleanup there. Correct. But I think the design is missing one thing. If I allocate the stub and env and then do an async call, I'm not allowed to free those two resources in the callback, because they're used by the axis framework. But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. As you indicate, the only safe way is to wait until the thread is finished. But the axis framework does not provide an api to find out which thread is processing you request. And it shouldn't, because the thread mechanism is an implementation detail of the axis framework. Future versions might re-use the thread or even use no threading at all for asynchronous calls. So the only safe way to free resources is for the axis framework to signal the caller that the resources are no longer needed. A (second?) callback is the most used (elegant) way to do this. Right now, the framework does not provide a safe way of freeing resources in async calls. My reason for responding though is really to comment on this phrase: Threads are a rather expensive resource to use for just waiting on an IO completion. It may be my lack of understanding, but I am pretty sure that -- at least in the win32 tcp/ip stack -- once your thread goes into asynchronous communication on a socket, you do not see it again until there is some result. This means if there is a timeout your thread is inactive for a long time. Correct. So if I've got a couple of hundred outstanding calls, they all consume precious memory. In our case, this is a lot of memory, since we have a heavy server applications with a greedy memory allocation strategy per thread (for performance) and a rather large default stacks. Of course, both can be optimized for the 'just waiting on io-completion'-threads... CPU-wise, it's no problem. How can one thread wait on more than one asychronous communication? I admit this would be a far better solution, however from my understanding of winsock2 it is not possible. With the fd_set in winsock and the select() function, you can wait at a maximum of 64 (current implementation) sockets at once. With I/O Completion Ports you can use one thread for an infinite number of ports (though a pool of threads might be a good idea if the number of sockets grows large). This is also used by the well known boost (C++) library. Mechanisms like these would be a much better implementation. But I think they don't fit well in the modular (transportation) design of axis, since they require knowledge about the lower level transportation on a higher level. Seen this way, one thread per socket communication is maybe expensive in resources, but it is the only way to ensure your main thread continues to operate in a timely fashion. But prone to explode with a log of async calls. As a 'workaround' I've now my own static-sized thread pool that perform synchronous calls. If there are more async calls then threads in the pool, they're queued. Thank you for your input. -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
RE: Multi-threading
Hello Bill Patrick, when building a multi-threaded Axis2C client I too was concerned about the multiple environments. Although your statement is correct in a sense that each thread needs its own environment/stub, these environments can in fact share much of the underlying structures. In practice, each thread needs its own error stack, but it can certainly share the allocator and logger. And the configuration information is associated with the allocator. There is a primitive function axutil_env_create_with_error_log_thread_pool() that lets you share the substructures already created for the global environment created once for the application. This way the configuration information is read only once. Axutil_env_free_masked() lets each thread free just its error stack upon termination, leaving the allocator et.al. intact. Correct. I already use these. But afaik the configuration file is read when creating the stub. And that should be done for each thread / call. So while many resources can indeed be shared, the one needing the most (time-consuming) initialization (I think), can't. I think this would be a great improvement for the future. I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. The current implementation of a thread pool in axis is no thread pool but a collection of thread creation and deletion methods... So no... Thank you for your input. -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
Multi-threading
Hello, I'm experiencing serious limitations while using axis in a multi-threading environment. I know axis is not fully designed (yet?) for multi-threading, but I think some 'small' changes might make it more usable. One can't deny multi-threading. Here my 2 cents: * Callback and resources In a multi-threading environment, an asynchronous job is often responsible for freeing it's own resources (in this case, the environment, the stub and possible extra application dependent data). In the axis framework, this can't be done in the callback, since the framework will use the stub after the callback is finished. This makes it impossible for an application to free resources after a call has finished (because you never know exactly when the call (including the framework part of it) is finished. This makes the asynchronous implementation of axis useless in a job-oriented multi-threading environment. Improvements might include adding an extra callback to free resources, that is made when axis has freed all its resources and does not need any resources the user might free. * Environment vs stub Since every thread needs it's own environment and stub in axis and (as stated above) in a multi-threaded environment a job is often responsible of it's own resources, every job needs to allocate and initialize it's environment and stub for each call (or keep one set initialized for every thread, but that's not feasible when one thread can be used for multiple purposes / jobs and/or threads can be added dynamically). And free it after the job is finished. Apart from the (slight) performance drawback, this poses another problem: Part of the stub initialization includes reading the configuration file. When two threads try to do this simultaneously, the last one who tries this, fails. Solutions to this problem might include: - Create a clone function for the stub, so all threads can clone from template stub, instead of reading from disk. - Separate the state information from the stub and put it in the environment, so the stub can be used read-only and shared by threads. * Async model The asynchronous call implementation of axis is based on creating new threads that just wait on a response. Threads are a rather expensive resource to use for just waiting on an IO completion (and then performing some small task). It might be better that the waiting on all outstanding IO is done by one single thread. The work after the IO completed can then be done by either that thread, or a (small and static) thread pool. That way, no threads have to be created / deleted on the flow, not more than one thread is waiting on IO and no high amount of threads will exist when a lot of asynchronous calls exist in parallel. My axis knowledge is not enough to see solutions for this within axis right now. What do you all think about these points? Regards, -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E [EMAIL PROTECTED] I www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
[jira] Updated: (AXIS2C-1314) Memory leak in c code generation when adding the operations
[ https://issues.apache.org/jira/browse/AXIS2C-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick van Beem updated AXIS2C-1314: - Attachment: creating_the_operations_memleak.diff Memory leak in c code generation when adding the operations --- Key: AXIS2C-1314 URL: https://issues.apache.org/jira/browse/AXIS2C-1314 Project: Axis2-C Issue Type: Bug Components: code generation Environment: Win32/64 Reporter: Patrick van Beem Fix For: Current (Nightly) Attachments: creating_the_operations_memleak.diff Original Estimate: 1h Remaining Estimate: 1h The function axis2_op_create_with_qname() clones the name argument, so the ownership of the original argument remains with the caller. So we should free the allocated name: op_qname = axutil_qname_create(env, div , http://localhost/axis/Calculator;, NULL); op = axis2_op_create_with_qname(env, op_qname); axutil_qname_free(op_qname,env); /* line added */ -- 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]
[jira] Created: (AXIS2C-1314) Memory leak in c code generation when adding the operations
Memory leak in c code generation when adding the operations --- Key: AXIS2C-1314 URL: https://issues.apache.org/jira/browse/AXIS2C-1314 Project: Axis2-C Issue Type: Bug Components: code generation Environment: Win32/64 Reporter: Patrick van Beem Fix For: Current (Nightly) Attachments: creating_the_operations_memleak.diff The function axis2_op_create_with_qname() clones the name argument, so the ownership of the original argument remains with the caller. So we should free the allocated name: op_qname = axutil_qname_create(env, div , http://localhost/axis/Calculator;, NULL); op = axis2_op_create_with_qname(env, op_qname); axutil_qname_free(op_qname,env); /* line added */ -- 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]
[jira] Created: (AXIS2C-1315) Use defines (or enums) for axutil_env_free_masked()
Use defines (or enums) for axutil_env_free_masked() --- Key: AXIS2C-1315 URL: https://issues.apache.org/jira/browse/AXIS2C-1315 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: Patrick van Beem Priority: Trivial Fix For: Current (Nightly) Attachments: env_defines.diff Use defines or constants for axutil_env_free_masked(). This makes code easier to read and understand: AXIS_ENV_FREE_LOG- Frees the log AXIS_ENV_FREE_ERROR - Frees the error AXIS_ENV_FREE_THREADPOOL - Frees the thread pool -- 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]
[jira] Created: (AXIS2C-1313) Memory leak in axis2_desc_add_child
Memory leak in axis2_desc_add_child
---
Key: AXIS2C-1313
URL: https://issues.apache.org/jira/browse/AXIS2C-1313
Project: Axis2-C
Issue Type: Bug
Components: core/description
Environment: Win32/64
Reporter: Patrick van Beem
Fix For: Current (Nightly)
Attachments: axis2_desc_add_child.diff
axis2_desc_add_child() overwrites existing children with the same name. These
become orphaned and are leaking memory (they'll never get freed).
Suggestion: Check for an existing child with the same key ad free it before
replacing it with the new child:
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_desc_add_child(
const axis2_desc_t * desc,
const axutil_env_t * env,
const axis2_char_t * key,
const void *child)
{
if (desc-children)
{
/* Added from here */
axis2_msg_t* msg = (axis2_msg_t *) axutil_hash_get(desc-children, key,
AXIS2_HASH_KEY_STRING);
if ( msg != NULL )
{
axis2_msg_free(msg, env);
}
/* Added to here */
axutil_hash_set(desc-children, key, AXIS2_HASH_KEY_STRING, child);
return AXIS2_SUCCESS;
}
return AXIS2_FAILURE;
}
--
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]
[jira] Updated: (AXIS2C-1315) Use defines (or enums) for axutil_env_free_masked()
[ https://issues.apache.org/jira/browse/AXIS2C-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick van Beem updated AXIS2C-1315: - Attachment: env_defines.diff Use defines (or enums) for axutil_env_free_masked() --- Key: AXIS2C-1315 URL: https://issues.apache.org/jira/browse/AXIS2C-1315 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: Patrick van Beem Priority: Trivial Fix For: Current (Nightly) Attachments: env_defines.diff Use defines or constants for axutil_env_free_masked(). This makes code easier to read and understand: AXIS_ENV_FREE_LOG- Frees the log AXIS_ENV_FREE_ERROR - Frees the error AXIS_ENV_FREE_THREADPOOL - Frees the thread pool -- 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]
[jira] Created: (AXIS2C-1305) error not set when memory allocation fails in axis2_stub_start_op_... generated code
error not set when memory allocation fails in axis2_stub_start_op_... generated
code
Key: AXIS2C-1305
URL: https://issues.apache.org/jira/browse/AXIS2C-1305
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Win
Reporter: Patrick van Beem
Priority: Minor
Fix For: Current (Nightly)
In the axis2_stub_start_op_... generated code, the error fields are not set
when memory allocation fails. The using code will assume the call succeeded
because no error is set, while it actually failed (although out-of-mem is
hopefully a rare situation).
See example code from the calculator example:
void AXIS2_CALL
axis2_stub_start_op_Calculator_add( axis2_stub_t *stub, const
axutil_env_t *env,
:
:
callback_data = (struct axis2_stub_Calculator_add_callback_data*)
AXIS2_MALLOC(env-allocator,
sizeof(struct
axis2_stub_Calculator_add_callback_data));
if(NULL == callback_data)
{
AXIS2_ERROR_SET(env-error, AXIS2_ERROR_NO_MEMORY,
AXIS2_FAILURE); // === This line was not there!
AXIS2_LOG_ERROR( env-log, AXIS2_LOG_SI, Can not allocate
memeory for the callback data structures);
return;
}
--
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]
[jira] Updated: (AXIS2C-1305) error not set when memory allocation fails in axis2_stub_start_op_... generated code
[
https://issues.apache.org/jira/browse/AXIS2C-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick van Beem updated AXIS2C-1305:
-
Attachment: mem-error.diff
error not set when memory allocation fails in axis2_stub_start_op_...
generated code
Key: AXIS2C-1305
URL: https://issues.apache.org/jira/browse/AXIS2C-1305
Project: Axis2-C
Issue Type: Bug
Components: code generation
Affects Versions: Current (Nightly)
Environment: Win
Reporter: Patrick van Beem
Priority: Minor
Fix For: Current (Nightly)
Attachments: mem-error.diff
Original Estimate: 2h
Remaining Estimate: 2h
In the axis2_stub_start_op_... generated code, the error fields are not set
when memory allocation fails. The using code will assume the call succeeded
because no error is set, while it actually failed (although out-of-mem is
hopefully a rare situation).
See example code from the calculator example:
void AXIS2_CALL
axis2_stub_start_op_Calculator_add( axis2_stub_t *stub, const
axutil_env_t *env,
:
:
callback_data = (struct axis2_stub_Calculator_add_callback_data*)
AXIS2_MALLOC(env-allocator,
sizeof(struct
axis2_stub_Calculator_add_callback_data));
if(NULL == callback_data)
{
AXIS2_ERROR_SET(env-error, AXIS2_ERROR_NO_MEMORY,
AXIS2_FAILURE); // === This line was not there!
AXIS2_LOG_ERROR( env-log, AXIS2_LOG_SI, Can not allocate
memeory for the callback data structures);
return;
}
--
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]
Duplicate function in generated axis2_stubs.
In the main trunk, the C-code generator now generates the following function in the axis2_stub_xxx.c: axiom_node_t* AXIS2_CALL axis2_deserialize_buffer ( const axutil_env_t * env, char *buffer); This one is the same for every stub generated. So if you use more SOAP interfaces in one project, you get this function multiple times in one project. The linker does not like that... Possible solutions include: - Make it static, so the linker won't complain. Drawback: You will end up with multiple copies of the same function. (Intelligent linkers might remove these duplicates when optimizing.) - Deliver it in a separate file outside of the generation process and tell the user to include it in their project. Drawback: Less user-friendly. - Generate it in a separate file and tell the user to delete duplicates. Drawback: less user-friendly. Any other solutions? Anyone? What's preferred? -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E [EMAIL PROTECTED] I www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-1306) Duplicate function in generated axis2_stubs.
Duplicate function in generated axis2_stubs. Key: AXIS2C-1306 URL: https://issues.apache.org/jira/browse/AXIS2C-1306 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: All Reporter: Patrick van Beem Priority: Minor Fix For: Current (Nightly) In the main trunk, the C-code generator now generates the following function in the axis2_stub_xxx.c: axiom_node_t* AXIS2_CALL axis2_deserialize_buffer ( const axutil_env_t * env, char *buffer); This one is the same for every stub generated. So if you use more SOAP interfaces in one project, you get this function multiple times in one project. The linker does not like that... Possible solutions include: - Make it static, so the linker won't complain. Drawback: You will end up with multiple copies of the same function. (Intelligent linkers might remove these duplicates when optimizing.) - Deliver it in a separate file outside of the generation process and tell the user to include it in their project. Drawback: Less user-friendly. - Generate it in a separate file and tell the user to delete duplicates. Drawback: less user-friendly. Dimuthu inputed: I think this function should be moved to axiom_node functions. To something like axiom_node_t *axiom_node_create_from_buffer(const axutil_env_t *env, axis2_char_t *buffer) It will be very easy to work with in other applications also. -- 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]
[jira] Updated: (AXIS2C-1296) Better usage of const and improved calling convention consistency in generated C-code
[ https://issues.apache.org/jira/browse/AXIS2C-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick van Beem updated AXIS2C-1296: - Priority: Minor (was: Major) Better usage of const and improved calling convention consistency in generated C-code - Key: AXIS2C-1296 URL: https://issues.apache.org/jira/browse/AXIS2C-1296 Project: Axis2-C Issue Type: Improvement Components: code generation Affects Versions: Current (Nightly) Environment: Windows Reporter: Patrick van Beem Priority: Minor Fix For: Current (Nightly) Attachments: update_linkage.diff Original Estimate: 2h Remaining Estimate: 2h * In the generated C-code, const is not used for some string arguments, where one would expect this. This leads to unnecessary casts in user-code. * The calling convention of the generated C-code is different for different functions in the same file (can lead to problems with some development tools). I will attach a patch. -- 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]
[jira] Created: (AXIS2C-1296) Better usage of const and improved calling convention consistency in generated C-code
Better usage of const and improved calling convention consistency in generated C-code - Key: AXIS2C-1296 URL: https://issues.apache.org/jira/browse/AXIS2C-1296 Project: Axis2-C Issue Type: Improvement Components: code generation Affects Versions: Current (Nightly) Environment: Windows Reporter: Patrick van Beem Fix For: Current (Nightly) * In the generated C-code, const is not used for some string arguments, where one would expect this. This leads to unnecessary casts in user-code. * The calling convention of the generated C-code is different for different functions in the same file (can lead to problems with some development tools). I will attach a patch. -- 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]
[jira] Updated: (AXIS2C-1296) Better usage of const and improved calling convention consistency in generated C-code
[ https://issues.apache.org/jira/browse/AXIS2C-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick van Beem updated AXIS2C-1296: - Attachment: update_linkage.diff Better usage of const and improved calling convention consistency in generated C-code - Key: AXIS2C-1296 URL: https://issues.apache.org/jira/browse/AXIS2C-1296 Project: Axis2-C Issue Type: Improvement Components: code generation Affects Versions: Current (Nightly) Environment: Windows Reporter: Patrick van Beem Fix For: Current (Nightly) Attachments: update_linkage.diff Original Estimate: 2h Remaining Estimate: 2h * In the generated C-code, const is not used for some string arguments, where one would expect this. This leads to unnecessary casts in user-code. * The calling convention of the generated C-code is different for different functions in the same file (can lead to problems with some development tools). I will attach a patch. -- 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]
