You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's more logical to me that locations in domain-dir are preferred over as-install location, because if GlassFish installation contains custom JARs, it should be possible to override them for each domain. Multiple domains running from the same installation would not have to share the same JARs if they are dropped into the installation. Edge case, I know :)
Another issue with the Common classloader is that it scans all the JARs in the as-install/lib folder, opens their manifests and searches for the GlassFish-ServerExcluded field there, to find out whether to ignore the JAR or not. By default, currently, there are 3 JARs in the lib folder, so 3 JARs need to be opened and their manifests unpacked at startup. it would be better to avoid opening them just to scan values in their manifests. We could, at package time, generate a file that lists the JARs that should be ignored. Then just a single file would need to be opened and ready, instead of opening a file from 3 JAR archives.
Environment Details
GlassFish Version (and build number): up to 7.0.17
The common classloader loads classes from the following locations, in that order (see CommonClassLoaderServiceImpl.java):
as-install/lib
- JARsdomain-dir/lib/classes
- classesdomain-dir/lib
- JARsIt's more logical to me that locations in
domain-dir
are preferred overas-install
location, because if GlassFish installation contains custom JARs, it should be possible to override them for each domain. Multiple domains running from the same installation would not have to share the same JARs if they are dropped into the installation. Edge case, I know :)Another issue with the Common classloader is that it scans all the JARs in the
as-install/lib
folder, opens their manifests and searches for theGlassFish-ServerExcluded
field there, to find out whether to ignore the JAR or not. By default, currently, there are 3 JARs in thelib
folder, so 3 JARs need to be opened and their manifests unpacked at startup. it would be better to avoid opening them just to scan values in their manifests. We could, at package time, generate a file that lists the JARs that should be ignored. Then just a single file would need to be opened and ready, instead of opening a file from 3 JAR archives.Environment Details
Impact of Issue
Slows down server startup
Type: Improvement
Component: Startup, Classloader
Priority: low
The text was updated successfully, but these errors were encountered: