Apache NetBeans version
Apache NetBeans 25 / dev (longstanding; affects all current versions)
What happened
Registering a GlassFish 8.x Web Profile install via Services → Servers → Add Server → GlassFish Server fails: NetBeans reports the installation as invalid and refuses the directory. The Full distribution of the same version is accepted. Reported downstream at eclipse-ee4j/glassfish#26098.
Root cause
ServerWizardIterator.isValidInstall() (module enterprise/glassfish.common) gates on finding a jar in modules/ whose name matches ServerUtilities.GFV3_JAR_MATCHER:
glassfish(?:-[0-9bSNAPHOT]+(?:\.[0-9]+(?:_[0-9]+|)|).*|).jar
This was meant to find the kernel jar modules/glassfish.jar (or glassfish-<version>.jar) shipped by GlassFish 3–7.
In GlassFish 8.x there is no modules/glassfish.jar anymore — the bootstrap jar moved to lib/bootstrap/glassfish.jar, which getJarName() (it only scans modules/) never sees. Detection then falls back to matching the loose regex against whatever else is in modules/. Matching jars present (case-sensitive, as Java matches):
| Distribution |
modules/*.jar that match |
| Full |
glassfish-batch-commands.jar, glassfish-batch-connector.jar |
| Web Profile |
(none) |
The Full profile passes only by accident — glassfish-batch-*.jar matches because the char class [0-9bSNAPHOT] contains a lowercase b (glassfish-api.jar, glassfish-naming.jar, etc. do not match). The Web Profile excludes the Batch feature, so no jar qualifies, getJarName() returns null, and the install is rejected.
Note: NetBeans' actual version detection, ServerUtils.getServerVersion() (reads Bundle-Version from modules/common-util.jar), works for both profiles. Only the brittle glassfish*.jar presence gate fails.
Steps to reproduce
- Download Eclipse GlassFish 8.0.x Web Profile, unzip.
- Services → Servers → Add Server → GlassFish Server.
- Point the wizard at the unzipped directory → "the installation is invalid".
- Repeat with the Full distribution → accepted.
Proposed fix
In ServerWizardIterator.isValidInstall(), accept lib/bootstrap/glassfish.jar (present in every GF distribution, full and web) as a fallback when the legacy modules/glassfish*.jar is absent. Backward-compatible with GF 3–7; config/glassfish.container check and version resolution via getServerVersion() stay unchanged.
File jar = ServerUtilities.getJarName(glassfishDir.getAbsolutePath(), ServerUtilities.GFV3_JAR_MATCHER);
if (jar == null || !jar.exists()) {
File bootstrapJar = new File(glassfishDir,
"lib" + File.separator + "bootstrap" + File.separator + "glassfish.jar"); // NOI18N
if (!bootstrapJar.exists()) {
return null;
}
}
I'm happy to open a PR for this.
Are you willing to submit a pull request?
Yes
Apache NetBeans version
Apache NetBeans 25 / dev (longstanding; affects all current versions)
What happened
Registering a GlassFish 8.x Web Profile install via Services → Servers → Add Server → GlassFish Server fails: NetBeans reports the installation as invalid and refuses the directory. The Full distribution of the same version is accepted. Reported downstream at eclipse-ee4j/glassfish#26098.
Root cause
ServerWizardIterator.isValidInstall()(moduleenterprise/glassfish.common) gates on finding a jar inmodules/whose name matchesServerUtilities.GFV3_JAR_MATCHER:This was meant to find the kernel jar
modules/glassfish.jar(orglassfish-<version>.jar) shipped by GlassFish 3–7.In GlassFish 8.x there is no
modules/glassfish.jaranymore — the bootstrap jar moved tolib/bootstrap/glassfish.jar, whichgetJarName()(it only scansmodules/) never sees. Detection then falls back to matching the loose regex against whatever else is inmodules/. Matching jars present (case-sensitive, as Java matches):modules/*.jarthat matchglassfish-batch-commands.jar,glassfish-batch-connector.jarThe Full profile passes only by accident —
glassfish-batch-*.jarmatches because the char class[0-9bSNAPHOT]contains a lowercaseb(glassfish-api.jar,glassfish-naming.jar, etc. do not match). The Web Profile excludes the Batch feature, so no jar qualifies,getJarName()returnsnull, and the install is rejected.Note: NetBeans' actual version detection,
ServerUtils.getServerVersion()(readsBundle-Versionfrommodules/common-util.jar), works for both profiles. Only the brittleglassfish*.jarpresence gate fails.Steps to reproduce
Proposed fix
In
ServerWizardIterator.isValidInstall(), acceptlib/bootstrap/glassfish.jar(present in every GF distribution, full and web) as a fallback when the legacymodules/glassfish*.jaris absent. Backward-compatible with GF 3–7;config/glassfish.containercheck and version resolution viagetServerVersion()stay unchanged.I'm happy to open a PR for this.
Are you willing to submit a pull request?
Yes