transformations

       <code>ap_log_*</code> without additional wrappers. In this way, the

       code will remain compatible with HTTPD 2.0 and 2.2.</p>

    <p>Consider the following changes to take advantage of the new

       <code>APLOG_TRACE1..8</code> log levels:

       <ul>

         <li>Check current use of <code>APLOG_DEBUG</code> and

         consider if one of the <code>APLOG_TRACEn</code> levels is

         more appropriate.</li>

         <li>If your module currently has a mechanism for configuring

         the amount of debug logging which is performed, consider

         eliminating that mechanism and relying on the use of

         different <code>APLOG_TRACEn</code> levels.  If expensive

         trace processing needs to be bypassed depending on the

         configured log level, use the <code>APLOGtrace<em>n</em></code>

         and <code>APLOGrtrace<em>n</em></code> macros to first check

         if tracing is enabled.</li>

       </ul></p>

    <p>Modules sometimes add process id and/or thread id to their log

       messages.  These ids are now logged by default, so it may not

       be necessary for the module to log them explicitly.  (Users may

       remove them from the error log format, but they can be

       instructed to add it back if necessary for problem diagnosis.)</p>

  <h3><a name="upgrading_byfunction" id="upgrading_byfunction">If your module uses these existing APIs...</a></h3>

    <dl>

      <dt><code>ap_default_type()</code></dt>

      <dd>This is no longer available; Content-Type must be configured

          explicitly or added by the application.</dd>

      <dt><code>ap_get_server_name()</code></dt>

      <dd>If the returned server name is used in a URL,

      use <code>ap_get_server_name_for_url()</code> instead.  This new

      function handles the odd case where the server name is an IPv6

      literal address.</dd>

      <dt><code>ap_get_server_version()</code></dt>

      <dd>For logging purposes, where detailed information is 

          appropriate, use <code>ap_get_server_description()</code>.

          When generating output, where the amount of information

          should be configurable by ServerTokens, use

          <code>ap_get_server_banner()</code>.</dd>

      <dt><code>ap_graceful_stop_signalled()</code></dt>

      <dd>Replace with a call

      to <code>ap_mpm_query(AP_MPMQ_MPM_STATE)</code> and checking for

      state <code>AP_MPMQ_STOPPING</code>.</dd>

      <dt><code>ap_max_daemons_limit</code>, <code>ap_my_generation</code>,

          and <code>ap_threads_per_child</code></dt>

      <dd>Use <code>ap_mpm_query()</code> query codes

          <code>AP_MPMQ_MAX_DAEMON_USED</code>, <code>AP_MPMQ_GENERATION</code>,

          and <code>AP_MPMQ_MAX_THREADS</code>, respectively.</dd>

      <dt><code>ap_mpm_query()</code></dt>

      <dd>Ensure that it is not used until after the register-hooks

          hook has completed.  Otherwise, an MPM built as a DSO

          would not have had a chance to enable support for this

          function.</dd>

      <dt><code>ap_server_conf-&gt;process-&gt;pool</code>

      userdata</dt>

      <dd>

        Optional:

        <ul>

          <li>If your module uses this to determine which pass of the

	  startup hooks is being run,

	  use <code>ap_state_query(AP_SQ_MAIN_STATE)</code>.</li>

          <li>If your module uses this to maintain data across the

          unloading and reloading of your module, use

          <code>ap_retained_data_create()</code> and

          <code>ap_retained_data_get()</code>.</li>

        </ul>

      </dd>

      <dt><code>apr_global_mutex_create()</code>,

          <code>apr_proc_mutex_create()</code></dt>

      <dd>Optional: See <code>ap_mutex_register()</code>,

          <code>ap_global_mutex_create()</code>, and

          <code>ap_proc_mutex_create()</code>; these allow your

          mutexes to be configurable with

          the <code class="directive"><a href="../mod/core.html#mutex">Mutex</a></code> directive;

          you can also remove any configuration mechanisms in your

          module for such mutexes

      </dd>

      <dt><code>CORE_PRIVATE</code></dt>

      <dd>This is now unnecessary and ignored.</dd>

      <dt><code>dav_new_error()</code>

      and <code>dav_new_error_tag()</code></dt>

      <dd>Previously, these assumed that <code>errno</code> contained

      information describing the failure.  Now,

      an <code>apr_status_t</code> parameter must be provided.  Pass

      0/APR_SUCCESS if there is no such error information, or a valid

      <code>apr_status_t</code> value otherwise.</dd>

      <dt><code>unixd_config</code></dt>

      <dd>This has been renamed to ap_unixd_config.</dd>

    </dl>

  <h3><a name="upgrading_byfeature" id="upgrading_byfeature">If your module interfaces with this feature...</a></h3>

    <dl>

      <dt>suEXEC</dt>

      <dd>Optional: If your module logs an error

          when <code>ap_unixd_config.suexec_enabled</code> is 0,

          also log the value of the new

          field <code>suexec_disabled_reason</code>, which contains an

          explanation of why it is not available.</dd>

      <dt>Extended status data in the scoreboard</dt>

      <dd>In previous releases, <code>ExtendedStatus</code> had to be

          set to <code>On</code>, which in turn required that

          mod_status was loaded.  In 2.4, just

          set <code>ap_extended_status</code> to <code>1</code> in a

          pre-config hook and the extended status data will be

          available.</dd>

    </dl>

  <h3><a name="upgrading_newfeatures" id="upgrading_newfeatures">Does your module...</a></h3>

    <dt>Parse query args</dt>

    <dd>Consider if <code>ap_args_to_table()</code> would be

    helpful.</dd>

    <dt>Parse form data...</dt>

    <dd>Use <code>ap_parse_form_data()</code>.</dd>

    <dt>Check for request header fields <code>Content-Length</code>

    and <code>Transfer-Encoding</code> to see if a body was

    specified</dt>

    <dd>Use <code>ap_request_has_body()</code>.</dd>

    <dt>Implement cleanups which clear pointer variables</dt>

    <dd>Use <code>ap_pool_cleanup_set_null()</code>.</dd>

</div></div>

<div class="bottomlang">

<li><a href="mod_negotiation.html#languagepriority" id="L" name="L">LanguagePriority</a></li>

<li><a href="mod_ldap.html#ldapcacheentries">LDAPCacheEntries</a></li>

<li><a href="mod_ldap.html#ldapcachettl">LDAPCacheTTL</a></li>

<li><a href="mod_ldap.html#ldapconnectionpoolttl">LDAPConnectionPoolTTL</a></li>

<li><a href="mod_ldap.html#ldapconnectiontimeout">LDAPConnectionTimeout</a></li>

<li><a href="mod_ldap.html#ldaplibrarydebug">LDAPLibraryDebug</a></li>

<li><a href="mod_ldap.html#ldapopcacheentries">LDAPOpCacheEntries</a></li>

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>

<!-- English Revision: 504183:1070179 (outdated) -->

<!-- English Revision: 504183:1080834 (outdated) -->

<!--

 Licensed to the Apache Software Foundation (ASF) under one or more

<?xml version="1.0" encoding="EUC-KR" ?>

<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>

<!-- English Revision: 105569:1070179 (outdated) -->

<!-- English Revision: 105569:1080834 (outdated) -->

<!--

 Licensed to the Apache Software Foundation (ASF) under one or more