Private/unsupported modules in JBoss EAP

Solution Verified - Updated -

Environment

  • Red Hat JBoss Enterprise Application Platform (EAP)

Issue

  • Receving a warning in regards to modules being private or unsupported:

    • EAP 7 and EAP 8

      WARN  [org.jboss.as.dependency.private] (MSC service thread 1-8) WFLYSRV0018: Deployment "deployment.jaxp.jar" is using a private module ("org.jboss.as.cli") which may be changed or removed in future versions without notice.

    • EAP 6

      WARN  [org.jboss.as.dependency.private] (MSC service thread 1-6) JBAS018567: Deployment "deployment.com.aaa.bbb.test.zzz.ear" is using a private module ("com.sun.jsf-impl:1.2") which may be changed or removed in future versions without notice.

WARN  [org.jboss.as.dependency.unsupported] (MSC service thread 1-2) JBAS018568: Deployment "deployment.com.aaa.bbb.test.zzz.ear" is using an unsupported module ("org.infinispan:main") which may be changed or removed in future versions without notice.

  • Depend on private or unsupported modules

  • We have recently found that the JBoss dependency included in our latest product to fix an issue is marked by Red Hat as private. Is there a possible way to make this public rather than private. Or is there a workaround?

Resolution

  • Private modules are used by JBoss internally. When one sets a dependency on a private, they will get above WARN message letting them know that a dependency is set on a private module (which should ultimately be avoided). There wouldn't be any adverse effects with respect to functionality if the application is depending on a private module.
  • The private modules can be considered as Preview modules. It will be the first release of the jars. These private modules will undergo technical reviews. Once the module is reviewed & tested then it might be bundled as a public module.
  • The risks in using private modules are only that Red Hat does not provide fixes that result from the use of unsupported modules. Except those, there are no more risks in using private modules. Complete list of modules
  • Use public JDK, JavaEE, and JBoss API's and not private API's. Third party frameworks can be packaged in the application instead of using private modules that JBoss uses internally. But the best workaround instead of using private modules is by packaging them as custom modules.

Diagnostic Steps

  • Review the logs.
  • Check the jboss-deployment-structure.xml to verify if an unsupported or private module is being referenced.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments