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

[Tomaz Cerar (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278034#comment-13278034 ] 

Tomaz Cerar commented on WFLY-6943:
-----------------------------------

The current impl of ImportHandler probably works fine in non modular environments.
but in case of WildFly the EL api / impl classes are loaded from their own module and as such get module classloader that is limited to that module.

I think we could just fix or version of the ImportHandler to work with TCCL

> 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 to the API published by Oracle (as well as WildFly team's own copies).



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