axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dinesh Premalal (JIRA)" <>
Subject [jira] Assigned: (AXIS2C-380) mod_axis2 config issues
Date Tue, 07 Nov 2006 18:16:50 GMT
     [ ]

Dinesh Premalal reassigned AXIS2C-380:

    Assignee: Dinesh Premalal

> mod_axis2 config issues
> -----------------------
>                 Key: AXIS2C-380
>                 URL:
>             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
> configuration directives inside <Directory> or <Location> blocks, which is
> 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
> 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
> This function runs once for each child process that is started up by the main server
> 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
> 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:
For more information on JIRA, see:


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

View raw message