DO NOT REPLY [Bug 36852] New: - Custom Webapp loaders don't correctly honor context's privileged="true" attribute

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36852>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36852

           Summary: Custom Webapp loaders don't correctly honor context's
                    privileged="true" attribute
           Product: Tomcat 5
           Version: 5.5.9
          Platform: All
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: junk.brinkley@gmail.com


If you create a context.xml for a webapp and include a nested <Loader> element
within the <Context> element and the <Context> is set to privileged="true", then
the classloaders are not set up correctly and the webapp cannot see any of the
privileged classes (i.e. org.catalina.*) For example, the manager webapp won't
work, giving a NoClassDefFoundError for org.apache.catalina.ContainerServlet

I belive that the XML for the loader element is processed like this in
ContextRuleSet.begin() (around line 251):

        // Look up the required parent class loader
        ClassLoader parentClassLoader = null;
        Object ojb = digester.peek();
        if (ojb instanceof Container) {
              parentClassLoader = ((Container)ojb).getParentClassLoader();
        }
        // Instantiate a new Loader implementation object
        String className = loaderClass;
        if (attributeName != null) {
            String value = attributes.getValue(attributeName);
            if (value != null)
                className = value;
        }
        Class clazz = Class.forName(className);
        Class types[] = { ClassLoader.class };
        Object args[] = { parentClassLoader };
        Constructor constructor = clazz.getDeclaredConstructor(types);
        Loader loader = (Loader) constructor.newInstance(args);



However, this is not retrieving the correct parent classloader for privileged
webapps. See the following code in StandardContext.start() (around line 3950):

        if (getLoader() == null) {
            ClassLoader parent = null;
            if (getPrivileged()) {
                if (log.isDebugEnabled())
                    log.debug("Configuring privileged default Loader");
                parent = this.getClass().getClassLoader();
            } else {
                if (log.isDebugEnabled())
                    log.debug("Configuring non-privileged default Loader");
                parent = getParentClassLoader();
            }
            WebappLoader webappLoader = new WebappLoader(parent);
            webappLoader.setDelegate(getDelegate());
            setLoader(webappLoader);
        }


In the case where the <Loader> element was specified, getLoader() will return
non-null and this block will never be entered. However, when that loader was
created in ContextRuleSet, only the "non-privileged" parent class was used (i.e.
StandardContext.getParentClassLoader()) rather than the privileged classloader
at the appropriate times (i.e. StandardContext.getClass().getClassLoader())

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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