WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory ...

[nicolasduminil]

Hello,

I'm using wildfly-jar-maven-plugin:10.0.0.Final to provision a wildfly bootable 30.0.1.Final. Here is the config:

      <plugin>
        <groupId>org.wildfly.plugins</groupId>
        <artifactId>wildfly-jar-maven-plugin</artifactId>
        <configuration>
          <feature-pack-location>wildfly@maven(org.jboss.universe:community-universe)#${wildfly.version}
          </feature-pack-location>
          <layers>
            <layer>jaxrs</layer>
            <layer>elytron</layer>
            <layer>ee-security</layer>
          </layers>
          <excluded-layers>
            <layer>deployment-scanner</layer>
          </excluded-layers>
          <hollow-jar>true</hollow-jar>
          <output-file-name>server-layer.jar</output-file-name>
          <plugin-options>
            <jboss-fork-embedded>true</jboss-fork-embedded>
          </plugin-options>
          <cli-sessions>
            <cli-session>
              <script-files>
                <script>create-realm.cli</script>
              </script-files>
            </cli-session>
          </cli-sessions>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>package</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

This is a hollow JAR. Then, I create a JIB base image and I extend it to add an application deployed as ROOT.war. Running the final image with Docker raises the following exception:

17:14:22,585 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /secured: org.glassfish.soteria.identitystores.IdentityStoreRuntimeException: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "deployment.ROOT.war" from Service Module Loader [Root exception is java.lang.IllegalAccessException: class org.jboss.as.naming.InitialContext cannot access class com.sun.jndi.ldap.LdapCtxFactory (in module java.naming) because module java.naming does not export com.sun.jndi.ldap to unnamed module @34d8388b]

However, looking in the hollow JAR MANIFEST.MF file I can see:

Add-Exports: java.desktop/sun.awt java.naming/com.sun.jndi.ldap java.nam ing/com.sun.jndi.url.ldap java.naming/com.sun.jndi.url.ldaps jdk.naming .dns/com.sun.jndi.dns
Add-Opens: java.base/com.sun.net.ssl.internal.ssl java.base/java.lang ja va.base/java.lang.invoke java.base/java.lang.reflect java.base/java.io java.base/java.net java.base/java.security java.base/java.util java.bas e/java.util.concurrent java.management/javax.management java.naming/jav ax.naming

Isn't it supposed to avoid this exception ? Does the fact of extending the associated image have an impact in this case ? The final image is built with the JIB plugin, as follows:

      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <configuration>
          <from>
            <image>docker://wildfly-bootable/server-layer</image>
          </from>
          <to>
            <image>wildfly-bootable/app-layer</image>
          </to>
          <container>
            <entrypoint>INHERIT</entrypoint>
            <appRoot>/deployments/ROOT.war</appRoot>
          </container>
        </configuration>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>dockerBuild</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

The MANIFEST.MF file of the associated WAR doesn't contain the required Add-Exports and Add-Open as does the hollow JAR. Is that normal ?

In any case, what am I supposed to do in order to avoid this exception ?

Many thanks in advance.

Kind regards,
Nicolas

[jfdenise]

Hi,
It would really help to have a reproducer for your issue (having a simplified github project that highlights the problem).
I suspect that you could reproduce the problem on bare-metal, jib docker image shouldn't be bound to the problem.
Thank-you.