[jboss-jira] [JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader

[jaikiran pai (JIRA)]

jaikiran pai created WFLY-6943:
----------------------------------

             Summary: javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
                 Key: WFLY-6943
                 URL: https://issues.jboss.org/browse/WFLY-6943
             Project: WildFly
          Issue Type: Bug
          Components: EE
    Affects Versions: 10.1.0.CR1, 10.0.0.Final
            Reporter: jaikiran pai


The EL 3.0 spec, section 1.22.2 states:

{quote}
Either a class or a package can be explicitly imported into the EL evaluation
environment. Importing a package imports all the classes in the package. The classes
that can be imported are restricted to the classes that can be loaded by the *current class loader*.

The imports of packages, classes, and static fields are handled by the
*ImportHandler* in the ELContext.

{quote}

It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported. 

The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method  doesn't return the application specific Class instance back and instead returns null.

This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/src/main/java/javax/el/ImportHandler.java#L176
{code}
try {
return Class.forName(className, false, getClass().getClassLoader());
} catch (ClassNotFoundException ex) {
notAClass.add(className);
}
{code}

The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix the API published by Oracle (as well as our own copies).




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)