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 (asf.osuosl.org: local policy)
Message-ID: <44FB7CB1.9020409@apache.org>
Date: Sun, 03 Sep 2006 21:09:05 -0400
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: svn commit: r439322 - in
 /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina:
 core/StandardContext.java startup/ContextRuleSet.java
References: <20060901135452.397481A981A@eris.apache.org>
In-Reply-To: <20060901135452.397481A981A@eris.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

remm@apache.org wrote:
> Author: remm
> Date: Fri Sep  1 06:54:50 2006
> New Revision: 439322
> 
> URL: http://svn.apache.org/viewvc?rev=439322&view=rev
> Log:
> - Revert the fix, since the situation described in the bug is not valid (and I'm afraid my boss would murder me 
>   if there's a regression).
The situation described in 39704 and the numerous duplicates is
valid. There are actually two separate issues in the bug, both caused
by the fix to http://jira.jboss.com/jira/browse/JBAS-1688 which is
included in 5.5.10+. Specifically:
1. parent classloader when privilege="true"
2. parent classloader when a custom Loader is used

> - Cleanup getParentCL so that it returns consistent results when using privileged="true". This might have been
>   causing problems in some cases.
This is issue 1 which has been fixed (under bug 36852) in 5.5.13+. The
clean-up appears to make the fix (in ContextRuleSet) redundant but I
haven't tested this thoroughly (so I haven't removed the possibly
redundant code).

> - After looking a bit everywhere, the CreateLoaderRule will use the same parent CL as the one which would be set
>   by the CopyParentCL rule, so I don't see how a problem could occur.
It comes down to timing which is why it is hard to see just by looking
at the code. Stepping through the code with a debugger shows that if a
custom loader is specified in server.xml then at the time the call is
made to getParentClassLoader Context.parent is null so the system
classloader is returned. As far as I can tell this only happens for
custom loaders specified in server.xml.

A simple test, that does not require a custom loader, is to define a
context in server.xml and add an empty <Loader /> tag. If all was
working as it should, this should have the same effect as not
specifying the tag at all. With the current code, this breaks even the
most basic web application.

Some versions of Eclipse WTP appear integrate with Tomcat via custom
loaders defined in server.xml, hence the slew of bug reports.

The reverted fix for 39704 was careful to avoid creating a regression
for http://jira.jboss.com/jira/browse/JBAS-1688. The fix for JBAS-1688
removed the CopyParentCL rule in all cases. The reverted fix added it
back only on context creation which means the CopyParentCL rule is not
used in the code path described by
http://jira.jboss.com/jira/browse/JBAS-1688

I can't see how adding back the CopyParentCL rule as per the fix for
39704 could cause a regression. Certainly, it won't for JBAS-1688. Can
you provide a sample scenario where the 39704 would cause problems?

Mark

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