Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4A3D15F6.7050304@apache.org>
Date: Sat, 20 Jun 2009 18:01:42 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: className in conf/context.xml
References: <4A3AD5B8.1030908@hanik.com> <4A3B6608.2040101@apache.org>
In-Reply-To: <4A3B6608.2040101@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Mark Thomas wrote:
> Filip Hanik - Dev Lists wrote:
>> is no longer being picked up, at least not in my test.
>> I think it's related to the deploy refactor that has been going on,
>> possibly related to
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=47343
> 
> Possibly. I'll take a look.

AFAICT, className would never have been picked up in the global
context.xml or from the host level context.xml.default. Those files are
read in ContextConfig which itself is created from StandardContext. By
the time the code gets to that point it is too late to change the
Context implementation class.

If this were to be implemented, HostConfig would need to parse any
application context.xml file, any host context.xml.default file and the
global context.xml file and make the right selection for className based
on override and the presence, or not, of className in any of those files.

Since no-one has asked for this, I'd prefer to add a note to the docs
that className only has an effect if used in an application context.xml
file.

Mark


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