Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <859885.1162337058695.JavaMail.root@brutus>
Date: Tue, 31 Oct 2006 15:24:18 -0800 (PST)
From: "Chris Darroch (JIRA)" <jira@apache.org>
To: axis-c-dev@ws.apache.org
Subject: [jira] Updated: (AXIS2C-380) mod_axis2 config issues
In-Reply-To: <4190190.1162336616901.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ 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