-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
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.
- is related to
-
WFLY-16863 Express default standalone configurations with Galleon layers
- Closed