Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of knst.kolinko@gmail.com
 designates 209.85.212.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EB31DB2.5000102@apache.org>
References: 
 <CABzHfVmUd-_oqfbEWd-yaQbZYCyHQN_+KEWNf4rKod4bToU=9A@mail.gmail.com>
	<4EB2CA73.6080908@apache.org>
	<4EB31DB2.5000102@apache.org>
Date: Sat, 5 Nov 2011 19:24:15 +0400
Message-ID: 
 <CABzHfVnfZ3y60jTo6CKa4dirD0_k_Lt6LENTV-dZ-dmQmjnJnQ@mail.gmail.com>
Subject: Re: Redeploy on context.xml changes (Was: Tagging 7.0.23)
From: Konstantin Kolinko <knst.kolinko@gmail.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

2011/11/4 Mark Thomas <markt@apache.org>:
> On 03/11/2011 17:08, Mark Thomas wrote:
>> I'm still looking at:
>> - recovery after fixing the broken file
>> - not deploying an expanded dir if the context.xml in
>> conf/Catalina/localhost is broken.
>
> OK. Here is a patch for review. There are so many combinations
> deployment and ways to create a dodgy configuration that I have probably
> missed a couple of edge cases.
>
> The main idea with this patch is that a Context always gets added even
> if deployment fails. That allows fixes via JMX and prevents
> WAR/directory deployment after a failed descriptor deployment. If the
> context.xml can't be read, a new FailedContext object is used. This
> allows redeploy resources to be tracked but the Context cannot be started.
>
> A number of clean-up issues I spotted along the way have already been fixed.
>
> http://people.apache.org/~markt/patches/2011-11-03-redeploy-trunk-v2.patch
>

http://people.apache.org/~kkolinko/patches/2011-11-05_tc8_redeploy-v3.patch

It is just your patch, but
- reverted renames of "watched resource" -> "reload resource". (*)
- formatted FailedContext.java and added javadoc at the top of it
- corrected a typo s/absolue/absolute/

(*) Renaming does not add much, and so it is easier to backport. Let's
do not rename WatchedResource -> ReloadResource.


As of now:
1) addReloadResource() is not implemented in FailedContext. So there
is no way to add dependency on the global conf/context.xml there.

Possible solutions, but need to think about them
 a) store reload resources elsewhere outside of Context
 b) extract some code from StandardContext into a new class (something
like StandardContextBase?) and share it with FailedContext?  I see
that FailedContext does not inherit from ContainerBase, so maybe there
is some trouble with that.
 c) Copy some code into FailedContext?
 d) Use StandardContext, but overwrite some methods?

2) It is odd that FailedContext has
    @SuppressWarnings("unused")
    public synchronized void addValve(Valve valve)

3) deployer-howto.xml still mentions "RedeployResource". I'd see where
it goes and fix later.

PS: I had troubles applying your patch with svn and started a thread
on users@subversion referring to it as an example. It does not handle
the way git denotes added files. Not a big deal when there is only one
added file - it us easy to handle that.

Best regards,
Konstantin Kolinko

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