Hi Greg, short disclaimer: I'm learning and testing the "--scan-module" magic at the moment to implement a similar feature in JUnit 5. See [1] for details. If I'm talking non-sense, please correct me jigsaw-devs.
To scan the contents of a module you'll need a ModuleReference[2] instance. You may open() such a reference to obtain a ModuleReader[3] which allows you to list() all or find() some of the contents of the referenced module. How to get ModuleReference instances? There're at least two ways: either ask the runtime to report all resolved modules in a specific layer. See [4] for details and [5] how I try to obtain all modules on the module-path. Or you may build your own ModuleFinder [6] with well-known module locations. Here [7] is an example how this could work. Cheers and hope that helps, Christian [1] https://github.com/junit-team/junit5/pull/1057/files#diff- 96762765b7aa19e415e25de774366feb [2] http://download.java.net/java/jdk9/docs/api/java/lang/ module/ModuleReference.html [3] http://download.java.net/java/jdk9/docs/api/java/lang/ module/ModuleReader.html [4] http://download.java.net/java/jdk9/docs/api/java/lang/ModuleLayer.html [5] https://github.com/junit-team/junit5/pull/1057/files#diff-6e80f389aa0b4148904a9c474b9e8fb8R43 [6] http://download.java.net/java/jdk9/docs/api/java/lang/ module/ModuleFinder.html [7] https://github.com/forax/pro/blob/master/src/main/java/com.github.forax.pro.helper/com/github/forax/pro/helper/ModuleHelper.java#L77 On Fri, Sep 15, 2017 at 6:01 AM, Greg Wilkins <gr...@webtide.com> wrote: > All, > another question on scanning, but more jigsaw related than my other > question. > > App containers have to scan jars deployed in EARs, WARs etc. for > annotations, fragments, resources etc. However, many containers also offer > features to be able to optionally scan jars that are on the system > classpath. > > For example, Jetty deploys the JSTL jar on the system classpath, but adds > it to the annotation scanning for every webapp deployed. Similarly when > running in embedded mode, where all jars are on the system class path, we > have been able to find and scan those that matched a pattern. > > However, with java9 modules, we have two problems if a jar like jstl.jar is > deployed on at runtime. > > Firstly, the system loader is no longer a URLClassLoader, so we cannot scan > to list of provided jar files looking for potential matches of known jars > that we wish to scan. > > We can work around that by loading a known class from the known jars and > asking for its location (via it's protection domain). For a normal jar, > this gives us a file URI, which we can then use as the basis for a scan. > > However, I expect that eventually JSTL will be converted to a module, and > then the location will just be something like jrt://apache.jstl. Which > gives us our second problem - given a known or discovered module, how do we > discover what classes are within that module in order to scan them for > annotations? We cannot find any API via Module nor the jrt URLHandler > that gives us access to a list of classes? > > We can get a lists/sets of Packages,Exports etc. but nothing we can see > gives us the actual classes/resources contained in that module, nor the > location of the source jar file that we could open and thus determine the > contents ourselves. > > So some guidance of how we are meant to do discovery of annotations, > fragments etc in a modularized deployment would be very useful. > > regards > > > -- > Greg Wilkins <gr...@webtide.com> CTO http://webtide.com >
