[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
