Scanning modules?

[Christian Stein]

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 <gregw at 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 <gregw at webtide.com> CTO http://webtide.com
>