[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
