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

Module / library dependency #1

Open
lkedves opened this issue Aug 22, 2024 · 0 comments
Open

Module / library dependency #1

lkedves opened this issue Aug 22, 2024 · 0 comments
Assignees

Comments

@lkedves
Copy link
Member

lkedves commented Aug 22, 2024

The modules are loaded into their own ClassLoaders, can't talk with each other on binary level and this may cause problems.

Example: Servlet API is wrapped into one Module, an actual server implementation like Jetty into another. Of course, Jetty should use ServletAPI objects in a shared ClassLoader. The idea is to set the Servlet API Module as parent of the Jetty Module (same with any other implementation) that forces Machine to load the parent Module first and set its ClassLoader as parent.
In this case I assume there is no "diamond" in the dependency graph, just pure trees. Also, this makes the parent classes visible to the derived Module (like allowing shared "tool" logic - not really aligned with the goals here)

Another approach: define "Libraries" as separate entities with their jars. Load libraries in their own ClassLoaders, refer to them when creating the Module, ensure that the Module ClassLoader can access the list of Library ClassLoaders. This allows free linking, keeps the binary separation among modules - denies binary-level shared tools.

@lkedves lkedves self-assigned this Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant