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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: