Return-Path: 
 <users-return-212274-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 26043 invoked from network); 16 May 2010 22:50:20 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 16 May 2010 22:50:20 -0000
Received: (qmail 33556 invoked by uid 500); 16 May 2010 22:50:17 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 33440 invoked by uid 500); 16 May 2010 22:50:17 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 33431 invoked by uid 99); 16 May 2010 22:50:17 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 May 2010 22:50:17 +0000
X-ASF-Spam-Status: No, hits=-0.9 required=10.0
	tests=AWL,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 May 2010 22:50:09 +0000
Received: from localhost (localhost [127.0.0.1])
	by tor.combios.es (Postfix) with ESMTP id DD35D226167
	for <users@tomcat.apache.org>; Mon, 17 May 2010 00:48:56 +0200 (CEST)
Received: from tor.combios.es ([127.0.0.1])
	by localhost (tor.combios.es [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 5vm3hA0a4cdN for <users@tomcat.apache.org>;
	Mon, 17 May 2010 00:48:56 +0200 (CEST)
Received: from [192.168.245.129] (p549E1AE3.dip0.t-ipconnect.de
 [84.158.26.227])
	by tor.combios.es (Postfix) with ESMTPA id 81AC422615F
	for <users@tomcat.apache.org>; Mon, 17 May 2010 00:48:56 +0200 (CEST)
Message-ID: <4BF07680.5030404@ice-sa.com>
Date: Mon, 17 May 2010 00:49:36 +0200
From: =?ISO-8859-15?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: mod_jk file not found
References: <4BEB448B.3090208@gmx.at> <4BEBEAF0.3050001@ice-sa.com>
 <4BF018CD.4090803@gmx.at> <4BF0435D.2010404@ice-sa.com>
 <4BF05251.3060808@gmx.at>
In-Reply-To: <4BF05251.3060808@gmx.at>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Markus Mehrwald wrote:
>> ...
>> By default JkMount entries are not inherited from the global server to
>> other VirtualHosts or between VirtualHosts. For the complete inheritance
>> rules, see: JkMountCopy.
> 
> But why does it work with the VirtualHost for port 80?
> 
>>
It should not. But I don't know the details of how you have defined your 
"main" host and your <VirtualHost> sections.

JkMount/JkUnMount are not supposed to be copied from the "main" section 
into the <VirtualHost> sections, unless :

either :
a) The "main" host config contains a directive
JkMountCopy All

or:
b) The <VirtualHost> config(s) contain(s) a directive
JkMountCopy On

(a) above is supposed to copy them to *all* <VirtualHost> sections.
(**)
But maybe there is a subtle condition which causes this not to work if 
you have configured the main section to Listen on two ports ?
Using a name-based <VirtualHost> for HTTPS (if that is what you are 
doing) is a kludge anyway.  It only works because there is only one VH 
defined for that port, and Apache defaults to it when it cannot match 
the name.  Maybe that kludhe somehow interferes with the Jk mounts copy 
mechanism. (I don't know, I haven't tried.)

(b) allows you to be selective about which VH inherits the mounts and 
which not.

Anyway, try to use
JkMountCopy On
in each of the VirtualHost sections (and no JkMountCopy line in the main 
configuration). That should always work.


Apart from that, and to figure out what is being sent by what and/or 
where you are getting the 404 from, I suggest that you install a plugin 
in your browser which allows you to examine the sequence of 
request/responses that really happen.
(Firefox : HttpFox or LiveHttpHeaders; IE : Fiddler2)
An application may be returning a redirect response to the browser, with 
a bad URL, and it may be when the browser tries to get to that 
"replacement" URL that it gets the 404.



(**) Actually, it is more subtle.
JkMountCopy "exists", by default, in all VH, with a default value of "Off".
By setting "JkMountCopy On" in a VH, you make it copy the Jk mounts from 
the main config.
By setting "JkMountCopy All" in the main host, you change the default of 
JkMountCopy in the VH's, from "Off" to "On".
You can still then set "JkMountCopy Off" in one VH, to disable the copy 
for that VH.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org