Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-17505

Provisioning just the standalone-full.xml fails due to missing modules referenced in the config

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • Build System
    • None
    • ---
    • ---

      Provisioning a bootable jar with the

      <included-default-config>standalone-full.xml</included-default-config>

      option results in a jar that won't boot. The 'com.h2database.h2' and 'org.wildfly.openssl' are both referenced in standalone-full.xml, but the modules are not provisioned. The 'org.jboss.as.webservices.server.integration' also isn't provisioned.

      Adding this plug-option does not help:

      <optional-packages>passive+</optional-packages>

      My impression from looking at AbstractGalleonConfig.setupPluginOptions() is that setting optional-packages to passive+ shouldn't be required anyway.

      I'm discussing standalone-full.xml here, but I expect if I tried I'd see the same thing with standalone.xml, standalone-ha.xml and standalone-full-ha.xml. The standalone-microprofile.xml and standalone-microprofile-ha.xml configs do not have the problem. I believe that is because those use layers, and for each of the missing modules a relevant layer explicitly declares it as a package.

      I see three aspects to this:

      1) com.h2database.h2. Resolving this would either require new Galleon functionality like WFGP-238, or we move all the standard configs to using layers. I assume the latter will be the short term solution.

      2) org.wildfly.openssl. Here there may be a Galleon or wildfly-jar-maven-plugin bug. The io.undertow.core module has an optional dep on this, so AFAICT passive+ should result in it being provisioned. If I've missed something and there's a valid reason passive+ doesn't provision it, then this is another case like com.h2database.h2.

      3) org.jboss.as.webservices.server.integration. Here I think there's a webservices bug that likely should be handled under a different issue. My impression is if the subsystem is used this module must always be provisioned, but there is nothing telling Galleon this. It has a lot of dependencies, so relying on passive+ is not safe. Either the WS extension module should add a dependency or its ResourceDefinition should declare the dependency.

      I focus on bootable jar here but it would not surprise me if provisioning using the galleon-maven-plugin or the Galleon CLI tool with the '--default-configs=standalone-full.xml' option has similar issues.

            jdenise@redhat.com Jean Francois Denise
            bstansbe@redhat.com Brian Stansberry
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: