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 (nike.apache.org: local policy)
Message-ID: <47A21FBA.9020509@apache.org>
Date: Thu, 31 Jan 2008 19:21:30 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: svn commit: r616973 - /tomcat/tc6.0.x/trunk/STATUS.txt
References: <20080131011248.EBA981A9832@eris.apache.org>
In-Reply-To: <20080131011248.EBA981A9832@eris.apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

remm@apache.org wrote:
> Modified: tomcat/tc6.0.x/trunk/STATUS.txt
> URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=616973&r1=616972&r2=616973&view=diff
> ==============================================================================
> --- tomcat/tc6.0.x/trunk/STATUS.txt (original)
> +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Jan 30 17:12:44 2008
> @@ -43,33 +43,37 @@
>    Patch provided by Anthony Berglas
>    http://svn.apache.org/viewvc?rev=616556&view=rev
>    +1: markt
> -  -1:
> +  -1: remm: I didn't test the performance issue. If it exists, then the patch could be improved
> +            (move any check logic to the Compiler class - and maybe try to handle JAR updates ?).
I'll look at options for moving the logic. I did look at handling JAR 
updates and it was looking as if lots of changes would be required. Is 
there any reason to handle them for this case when for the general case we 
just reload the app?

>  * Fix http://issues.apache.org/bugzilla/show_bug.cgi?id=43878
>    Use a single class loader when not reloading JSPs and tag files to reduce perm
>    gen usage.
>    http://svn.apache.org/viewvc?rev=616563&view=rev
>    +1: markt
> +  +0: remm: The patch will now no longer blow up with the background reloading thread,
> +            but the use case intersects with precompilation, so it's probably not very useful.
Fair point. If that is the general consensus I'll revert it and mark the 
bug as WONTFIX.

>  * Remove old TLS code
>    http://svn.apache.org/viewvc?rev=616894&view=rev
>    +1: markt
> -  -1:
> +  -1: remm: I don't see the point of backporting these API changing cleanups
This isn't an API change. The TLS code has been excluded from the build 
since 6.0.0. It is purely a clean up.

>  * Modify NIo connector to use JSSE SSL implementation directly
>    http://svn.apache.org/viewvc?rev=616896&view=rev
>    +1: markt
> -  -1: 
> +  -1: remm: I don't see the point of backporting these API changing cleanups
Again, no API change here.

>  * Remove JSSE dependency from SSL abstraction
>    Requires NIO patch above
>    http://svn.apache.org/viewvc?rev=616897&view=rev
>    +1: markt
> -  -1:
> +  -1: remm: I don't see the point of backporting these API changing cleanups
Fair point on this one - it does change the API.

>  * Fix http://issues.apache.org/bugzilla/show_bug.cgi?id=44282
>    Do call to getClassLoader() in a privileged block.
>    http://svn.apache.org/viewvc?rev=616953&view=rev
>    +1: markt
> +  +0: remm: do we really want to fix these sort of "bugs" ?
Yes. It might be trivial but it is still a bug.


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