The EL 3.0 spec, section 1.22.2 states:

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.

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

try {
return Class.forName(className, false, getClass().getClassLoader());
} catch (ClassNotFoundException ex) {
notAClass.add(className);
}

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