[jira] Created: (AXIS2C-410) custom URL prefixes not allowed
custom URL prefixes not allowed --- Key: AXIS2C-410 URL: http://issues.apache.org/jira/browse/AXIS2C-410 Project: Axis2-C Issue Type: Bug Components: core/context, core/engine, util Affects Versions: 0.95 Reporter: Chris Darroch In AXIS2C-380 I mentioned that although Apache httpd and mod_axis2 allow you to customize the URL location where Web Services will be provided, in Axis2/C itself this URL prefix is hard-coded. For example, with mod_axis2 you might do, in httpd.conf: Location /my/services/here SetHandler axis2_module /Location There are several problems here. The main one is that several files in modules/core/engine call the single function in util/src/utils.c and to parse the request's URL. However, this function just scans for the hard-coded string /services -- so it's going to fail in this case because the /services in httpd's Location will match too early. If the Location is something like /foo, it won't match at all. Also, even if the Location is for /axis2/services, if the incoming request is for the URL /axis2//services//foo//bar, the extra slashes mean it won't match. The attached patch attempts to take care of all these issues by centralizing a lot of the parse code into modules/core/context/msg_ctx.c and by rewriting util/src/utils.c to use the axis2_uri_t functions. A new parameter in axis2.xml is introduced, requestURLPrefix, which the administrator should set to whatever matches their httpd Location. This still isn't ideal because really we should match against only what is in the Location directive, and if multiple Locations were defined with the axis2_module handler, they should all work. Having just a single matching parameter in axis2.xml won't fix this. But, it's a start, I think, and if someone can improve it, go for it! Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-399) memory leaks
[ http://issues.apache.org/jira/browse/AXIS2C-399?page=comments#action_12449734 ] Chris Darroch commented on AXIS2C-399: -- Just to reiterate a point, I think that if Axis2/C could be converted to the use of APR memory pools, this kind of concern about memory leakage would be significantly reduced, if not erased. I provided an initial patch here: http://marc.theaimsgroup.com/?l=axis-c-devm=116259914508051w=2 where mod_axis2 is modified to override the standard AXIS2_MALLOC() and AXIS2_FREE(). In particular, AXIS2_FREE() becomes a no-op, and AXIS2_MALLOC() allocates from an APR memory pool. During httpd configuration, the memory pool is the one that's passed to the child_init hook function -- this pool is suitable for use when creating configuration data that should persist throughout the life of a process. Then, for each request, the pool that's used is the thread-private pool for that individual request. Anything that's allocated during the request is then cleared automatically after httpd finishes serving the request. The axis2_http_server could be fairly easily modified to do a similar thing. You do need to remove any calls to AXIS2_REALLOC(); I did this in the main code but rampart and a few other places would need editing as well. The problem I've had is that after a few requests, you get a segfault. My assumption is that this must be caused by some place where the code is editing the config data structures within each request. Any such editing should either be removed -- i.e., do it during the child_init phase -- or should use the pool that was used for the original config data. This can be done by: a) Creating a thread mutex and sub-pool in child_init, using the sub-pool for all config allocations, and then storing pointers to the mutex and sub-pool in the config data structures. b) During a request, acquiring the mutex, using the config sub-pool to modify the config data structures, and releasing the mutex. Those steps ensure that the config data can be modified in a thread-safe manner during request handling. The sub-pool is required to ensure that you don't try to use the original pool passed during child_init, because at request time some other thread in a different part of httpd might be using it. You can use it in child_init safely because httpd is single-threaded at that early stage, but not if you're planning on modifying the stuff you do in child_init later on. If that can be done, then you can later simply remove all calls to AXIS2_FREE() and friends (like AXIOM_NODE_FREE_TREE() and so forth)! This has multiple advantages. First, it's much harder to accidentally free something too early and cause a segfault. If you do get a segfault, you know you must be messing with config data somewhere. Second, when dealing with the normal code path (where no errors occur), you don't have to worry about freeing everything you allocate. This is presumably the source of the memory leaks caught by valgrind, since the bug reporter's service is just a stub. Given all the code that might execute to handle a single request, and all the different normal code paths (depending on the type of request, whether MTOM or addressing or rampart or whatever is in use, etc.), that's a lot of code you otherwise have to review and verify has absolutely no leaks. Hard. Third, when dealing with error conditions, you can also simplify your code. In many functions, an error condition requires you to free all the internal structures that have been allocated so far during the function's execution. Often each subsequent error handling block has to free one additional data structure. It's easy to lose track of what needs to be freed when writing such code, especially because it's unlikely any coder would actually test each error handling block -- so they'll only execute when someone actually encounters an error, and then errors in the error handling block itself (such as memory freed too early, or twice) end up disguising the error condition! If you can just forget about freeing memory, these error handling blocks of code often become much simpler and easier to write and verify. Anyway, that's my long-winded 2 cents worth. memory leaks Key: AXIS2C-399 URL: http://issues.apache.org/jira/browse/AXIS2C-399 Project: Axis2-C Issue Type: Bug Affects Versions: Current (Nightly) Environment: linux simple http server Reporter: Marc Giger I see massive memory leaks with the Simple Axis2 HTTP Server. Because I can't test it with mod_axis2 I can only report it with the simple http server. Here are two valgrind outputs: The first one is with a shoot to the sample echo service: Started Simple Axis2 HTTP Server ... ==19904== ==19904== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 45 from 1) ==19904== malloc/free: in use at exit: 71,000 bytes in
[jira] Commented: (AXIS2C-380) mod_axis2 config issues
[ http://issues.apache.org/jira/browse/AXIS2C-380?page=comments#action_12447995 ] Chris Darroch commented on AXIS2C-380: -- Your syntax error from Apache httpd is probably because, with the patches in place, the Axis2RepoPath, Axis2LogFile, and Axis2LogLevel directives must reside *only* in the main server configuration block. They used to appear inside a Location -- but that's wrong, because that implies you can have multiple different settings for multiple different locations. The way the code is written, though, they only accept a single value for the entire server. My patch now enforces that condition. So, all you should have in a Location block is a SetHandler, and you can indeed have more than one Location, e.g.: Location /axis2 SetHandler axis2_module /Location VirtualHost ... Location /other/location SetHandler axis2_module /Location /VIrtualHost mod_axis2 config issues --- Key: AXIS2C-380 URL: http://issues.apache.org/jira/browse/AXIS2C-380 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 0.95 Reporter: Chris Darroch Assigned To: Dinesh Premalal Attachments: axis2c-380-2.patch, axis2c-380.patch The mod_axis2 Apache httpd module needs some work with regard to its configuration directives. The attached patch fixes several issues: 1) All directives now start with a common prefix Axis2 so that they don't interfere with other httpd modules' directives. For example, LogFile is too generic and might collide with another third-party module's directive name. 2) The configuation directives are changed to RSRC_CONF instead of ACCESS_CONF. Because mod_axis2 only supplies a server configuration creation function, i.e., axis2_create_svr(), and no per-directory functions, it is not really appropriate to put the configuration directives inside Directory or Location blocks, which is what ACCESS_CONF means. RSRC_CONF means that the directives should appear outside of such blocks, either in the main server configuration or in a VirtualHost. The configuration directive functions in mod_axis2 further check for GLOBAL_ONLY context, which disallows their use in VirtualHosts. This is appropriate because these directives set effectively global values (repository path, log file, log level) in the server-level axis2_config_rec_t structure. 3) The values accepted by the Axis2LogLevel directive are now in line with those used by httpd's own LogLevel directive, e.g., debug, emerg, etc. 4) The call to axiom_xml_reader_init() is moved into the child_init handler axis2_module_init() function. This is more appropriate than putting it into the server configuration creation function axis2_create_svr(), I think. Note that when httpd starts up and reads its configuration files, the configuration creation functions for each module run once for the main server configuration, and once each for every VirtualHost found in the files. Then after httpd forks and creates the main server process, the main server process runs through the configuration files again, executing the server configuration creation functions a second time (again, once for the main server configuration, and once for every VirtualHost). (The original httpd startup process exits, by the way.) What axiom_xml_reader_init() does, at least when using libxml2, is call xmlInitParser(). That call should execute once only for each process. So having it execute multiple times if there are multiple VirtualHosts really isn't necessary. Also, you probably want it to execute once for each child process, but these processes don't run through the configuration files and simply inherit the data structures created during the second pass through the configuration files (in the main server process, which is what forks all the child processes). A better place to execute axiom_xml_reader_init() is probably in the child_init hook function. This function runs once for each child process that is started up by the main server process, and before any worker/event/other threads are created in that child process. This set of patches doesn't address the problem that mod_axis2 -- at least as far as I can tell -- is unable to return a SOAP fault message when it returns an HTTP error code such as 500 (internal server error). Instead, httpd overwrites it with whatever the user has configured using ErrorDocument. Another problem not addressed here is that if the caller supplied a well-formed URL but one which has extra slashes in it, e.g., /axis2/services//foo, then axis2_parse_request_url_for_svc_and_op() in util/src/utils.c won't detect it. Looking at the code in that function, it's also going to cause a problem if the user has configured mod_axis2
[jira] Created: (AXIS2C-384) CLONE -calls to NULL pointers in woden/src/wsdl10/part.c
CLONE -calls to NULL pointers in woden/src/wsdl10/part.c
Key: AXIS2C-384
URL: http://issues.apache.org/jira/browse/AXIS2C-384
Project: Axis2-C
Issue Type: Bug
Components: woden
Affects Versions: Current (Nightly), 0.94
Reporter: Chris Darroch
Assigned To: Dinesh Premalal
Priority: Minor
Fix For: 0.95
In woden/src/wsdl10/msg_ref.c the following code is repeated often:
if (!msg_ref)
{
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) create(env);
}
else
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) msg_ref;
woden_wsdl10_msg_ref_free_ops(msg_ref, env);
This won't actually work if msg_ref is NULL, because although create() runs OK,
the
call to woden_wsdl10_msg_ref_free_ops() then fails with a segfault.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-384) CLONE -calls to NULL pointers in woden/src/wsdl10/part.c
[
http://issues.apache.org/jira/browse/AXIS2C-384?page=comments#action_12447077 ]
Chris Darroch commented on AXIS2C-384:
--
While woden/src/wsdl10/msg_ref.c has been fixed, I see similar problems in
woden/src/wsdl10/part.c, for example:
if (!part)
{
part_impl = (woden_wsdl10_part_impl_t *) create(env);
}
else
part_impl = (woden_wsdl10_part_impl_t *) part;
woden_wsdl10_part_free_ops(part, env);
I suspect there are other places where this occurs too ... I see some in
wsdl10_desc.c, and also over in woden/src/wsdl20/desc.c, etc. Someone
will need to do a thorough seach through the code, I'm afraid. Sorry!
CLONE -calls to NULL pointers in woden/src/wsdl10/part.c
Key: AXIS2C-384
URL: http://issues.apache.org/jira/browse/AXIS2C-384
Project: Axis2-C
Issue Type: Bug
Components: woden
Affects Versions: Current (Nightly), 0.94
Reporter: Chris Darroch
Assigned To: Dinesh Premalal
Priority: Minor
Fix For: 0.95
In woden/src/wsdl10/msg_ref.c the following code is repeated often:
if (!msg_ref)
{
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) create(env);
}
else
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) msg_ref;
woden_wsdl10_msg_ref_free_ops(msg_ref, env);
This won't actually work if msg_ref is NULL, because although create() runs
OK, the
call to woden_wsdl10_msg_ref_free_ops() then fails with a segfault.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-322) calls to NULL pointers in wsdl10/msg_ref.c
[
http://issues.apache.org/jira/browse/AXIS2C-322?page=comments#action_12447079 ]
Chris Darroch commented on AXIS2C-322:
--
I'm not sure this is completely fixed. First, see AXIS2C-384 about similar
problems elsewhere in woden. Second, if I read the new code right, it
will return NULL in the case where msg_ref is NULL on input, because
it never assigns the value of msg_ref_impl that's created by create(env)
back to msg_ref ... but then it returns msg_ref, which will just be NULL.
Maybe I'm wrong; I haven't tested it.
calls to NULL pointers in wsdl10/msg_ref.c
--
Key: AXIS2C-322
URL: http://issues.apache.org/jira/browse/AXIS2C-322
Project: Axis2-C
Issue Type: Bug
Components: woden
Affects Versions: Current (Nightly), 0.94
Reporter: Chris Darroch
Assigned To: Dinesh Premalal
Priority: Minor
Fix For: 0.95
In woden/src/wsdl10/msg_ref.c the following code is repeated often:
if (!msg_ref)
{
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) create(env);
}
else
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) msg_ref;
woden_wsdl10_msg_ref_free_ops(msg_ref, env);
This won't actually work if msg_ref is NULL, because although create() runs
OK, the
call to woden_wsdl10_msg_ref_free_ops() then fails with a segfault.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-384) CLONE -calls to NULL pointers in woden/src/wsdl10/part.c
[
http://issues.apache.org/jira/browse/AXIS2C-384?page=comments#action_12447080 ]
Chris Darroch commented on AXIS2C-384:
--
I'm also not sure that this is completely fixed in msg_ref.c, as per AXIS2C-322.
If I read the new code there right, it will return NULL in the case where
msg_ref is NULL on input, because it never assigns the value of msg_ref_impl
that's created by create(env) back to msg_ref ... but then it returns msg_ref,
which will just be NULL.
Maybe I'm wrong; I haven't tested it.
CLONE -calls to NULL pointers in woden/src/wsdl10/part.c
Key: AXIS2C-384
URL: http://issues.apache.org/jira/browse/AXIS2C-384
Project: Axis2-C
Issue Type: Bug
Components: woden
Affects Versions: Current (Nightly), 0.94
Reporter: Chris Darroch
Assigned To: Dinesh Premalal
Priority: Minor
Fix For: 0.95
In woden/src/wsdl10/msg_ref.c the following code is repeated often:
if (!msg_ref)
{
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) create(env);
}
else
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) msg_ref;
woden_wsdl10_msg_ref_free_ops(msg_ref, env);
This won't actually work if msg_ref is NULL, because although create() runs
OK, the
call to woden_wsdl10_msg_ref_free_ops() then fails with a segfault.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-328) unable to return custom SOAP faults
[
http://issues.apache.org/jira/browse/AXIS2C-328?page=comments#action_12446664 ]
Chris Darroch commented on AXIS2C-328:
--
See the most recent set of patches I'm attching now to AXIS2C-380. These
enable SOAP faults to be returned properly in httpd+mod_axis2 as well as the
axis2_http_server.
The key changes are:
1) apache2_worker.c needs to set request-status to
HTTP_INTERNAL_SERVER_ERROR but return OK; otherwise httpd
will supply its own ErrorDocument reponse.
2) engine.c and raw_xml_in_out_msg_recv.c both need to create SOAP
faults in a better manner, using appropriate XML namespace prefixes and
fault code strings.
3) raw_xml_in_out_msg_recv.c needs to return AXIS2_SUCCESS in the case
where it's generated a correct SOAP fault reponse, as noted in the initial bug
report.
4) disp_checker.c needs to set the error code to
AXIS2_ERROR_SVC_OR_OP_NOT_FOUND when handling those
conditions.
unable to return custom SOAP faults
---
Key: AXIS2C-328
URL: http://issues.apache.org/jira/browse/AXIS2C-328
Project: Axis2-C
Issue Type: Bug
Components: core/receivers, code generation, wsdl2c tool
Affects Versions: Current (Nightly), 0.93
Reporter: Chris Darroch
Thanks, BTW, for the tcpmon tool -- very helpful!
I have a need to return custom SOAP fault messages from an Axis2/C server.
This turns out to require some patches in a few places. First, the code
generated by the w2c tool always calls a local on_fault handler, named
axis2_svc_skel_foo_on_fault() in the axis2_svc_skel_foo.c file. This
function, as generated by w2c, creates a fault element and returns it in
the SOAP body.
Changing axis2_svc_skel_foo_on_fault() to simply return NULL instead allows
the
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync() function in
modules/core/receivers/raw_xml_in_out_msg_recv.c to recognize that no body
element
has been returned, and create a SOAP fault instead.
The actual business logic that one fills into the axis2_skel_foo.c file can
then simply
do the following:
axis2_skel_foo_Foo(...) {
AXIS2_ERROR_SET_STATUS_CODE(env-error, AXIS2_FAILURE);
AXIS2_ERROR_SET_ERROR_NUMBER(env-error,
AXIS2_ERROR_FOO);
return NULL;
}
This almost works, and
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync()
now recognizes the fault condition and calls
axiom_soap_fault_create_default_fault()
to create the SOAP fault element. Good, except that it then returns
AXIS2_FAILURE,
so that its caller, axis2_raw_xml_in_out_msg_recv_receive_sync() in
modules/core/receivers/msg_recv.c, then does this:
status = AXIS2_MSG_RECV_INVOKE_IN_OUT_BUSINESS_LOGIC_SYNC(msg_recv, env,
msg_ctx, out_msg_ctx);
if(AXIS2_SUCCESS != status)
{
axis2_core_utils_reset_out_msg_ctx(env, out_msg_ctx);
AXIS2_MSG_CTX_FREE(out_msg_ctx, env);
return status;
}
which destroys the nice SOAP fault and returns an empty body element instead
to the client!
My current patch is to have
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync() return
AXIS2C_SUCCESS instead -- this makes sense to me, because although an fault
condition has been detected, the function has successfully handled it by
creating
the SOAP fault element. Here's the patch:
--- modules/core/receivers/raw_xml_in_out_msg_recv.c.orig 2006-10-07
13:31:17.801951262 -0400
+++ modules/core/receivers/raw_xml_in_out_msg_recv.c2006-10-07
13:31:36.094847670 -0400
@@ -325,7 +325,7 @@
else if (soap_fault)
{
AXIS2_MSG_CTX_SET_SOAP_ENVELOPE(new_msg_ctx, env, default_envelope);
-status = AXIS2_FAILURE; /* if there is a failure we have to return a
failure code */
+status = AXIS2_SUCCESS;
}
else
{
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-380) mod_axis2 config issues
[ http://issues.apache.org/jira/browse/AXIS2C-380?page=all ] Chris Darroch updated AXIS2C-380: - Attachment: axis2c-380-2.patch This is an updated set of patches that addresses the SOAP fault issue (see AXIS2C-328) and also cleans up the logging in the child_init hook handler. It also performs axis2_error_init() in the child_init handler so that the error message array is populated, otherwise all error messages are just empty strings! I haven't addressed the issue of the URL paths yet; I'll put that in a separate patch to util/src/utils.c. Finally, I've experimented with using APR memory pools instead of normal Axis2/C malloc()/free(). This would be nice because it would ensure that after each HTTP request, Apache fully cleaned up all the memory used by the request. I've had partial success but have run into segfaults that seem to be caused by svc_ctx data that gets created during one request and which is then expected to still be allocated during another request. If I get some time I'll go back and revisit this. This would be a thing to get working because otherwise I suspect that relying on the whole stack of Axis2/C code to properly free() all resources isn't going to work very well, and you'll gradually see mod_axis2 sucking up memory. Let me know if you want to see the patches I've had partial success with. mod_axis2 config issues --- Key: AXIS2C-380 URL: http://issues.apache.org/jira/browse/AXIS2C-380 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 0.95 Reporter: Chris Darroch Attachments: axis2c-380-2.patch, axis2c-380.patch The mod_axis2 Apache httpd module needs some work with regard to its configuration directives. The attached patch fixes several issues: 1) All directives now start with a common prefix Axis2 so that they don't interfere with other httpd modules' directives. For example, LogFile is too generic and might collide with another third-party module's directive name. 2) The configuation directives are changed to RSRC_CONF instead of ACCESS_CONF. Because mod_axis2 only supplies a server configuration creation function, i.e., axis2_create_svr(), and no per-directory functions, it is not really appropriate to put the configuration directives inside Directory or Location blocks, which is what ACCESS_CONF means. RSRC_CONF means that the directives should appear outside of such blocks, either in the main server configuration or in a VirtualHost. The configuration directive functions in mod_axis2 further check for GLOBAL_ONLY context, which disallows their use in VirtualHosts. This is appropriate because these directives set effectively global values (repository path, log file, log level) in the server-level axis2_config_rec_t structure. 3) The values accepted by the Axis2LogLevel directive are now in line with those used by httpd's own LogLevel directive, e.g., debug, emerg, etc. 4) The call to axiom_xml_reader_init() is moved into the child_init handler axis2_module_init() function. This is more appropriate than putting it into the server configuration creation function axis2_create_svr(), I think. Note that when httpd starts up and reads its configuration files, the configuration creation functions for each module run once for the main server configuration, and once each for every VirtualHost found in the files. Then after httpd forks and creates the main server process, the main server process runs through the configuration files again, executing the server configuration creation functions a second time (again, once for the main server configuration, and once for every VirtualHost). (The original httpd startup process exits, by the way.) What axiom_xml_reader_init() does, at least when using libxml2, is call xmlInitParser(). That call should execute once only for each process. So having it execute multiple times if there are multiple VirtualHosts really isn't necessary. Also, you probably want it to execute once for each child process, but these processes don't run through the configuration files and simply inherit the data structures created during the second pass through the configuration files (in the main server process, which is what forks all the child processes). A better place to execute axiom_xml_reader_init() is probably in the child_init hook function. This function runs once for each child process that is started up by the main server process, and before any worker/event/other threads are created in that child process. This set of patches doesn't address the problem that mod_axis2 -- at least as far as I can tell -- is unable to return a SOAP fault message when it returns an HTTP error code such as 500 (internal server error). Instead, httpd overwrites it with whatever
[jira] Commented: (AXIS2C-381) Simple Axis Server doesn't give proper faults
[ http://issues.apache.org/jira/browse/AXIS2C-381?page=comments#action_12446347 ] Chris Darroch commented on AXIS2C-381: -- I think this is partially related to AXIS2C-328. There's a patch in that bug report that helps me a bit to return custom SOAP faults, and I'm working on a set of patches that do the same thing for mod_axis2. As of 0.95, it seems that there's a new factor in the code that handles operation and service not found situations and I'm looking now to see what's changed; it seems to be somewhere around disp_checker.c. Simple Axis Server doesn't give proper faults - Key: AXIS2C-381 URL: http://issues.apache.org/jira/browse/AXIS2C-381 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 0.95 Reporter: Dinesh Premalal When I try to send improper content to echo service. simple axis server didn't give any fault message... request POST /axis/services/echo HTTP/1.1 User-Agent: Axis2/C Content-Length: 238 Content-Type: application/soap+xml;charset=UTF-8; Host: 127.0.0.1 ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header/soapenv:Header soapenv:Body root aa/a bb/b c dd/d /c /root /soapenv:Body /soapenv:Envelope response --- HTTP/1.1 500 Internal Server Error Content-Type: application/soap+xml;charset=UTF-8 Content-Length: 194 ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header/soapenv:Header soapenv:Body/soapenv:Body /soapenv:Envelope -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-380) mod_axis2 config issues
mod_axis2 config issues --- Key: AXIS2C-380 URL: http://issues.apache.org/jira/browse/AXIS2C-380 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 0.95 Reporter: Chris Darroch The mod_axis2 Apache httpd module needs some work with regard to its configuration directives. The attached patch fixes several issues: 1) All directives now start with a common prefix Axis2 so that they don't interfere with other httpd modules' directives. For example, LogFile is too generic and might collide with another third-party module's directive name. 2) The configuation directives are changed to RSRC_CONF instead of ACCESS_CONF. Because mod_axis2 only supplies a server configuration creation function, i.e., axis2_create_svr(), and no per-directory functions, it is not really appropriate to put the configuration directives inside Directory or Location blocks, which is what ACCESS_CONF means. RSRC_CONF means that the directives should appear outside of such blocks, either in the main server configuration or in a VirtualHost. The configuration directive functions in mod_axis2 further check for GLOBAL_ONLY context, which disallows their use in VirtualHosts. This is appropriate because these directives set effectively global values (repository path, log file, log level) in the server-level axis2_config_rec_t structure. 3) The values accepted by the Axis2LogLevel directive are now in line with those used by httpd's own LogLevel directive, e.g., debug, emerg, etc. 4) The call to axiom_xml_reader_init() is moved into the child_init handler axis2_module_init() function. This is more appropriate than putting it into the server configuration creation function axis2_create_svr(), I think. Note that when httpd starts up and reads its configuration files, the configuration creation functions for each module run once for the main server configuration, and once each for every VirtualHost found in the files. Then after httpd forks and creates the main server process, the main server process runs through the configuration files again, executing the server configuration creation functions a second time (again, once for the main server configuration, and once for every VirtualHost). (The original httpd startup process exits, by the way.) What axiom_xml_reader_init() does, at least when using libxml2, is call xmlInitParser(). That call should execute once only for each process. So having it execute multiple times if there are multiple VirtualHosts really isn't necessary. Also, you probably want it to execute once for each child process, but these processes don't run through the configuration files and simply inherit the data structures created during the second pass through the configuration files (in the main server process, which is what forks all the child processes). A better place to execute axiom_xml_reader_init() is probably in the child_init hook function. This function runs once for each child process that is started up by the main server process, and before any worker/event/other threads are created in that child process. This set of patches doesn't address the problem that mod_axis2 -- at least as far as I can tell -- is unable to return a SOAP fault message when it returns an HTTP error code such as 500 (internal server error). Instead, httpd overwrites it with whatever the user has configured using ErrorDocument. Another problem not addressed here is that if the caller supplied a well-formed URL but one which has extra slashes in it, e.g., /axis2/services//foo, then axis2_parse_request_url_for_svc_and_op() in util/src/utils.c won't detect it. Looking at the code in that function, it's also going to cause a problem if the user has configured mod_axis2 within a Location that has the string services/ in it, e.g.: Location /myapp/web-services SetHandler axis2_module /Location I'll try to address these in some other patches, but the SOAP fault one takes precedence for me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-380) mod_axis2 config issues
[ http://issues.apache.org/jira/browse/AXIS2C-380?page=all ] Chris Darroch updated AXIS2C-380: - Attachment: axis2c-380.patch mod_axis2 config issues --- Key: AXIS2C-380 URL: http://issues.apache.org/jira/browse/AXIS2C-380 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: 0.95 Reporter: Chris Darroch Attachments: axis2c-380.patch The mod_axis2 Apache httpd module needs some work with regard to its configuration directives. The attached patch fixes several issues: 1) All directives now start with a common prefix Axis2 so that they don't interfere with other httpd modules' directives. For example, LogFile is too generic and might collide with another third-party module's directive name. 2) The configuation directives are changed to RSRC_CONF instead of ACCESS_CONF. Because mod_axis2 only supplies a server configuration creation function, i.e., axis2_create_svr(), and no per-directory functions, it is not really appropriate to put the configuration directives inside Directory or Location blocks, which is what ACCESS_CONF means. RSRC_CONF means that the directives should appear outside of such blocks, either in the main server configuration or in a VirtualHost. The configuration directive functions in mod_axis2 further check for GLOBAL_ONLY context, which disallows their use in VirtualHosts. This is appropriate because these directives set effectively global values (repository path, log file, log level) in the server-level axis2_config_rec_t structure. 3) The values accepted by the Axis2LogLevel directive are now in line with those used by httpd's own LogLevel directive, e.g., debug, emerg, etc. 4) The call to axiom_xml_reader_init() is moved into the child_init handler axis2_module_init() function. This is more appropriate than putting it into the server configuration creation function axis2_create_svr(), I think. Note that when httpd starts up and reads its configuration files, the configuration creation functions for each module run once for the main server configuration, and once each for every VirtualHost found in the files. Then after httpd forks and creates the main server process, the main server process runs through the configuration files again, executing the server configuration creation functions a second time (again, once for the main server configuration, and once for every VirtualHost). (The original httpd startup process exits, by the way.) What axiom_xml_reader_init() does, at least when using libxml2, is call xmlInitParser(). That call should execute once only for each process. So having it execute multiple times if there are multiple VirtualHosts really isn't necessary. Also, you probably want it to execute once for each child process, but these processes don't run through the configuration files and simply inherit the data structures created during the second pass through the configuration files (in the main server process, which is what forks all the child processes). A better place to execute axiom_xml_reader_init() is probably in the child_init hook function. This function runs once for each child process that is started up by the main server process, and before any worker/event/other threads are created in that child process. This set of patches doesn't address the problem that mod_axis2 -- at least as far as I can tell -- is unable to return a SOAP fault message when it returns an HTTP error code such as 500 (internal server error). Instead, httpd overwrites it with whatever the user has configured using ErrorDocument. Another problem not addressed here is that if the caller supplied a well-formed URL but one which has extra slashes in it, e.g., /axis2/services//foo, then axis2_parse_request_url_for_svc_and_op() in util/src/utils.c won't detect it. Looking at the code in that function, it's also going to cause a problem if the user has configured mod_axis2 within a Location that has the string services/ in it, e.g.: Location /myapp/web-services SetHandler axis2_module /Location I'll try to address these in some other patches, but the SOAP fault one takes precedence for me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-379) CLONE -LDFLAGS overridden by configure
CLONE -LDFLAGS overridden by configure -- Key: AXIS2C-379 URL: http://issues.apache.org/jira/browse/AXIS2C-379 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux) Affects Versions: 0.94 Reporter: Chris Darroch Assigned To: Sanjaya Ratnaweera The configure.ac files contain the following line: LDFLAGS=-lpthread This has the effect of overriding any input LDFLAGS that the user specifies. The configure script's --help option says you can set CFLAGS, LDFLAGS, etc. prior to running ./configure: ./configure --help ... Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -Llib dir if you have libraries in a nonstandard directory lib dir ... The line should probably be LDFLAGS=$LDFLAGS -lpthread in all of the configure.ac files (configure, woden/configure, etc.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-379) CLONE -LDFLAGS overridden by configure
[ http://issues.apache.org/jira/browse/AXIS2C-379?page=comments#action_12445326 ] Chris Darroch commented on AXIS2C-379: -- The woden/configure and xml_schema/configure files still need the fix. Thanks! CLONE -LDFLAGS overridden by configure -- Key: AXIS2C-379 URL: http://issues.apache.org/jira/browse/AXIS2C-379 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux) Affects Versions: 0.94 Reporter: Chris Darroch Assigned To: Sanjaya Ratnaweera The configure.ac files contain the following line: LDFLAGS=-lpthread This has the effect of overriding any input LDFLAGS that the user specifies. The configure script's --help option says you can set CFLAGS, LDFLAGS, etc. prior to running ./configure: ./configure --help ... Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -Llib dir if you have libraries in a nonstandard directory lib dir ... The line should probably be LDFLAGS=$LDFLAGS -lpthread in all of the configure.ac files (configure, woden/configure, etc.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-376) --enable-tests and make check has multiple errors
--enable-tests and make check has multiple errors --- Key: AXIS2C-376 URL: http://issues.apache.org/jira/browse/AXIS2C-376 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux) Affects Versions: 0.94 Environment: Unix/Linux, maybe others Reporter: Chris Darroch Priority: Minor Normally, when using a package built with autoconf, one can expect to do: ./configure --enable-tests make check For Axis2/C this runs into a variety of problems. I noted a few of these issues in AXIS2C-313 as well, but this is a more detailed summary of the problems I've seen. Specifically: 1) The libcutest library is required, but it's a non-standard library, and isn't even installed as part of the CuTest package -- it has to be built by hand. 2) A number of the test programs have errors; for example, they free their env variable early and then segfault, or report a failure when none has occurred. 3) Test resource files are referenced that aren't supplied in the package, for example, Calculator.wsdl. 4) Some of the tests require that AXIS2C_HOME be set and that a valid axis2.xml file exist. 5) If --enable-tests is used for ./configure, then when make install runs in the test directories, it installs various programs and libraries in directories named itest, unit_test, and system_test under the specified --prefix. Even if these programs should be installed (which is arguable), they should be installed under the --bindir and --libdir locations, not --prefix. In my case, we try to make running make check a standard part of our global package installation framework, which is automated. I'll attach as files (if I can) the various patches we make to the Axis2/C test framework to deal with problems #2, #3, #4 and #5. To deal with problem #3 we also unpack the following resources, which I hunted around for on svn.apache.org: https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ into xml_schema https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl/ into woden/test To deal with problem #4, we patch samples/server/axis2.xml to not engage the addressing module, and then point AXIS2C_HOME to samples/server in our build directory before running make check. That allows the tests to run without having already done a make install -- since our installation framework won't install the package until it's seen a successful make check run! Finally, to deal with problem #1, we build and install libcutest prior to building, testing, and installing Axis2/C, using the CuTest package and the trick found in this axis-c-dev mailing list posting: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile In general, though, all these tricks shouldn't be necessary. A user should be able to download the axis2c package, run ./configure --enable-tests and make check with no special knowledge, I believe. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-376) --enable-tests and make check has multiple errors
[ http://issues.apache.org/jira/browse/AXIS2C-376?page=all ] Chris Darroch updated AXIS2C-376: - Attachment: axis2c-376.patch This is a set of patches to the test suites in the 0.94 release, along with the samples/server/axis2.xml file, that assist in allowing make check to run to completion successfully. Note that woden/test/main.c is patched to remove the call to getchar() so that the test suite doesn't require the user to type something on the command line before proceeding to the next test. --enable-tests and make check has multiple errors --- Key: AXIS2C-376 URL: http://issues.apache.org/jira/browse/AXIS2C-376 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux) Affects Versions: 0.94 Environment: Unix/Linux, maybe others Reporter: Chris Darroch Priority: Minor Attachments: axis2c-376.patch Normally, when using a package built with autoconf, one can expect to do: ./configure --enable-tests make check For Axis2/C this runs into a variety of problems. I noted a few of these issues in AXIS2C-313 as well, but this is a more detailed summary of the problems I've seen. Specifically: 1) The libcutest library is required, but it's a non-standard library, and isn't even installed as part of the CuTest package -- it has to be built by hand. 2) A number of the test programs have errors; for example, they free their env variable early and then segfault, or report a failure when none has occurred. 3) Test resource files are referenced that aren't supplied in the package, for example, Calculator.wsdl. 4) Some of the tests require that AXIS2C_HOME be set and that a valid axis2.xml file exist. 5) If --enable-tests is used for ./configure, then when make install runs in the test directories, it installs various programs and libraries in directories named itest, unit_test, and system_test under the specified --prefix. Even if these programs should be installed (which is arguable), they should be installed under the --bindir and --libdir locations, not --prefix. In my case, we try to make running make check a standard part of our global package installation framework, which is automated. I'll attach as files (if I can) the various patches we make to the Axis2/C test framework to deal with problems #2, #3, #4 and #5. To deal with problem #3 we also unpack the following resources, which I hunted around for on svn.apache.org: https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ into xml_schema https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl/ into woden/test To deal with problem #4, we patch samples/server/axis2.xml to not engage the addressing module, and then point AXIS2C_HOME to samples/server in our build directory before running make check. That allows the tests to run without having already done a make install -- since our installation framework won't install the package until it's seen a successful make check run! Finally, to deal with problem #1, we build and install libcutest prior to building, testing, and installing Axis2/C, using the CuTest package and the trick found in this axis-c-dev mailing list posting: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile In general, though, all these tricks shouldn't be necessary. A user should be able to download the axis2c package, run ./configure --enable-tests and make check with no special knowledge, I believe. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-312) remove fixed paths from code
[ http://issues.apache.org/jira/browse/AXIS2C-312?page=comments#action_12444754 ] Chris Darroch commented on AXIS2C-312: -- I'm attaching one possible set of changes to fix the $AXIS2C_HOME/lib requirement. A configuration file parameter named libraryDir contains the path to the libraries. The configure.ac build script is changed slightly so that samples/server/axis2.xml.in is parsed by configure and the @libdir@ value interpolated into place, so that the axis2.xml file is then ready for installation. This is just one possible patch, of course; one could also interpolate @libdir@ right into the modules/core/deployment C files; or do something fancier so that the library loading code in util/src/class_loader.c didn't require an input path but instead looked in the locations specified by the ld system (e.g., LD_LIBRARY_PATH). That might be best of all, really. remove fixed paths from code Key: AXIS2C-312 URL: http://issues.apache.org/jira/browse/AXIS2C-312 Project: Axis2-C Issue Type: Bug Components: core/deployment, build system (Unix/Linux) Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch Assigned To: Sanjaya Ratnaweera As per this thread on the user mailing list, I've found that one can't actually use the --libdir, --includedir, etc. options to the autoconf configure program: http://marc.theaimsgroup.com/?l=axis-c-userm=115956538314942w=2 Here's the crux of the problem: hard-coded paths. While I appreciate that these are easier to write than a fully-configurable package, the documentation in the INSTALL file and the use of autoconf implies that one can customize the installation. For example, the INSTALL file says: Please run './configure --help' in samples folder for more information on configure options. As it happens, when I discovered that the package was going to install about 15 libraries and 375 header files, I purposefully used the standard autoconf configure options to put these in subdirectories: ./configure --prefix=$(INSTALL_PATH) --enable-tests \ --bindir=$(INSTALL_PATH)/bin/axis2 \ --includedir=$(INSTALL_PATH)/include/axis2 \ --libdir=$(INSTALL_PATH)/lib/axis2 \ With the appropriate CFLAGS and LDFLAGS and a little Makefile tuning, this all compiles OK and installs OK. It's also a fairly standard Apache way of doing things -- the APR and httpd projects use the apr-majorversion and apache2 subdirectories, for example, to keep their headers and libraries from polluting the user's --includedir location. Alas, in axis2_conf_builder_process_transport_senders(), we have this code: repos_name = AXIS2_DEP_ENGINE_GET_REPOS_PATH(conf_builder- desc_builder-engine, env); temp_path = AXIS2_STRACAT(repos_name, AXIS2_PATH_SEP_STR, env); temp_path2 = AXIS2_STRACAT(temp_path, AXIS2_LIB_FOLDER, env); temp_path3 = AXIS2_STRACAT(temp_path2, AXIS2_PATH_SEP_STR, env); path_qualified_dll_name = AXIS2_STRACAT(temp_path3, dll_name, env); This means that, in effect, the --libdir option to configure is useless, because the code is going to ignore whatever the specified installation locations were and go looking in the $AXIS2C_HOME/lib location regardless. What I'll do for now, I guess, is creating a symlink from $AXIS2C_HOME/lib to my $INSTALL_PATH/lib/axis2 location, and this does indeed work OK. However, it's a workaround caused by what I'd suggest is a pair of bugs. First, I'd suggest that there should be no hard-coded paths like the ones I see in modules/core/deployment/conf_builder.c, desc_builder.c, and arch_reader.c. These are just the ones using AXIS2_DEP_ENGINE_GET_REPOS_PATH(); there may well be other similar functions I'm not aware of, though. Such paths should be determined from configuration parameters. For example, programs could look for axis2.xml $AXIS2C_HOME, then in a directory specified at compile time using an option to ./configure, and finally in the current directory. The axis2.xml file would then, in turn, include the paths to the directories used for logs, libraries, services, modules, etc. It would also be nice if at compile time and run time one could specify a different name for the axis2.xml file -- for example, Apache httpd accepts an -f run-time option to use a non-standard configuration file. Second, whole autoconf system for axis2c needs some work. I'll put details into a second enhancement request, but as far as this particular bug is concerned, I'd suggest that since --libdir does correctly install the libraries into a given location, it's wrong to then go looking in $AXIS2C_HOME/lib despite what the user requested. -- This message is automatically
[jira] Updated: (AXIS2C-312) remove fixed paths from code
[ http://issues.apache.org/jira/browse/AXIS2C-312?page=all ] Chris Darroch updated AXIS2C-312: - Attachment: axis2c-312.patch remove fixed paths from code Key: AXIS2C-312 URL: http://issues.apache.org/jira/browse/AXIS2C-312 Project: Axis2-C Issue Type: Bug Components: core/deployment, build system (Unix/Linux) Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch Assigned To: Sanjaya Ratnaweera Attachments: axis2.xml.in, axis2c-312.patch As per this thread on the user mailing list, I've found that one can't actually use the --libdir, --includedir, etc. options to the autoconf configure program: http://marc.theaimsgroup.com/?l=axis-c-userm=115956538314942w=2 Here's the crux of the problem: hard-coded paths. While I appreciate that these are easier to write than a fully-configurable package, the documentation in the INSTALL file and the use of autoconf implies that one can customize the installation. For example, the INSTALL file says: Please run './configure --help' in samples folder for more information on configure options. As it happens, when I discovered that the package was going to install about 15 libraries and 375 header files, I purposefully used the standard autoconf configure options to put these in subdirectories: ./configure --prefix=$(INSTALL_PATH) --enable-tests \ --bindir=$(INSTALL_PATH)/bin/axis2 \ --includedir=$(INSTALL_PATH)/include/axis2 \ --libdir=$(INSTALL_PATH)/lib/axis2 \ With the appropriate CFLAGS and LDFLAGS and a little Makefile tuning, this all compiles OK and installs OK. It's also a fairly standard Apache way of doing things -- the APR and httpd projects use the apr-majorversion and apache2 subdirectories, for example, to keep their headers and libraries from polluting the user's --includedir location. Alas, in axis2_conf_builder_process_transport_senders(), we have this code: repos_name = AXIS2_DEP_ENGINE_GET_REPOS_PATH(conf_builder- desc_builder-engine, env); temp_path = AXIS2_STRACAT(repos_name, AXIS2_PATH_SEP_STR, env); temp_path2 = AXIS2_STRACAT(temp_path, AXIS2_LIB_FOLDER, env); temp_path3 = AXIS2_STRACAT(temp_path2, AXIS2_PATH_SEP_STR, env); path_qualified_dll_name = AXIS2_STRACAT(temp_path3, dll_name, env); This means that, in effect, the --libdir option to configure is useless, because the code is going to ignore whatever the specified installation locations were and go looking in the $AXIS2C_HOME/lib location regardless. What I'll do for now, I guess, is creating a symlink from $AXIS2C_HOME/lib to my $INSTALL_PATH/lib/axis2 location, and this does indeed work OK. However, it's a workaround caused by what I'd suggest is a pair of bugs. First, I'd suggest that there should be no hard-coded paths like the ones I see in modules/core/deployment/conf_builder.c, desc_builder.c, and arch_reader.c. These are just the ones using AXIS2_DEP_ENGINE_GET_REPOS_PATH(); there may well be other similar functions I'm not aware of, though. Such paths should be determined from configuration parameters. For example, programs could look for axis2.xml $AXIS2C_HOME, then in a directory specified at compile time using an option to ./configure, and finally in the current directory. The axis2.xml file would then, in turn, include the paths to the directories used for logs, libraries, services, modules, etc. It would also be nice if at compile time and run time one could specify a different name for the axis2.xml file -- for example, Apache httpd accepts an -f run-time option to use a non-standard configuration file. Second, whole autoconf system for axis2c needs some work. I'll put details into a second enhancement request, but as far as this particular bug is concerned, I'd suggest that since --libdir does correctly install the libraries into a given location, it's wrong to then go looking in $AXIS2C_HOME/lib despite what the user requested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-312) remove fixed paths from code
[ http://issues.apache.org/jira/browse/AXIS2C-312?page=all ] Chris Darroch updated AXIS2C-312: - Attachment: axis2.xml.in remove fixed paths from code Key: AXIS2C-312 URL: http://issues.apache.org/jira/browse/AXIS2C-312 Project: Axis2-C Issue Type: Bug Components: core/deployment, build system (Unix/Linux) Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch Assigned To: Sanjaya Ratnaweera Attachments: axis2.xml.in, axis2c-312.patch As per this thread on the user mailing list, I've found that one can't actually use the --libdir, --includedir, etc. options to the autoconf configure program: http://marc.theaimsgroup.com/?l=axis-c-userm=115956538314942w=2 Here's the crux of the problem: hard-coded paths. While I appreciate that these are easier to write than a fully-configurable package, the documentation in the INSTALL file and the use of autoconf implies that one can customize the installation. For example, the INSTALL file says: Please run './configure --help' in samples folder for more information on configure options. As it happens, when I discovered that the package was going to install about 15 libraries and 375 header files, I purposefully used the standard autoconf configure options to put these in subdirectories: ./configure --prefix=$(INSTALL_PATH) --enable-tests \ --bindir=$(INSTALL_PATH)/bin/axis2 \ --includedir=$(INSTALL_PATH)/include/axis2 \ --libdir=$(INSTALL_PATH)/lib/axis2 \ With the appropriate CFLAGS and LDFLAGS and a little Makefile tuning, this all compiles OK and installs OK. It's also a fairly standard Apache way of doing things -- the APR and httpd projects use the apr-majorversion and apache2 subdirectories, for example, to keep their headers and libraries from polluting the user's --includedir location. Alas, in axis2_conf_builder_process_transport_senders(), we have this code: repos_name = AXIS2_DEP_ENGINE_GET_REPOS_PATH(conf_builder- desc_builder-engine, env); temp_path = AXIS2_STRACAT(repos_name, AXIS2_PATH_SEP_STR, env); temp_path2 = AXIS2_STRACAT(temp_path, AXIS2_LIB_FOLDER, env); temp_path3 = AXIS2_STRACAT(temp_path2, AXIS2_PATH_SEP_STR, env); path_qualified_dll_name = AXIS2_STRACAT(temp_path3, dll_name, env); This means that, in effect, the --libdir option to configure is useless, because the code is going to ignore whatever the specified installation locations were and go looking in the $AXIS2C_HOME/lib location regardless. What I'll do for now, I guess, is creating a symlink from $AXIS2C_HOME/lib to my $INSTALL_PATH/lib/axis2 location, and this does indeed work OK. However, it's a workaround caused by what I'd suggest is a pair of bugs. First, I'd suggest that there should be no hard-coded paths like the ones I see in modules/core/deployment/conf_builder.c, desc_builder.c, and arch_reader.c. These are just the ones using AXIS2_DEP_ENGINE_GET_REPOS_PATH(); there may well be other similar functions I'm not aware of, though. Such paths should be determined from configuration parameters. For example, programs could look for axis2.xml $AXIS2C_HOME, then in a directory specified at compile time using an option to ./configure, and finally in the current directory. The axis2.xml file would then, in turn, include the paths to the directories used for logs, libraries, services, modules, etc. It would also be nice if at compile time and run time one could specify a different name for the axis2.xml file -- for example, Apache httpd accepts an -f run-time option to use a non-standard configuration file. Second, whole autoconf system for axis2c needs some work. I'll put details into a second enhancement request, but as far as this particular bug is concerned, I'd suggest that since --libdir does correctly install the libraries into a given location, it's wrong to then go looking in $AXIS2C_HOME/lib despite what the user requested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-376) --enable-tests and make check has multiple errors
[ http://issues.apache.org/jira/browse/AXIS2C-376?page=all ] Chris Darroch updated AXIS2C-376: - Attachment: axis2c-376.patch More files which prevent all the test libraries and binaries from getting installed. --enable-tests and make check has multiple errors --- Key: AXIS2C-376 URL: http://issues.apache.org/jira/browse/AXIS2C-376 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux) Affects Versions: 0.94 Environment: Unix/Linux, maybe others Reporter: Chris Darroch Priority: Minor Attachments: axis2c-376.patch, axis2c-376.patch Normally, when using a package built with autoconf, one can expect to do: ./configure --enable-tests make check For Axis2/C this runs into a variety of problems. I noted a few of these issues in AXIS2C-313 as well, but this is a more detailed summary of the problems I've seen. Specifically: 1) The libcutest library is required, but it's a non-standard library, and isn't even installed as part of the CuTest package -- it has to be built by hand. 2) A number of the test programs have errors; for example, they free their env variable early and then segfault, or report a failure when none has occurred. 3) Test resource files are referenced that aren't supplied in the package, for example, Calculator.wsdl. 4) Some of the tests require that AXIS2C_HOME be set and that a valid axis2.xml file exist. 5) If --enable-tests is used for ./configure, then when make install runs in the test directories, it installs various programs and libraries in directories named itest, unit_test, and system_test under the specified --prefix. Even if these programs should be installed (which is arguable), they should be installed under the --bindir and --libdir locations, not --prefix. In my case, we try to make running make check a standard part of our global package installation framework, which is automated. I'll attach as files (if I can) the various patches we make to the Axis2/C test framework to deal with problems #2, #3, #4 and #5. To deal with problem #3 we also unpack the following resources, which I hunted around for on svn.apache.org: https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ into xml_schema https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl/ into woden/test To deal with problem #4, we patch samples/server/axis2.xml to not engage the addressing module, and then point AXIS2C_HOME to samples/server in our build directory before running make check. That allows the tests to run without having already done a make install -- since our installation framework won't install the package until it's seen a successful make check run! Finally, to deal with problem #1, we build and install libcutest prior to building, testing, and installing Axis2/C, using the CuTest package and the trick found in this axis-c-dev mailing list posting: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile In general, though, all these tricks shouldn't be necessary. A user should be able to download the axis2c package, run ./configure --enable-tests and make check with no special knowledge, I believe. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-313) improve autoconf support
[ http://issues.apache.org/jira/browse/AXIS2C-313?page=comments#action_12444760 ] Chris Darroch commented on AXIS2C-313: -- I've included some quick patches in AXIS2C-376 and AXIS2C-312 that deal with a few bits of the issues raised above. A few other quick things that could be done are in Makefile.am, change to using: docsdir=$(docdir) so that --docdir works, and in modules/core/transport/http/server/simple_axis2_server/Makefile.am: prgbindir=$(bindir) so that axis2_http_server goes in the right place. improve autoconf support Key: AXIS2C-313 URL: http://issues.apache.org/jira/browse/AXIS2C-313 Project: Axis2-C Issue Type: Improvement Components: build system (Unix/Linux) Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch Assigned To: Sanjaya Ratnaweera The autoconf system really isn't being used effectively for the axis2c package. First, as noted in another bug report, some of the code searches for libraries in $AXIS2C_HOME/lib regardless of what is specified by the user when using the --libdir configure option. Second, it would be better if include files were installed in, say, $includedir/axis2, the way the APR project installs them in $includedir/apr-$majorversion and httpd installs them in $includedir/apache2. Given that 375 files are installed, this is otherwise a major source of pollution in a common location. Third, if one uses --libdir, --includedir, and --bindir, then each successive installation of an axis2c sub-project (like xml_schema or woden) and the main axis2c installation itself should use these locations to search for dependencies. As it is, the util sub-project installs quite neatly, but then all the others require patches to their Makefiles and/or specific CFLAGS and LDFLAGS settings so that they can locate the previous sub-projects' headers and libraries. This really shouldn't be necessary; they should look in --libdir and --includedir automatically. Fourth, the various test suites that run when make check is used fail in a wide variety of ways. Many of the test suites depend on libcutest.a -- but this isn't something the CuTest package provides! Instead, you have to dig out a posting to the mailing list: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile (An alternative would be the derived version that the APR test suite uses.) Other tests depend on data files that aren't in the distribution; for example, the xml_schema tests seem to require the files from https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ in a resources directory. The woden tests require a Calculator.wsdl file that I found in https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl, but it required that the xmlns:wsdl=http://schemas.xmlsoap.org/wsdl; attribute *not* have a trailing slash and WODEN_WSDL10_DESC_GET_INTERFACES() be used. The util/test/util/test_util.c file calls run_test_string(env) after freeing the env variable, producing a segfault. And so forth. Fifth, while I realize this would be a pain, it would be really superb if one could control the layout of the $AXIS2C_HOME location using the kinds of options provided by the config.layout file in the httpd package. More, instead of requiring directories under $AXIS2C_HOME named logs, services, modules, and so forth, and requiring that the libraries in the services and modules directories be accompanied by XML files, it would be great if you could ask for a layout like this: $prefix = $MY_INSTALL_DIR $bindir = $prefix/bin (by default, use --bindir to change) $includedir = $prefix/include/axis2 (by default, use --includedir to change) $libdir = $prefix/lib/axis2 (by default, use --libdir to change) $sysconfdir = $prefix/etc/axis2 (by default, use --sysconfdir to change) $localstatedir = $prefix (by default, use --localstatedir to change) $logfiledir = $localstatedir/logs (by default, use config.layout or axis2.xml to change) $servicesdir = $libdir/services (by default, use config.layout or axis2.xml to change) $modulesdir = $libdir/modules (by default, use config.layout or axis2.xml to change) The axis2.xml file would be expected to reside in $sysconfdir. There would be runtime options (like httpd's -f option) that would allow the user to point to another non-standard file, though. This file would could then contain logsDir, servicesDir, modulesDir to point to non-standard directories for those things, if the user wanted a different layout. Among other things, this kind of framework allows for easy switching between different versions of the same services and modules for testing purposes. Sorry to sound
[jira] Commented: (AXIS2C-376) --enable-tests and make check has multiple errors
[ http://issues.apache.org/jira/browse/AXIS2C-376?page=comments#action_12444761 ] Chris Darroch commented on AXIS2C-376: -- Just as a note, that last set of patches to the Makefile.in files isn't really suitable for use against the svn trunk -- you'd want to turn them into patches against the Makefile.am files. But hopefully you'll get the idea of what I'm doing. --enable-tests and make check has multiple errors --- Key: AXIS2C-376 URL: http://issues.apache.org/jira/browse/AXIS2C-376 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux) Affects Versions: 0.94 Environment: Unix/Linux, maybe others Reporter: Chris Darroch Priority: Minor Attachments: axis2c-376.patch, axis2c-376.patch Normally, when using a package built with autoconf, one can expect to do: ./configure --enable-tests make check For Axis2/C this runs into a variety of problems. I noted a few of these issues in AXIS2C-313 as well, but this is a more detailed summary of the problems I've seen. Specifically: 1) The libcutest library is required, but it's a non-standard library, and isn't even installed as part of the CuTest package -- it has to be built by hand. 2) A number of the test programs have errors; for example, they free their env variable early and then segfault, or report a failure when none has occurred. 3) Test resource files are referenced that aren't supplied in the package, for example, Calculator.wsdl. 4) Some of the tests require that AXIS2C_HOME be set and that a valid axis2.xml file exist. 5) If --enable-tests is used for ./configure, then when make install runs in the test directories, it installs various programs and libraries in directories named itest, unit_test, and system_test under the specified --prefix. Even if these programs should be installed (which is arguable), they should be installed under the --bindir and --libdir locations, not --prefix. In my case, we try to make running make check a standard part of our global package installation framework, which is automated. I'll attach as files (if I can) the various patches we make to the Axis2/C test framework to deal with problems #2, #3, #4 and #5. To deal with problem #3 we also unpack the following resources, which I hunted around for on svn.apache.org: https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ into xml_schema https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl/ into woden/test To deal with problem #4, we patch samples/server/axis2.xml to not engage the addressing module, and then point AXIS2C_HOME to samples/server in our build directory before running make check. That allows the tests to run without having already done a make install -- since our installation framework won't install the package until it's seen a successful make check run! Finally, to deal with problem #1, we build and install libcutest prior to building, testing, and installing Axis2/C, using the CuTest package and the trick found in this axis-c-dev mailing list posting: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile In general, though, all these tricks shouldn't be necessary. A user should be able to download the axis2c package, run ./configure --enable-tests and make check with no special knowledge, I believe. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-369) LDFLAGS overridden by configure
LDFLAGS overridden by configure --- Key: AXIS2C-369 URL: http://issues.apache.org/jira/browse/AXIS2C-369 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux) Affects Versions: 0.94 Reporter: Chris Darroch The configure.ac files contain the following line: LDFLAGS=-lpthread This has the effect of overriding any input LDFLAGS that the user specifies. The configure script's --help option says you can set CFLAGS, LDFLAGS, etc. prior to running ./configure: ./configure --help ... Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -Llib dir if you have libraries in a nonstandard directory lib dir ... The line should probably be LDFLAGS=$LDFLAGS -lpthread in all of the configure.ac files (configure, woden/configure, etc.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-328) unable to return custom SOAP faults
unable to return custom SOAP faults
---
Key: AXIS2C-328
URL: http://issues.apache.org/jira/browse/AXIS2C-328
Project: Axis2-C
Issue Type: Bug
Components: code generation, core/receivers, wsdl2c tool
Affects Versions: 0.93, Current (Nightly)
Reporter: Chris Darroch
Thanks, BTW, for the tcpmon tool -- very helpful!
I have a need to return custom SOAP fault messages from an Axis2/C server.
This turns out to require some patches in a few places. First, the code
generated by the w2c tool always calls a local on_fault handler, named
axis2_svc_skel_foo_on_fault() in the axis2_svc_skel_foo.c file. This function,
as generated by w2c, creates a fault element and returns it in the SOAP body.
Changing axis2_svc_skel_foo_on_fault() to simply return NULL instead allows the
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync() function in
modules/core/receivers/raw_xml_in_out_msg_recv.c to recognize that no body
element
has been returned, and create a SOAP fault instead.
The actual business logic that one fills into the axis2_skel_foo.c file can
then simply
do the following:
axis2_skel_foo_Foo(...) {
AXIS2_ERROR_SET_STATUS_CODE(env-error, AXIS2_FAILURE);
AXIS2_ERROR_SET_ERROR_NUMBER(env-error,
AXIS2_ERROR_FOO);
return NULL;
}
This almost works, and
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync()
now recognizes the fault condition and calls
axiom_soap_fault_create_default_fault()
to create the SOAP fault element. Good, except that it then returns
AXIS2_FAILURE,
so that its caller, axis2_raw_xml_in_out_msg_recv_receive_sync() in
modules/core/receivers/msg_recv.c, then does this:
status = AXIS2_MSG_RECV_INVOKE_IN_OUT_BUSINESS_LOGIC_SYNC(msg_recv, env,
msg_ctx, out_msg_ctx);
if(AXIS2_SUCCESS != status)
{
axis2_core_utils_reset_out_msg_ctx(env, out_msg_ctx);
AXIS2_MSG_CTX_FREE(out_msg_ctx, env);
return status;
}
which destroys the nice SOAP fault and returns an empty body element instead to
the client!
My current patch is to have
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync() return
AXIS2C_SUCCESS instead -- this makes sense to me, because although an fault
condition has been detected, the function has successfully handled it by
creating
the SOAP fault element. Here's the patch:
--- modules/core/receivers/raw_xml_in_out_msg_recv.c.orig 2006-10-07
13:31:17.801951262 -0400
+++ modules/core/receivers/raw_xml_in_out_msg_recv.c2006-10-07
13:31:36.094847670 -0400
@@ -325,7 +325,7 @@
else if (soap_fault)
{
AXIS2_MSG_CTX_SET_SOAP_ENVELOPE(new_msg_ctx, env, default_envelope);
-status = AXIS2_FAILURE; /* if there is a failure we have to return a
failure code */
+status = AXIS2_SUCCESS;
}
else
{
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-328) unable to return custom SOAP faults
[
http://issues.apache.org/jira/browse/AXIS2C-328?page=comments#action_12440692 ]
Chris Darroch commented on AXIS2C-328:
--
Oh, right -- I forgot to add that it would be very helpful if the util package
could provide some add_error functions, so that one could register
custom error codes and messages. As it is, I'll have to patch
axis2_error.h and friends so that my custom AXIS2_ERROR_FOO
code and matching message are registered in advance.
Maybe there's an even cleaner way to allow services to return custom soap
faults, but I haven't given it much thought. Sorry.
unable to return custom SOAP faults
---
Key: AXIS2C-328
URL: http://issues.apache.org/jira/browse/AXIS2C-328
Project: Axis2-C
Issue Type: Bug
Components: core/receivers, code generation, wsdl2c tool
Affects Versions: Current (Nightly), 0.93
Reporter: Chris Darroch
Thanks, BTW, for the tcpmon tool -- very helpful!
I have a need to return custom SOAP fault messages from an Axis2/C server.
This turns out to require some patches in a few places. First, the code
generated by the w2c tool always calls a local on_fault handler, named
axis2_svc_skel_foo_on_fault() in the axis2_svc_skel_foo.c file. This
function, as generated by w2c, creates a fault element and returns it in
the SOAP body.
Changing axis2_svc_skel_foo_on_fault() to simply return NULL instead allows
the
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync() function in
modules/core/receivers/raw_xml_in_out_msg_recv.c to recognize that no body
element
has been returned, and create a SOAP fault instead.
The actual business logic that one fills into the axis2_skel_foo.c file can
then simply
do the following:
axis2_skel_foo_Foo(...) {
AXIS2_ERROR_SET_STATUS_CODE(env-error, AXIS2_FAILURE);
AXIS2_ERROR_SET_ERROR_NUMBER(env-error,
AXIS2_ERROR_FOO);
return NULL;
}
This almost works, and
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync()
now recognizes the fault condition and calls
axiom_soap_fault_create_default_fault()
to create the SOAP fault element. Good, except that it then returns
AXIS2_FAILURE,
so that its caller, axis2_raw_xml_in_out_msg_recv_receive_sync() in
modules/core/receivers/msg_recv.c, then does this:
status = AXIS2_MSG_RECV_INVOKE_IN_OUT_BUSINESS_LOGIC_SYNC(msg_recv, env,
msg_ctx, out_msg_ctx);
if(AXIS2_SUCCESS != status)
{
axis2_core_utils_reset_out_msg_ctx(env, out_msg_ctx);
AXIS2_MSG_CTX_FREE(out_msg_ctx, env);
return status;
}
which destroys the nice SOAP fault and returns an empty body element instead
to the client!
My current patch is to have
axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync() return
AXIS2C_SUCCESS instead -- this makes sense to me, because although an fault
condition has been detected, the function has successfully handled it by
creating
the SOAP fault element. Here's the patch:
--- modules/core/receivers/raw_xml_in_out_msg_recv.c.orig 2006-10-07
13:31:17.801951262 -0400
+++ modules/core/receivers/raw_xml_in_out_msg_recv.c2006-10-07
13:31:36.094847670 -0400
@@ -325,7 +325,7 @@
else if (soap_fault)
{
AXIS2_MSG_CTX_SET_SOAP_ENVELOPE(new_msg_ctx, env, default_envelope);
-status = AXIS2_FAILURE; /* if there is a failure we have to return a
failure code */
+status = AXIS2_SUCCESS;
}
else
{
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-326) fails if name attribute missing from input/output
fails if name attribute missing from input/output - Key: AXIS2C-326 URL: http://issues.apache.org/jira/browse/AXIS2C-326 Project: Axis2-C Issue Type: Bug Components: wsdl2c tool Affects Versions: 0.94 Reporter: Chris Darroch I tried running the wsdl2c tool on some WSDL that contained the following: wsdl:portType name=fooSoap wsdl:operation name=Foo wsdl:input message=tns:FooSoapIn / wsdl:output message=tns:FooSoapOut / /wsdl:operation and it failed with a segfault. Eventually I tracked down that something in the woden library really expected a name attribute on these input and output elements. I'm sorry but I've lost track exactly, but I think it was in woden/src/builder/wsdl10/wsdl10_reader.c in the parse_binding_msg_ref() function, specifically this chunk: int_msg_ref = woden_wsdl10_interface_msg_ref_to_interface_msg_ref_element( int_msg_ref, env); intf_msg_qname = WODEN_WSDL10_INTERFACE_MSG_REF_ELEMENT_GET_QNAME( int_msg_ref, env); where because no matching SET_QNAME had ever been performed, this would return NULL and the code would segfault. In fact, I think this is also where I stumbled on AXIS2C-322 re woden/src/wsdl10/msg_ref.c because after that patch, the GET_NAME would run, but return NULL -- without that patch, GET_NAME itself failed -- I think. Sorry, I've lost my notes and am working to a deadline at the moment. Anyway, changing the WSDL to this made things work, but I don't think the name attribute is actually required by the WSDL spec -- but I might be wrong about that; please check! wsdl:portType name=fooSoap wsdl:operation name=Foo wsdl:input name=FooSoapIn message=tns:FooSoapIn / wsdl:output name=FooSoapOut message=tns:FooSoapOut / /wsdl:operation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-327) trailing slash in namespace uri causes service load error
trailing slash in namespace uri causes service load error - Key: AXIS2C-327 URL: http://issues.apache.org/jira/browse/AXIS2C-327 Project: Axis2-C Issue Type: Bug Components: woden, wsdl, wsdl2c tool Reporter: Chris Darroch I was given some WSDL with the following namespace declaration: xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; and running it through w2c would produce the message Error in loading Services. Removing the trailing slash from the namespace URI allows w2c to proceed. This problem affects other parts of Axis2/C as well. It appears to be due to the match against the namespace URIs defined in woden/src/wsdl10/woden_wsdl10_constants.h and elsewhere. It would be nice if the trailing slash (which seems to be generated by other, non-Axis2/C tools) could be ignored; failing that, a better warning message that helps users to diagnose the problem would be much better than Error in loading Services. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-313) improve autoconf support
[ http://issues.apache.org/jira/browse/AXIS2C-313?page=comments#action_12439886 ] Chris Darroch commented on AXIS2C-313: -- Oh, and I meant to add that --libexecdir is probably the most GNU-ish place to install service and module libraries. I suspect that the directory structure of the Axis2/C project is largely derived from the Java one, and so these GNU-style package layout suggestions are probably somewhat at odds with that. However, in my case I'm installing it along with a lot of other packages, all of which follow the GNU standard, so these issues came to the forefront for me. For example, httpd modules that are compiled as dynamically loadable libraries live in $INSTALL_PATH/libexec, so it would be nice to have axis2 service and module libraries in there too. improve autoconf support Key: AXIS2C-313 URL: http://issues.apache.org/jira/browse/AXIS2C-313 Project: Axis2-C Issue Type: Improvement Components: build system (Unix/Linux) Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch The autoconf system really isn't being used effectively for the axis2c package. First, as noted in another bug report, some of the code searches for libraries in $AXIS2C_HOME/lib regardless of what is specified by the user when using the --libdir configure option. Second, it would be better if include files were installed in, say, $includedir/axis2, the way the APR project installs them in $includedir/apr-$majorversion and httpd installs them in $includedir/apache2. Given that 375 files are installed, this is otherwise a major source of pollution in a common location. Third, if one uses --libdir, --includedir, and --bindir, then each successive installation of an axis2c sub-project (like xml_schema or woden) and the main axis2c installation itself should use these locations to search for dependencies. As it is, the util sub-project installs quite neatly, but then all the others require patches to their Makefiles and/or specific CFLAGS and LDFLAGS settings so that they can locate the previous sub-projects' headers and libraries. This really shouldn't be necessary; they should look in --libdir and --includedir automatically. Fourth, the various test suites that run when make check is used fail in a wide variety of ways. Many of the test suites depend on libcutest.a -- but this isn't something the CuTest package provides! Instead, you have to dig out a posting to the mailing list: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile (An alternative would be the derived version that the APR test suite uses.) Other tests depend on data files that aren't in the distribution; for example, the xml_schema tests seem to require the files from https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ in a resources directory. The woden tests require a Calculator.wsdl file that I found in https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl, but it required that the xmlns:wsdl=http://schemas.xmlsoap.org/wsdl; attribute *not* have a trailing slash and WODEN_WSDL10_DESC_GET_INTERFACES() be used. The util/test/util/test_util.c file calls run_test_string(env) after freeing the env variable, producing a segfault. And so forth. Fifth, while I realize this would be a pain, it would be really superb if one could control the layout of the $AXIS2C_HOME location using the kinds of options provided by the config.layout file in the httpd package. More, instead of requiring directories under $AXIS2C_HOME named logs, services, modules, and so forth, and requiring that the libraries in the services and modules directories be accompanied by XML files, it would be great if you could ask for a layout like this: $prefix = $MY_INSTALL_DIR $bindir = $prefix/bin (by default, use --bindir to change) $includedir = $prefix/include/axis2 (by default, use --includedir to change) $libdir = $prefix/lib/axis2 (by default, use --libdir to change) $sysconfdir = $prefix/etc/axis2 (by default, use --sysconfdir to change) $localstatedir = $prefix (by default, use --localstatedir to change) $logfiledir = $localstatedir/logs (by default, use config.layout or axis2.xml to change) $servicesdir = $libdir/services (by default, use config.layout or axis2.xml to change) $modulesdir = $libdir/modules (by default, use config.layout or axis2.xml to change) The axis2.xml file would be expected to reside in $sysconfdir. There would be runtime options (like httpd's -f option) that would allow the user to point to another non-standard file, though. This file would could then contain logsDir, servicesDir, modulesDir to point to non-standard directories
[jira] Created: (AXIS2C-322) calls to NULL pointers in wsdl10/msg_ref.c
calls to NULL pointers in wsdl10/msg_ref.c
--
Key: AXIS2C-322
URL: http://issues.apache.org/jira/browse/AXIS2C-322
Project: Axis2-C
Issue Type: Bug
Components: woden
Affects Versions: Current (Nightly), 0.94
Reporter: Chris Darroch
Priority: Minor
In woden/src/wsdl10/msg_ref.c the following code is repeated often:
if (!msg_ref)
{
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) create(env);
}
else
msg_ref_impl = (woden_wsdl10_msg_ref_impl_t *) msg_ref;
woden_wsdl10_msg_ref_free_ops(msg_ref, env);
This won't actually work if msg_ref is NULL, because although create() runs OK,
the
call to woden_wsdl10_msg_ref_free_ops() then fails with a segfault.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-313) improve autoconf support
[ http://issues.apache.org/jira/browse/AXIS2C-313?page=comments#action_12439726 ] Chris Darroch commented on AXIS2C-313: -- Sorry, I just meant autoconf in a generic sense of the GNU build system, not the specific autoconf program, as opposed to an entirely different build system like the one for the (non-Apache) package that builds the zip command (from ftp.info-zip.org). I did indeed use ./configure, but all of my comments apply to that, not the autoconf command itself. I'll try the 0.94 release after I get back from ApacheCon in a couple of weeks. Thanks! improve autoconf support Key: AXIS2C-313 URL: http://issues.apache.org/jira/browse/AXIS2C-313 Project: Axis2-C Issue Type: Improvement Components: build system (Unix/Linux) Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch The autoconf system really isn't being used effectively for the axis2c package. First, as noted in another bug report, some of the code searches for libraries in $AXIS2C_HOME/lib regardless of what is specified by the user when using the --libdir configure option. Second, it would be better if include files were installed in, say, $includedir/axis2, the way the APR project installs them in $includedir/apr-$majorversion and httpd installs them in $includedir/apache2. Given that 375 files are installed, this is otherwise a major source of pollution in a common location. Third, if one uses --libdir, --includedir, and --bindir, then each successive installation of an axis2c sub-project (like xml_schema or woden) and the main axis2c installation itself should use these locations to search for dependencies. As it is, the util sub-project installs quite neatly, but then all the others require patches to their Makefiles and/or specific CFLAGS and LDFLAGS settings so that they can locate the previous sub-projects' headers and libraries. This really shouldn't be necessary; they should look in --libdir and --includedir automatically. Fourth, the various test suites that run when make check is used fail in a wide variety of ways. Many of the test suites depend on libcutest.a -- but this isn't something the CuTest package provides! Instead, you have to dig out a posting to the mailing list: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile (An alternative would be the derived version that the APR test suite uses.) Other tests depend on data files that aren't in the distribution; for example, the xml_schema tests seem to require the files from https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ in a resources directory. The woden tests require a Calculator.wsdl file that I found in https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl, but it required that the xmlns:wsdl=http://schemas.xmlsoap.org/wsdl; attribute *not* have a trailing slash and WODEN_WSDL10_DESC_GET_INTERFACES() be used. The util/test/util/test_util.c file calls run_test_string(env) after freeing the env variable, producing a segfault. And so forth. Fifth, while I realize this would be a pain, it would be really superb if one could control the layout of the $AXIS2C_HOME location using the kinds of options provided by the config.layout file in the httpd package. More, instead of requiring directories under $AXIS2C_HOME named logs, services, modules, and so forth, and requiring that the libraries in the services and modules directories be accompanied by XML files, it would be great if you could ask for a layout like this: $prefix = $MY_INSTALL_DIR $bindir = $prefix/bin (by default, use --bindir to change) $includedir = $prefix/include/axis2 (by default, use --includedir to change) $libdir = $prefix/lib/axis2 (by default, use --libdir to change) $sysconfdir = $prefix/etc/axis2 (by default, use --sysconfdir to change) $localstatedir = $prefix (by default, use --localstatedir to change) $logfiledir = $localstatedir/logs (by default, use config.layout or axis2.xml to change) $servicesdir = $libdir/services (by default, use config.layout or axis2.xml to change) $modulesdir = $libdir/modules (by default, use config.layout or axis2.xml to change) The axis2.xml file would be expected to reside in $sysconfdir. There would be runtime options (like httpd's -f option) that would allow the user to point to another non-standard file, though. This file would could then contain logsDir, servicesDir, modulesDir to point to non-standard directories for those things, if the user wanted a different layout. Among other things, this kind of framework allows for easy switching between different versions of the same services and modules for testing purposes.
[jira] Created: (AXIS2C-312) remove fixed paths from code
remove fixed paths from code Key: AXIS2C-312 URL: http://issues.apache.org/jira/browse/AXIS2C-312 Project: Axis2-C Issue Type: Bug Components: build system (Unix/Linux), core/deployment Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch As per this thread on the user mailing list, I've found that one can't actually use the --libdir, --includedir, etc. options to the autoconf configure program: http://marc.theaimsgroup.com/?l=axis-c-userm=115956538314942w=2 Here's the crux of the problem: hard-coded paths. While I appreciate that these are easier to write than a fully-configurable package, the documentation in the INSTALL file and the use of autoconf implies that one can customize the installation. For example, the INSTALL file says: Please run './configure --help' in samples folder for more information on configure options. As it happens, when I discovered that the package was going to install about 15 libraries and 375 header files, I purposefully used the standard autoconf configure options to put these in subdirectories: ./configure --prefix=$(INSTALL_PATH) --enable-tests \ --bindir=$(INSTALL_PATH)/bin/axis2 \ --includedir=$(INSTALL_PATH)/include/axis2 \ --libdir=$(INSTALL_PATH)/lib/axis2 \ With the appropriate CFLAGS and LDFLAGS and a little Makefile tuning, this all compiles OK and installs OK. It's also a fairly standard Apache way of doing things -- the APR and httpd projects use the apr-majorversion and apache2 subdirectories, for example, to keep their headers and libraries from polluting the user's --includedir location. Alas, in axis2_conf_builder_process_transport_senders(), we have this code: repos_name = AXIS2_DEP_ENGINE_GET_REPOS_PATH(conf_builder- desc_builder-engine, env); temp_path = AXIS2_STRACAT(repos_name, AXIS2_PATH_SEP_STR, env); temp_path2 = AXIS2_STRACAT(temp_path, AXIS2_LIB_FOLDER, env); temp_path3 = AXIS2_STRACAT(temp_path2, AXIS2_PATH_SEP_STR, env); path_qualified_dll_name = AXIS2_STRACAT(temp_path3, dll_name, env); This means that, in effect, the --libdir option to configure is useless, because the code is going to ignore whatever the specified installation locations were and go looking in the $AXIS2C_HOME/lib location regardless. What I'll do for now, I guess, is creating a symlink from $AXIS2C_HOME/lib to my $INSTALL_PATH/lib/axis2 location, and this does indeed work OK. However, it's a workaround caused by what I'd suggest is a pair of bugs. First, I'd suggest that there should be no hard-coded paths like the ones I see in modules/core/deployment/conf_builder.c, desc_builder.c, and arch_reader.c. These are just the ones using AXIS2_DEP_ENGINE_GET_REPOS_PATH(); there may well be other similar functions I'm not aware of, though. Such paths should be determined from configuration parameters. For example, programs could look for axis2.xml $AXIS2C_HOME, then in a directory specified at compile time using an option to ./configure, and finally in the current directory. The axis2.xml file would then, in turn, include the paths to the directories used for logs, libraries, services, modules, etc. It would also be nice if at compile time and run time one could specify a different name for the axis2.xml file -- for example, Apache httpd accepts an -f run-time option to use a non-standard configuration file. Second, whole autoconf system for axis2c needs some work. I'll put details into a second enhancement request, but as far as this particular bug is concerned, I'd suggest that since --libdir does correctly install the libraries into a given location, it's wrong to then go looking in $AXIS2C_HOME/lib despite what the user requested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-313) improve autoconf support
improve autoconf support Key: AXIS2C-313 URL: http://issues.apache.org/jira/browse/AXIS2C-313 Project: Axis2-C Issue Type: Improvement Components: build system (Unix/Linux) Affects Versions: 0.93 Environment: Unix/Linux, maybe Windows and others. Reporter: Chris Darroch The autoconf system really isn't being used effectively for the axis2c package. First, as noted in another bug report, some of the code searches for libraries in $AXIS2C_HOME/lib regardless of what is specified by the user when using the --libdir configure option. Second, it would be better if include files were installed in, say, $includedir/axis2, the way the APR project installs them in $includedir/apr-$majorversion and httpd installs them in $includedir/apache2. Given that 375 files are installed, this is otherwise a major source of pollution in a common location. Third, if one uses --libdir, --includedir, and --bindir, then each successive installation of an axis2c sub-project (like xml_schema or woden) and the main axis2c installation itself should use these locations to search for dependencies. As it is, the util sub-project installs quite neatly, but then all the others require patches to their Makefiles and/or specific CFLAGS and LDFLAGS settings so that they can locate the previous sub-projects' headers and libraries. This really shouldn't be necessary; they should look in --libdir and --includedir automatically. Fourth, the various test suites that run when make check is used fail in a wide variety of ways. Many of the test suites depend on libcutest.a -- but this isn't something the CuTest package provides! Instead, you have to dig out a posting to the mailing list: http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile (An alternative would be the derived version that the APR test suite uses.) Other tests depend on data files that aren't in the distribution; for example, the xml_schema tests seem to require the files from https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/ in a resources directory. The woden tests require a Calculator.wsdl file that I found in https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl, but it required that the xmlns:wsdl=http://schemas.xmlsoap.org/wsdl; attribute *not* have a trailing slash and WODEN_WSDL10_DESC_GET_INTERFACES() be used. The util/test/util/test_util.c file calls run_test_string(env) after freeing the env variable, producing a segfault. And so forth. Fifth, while I realize this would be a pain, it would be really superb if one could control the layout of the $AXIS2C_HOME location using the kinds of options provided by the config.layout file in the httpd package. More, instead of requiring directories under $AXIS2C_HOME named logs, services, modules, and so forth, and requiring that the libraries in the services and modules directories be accompanied by XML files, it would be great if you could ask for a layout like this: $prefix = $MY_INSTALL_DIR $bindir = $prefix/bin (by default, use --bindir to change) $includedir = $prefix/include/axis2 (by default, use --includedir to change) $libdir = $prefix/lib/axis2 (by default, use --libdir to change) $sysconfdir = $prefix/etc/axis2 (by default, use --sysconfdir to change) $localstatedir = $prefix (by default, use --localstatedir to change) $logfiledir = $localstatedir/logs (by default, use config.layout or axis2.xml to change) $servicesdir = $libdir/services (by default, use config.layout or axis2.xml to change) $modulesdir = $libdir/modules (by default, use config.layout or axis2.xml to change) The axis2.xml file would be expected to reside in $sysconfdir. There would be runtime options (like httpd's -f option) that would allow the user to point to another non-standard file, though. This file would could then contain logsDir, servicesDir, modulesDir to point to non-standard directories for those things, if the user wanted a different layout. Among other things, this kind of framework allows for easy switching between different versions of the same services and modules for testing purposes. Sorry to sound negative about all this -- the axis2c package looks to be ideal for my purposes (combining it with mod_dbd inside httpd); I've just had to struggle with the installation process quite a bit to get things laid out the way I want them. Thanks for listening! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
[jira] Created: (AXIS2C-305) remove GPL text from COPYING files
remove GPL text from COPYING files -- Key: AXIS2C-305 URL: http://issues.apache.org/jira/browse/AXIS2C-305 Project: Axis2-C Issue Type: Task Components: build system (Unix/Linux), util Affects Versions: 0.93 Reporter: Chris Darroch The util/COPYING and axiom/COPYING files contain the text of the GNU General Public License, not the Apache License 2.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
