Skip to content

Fix GlassFish 8.x install detection when modules/glassfish.jar is absent#9442

Open
renatsaf wants to merge 1 commit into
apache:masterfrom
renatsaf:glassfish8-webprofile-detection-9441
Open

Fix GlassFish 8.x install detection when modules/glassfish.jar is absent#9442
renatsaf wants to merge 1 commit into
apache:masterfrom
renatsaf:glassfish8-webprofile-detection-9441

Conversation

@renatsaf

Copy link
Copy Markdown

Fixes #9441

What

The Add Server → GlassFish Server wizard rejects a GlassFish 8.x Web Profile installation as invalid, while accepting the Full distribution of the same version. Reported downstream at eclipse-ee4j/glassfish#26098.

Root cause

ServerWizardIterator.isValidInstall() requires 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. GlassFish 8 no longer ships it — 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/:

Distribution modules/*.jar that match (case-sensitive)
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.

Version detection itself is unaffected: ServerUtils.getServerVersion() (reads Bundle-Version from modules/common-util.jar) works for both profiles. Only the brittle jar-presence gate fails.

Fix

When the legacy modules/glassfish*.jar is absent, fall back to lib/bootstrap/glassfish.jar, which is present in every GlassFish distribution (full and web). This is backward compatible with GlassFish 3–7, and the config/glassfish.container check plus version resolution via getServerVersion() are left unchanged.

Testing

Verified against staged GlassFish 8.x builds: lib/bootstrap/glassfish.jar exists in both the full and web profile distributions, and neither has modules/glassfish.jar. With this change the web profile directory is accepted by the wizard; the full distribution and older (3–7) installs continue to be detected.

The Add Server wizard validated a GlassFish install by requiring a jar in
modules/ matching GFV3_JAR_MATCHER (originally modules/glassfish.jar from
GlassFish 3-7). GlassFish 8 removed that jar; the bootstrap jar moved to
lib/bootstrap/glassfish.jar, which getJarName() does not scan. The full
distribution still matches only by accident (glassfish-batch-*.jar), while
the Web Profile excludes Batch and so matches nothing, causing the wizard
to reject it as an invalid installation.

Accept lib/bootstrap/glassfish.jar (present in every distribution, full and
web) as a fallback. Backward compatible with GlassFish 3-7; the container
check and version resolution via getServerVersion() are unchanged.

Fixes apache#9441
@mbien mbien added Java EE/Jakarta EE [ci] enable enterprise job enterprise [ci] enable enterprise job ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) labels Jun 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) enterprise [ci] enable enterprise job Java EE/Jakarta EE [ci] enable enterprise job

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GlassFish 8.x Web Profile rejected by Add Server wizard (modules/glassfish.jar removed in GF 8)

2 participants