Added JPMS payload support (#511)

[DaSpood]

#511

Only the 4 following commits from mag/jpms were identified as actually related to the JPMS changes:

• 8d69de6
• dbff9de
• 4b62b78
• a70c823

Current problems:

• In order to properly instantiate JDBC drivers, we need to remove the driverClassName key from the resource definition xml. When it is present, Tomcat will use reflection to instantiate drivers, which will fail if the driver implements JPMS properly. When the key is missing, Tomcat calls the DriverManager which is the wanted behavior. For now this is only an issue with the HSQLDB driver (driverClassName="org.hsqldb.jdbcDriver"), not tested yet for other drivers. This change has not been commited yet.

• In ModuleManager (in jqm-runner), at the end of the method, resolveAndBind will throw an exception if one of the modules present in paths already existed in parentModuleLayer (for example slf4j), with ResolutionException: Module XXX reads more than one module named YYY. Manually removing the slf4j jar from the paths array solved it but we need to find a way to automatically detect and remove duplicates, which sounds like a lot of ugly code to write because it is hard to match a file system path to a module name without calling moduleFinder.findAll() on each path first.

• After the above error is fixed, some JPMS tests still fail due to the content of the test jar: ServiceConfigurationError: com.enioka.jqm.tests.jpms.api.TestService: Provider com.enioka.jqm.tests.jpms.services.TestServiceImpl1 not found. It may simply be a module-info.jar mistake, did not have time to investigate further.

• There is a regression with an existing non-JPMS test: EngineHiddenJavaClassesTest.testHiddenBigInteger, which expected a KO and got an OK result. No time to investigate yet. Because these are integration tests this may be a side effect of other failures related to the errors above.

[marcanpilami]

Problem 1: we agree on the solution. It even works outside JPMS (the DriverManager will select the correct driver according to the URL, which contains the codename of the driver). I have corrected the resource file just for the tests.

Problem 2: not really an issue. Indeed we must avoir loading a module inside a layer when the parent already contains it. This is imposed by the JPMS norm. So I have added n attempt at doing so, see commit.

Problem 3: that was because you had not taken some class loader code in the original branch. URLClassLoader by default has no idea how to deal with modules, a method must be overloaded for this.

Problem 4: actually this test cannot exist in a JPMS world - what it does is explicitely what JPMS tries to make impossible. It was commented in the oirignal branch.