tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r439322 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina: core/ startup/
Date Mon, 04 Sep 2006 01:09:05 GMT wrote:
> Author: remm
> Date: Fri Sep  1 06:54:50 2006
> New Revision: 439322
> URL:
> 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 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 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

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?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message