[JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-6943:
-------------------------------
Fix Version/s: 11.0.0.Alpha1
> 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: James Perkins
> Fix For: 10.1.0.Final, 11.0.0.Alpha1
>
>
> 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).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ]
jaikiran pai resolved WFLY-6943.
--------------------------------
Release Notes Text:
Newer version of the EL spec API project has been merged to 10.x (and master) of WildFly https://github.com/wildfly/wildfly/commit/d1212ed7091627aed9696d2e5361bdf....
Fix Version/s: 10.1.0.Final
Resolution: Done
> 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: James Perkins
> Fix For: 10.1.0.Final
>
>
> 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).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ]
jaikiran pai reassigned WFLY-6943:
----------------------------------
Assignee: James Perkins (was: Jason Greene)
James fixed it in our EL API code https://github.com/jboss/jboss-el-api_spec/commit/30972d1e849df479477fc7b.... Thanks James. Marking this as resolved.
> 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: James Perkins
>
> 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).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1705) A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml
by Peter Nalyvayko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1705?page=com.atlassian.jira.plugi... ]
Peter Nalyvayko updated WFCORE-1705:
------------------------------------
Summary: A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml (was: A system dependency sun/security/provider/certpath is missing from wildfly's module.xml)
> A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1705
> URL: https://issues.jboss.org/browse/WFCORE-1705
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 2.2.0.Final
> Reporter: Peter Nalyvayko
> Assignee: David Lloyd
> Priority: Blocker
> Labels: jboss
>
> There is a system dependency path "sun/security/provider/certpath" missing from modules\system\layers\base\sun\jdk\main\module.xml. This is causing class def not found exception when attempting to create an instance of a class from that namespace. The module contents (abbreviated) are shown below. Notice that the path to "sun/security/provider/certpath" is not listed in there:
> {{<module xmlns="urn:jboss:module:1.3" name="sun.jdk">
> <resources>
> <!-- currently jboss modules has not way of importing services from
> classes.jar so we duplicate them here -->
> <resource-root path="service-loader-resources"/>
> </resources>
> <dependencies>
> <module name="sun.scripting" export="true"/>
> <system export="true">
> <paths>
> ...
> <path name="sun/security/action"/>
> <path name="sun/security/pkcs"/>
> <path name="sun/security/x509"/>
> <path name="sun/security"/>
> <path name="sun/security/util"/>
> <path name="sun/security/krb5"/>
> <path name="sun/security/krb5/internal"/>
> <path name="sun/security/pkcs11"/>
> <path name="sun/security/provider"/>
> ...
> </paths>
> <exports>
> <include-set>
> <path name="META-INF/services"/>
> </include-set>
> </exports>
> </system>
> </dependencies>
> </module>
> }}Manually adding the missing system dependency path fixes the issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1705) A system dependency sun/security/provider/certpath is missing from wildfly's module.xml
by Peter Nalyvayko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1705?page=com.atlassian.jira.plugi... ]
Peter Nalyvayko updated WFCORE-1705:
------------------------------------
Priority: Blocker (was: Major)
> A system dependency sun/security/provider/certpath is missing from wildfly's module.xml
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1705
> URL: https://issues.jboss.org/browse/WFCORE-1705
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 2.2.0.Final
> Reporter: Peter Nalyvayko
> Assignee: David Lloyd
> Priority: Blocker
> Labels: jboss
>
> There is a system dependency path "sun/security/provider/certpath" missing from modules\system\layers\base\sun\jdk\main\module.xml. This is causing class def not found exception when attempting to create an instance of a class from that namespace. The module contents (abbreviated) are shown below. Notice that the path to "sun/security/provider/certpath" is not listed in there:
> {{<module xmlns="urn:jboss:module:1.3" name="sun.jdk">
> <resources>
> <!-- currently jboss modules has not way of importing services from
> classes.jar so we duplicate them here -->
> <resource-root path="service-loader-resources"/>
> </resources>
> <dependencies>
> <module name="sun.scripting" export="true"/>
> <system export="true">
> <paths>
> ...
> <path name="sun/security/action"/>
> <path name="sun/security/pkcs"/>
> <path name="sun/security/x509"/>
> <path name="sun/security"/>
> <path name="sun/security/util"/>
> <path name="sun/security/krb5"/>
> <path name="sun/security/krb5/internal"/>
> <path name="sun/security/pkcs11"/>
> <path name="sun/security/provider"/>
> ...
> </paths>
> <exports>
> <include-set>
> <path name="META-INF/services"/>
> </include-set>
> </exports>
> </system>
> </dependencies>
> </module>
> }}Manually adding the missing system dependency path fixes the issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1705) A system dependency sun/security/provider/certpath is missing from wildfly's module.xml
by Peter Nalyvayko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1705?page=com.atlassian.jira.plugi... ]
Peter Nalyvayko updated WFCORE-1705:
------------------------------------
Issue Type: Bug (was: Feature Request)
> A system dependency sun/security/provider/certpath is missing from wildfly's module.xml
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1705
> URL: https://issues.jboss.org/browse/WFCORE-1705
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 2.2.0.Final
> Reporter: Peter Nalyvayko
> Assignee: David Lloyd
> Labels: jboss
>
> There is a system dependency path "sun/security/provider/certpath" missing from modules\system\layers\base\sun\jdk\main\module.xml. This is causing class def not found exception when attempting to create an instance of a class from that namespace. The module contents (abbreviated) are shown below. Notice that the path to "sun/security/provider/certpath" is not listed in there:
> {{<module xmlns="urn:jboss:module:1.3" name="sun.jdk">
> <resources>
> <!-- currently jboss modules has not way of importing services from
> classes.jar so we duplicate them here -->
> <resource-root path="service-loader-resources"/>
> </resources>
> <dependencies>
> <module name="sun.scripting" export="true"/>
> <system export="true">
> <paths>
> ...
> <path name="sun/security/action"/>
> <path name="sun/security/pkcs"/>
> <path name="sun/security/x509"/>
> <path name="sun/security"/>
> <path name="sun/security/util"/>
> <path name="sun/security/krb5"/>
> <path name="sun/security/krb5/internal"/>
> <path name="sun/security/pkcs11"/>
> <path name="sun/security/provider"/>
> ...
> </paths>
> <exports>
> <include-set>
> <path name="META-INF/services"/>
> </include-set>
> </exports>
> </system>
> </dependencies>
> </module>
> }}Manually adding the missing system dependency path fixes the issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months