Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Replace HK2/Types/Parser/Scanner with Jandex and cache in the domain #7165

Draft
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

lprimak
Copy link
Contributor

@lprimak lprimak commented Jan 21, 2025

Deploy performance improvements

Fixes #7079

  • Save jandex to transient metadata
  • Refactor HK2-Types stuff in WeldUtils into separate file
  • Use Jandex in addition to Types in WeldUtils (get jandex-based WAR to deploy) - ignoring dependencies for now
  • How does Scanner / Parser parse war-libraries? - what's the calling flow? - in ApplicationLifecycle (kernel)
  • Save / cache Types or use Jandex for dep libs? - Jandex
  • Index (via Jandex)
  • Index via Jandex - WAR dependencies
  • Restore shared WARlib functionality
  • Cache Jandex indexes in the domain - file cache on disk
  • Load Jandex from cache, if exists
  • EAR support (DOL module, etc)
  • Check for ClassLoader leaks
  • Check old lifecycle to see if anything is missing that needs to be restored
  • Code cleanup
  • Re-introduce parallel scanning? Does it actually work to reduce scanning time? I/O bound...
  • Get tests to pass again

…I-enabled library JARs

- correctly copy BDA sets for each war in EAR
- Make WAR's CDI beans available in EAR-libs
- read web-fragment.xml from EAR-libs
- processing ear-lib manifest
- de-duplicate BDAs in CDI processing by using LinkedHashSet intead of ArrayList
- made some structures final (cleanup)
- fixed ear and concurrent classloader leaks, including refactored reflection caching
@lprimak lprimak changed the title [WIP] Replace HK2/Types with Jandex and cache in the domain [WIP] Replace HK2/Types/Parser/Scanner with Jandex and cache in the domain Jan 21, 2025
void index(DeploymentContext deploymentContext) throws IOException;
void reindex(DeploymentContext deploymentContext) throws IOException;
boolean isJakartaEEApplication(DeploymentContext deploymentContext) throws IOException;
Index getRootIndex(DeploymentContext deploymentContext);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might want to avoid spreading the JBoss classes like i.e. Index around in the Payara codebase.

Copy link
Contributor Author

@lprimak lprimak Jan 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Index is kinda the whole point of this PR.
The issue is that current annotation scanning framework is not made for CDI, is slow, and can't be cached.
Jandex is a small, separate project, has no dependencies, and is tailor made for CDI.
While it did come from JBoss, it's no longer embedded in that ecosystem and can be used unencumbered.

Any effort to isolate Index class will result in an unnecessary wrapper that would not add any value.

Do you have a specific suggestion? Am I missing something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enhancement: Payara should use Jandex to speed up CDI deployments
2 participants