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: local policy)
Message-ID: <48BECB85.7070600@kippdata.de>
Date: Wed, 03 Sep 2008 19:38:13 +0200
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Thunderbird 2.0.0.6 (X11/20070802)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: [VOTE] Release build 5.5.27
References: <48BD87E5.3090109@hanik.com> <48BD8D86.4080700@mhsoftware.com>
 <72dbd3150809021714k60bf3afameefb7dda2482ea63@mail.gmail.com>
	 <48BEA909.5020908@mhsoftware.com> <48BEC067.1070104@rowe-clan.net>
 <48BEC8AA.5010801@mhsoftware.com>
In-Reply-To: <48BEC8AA.5010801@mhsoftware.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

George Sexton wrote:
> For me this is a critical error. Tomcat 5.5.26 and 5.5.27 don't work 
> when run under the security manager.
> 
> It's really not a trivial corner case. Did you look at my stack trace 
> from Saturday? Trying to open a socket in one part of my code triggered 
> the bug. The class loader is looking for a logging.properties in 
> context/WEB-INF/classes and it's bombing.
> 
> I'm really not trying to be overly picky here, but if the whole security 
> manager functionality is broken, that's a pretty big thing. The fact 
> that it was broken in the last release, and will be broken in the new 
> release is even worse.
> 
>  From now until the NEXT release is created, people will be posting it 
> as a bug, which will then get marked RESOLVED, INVALID. They will then 
> re-open and wonder why it was closed. It will then be explained that the 
> fix is in CVS and that's why it was closed. The end user will then want 
> to know when the release with the fix will be present.
> 
> Whatever. I've made my opinion known. If the release gets done with the 
> bug still in it, then I'm a big enough boy to apply the patch and 
> re-compile it so things work.

As far as I understand the issue, the solution is to use the correct 
security manager profile. In catalina.policy there is already a comment 
how to do that (search for "per context logging").

Even with Marks patch (or with his plus mine), there would still be the 
problem of the container not able to read logging.properties from a 
context without giving it permissions. The only difference that the 
patch makes, is that it swallows the exception resp. logs it.

Can you shortly describe

- if adding the correct configuration to catalina.policy fixes your problem

- why not having those lines breaks your application and this breakage 
is not happening with the patch? Is it because the 
AccessControlException is not caught?

Regards,

Rainer

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