Scanning modules?

[Greg Wilkins]

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