> > 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). >
I once had the pleasure of debugging a system which after running in production for a few days would suddenly start returning 404 errors. Turned out someone (me) had forgotten to specify where Jetty should unpack its WAR files. So they ended up on shared temp space where a weekly Centos cron job cleaned them up. After this experience I pledged to never unpack code to temp again :-) Also, the performance implications seems not very appealing. > It does this in order to support signed JARs as the zip file system > provider doesn't have any support for validating signatures. > Hmm.. I guess exploded jars won't support signature verification. Too bad that the implementation is so tightly coupled to jar files. It could instead have defined behaviour in terms of abstract paths within a package, in which signatures would 'just work'. Similar situation for automatic modules. That could also have been specified in terms of abstract paths without mandating a specific packaging format. > 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. > Thanks, this code did seem security sensitive, so I conservatively did a deep copy. I have pruned some of the code now. 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 > I'll see if I can get a demo together at some point. > I'm curious if the service wiring make use of the existing uses/provides > or something else. > Modules make use of provides to expose binding classes to the runtime. Binding classes contain methods which consume and produce services, thereby forming a dependency graph. > 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. > The Jersey layer in the demo depends on both the servlet layer and the jax.rs layers. However, these two layers do not share any modules, so I didn't get into trouble. One could imagine a layer depending on two parent layers who define separate "instances" of the same module, which I think JPMS would flag as an invalid configuration. My Maven plugin already excludes modules from a layer when the dependency is already visible up the ancestor chain, so it should be straightforward to add a check for detecting same-module-in-multiple-parents and flag that to the user at build time. Eirik.
