Overview

Use (or not) of jboss-modules in the CLI or for embedded server boot has some areas that could be improved. Most of these issues are located around what versions of modules and / or which module directories are used. Generally a particular Wildfly version will be paired with a particular version of jboss-modules and $JBOSS_HOME/modules directory, used during server boot. We have several use cases of interest here:

General Use Cases:

[Note use of embedded-server below should be taken to represent usage of both the embedded-server and the embedded-host-controller]

(1) Use from inside the CLI, with existing jboss-modules: ('modular')

     In this case, jboss-cli.sh is started, followed by usage of the embed-server or embed-host-controller commands. The CLI already uses jboss-modules during loading, so currently subsequent calls to Module.get*ModuleLoader() are generally available, and shared between the CLI and embedded process. This is problematic in the case of wanting to start a CLI from one Wildfly location, but perhaps point to a different Wildfly location to run an embedded instance within that running CLI, as the Module roots are statically set to the CLI configured ones.

(2) Use without an existing jboss-modules ('non-modular')

This is how (for example) the bin/client/ jars use embedded. However, currently, even though jboss-modules are not already available on start, the embedded implementations obtain a ModuleLoader and use that to pass down to the booting embedded server. This shares similar issues to #1 with regard to ModuleLoader and roots being static and reused by subsequent executions of the embedded server within the same CLI.

(3) *New*: Using a current CLI, boot an older version of the embedded server. [This could be in addition to (1) or (2) above.]

(4) *New*: Using an older CLI, boot a newer version of the embedded server. [This could be in addition to (1) or (2) above.]

     I don't think this should be a supported configuration. Is there a use case for upgrading maybe?

(5) Wildfly-plugin for provisioning tool:

      <Need details>

(6) Migration tool:

     <Need details>. The migration tool does appear to have a need for #3 above, booting an older server.

(7) *New* Provisioning:

     <Need details>. Currently the example I have from provisioning is using the CLI to start two seperate wildfly instances. [Please add provisioning use cases below.]

(8) *New* JDK9:

     It is to be determined what (if any) JDK9 might have on these implementations.

(9) Existing user usage, applications and compatability

     These changes should remain backwardly compatible insofar has this is possible with existing programatic usage of the embedded-server. This means existing factory methods and interfaces etc.

(10) Additional cases, add as needed.

Issue Metadata:

Requirements

Hard Requirements

Nice-to-have Requirements

Non-Requirements

Issues

[This could be in addition to (1) or (2) above.]