[jboss-jira] [JBoss JIRA] (ELY-1569) Revisit X500PrincipalUtil optimalisation
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)