Redesign of GlassFish bootstrap

[dmatej]

Main feature changes

• Fixes JDK loggers can initialize the JDK LogManager before GlassFishLogManager is set #25133 - we use the standard JVM option, however complete initialization is finished by HK2 service.
• ClassLoaders reflect boot phases
• All our classloaders have names
• asenv.conf respects existing environment
• Server's logging manager is set by JVM option
• All our classloaders are "parallel capable".
• Asadmin and nadmin and startserv scripts use JPMS

Bootstrap libs

• glassfish.jar split to non-osgi and osgi part
• glassfish-jdk-extensions split from common-util and doesn't support osgi.
• simple-glassfish-api goes to command-line cp and doesn't support osgi.
• 4 libs support JPMS: glassfish.jar, glassfish-jdk-extensions, glassfish-jul-extension, simple-glassfish-api
• these 4 libs are used as JPMS modules.
• *.cli jars were moved to install root as they are simply executable jars.

Bootstrap design

• Basically still the same, but more comprehensible.
• Executable JAR (admin-cli.jar), started by asadmin script or startserv script starts appserver-cli.jar
• That runs GlassFishMainLauncher which prepares command line to run the server, runs GlassFishMain and stops itself.
• GlassFishMain does some basic stuff and initializes OSGi and HK2 environment.
• Server started.

Related changes

• Were mostly pushed in own PRs this week, but some are here, some are waiting, but this should be a safe point.
• asenv.conf on linux respects external env variables. I don't know how to do that on Windows, so there it is as it was before.
• Added reproducer test for JDK loggers can initialize the JDK LogManager before GlassFishLogManager is set #25133
• Classpath is not added to manifests. It caused issues with classloading, ie defaul-web.xml filter was ignored, required classes were still found by parent classloader. The manifest works just if files are when expected which is the case of the server, but then something else was not working - responsibility of classloader hierarchy. See Fixed default-web.xml #25179

Future PRs

• Next PR will disassemble SystemPropertyConstants and add enum making initialization of env and sys props easier.
• glassfish-jdk-extensions now contains just two classes, we will go through common-util and move here more things. Basically it should contain implementations which might be implemented in future JDK versions. It will never have dependencies on other GF libs.
• common-util will remain dependent on HK2, OSGI, whatever. It is used quite often, we should optimize it.
• we will get rid of felix-framework.jar because it overlaps with osgi-core.jar, or we have to repackage it. We have to try which solution is the best. JPMS hates it.
• Might be possible to start the logging immediately after start, I am not sure with that now, I need to prototype it first.
• I have around 10 discovered minor issues on paper, should be faster to fix.

Review

Probably is better to go through commits.

git remote add dmatej git@github.com:dmatej/glassfish.git
git checkout -b gjule-vs-gc dmatej/gjule-vs.gc
git diff -w -M git show -M -w dmatej/gjule-vs-gc^^^^^^^^^

Notes

• Startup speed is nearly the same as with previous version - measured around some 50 times, this version has the best result, but we are talking about change in less then 10 ms of around 2500 millis (the time including CLI).
• Breaking changes - breaking in meaning of jar file api compatibility, but even if someone would copy older domain.xml, it should work without issues (I did not try it). I don't expect anyone using GlassFish jar files directly except realms and login modules.

[dmatej]

Wow, it took me a while to reproduce it - the reason is that JDK17 and JDK21 resolve Manifest classpath in different way! I have to find where and why it changed ...

EDIT: known issues:

• ResourceBundle Control is not supported with modules (caused NPE) - fixed locally.
• GlassFish doesn't support JPMS modules on command line (restarts, reposts, etc) - I am fixing now
• JDK 11 - 17 doesn't support referring JPMS modules on classpath in manifest. JDK21 does and I am using it most often, so I thought everything is fine. Previous point resolves this, we simply have to stop using manifests to specify classpath.

EDIT2: All resolved. I will also run all TCK tests locally. I noticed that servlet TCK executed one of cli jars instead of using script, so I expect yet some issues to resolve ... until that I will keep it as a draft.

[dmatej]

Ok, another round, seems we don't have any mavenized tests for gfclient, tbd soon ...