You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Chris Darroch (JIRA)" <ji...@apache.org> on 2006/11/01 00:16:56 UTC
[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 <VirtualHost>s. 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 <VirtualHost>s 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-380) mod_axis2 config issues
Posted by "Dinesh Premalal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-380?page=comments#action_12447920 ]
Dinesh Premalal commented on AXIS2C-380:
----------------------------------------
Hi Chris,
Seems you are going to make quite major change related to the mod_axis2. The reasons that you raise are more reasonable to me. I think changes like
+ Axis2RepoPath <axis2 repository path>
+ Axis2LogFile <axis2 log file path>
+ Axis2LogLevel LOG_LEVEL
and
- AXIS2_LOG_LEVEL_CRITICAL - Log critical errors only
- AXIS2_LOG_LEVEL_ERROR - Log errors critical errors
- AXIS2_LOG_LEVEL_WARNING - Log warnings and above
- AXIS2_LOG_LEVEL_INFO - Log info and above
- AXIS2_LOG_LEVEL_DEBUG - Log debug and above (default)
- AXIS2_LOG_LEVEL_TRACE - Log trace messages
+ crit - Log critical errors only
+ error - Log errors critical errors
+ warn - Log warnings and above
+ info - Log info and above
+ debug - Log debug and above (default)
+ trace - Log trace messages
should get special attention of the community. Therefore it is worth explainning these reasons in the mailling list.
BTW. applied your patches to my local code base, When I try to start apache2 it says
Syntax error on line 418 of /usr/local/apache2/conf/httpd.conf:
Axis2RepoPath not allowed here
It might be a my problem, give me some time to look on it.
appreciate your contribution !
> 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 <VirtualHost>s. 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 <VirtualHost>s 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-380) mod_axis2 config issues
Posted by "Chris Darroch (JIRA)" <ji...@apache.org>.
[ 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 <VirtualHost>s. 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 <VirtualHost>s 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-380) mod_axis2 config issues
Posted by "Dinesh Premalal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-380?page=comments#action_12449088 ]
Dinesh Premalal commented on AXIS2C-380:
----------------------------------------
my httpd.conf is
Axis2RepoPath /home/dinesh/axis2c/deploy/
Axis2LogFile /tmp/axis2.log
Axis2LogLevel info
LoadModule axis2_module /usr/local/apache2/modules/mod_axis2.so
<Location /axis2>
SetHandler axis2_module
</Location>
and it works !. Thanks Chris ...
patch applied ...
> 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 <VirtualHost>s. 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 <VirtualHost>s 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Updated: (AXIS2C-380) mod_axis2 config issues
Posted by "Chris Darroch (JIRA)" <ji...@apache.org>.
[ 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 <VirtualHost>s. 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 <VirtualHost>s 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Updated: (AXIS2C-380) mod_axis2 config issues
Posted by "Chris Darroch (JIRA)" <ji...@apache.org>.
[ 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 <VirtualHost>s. 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 <VirtualHost>s 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Assigned: (AXIS2C-380) mod_axis2 config issues
Posted by "Dinesh Premalal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-380?page=all ]
Dinesh Premalal reassigned AXIS2C-380:
--------------------------------------
Assignee: Dinesh Premalal
> 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 <VirtualHost>s. 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 <VirtualHost>s 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Resolved: (AXIS2C-380) mod_axis2 config issues
Posted by "Dinesh Premalal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-380?page=all ]
Dinesh Premalal resolved AXIS2C-380.
------------------------------------
Fix Version/s: Current (Nightly)
Resolution: Fixed
patch applied ! Thanks Chris. Keep them coming ...
> 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
> Fix For: Current (Nightly)
>
> 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 <VirtualHost>s. 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 <VirtualHost>s 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org