Upgrade to WildFly 30.0 and Java 11

373 views
Skip to first unread message

Sergey Scherbina

unread,
Mar 19, 2024, 10:49:41 AM3/19/24
to WildFly
There is a Java 8 application working fine on WildFly v.26.1.Final.
 
It uses AWS security with embedded WildFly support of OIDC as described here:

https://wildfly-security.github.io/wildfly-elytron/blog/securing-wildfly-apps-openid-connect/

Now we are trying to migrate to the last version of WildFly (30.0.1.Final was last tried) and accordingly to Jackarta EE 10 and Java 11.

After resolved all issues with compilation and runtime dependencies described here

https://blogs.oracle.com/javamagazine/post/transition-from-java-ee-to-jakarta-ee

there are still several issues which I can't find any solutions.

First issue is about security domains configuration. On the start it fails with this error:

java.lang.IllegalStateException: ELY01148:
  A SecurityDomain has already been associated with the specified ClassLoader
    at org.wildfly.secu...@2.2.2.Final/
    /org.wildfly.security.auth.server.SecurityDomain.registerWithClassLoader(SecurityDomain.java:152)

I've investigated the issue in debugger and it happens that way - at first "virtual" OIDC security domain is injected in classl-loader before everything else, and then WildFly tries to inject custom security domain from our configuration in usual order, but it fails because there is already injected "virtual" domain from OIDC.

That configuration (including OIDC) is working perfect in WildFly 26, so it seems coming from new Jackarta EE 10 changes which are in WildFly 30. Are there any possible solutions or workarounds?

What is worth to check to find the cause of issue and a solution?

Other issue with completely unclear reason:

 Caused by: java.lang.NoClassDefFoundError: javax/transaction/UserTransaction
    at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
    at java.base/java.lang.Class.getMethods(Class.java:1904)
    at java.desktop/java.beans.Introspector.getBeanInfo(Introspector.java:195)
    at deployment.ear//org.quartz.impl.StdSchedulerFactory.setBeanProps(StdSchedulerFactory.java:1453)

Note, please: there is no usage of javax.transaction.UserTransaction class in current build for Java 11 - all javax.* references and dependencies are replaced to jakarta.* respectively.

I have investigated that issue in debugger and have seen on my own eyes that some replacement of class references happens in native method java.base/java.lang.Class.getDeclaredMethods0, which IMHO seems really insane - how it possible to happens? It may need to start separate thread of discussion, but so far I keep it here together just for simpler watching.

Please, feel free to ask or suggest anything helpful or related to these issues.

Thank you in advance!

With respect,
Sergiy
Reply all
Reply to author
Forward
0 new messages