Loading an automatic module from an exploded directory

[Alan Bateman]

On 09/04/2020 19:23, Eirik Bjørsnøs wrote:
>
> Alan,
>
>     If I read your mail correctly, you are creating "multi-module JAR
>     files"
>     where the modules are "exploded" under /META-INF/modules in
>     ${NAME}-${VERSION} directories.
>
>
> Correct.
Do they need to be "exploded"? If the dependences are automatic modules 
then I assume putting the JAR files (without unpacking) into 
META-INF/modules should just work without needing a new ModuleFinder 
implementation or implementing the exploded equivalent of multi-module 
JAR files (or modular multi-release JAR files).

(The reason it should work is that the built-in implementation can work 
with paths to locations in virtual file systems. It handles this by 
copying the JAR files from the virtual file system to the default file 
system so that it can be opened with the JarFile API. It does this in 
order to support signed JARs as the zip file system provider doesn't 
have any support for validating signatures. It's possible this approach 
isn't very efficient, also we haven't looked into interactions with the 
cron jobs that clean tmpfs so there may be a bit more work needed here).

>
> To achieve this, I had to copy / replicate quite a bit of code from 
> the ModulePath class which is not accessible outside java.base.
>
> It wasn't all that hard, I just wasn't happy with the amount of 
> classes / methods I had to copy from java.base only to slightly modify 
> them
>
> This includes:
>
> Code to create / build the ModuleDescriptor (stolen from 
> deriveModuleDescriptor)
> Code to clean the artifactId used to produce the automatic name 
> (Stolen from cleanModuleName, Patterns and Checks)
> Duplication of ExplodedModuleReader which also dragged in Resources.
Understood although you probably don't need a deep copy of everything as 
there is a lot in exploded module reader related to potential security 
and traversal on the default file system that is less interesting in JAR 
files.


> :
>
> The runtime loads a graph of module layers, each containing one or 
> more modules. Layers may depend on other layers, forming a DAG with 
> corresponding class loader delegation.
>
> When the runtime detects that a module needs to be redeployed, the 
> transitive closure of depending layers is removed from the graph and 
> new module layers are created and added to the graph.
>
> Services are bound using dependency injection, so there's also a DAG 
> of service dependencies. This allows restarting services which are 
> affected by the redeploy, either because they are provided from 
> updated modules or because they consume services from updated modules.
>
> So not really hot-deploying in the JVM sense, but still pretty fast 
> and developer-friendly.
>
> My demo has a module which provides a JAX-RS resource which is 
> consumed by a Jersey module which provides an HttpServlet which is 
> again consumed by a Jetty module which deploys the servlet in a 
> servlet context.
>
> Redeploying the module containing the JAX-RS resource takes something 
> like 50ms IIRC.
>
This sounds very interesting. I'm sure there are several people here 
that would be interesting in seeing a write-up or demo of this. I'm 
curious if the service wiring make use of the existing uses/provides or 
something else. I'm also curious if you've run into any issues with 
multi-parent configurations as that is an area that might need attention 
some day.

-Alan