[JBoss JIRA] (WFCORE-3770) CNFE: sun.security.x509.X500Name from module elytron-private
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3770?page=com.atlassian.jira.plugi... ]
Martin Choma updated WFCORE-3770:
---------------------------------
Description:
with new style (jboss-modules 1.8 + ) of dependencies in elytron-private module (no sun.jdk module) I see this exception
{noformat}
15:29:14,654 TRACE [org.wildfly.security] (management task-1) X550Name.asX500Principal() is not available.: java.lang.ClassNotFoundException: sun.security.x509.X500Name from [Module "org.wildfly.security.elytron-private" version 1.2.4.Final from local module loader @17f6480 (finder: local module finder @2d6e8792 (roots: /home/mchoma/Repos/tests-security/elytron/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-security/elytron/target/dist/jboss-eap/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.wildfly.security.x500.util.X500PrincipalUtil.<clinit>(X500PrincipalUtil.java:54)
{noformat}
This exception is not breaking anything. Just create unnecessary log noise on TRACE level.
Either we need to:
* wait for ELY-1569
* somehow add back dependency on sun.security.x509 package to elytron-private module
was:
with new (jboss-modules 1.8 + ) style of dependencies is used in elytron-private module (no sun.jdk module) and I am experiencing this exception
{noformat}
15:29:14,654 TRACE [org.wildfly.security] (management task-1) X550Name.asX500Principal() is not available.: java.lang.ClassNotFoundException: sun.security.x509.X500Name from [Module "org.wildfly.security.elytron-private" version 1.2.4.Final from local module loader @17f6480 (finder: local module finder @2d6e8792 (roots: /home/mchoma/Repos/tests-security/elytron/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-security/elytron/target/dist/jboss-eap/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.wildfly.security.x500.util.X500PrincipalUtil.<clinit>(X500PrincipalUtil.java:54)
{noformat}
This exception is not breaking anything. Just create unnecessary log noise on TRACE level.
Either we need to:
* wait for ELY-1569
* somehow add back dependency on sun.security.x509 package to elytron-private module
> CNFE: sun.security.x509.X500Name from module elytron-private
> ------------------------------------------------------------
>
> Key: WFCORE-3770
> URL: https://issues.jboss.org/browse/WFCORE-3770
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 5.0.0.Alpha3
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Optional
>
> with new style (jboss-modules 1.8 + ) of dependencies in elytron-private module (no sun.jdk module) I see this exception
> {noformat}
> 15:29:14,654 TRACE [org.wildfly.security] (management task-1) X550Name.asX500Principal() is not available.: java.lang.ClassNotFoundException: sun.security.x509.X500Name from [Module "org.wildfly.security.elytron-private" version 1.2.4.Final from local module loader @17f6480 (finder: local module finder @2d6e8792 (roots: /home/mchoma/Repos/tests-security/elytron/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-security/elytron/target/dist/jboss-eap/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.wildfly.security.x500.util.X500PrincipalUtil.<clinit>(X500PrincipalUtil.java:54)
> {noformat}
> This exception is not breaking anything. Just create unnecessary log noise on TRACE level.
> Either we need to:
> * wait for ELY-1569
> * somehow add back dependency on sun.security.x509 package to elytron-private module
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFCORE-3770) CNFE: sun.security.x509.X500Name from module elytron-private
by Martin Choma (JIRA)
Martin Choma created WFCORE-3770:
------------------------------------
Summary: CNFE: sun.security.x509.X500Name from module elytron-private
Key: WFCORE-3770
URL: https://issues.jboss.org/browse/WFCORE-3770
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 5.0.0.Alpha3
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Optional
with new (jboss-modules 1.8 + ) style of dependencies is used in elytron-private module (no sun.jdk module) and I am experiencing this exception
{noformat}
15:29:14,654 TRACE [org.wildfly.security] (management task-1) X550Name.asX500Principal() is not available.: java.lang.ClassNotFoundException: sun.security.x509.X500Name from [Module "org.wildfly.security.elytron-private" version 1.2.4.Final from local module loader @17f6480 (finder: local module finder @2d6e8792 (roots: /home/mchoma/Repos/tests-security/elytron/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-security/elytron/target/dist/jboss-eap/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.wildfly.security.x500.util.X500PrincipalUtil.<clinit>(X500PrincipalUtil.java:54)
{noformat}
This exception is not breaking anything. Just create unnecessary log noise on TRACE level.
Either we need to:
* wait for ELY-1569
* somehow add back dependency on sun.security.x509 package to elytron-private module
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (ELY-1569) Revisit X500PrincipalUtil optimalisation
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1569?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1569:
------------------------------
Description:
Reason why it was added may be fixed in OpenJDK already. David thinks so, but I was not able to find issue for that.
Note, this was needed for older java 1.8 releases. So user with older java in use can experience problems with fixed Elytron. Must migrate to newer version of java.
{code:java|title=X500PrncipalUtil}
static {
Class<?> x500Name = null;
MethodHandle asX500PrincipalHandle = null;
try {
x500Name = Class.forName("sun.security.x509.X500Name", true, X500PrincipalUtil.class.getClassLoader());
asX500PrincipalHandle = MethodHandles.publicLookup().unreflect(x500Name.getDeclaredMethod("asX500Principal"));
} catch (Throwable t) {
/*
* This is intended to be a best efforts optimisation, if it fails for ANY reason we don't support the optimisation
* and resort to default behaviour.
*
* Throwing any Exception or Error from this static block results in a NoClassDefFoundError for any access to the
* class and subsequently even the non-optimised scenario is unavailable.
*/
log.trace("X550Name.asX500Principal() is not available.", t);
}
X500_NAME_CLASS = x500Name;
AS_X500_PRINCIPAL_HANDLE = asX500PrincipalHandle;
}
{code}
Related hipchat discussion
{noformat}
David Lloyd·Apr-26 3:44 PM
what JDK version?
that's not really an error per se
Darran Lofthouse·Apr-26 3:46 PM
it's a feature ;-)
David Lloyd·Apr-26 3:47 PM
tbh it's probably not needed anymore; the original code there is 3 years old
Martin Choma·Apr-26 3:48 PM
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
David Lloyd·Apr-26 3:48 PM
I think the original issue was fixed in openjdk a while back
Martin Choma·Apr-26 4:57 PM
David, I can see the exception on the Oracle JDK 1.8.0_172 as well
Darran Lofthouse·Apr-26 5:05 PM
Is the optimisation provided by that class still beneficial?
David Lloyd·Apr-26 5:11 PM
it's required for older 1.8 releases
note that it's a TRACE message though
it's not an error, it's just indicating that the detection of the internal type failed
so it won't be used
I did previously get a directive that we need not support older 1.8 releases though
so we could drop that code if desired
this would be considered code cleanup, so it's not an enhancement and not a bug fix
Martin Choma·Apr-26 5:20 PM
"1.8 releases" you mean jboss-modules 1.8?
and when searching internal type failed, which will be used then?
Darran Lofthouse·Apr-26 5:22 PM
If that type is not found and convert set to true we pass the name into the X500Principal constructor
David Lloyd·Apr-26 5:24 PM
no @MartinChoma I mean older Java 8 releases
older versions of Java returned X500Name for certain certificate methods instead of X500Principal
if you weren't ready for that, you can end up with an unexpected error condition
Martin Choma·Apr-26 5:32 PM
and now as jdk is fixed we can remove that workaround?
David Lloyd·Apr-26 5:32 PM
yes it should be safe
Martin Choma·Apr-26 5:34 PM
also for ibm jdk?
David Lloyd·Apr-26 5:34 PM
IBM never had the problem AFAIK
Martin Choma·Apr-26 5:50 PM
It would be nice if we know the JDK issue, but I can't find the one.
{noformat}
was:
Reason why it was added may be fixed in OpenJDK already. David thinks so, but I was not able to find issue for that.
Note, this was needed for older java 1.8 releases. So user with older java in use can experience problems with fixed Elytron. Must migrate to newer version of java.
{code}
static {
Class<?> x500Name = null;
MethodHandle asX500PrincipalHandle = null;
try {
x500Name = Class.forName("sun.security.x509.X500Name", true, X500PrincipalUtil.class.getClassLoader());
asX500PrincipalHandle = MethodHandles.publicLookup().unreflect(x500Name.getDeclaredMethod("asX500Principal"));
} catch (Throwable t) {
/*
* This is intended to be a best efforts optimisation, if it fails for ANY reason we don't support the optimisation
* and resort to default behaviour.
*
* Throwing any Exception or Error from this static block results in a NoClassDefFoundError for any access to the
* class and subsequently even the non-optimised scenario is unavailable.
*/
log.trace("X550Name.asX500Principal() is not available.", t);
}
X500_NAME_CLASS = x500Name;
AS_X500_PRINCIPAL_HANDLE = asX500PrincipalHandle;
}
{code}
Related hipchat discussion
{noformat}
David Lloyd·Apr-26 3:44 PM
what JDK version?
that's not really an error per se
Darran Lofthouse·Apr-26 3:46 PM
it's a feature ;-)
David Lloyd·Apr-26 3:47 PM
tbh it's probably not needed anymore; the original code there is 3 years old
Martin Choma·Apr-26 3:48 PM
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
David Lloyd·Apr-26 3:48 PM
I think the original issue was fixed in openjdk a while back
Martin Choma·Apr-26 4:57 PM
David, I can see the exception on the Oracle JDK 1.8.0_172 as well
Darran Lofthouse·Apr-26 5:05 PM
Is the optimisation provided by that class still beneficial?
David Lloyd·Apr-26 5:11 PM
it's required for older 1.8 releases
note that it's a TRACE message though
it's not an error, it's just indicating that the detection of the internal type failed
so it won't be used
I did previously get a directive that we need not support older 1.8 releases though
so we could drop that code if desired
this would be considered code cleanup, so it's not an enhancement and not a bug fix
Martin Choma·Apr-26 5:20 PM
"1.8 releases" you mean jboss-modules 1.8?
and when searching internal type failed, which will be used then?
Darran Lofthouse·Apr-26 5:22 PM
If that type is not found and convert set to true we pass the name into the X500Principal constructor
David Lloyd·Apr-26 5:24 PM
no @MartinChoma I mean older Java 8 releases
older versions of Java returned X500Name for certain certificate methods instead of X500Principal
if you weren't ready for that, you can end up with an unexpected error condition
Martin Choma·Apr-26 5:32 PM
and now as jdk is fixed we can remove that workaround?
David Lloyd·Apr-26 5:32 PM
yes it should be safe
Martin Choma·Apr-26 5:34 PM
also for ibm jdk?
David Lloyd·Apr-26 5:34 PM
IBM never had the problem AFAIK
Martin Choma·Apr-26 5:50 PM
It would be nice if we know the JDK issue, but I can't find the one.
{noformat}
> Revisit X500PrincipalUtil optimalisation
> ----------------------------------------
>
> Key: ELY-1569
> URL: https://issues.jboss.org/browse/ELY-1569
> Project: WildFly Elytron
> Issue Type: Bug
> Components: X.500
> Affects Versions: 1.3.0.Final
> Reporter: Martin Choma
> Priority: Optional
>
> Reason why it was added may be fixed in OpenJDK already. David thinks so, but I was not able to find issue for that.
> Note, this was needed for older java 1.8 releases. So user with older java in use can experience problems with fixed Elytron. Must migrate to newer version of java.
> {code:java|title=X500PrncipalUtil}
> static {
> Class<?> x500Name = null;
> MethodHandle asX500PrincipalHandle = null;
> try {
> x500Name = Class.forName("sun.security.x509.X500Name", true, X500PrincipalUtil.class.getClassLoader());
> asX500PrincipalHandle = MethodHandles.publicLookup().unreflect(x500Name.getDeclaredMethod("asX500Principal"));
> } catch (Throwable t) {
> /*
> * This is intended to be a best efforts optimisation, if it fails for ANY reason we don't support the optimisation
> * and resort to default behaviour.
> *
> * Throwing any Exception or Error from this static block results in a NoClassDefFoundError for any access to the
> * class and subsequently even the non-optimised scenario is unavailable.
> */
> log.trace("X550Name.asX500Principal() is not available.", t);
> }
> X500_NAME_CLASS = x500Name;
> AS_X500_PRINCIPAL_HANDLE = asX500PrincipalHandle;
> }
> {code}
> Related hipchat discussion
> {noformat}
> David Lloyd·Apr-26 3:44 PM
> what JDK version?
> that's not really an error per se
> Darran Lofthouse·Apr-26 3:46 PM
> it's a feature ;-)
> David Lloyd·Apr-26 3:47 PM
> tbh it's probably not needed anymore; the original code there is 3 years old
> Martin Choma·Apr-26 3:48 PM
> java version "1.8.0_161"
> Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
> David Lloyd·Apr-26 3:48 PM
> I think the original issue was fixed in openjdk a while back
> Martin Choma·Apr-26 4:57 PM
> David, I can see the exception on the Oracle JDK 1.8.0_172 as well
> Darran Lofthouse·Apr-26 5:05 PM
> Is the optimisation provided by that class still beneficial?
> David Lloyd·Apr-26 5:11 PM
> it's required for older 1.8 releases
> note that it's a TRACE message though
> it's not an error, it's just indicating that the detection of the internal type failed
> so it won't be used
> I did previously get a directive that we need not support older 1.8 releases though
> so we could drop that code if desired
> this would be considered code cleanup, so it's not an enhancement and not a bug fix
> Martin Choma·Apr-26 5:20 PM
> "1.8 releases" you mean jboss-modules 1.8?
> and when searching internal type failed, which will be used then?
> Darran Lofthouse·Apr-26 5:22 PM
> If that type is not found and convert set to true we pass the name into the X500Principal constructor
> David Lloyd·Apr-26 5:24 PM
> no @MartinChoma I mean older Java 8 releases
> older versions of Java returned X500Name for certain certificate methods instead of X500Principal
> if you weren't ready for that, you can end up with an unexpected error condition
> Martin Choma·Apr-26 5:32 PM
> and now as jdk is fixed we can remove that workaround?
> David Lloyd·Apr-26 5:32 PM
> yes it should be safe
> Martin Choma·Apr-26 5:34 PM
> also for ibm jdk?
> David Lloyd·Apr-26 5:34 PM
> IBM never had the problem AFAIK
> Martin Choma·Apr-26 5:50 PM
> It would be nice if we know the JDK issue, but I can't find the one.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (ELY-1569) Revisit X500PrincipalUtil optimalisation
by Martin Choma (JIRA)
Martin Choma created ELY-1569:
---------------------------------
Summary: Revisit X500PrincipalUtil optimalisation
Key: ELY-1569
URL: https://issues.jboss.org/browse/ELY-1569
Project: WildFly Elytron
Issue Type: Bug
Components: X.500
Affects Versions: 1.3.0.Final
Reporter: Martin Choma
Priority: Optional
Reason why it was added may be fixed in OpenJDK already. David thinks so, but I was not able to find issue for that.
Note, this was needed for older java 1.8 releases. So user with older java in use can experience problems with fixed Elytron. Must migrate to newer version of java.
{code}
static {
Class<?> x500Name = null;
MethodHandle asX500PrincipalHandle = null;
try {
x500Name = Class.forName("sun.security.x509.X500Name", true, X500PrincipalUtil.class.getClassLoader());
asX500PrincipalHandle = MethodHandles.publicLookup().unreflect(x500Name.getDeclaredMethod("asX500Principal"));
} catch (Throwable t) {
/*
* This is intended to be a best efforts optimisation, if it fails for ANY reason we don't support the optimisation
* and resort to default behaviour.
*
* Throwing any Exception or Error from this static block results in a NoClassDefFoundError for any access to the
* class and subsequently even the non-optimised scenario is unavailable.
*/
log.trace("X550Name.asX500Principal() is not available.", t);
}
X500_NAME_CLASS = x500Name;
AS_X500_PRINCIPAL_HANDLE = asX500PrincipalHandle;
}
{code}
Related hipchat discussion
{noformat}
David Lloyd·Apr-26 3:44 PM
what JDK version?
that's not really an error per se
Darran Lofthouse·Apr-26 3:46 PM
it's a feature ;-)
David Lloyd·Apr-26 3:47 PM
tbh it's probably not needed anymore; the original code there is 3 years old
Martin Choma·Apr-26 3:48 PM
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
David Lloyd·Apr-26 3:48 PM
I think the original issue was fixed in openjdk a while back
Martin Choma·Apr-26 4:57 PM
David, I can see the exception on the Oracle JDK 1.8.0_172 as well
Darran Lofthouse·Apr-26 5:05 PM
Is the optimisation provided by that class still beneficial?
David Lloyd·Apr-26 5:11 PM
it's required for older 1.8 releases
note that it's a TRACE message though
it's not an error, it's just indicating that the detection of the internal type failed
so it won't be used
I did previously get a directive that we need not support older 1.8 releases though
so we could drop that code if desired
this would be considered code cleanup, so it's not an enhancement and not a bug fix
Martin Choma·Apr-26 5:20 PM
"1.8 releases" you mean jboss-modules 1.8?
and when searching internal type failed, which will be used then?
Darran Lofthouse·Apr-26 5:22 PM
If that type is not found and convert set to true we pass the name into the X500Principal constructor
David Lloyd·Apr-26 5:24 PM
no @MartinChoma I mean older Java 8 releases
older versions of Java returned X500Name for certain certificate methods instead of X500Principal
if you weren't ready for that, you can end up with an unexpected error condition
Martin Choma·Apr-26 5:32 PM
and now as jdk is fixed we can remove that workaround?
David Lloyd·Apr-26 5:32 PM
yes it should be safe
Martin Choma·Apr-26 5:34 PM
also for ibm jdk?
David Lloyd·Apr-26 5:34 PM
IBM never had the problem AFAIK
Martin Choma·Apr-26 5:50 PM
It would be nice if we know the JDK issue, but I can't find the one.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months