Add modulepath-prefix/modulepath-suffix to java-config (mirror classpath handling)

[renatsaf]

Background

Follow-up suggested by @OndroMih in #24350: add modulepath-prefix / modulepath-suffix to domain.xml and stop honoring a raw --module-path JVM option, mirroring how classpath is handled via classpath-prefix / classpath-suffix.

Current behavior

The launcher always emits a single module-path entry for the bootstrap modules:

--module-path <installRoot>/lib/bootstrap --add-modules ALL-MODULE-PATH

(see GlassFishMainLauncher.prepareCommandLine and CommandLine.appendModulePath).

A user-supplied <jvm-options>--module-path=...</jvm-options> is passed through separately as a raw JVM option (collected in JvmOptions.longProps), so it currently appears as a second --module-path on the command line. Since GlassFish 7.0.23 (PR #25381) ${...} tokens in that option are resolved, so --module-path=${com.sun.aas.instanceRoot}/lib/foo.jar works.

By contrast, classpath cannot be set as a raw JVM option; users extend it only through classpath-prefix / classpath-suffix, which the launcher merges into the single -cp value.

Proposal

1. Add modulepath-prefix and modulepath-suffix attributes to the java-config element (config-api JavaConfig bean, ServerTags, DTD, admin console where relevant).
2. Merge them into the single launcher module-path: prefix + lib/bootstrap + suffix.
3. Stop honoring a raw --module-path JVM option (reject/ignore it), so there is exactly one --module-path on the command line — mirroring classpath.

Tradeoff / open question (the reason this is filed separately)

Step 3 is a breaking change. The workaround that resolves #24350 today is exactly a raw --module-path=${com.sun.aas.instanceRoot}/lib/... in <jvm-options>. Disabling it would break existing users who rely on that. Options:

• (a) Implement steps 1–2 only (non-breaking): add modulepath-prefix/modulepath-suffix while still honoring a raw --module-path. Cleaner config, no regression, but two ways to do the same thing.
• (b) Implement steps 1–3 (breaking): full parity with classpath, but needs a deprecation path for the raw option and a clear migration note.

This also overlaps with #26058 (adding lib/ext to the classpath), which already gives a drop-in route for jars that don't strictly need the module path.

Requesting a maintainer decision on (a) vs (b) before implementation.

References

• Originating discussion: JCA Provider Support #24350
• Related feature: Add lib/ext directory to the classpath on Java 9+ (drop-in support for static JCA Providers) #26058
• Module-path token-substitution fix (already merged): PR Improvement: Prefer env vars in Docker and cloud environments #25381

[dmatej]

I think (I might be wrong) the module path prefix/suffix is a wrong way. In classpath case it was used in GlassFish 2 aka SJAS9 for the last time. However JPMS as more strict rules and doesn't allow having multiple modules with same ids in the same JVM if I remember well. Then the "ordering" doesn't make sense, all you need is some extension point (another directory where to put modules and load them automatically OR way to add them one by one).