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

[jaikiran pai (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-6943:
-------------------------------
    Description: 
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 WildFly team's own copies).


  was:
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).




> 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.0.0.Final, 10.1.0.CR1
>            Reporter: jaikiran pai
>            Assignee: Jason Greene
>
> 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 WildFly team's own copies).



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