3

I migrated a Web application that worked fine on WildFly 17 on Java 11 to the latest versions of both: WildFly 19 on Java 14. In the end I'm getting a ClassNotFoundException: java.security.acl.Group, probably because the Web application uses JAAS.

Note that a similar Web application built following a tutorial of my own worked fine, but it doesn't use JAAS. That and the package java.security.acl made me think JAAS is related.

Searching the Web I found issue WFCORE-4282 at WildFly's JIRA which seems to imply that although they knew this java.security.acl.Group class was deprecated more than a year ago, WildFly 19 still requires it and Java 14 did actually remove it, thus causing the ClassNotFoundException for me.

Is my interpretation correct? Does WildFly 19 + Java 14 + JAAS = ClassNotFoundException necessarily or has anyone managed to make it work? Or maybe I'm doing something wrong? It just seems to me such a huge problem for JBoss to have overlooked on WildFly...

Update: I removed Java 14, installed Java 13, reinstalled Eclipse and WildFly and redeployed de application and it worked, so WildFly 19 + Java 13 + JAAS = OK!

Vítor E. Silva Souza
  • 1,575
  • 1
  • 18
  • 23
  • Hi Vitor, did you ever find a solution to this that didn't involve downgrading to Java 13? As you said, it seems such a huge problem. – Richard Kennard Feb 05 '22 at 04:13
  • 1
    Hi @RichardKennard, since my use for these things is for educational purposes (I'm a college professor and I teach Web Development to undergrad/grad students), I downgraded to Java 13 for this to work at that time and in the next semester I ended up migrating to Jakarta Security, so I didn't have further issues with this. Sorry I can't be of more help here. – Vítor E. Silva Souza Feb 07 '22 at 12:12

3 Answers3

2

This has been resolved as of late 2021 (better late than never!). So you can now use JDK 17+ with WildFly 26+. Note, however, you have to make the non-trivial move from:

<subsystem xmlns="urn:jboss:domain:security:1.2">
...
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
...
</login-module>
</subsystem>

...to...

<subsystem xmlns="urn:wildfly:elytron:15.0">
...
<security-realms>
    <jdbc-realm>
    ...
    </jdbc-realm>
</security-realms>
</subsystem>

YMMV depending on your architecture, but basically you have to embrace Elytron.

Richard Kennard
  • 1,325
  • 11
  • 20
1

The java.security.acl API was terminally deprecated and has been removed in Java 14: see release notes:

https://jdk.java.net/14/release-notes

daniel
  • 2,665
  • 1
  • 8
  • 18
  • 1
    Yeah, that was what op said in the question. – Johannes Kuhn Jun 02 '20 at 13:02
  • 1
    Which means that Vitor's interpretation was correct which was the question ;-) But maybe I misread that - if so apologies for the noise. – daniel Jun 02 '20 at 13:06
  • 2
    Thanks, @daniel. My interpretation goes further: not only it was deprecated but the WildFly developers did nothing about it. The counter-interpretation is that *I* am doing something wrong. Releasing a version of WildFly that just won't work with Java 14 and JAAS is a huge problema IMHO. – Vítor E. Silva Souza Jun 02 '20 at 19:04
0

Error: java.lang.NoClassDefFoundError: java/security/acl/Group 19:23:14,951 ERROR [org.apache.activemq.artemis.core.client] (default I/O-11) AMQ214013: Failed to decode packet: java.lang.NoClassDefFoundError: java/security/acl/Group

Please try following workaround update standalone.xml and restart Server

add xml tag <security enabled="false"/>

<server name="default">
<security enabled="false"/>
<statistics enabled="${wildfly.messaging-activemq.statistics-enabled:${wildfly.statistics-enabled:false}}"/>
<security-setting name="#">
    <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
</security-setting>
Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
sanjay mishra
  • 31
  • 2