Strange Deployment Warning

[Arnie Morein]

I'm migrating old JDK8/J2EE code to Wildly 28 and JDK 17.

The build is fine and the EAR deploys, but I get one of these for every module. 

I do not understand why it's happening since WLF is running on JDK17, which the code was compiled for use within WLF 28. Of course, the module-info.class file has the acc_module  flag is set!

What's this all about?

10:12:30,963 WARN  [org.jboss.modules.define] (MSC service thread 1-3) Failed to define class module-info in Module "jakarta.ejb.api" version 4.0.1 from local module loader @1894071 (finder: local module finder @2afee2ee (roots: C:\dev\jboss\wildfly-28.0.1.Final\modules,C:\dev\jboss\wildfly-28.0.1.Final\modules\system\layers\base,C:\dev\jboss\wildfly-28.0.1.Final\modules\system\layers\hhs)): java.lang.NoClassDefFoundError: Failed to link module-info (Module "jakarta.ejb.api" version 4.0.1 from local module loader @1894071 (finder: local module finder @2afee2ee (roots: C:\dev\jboss\wildfly-28.0.1.Final\modules,C:\dev\jboss\wildfly-28.0.1.Final\modules\system\layers\base,C:\dev\jboss\wildfly-28.0.1.Final\modules\system\layers\hhs))): module-info is not a class because access_flag ACC_MODULE is set

        at java.base/java.lang.ClassLoader.defineClass1(Native Method)

        at java.base/java.lang.ClassLoader._jr$defineClass(ClassLoader.java:1017)

        at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:43016)

        at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:350)

        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482)

        at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:276)

        at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79)

        at org.jboss.modules.Module.loadModuleClass(Module.java:765)

        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:192)

        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 org.jbos...@28.0.1.Final//org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68)

        at org.jboss...@5.1.0.Final//org.jboss.weld.WebAppBeanDeploymentArchiveUtil.loadNewClasses(WebAppBeanDeploymentArchiveUtil.java:126)

        at org.jbos...@28.0.1.Final//org.jboss.as.weld.deployment.BeanDeploymentArchiveImpl._scan(BeanDeploymentArchiveImpl.java:50014)

        at org.jbos...@28.0.1.Final//org.jboss.as.weld.deployment.BeanDeploymentArchiveImpl.jrRescan(BeanDeploymentArchiveImpl.java:57001)

        at org.jbos...@28.0.1.Final//org.jboss.as.weld.deployment.processors.BeanArchiveProcessor$ResourceRootHandler.handleResourceRoot(BeanArchiveProcessor.java:238)

        at org.jbos...@28.0.1.Final//org.jboss.as.weld.deployment.processors.BeanArchiveProcessor.deploy(BeanArchiveProcessor.java:119)

        at org.jboss...@20.0.2.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)

        at org.jb...@1.5.0.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1590)

        at org.jb...@1.5.0.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1553)

        at org.jb...@1.5.0.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1411)

        at org.jbos...@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)

        at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)

        at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)

        at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)

[luca stancapiano]

Hi Arnie,

those WARN logs are basically telling you that the container tried to treat module-info.class as a normal class, but since it has the ACC_MODULE flag set it cannot be linked as such, hence the NoClassDefFoundError: module-info is not a class because access_flag ACC_MODULE is set.

On JDK 17 with WildFly 28 this is usually harmless and comes from classpath/module scanning (Weld, etc.) bumping into JPMS module descriptors in libraries like jakarta.ejb.api.
If the rest of the deployment works correctly and you do not see actual failures, you can generally treat these as noisy warnings rather than a real deployment problem.

If they bother you, you might want to check that you are using the WildFly‑provided Jakarta APIs instead of bundling your own copies in the EAR, so that the server does not scan duplicate modules.

Best regards,
Luca Stancapiano

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/8af92a62-ac5f-4f13-8f45-59f6cc90f7e8n%40googlegroups.com.