[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ] 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/sr... {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). 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/sr... {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)