The fact to scan from the classloader and not assume it is an urlclassloader or even respects its contract makes it more portable (EE, plain tomcat which doesnt respect this contract, OSGi soon, custom classloaders etc...).
It is trivial to have failing cases using URLClassLoader sadly. That said letting the user resolve the jars to stage can be saner instead of assuming it is in the classpath/loader. I already have a few cases where it will fail cause the transforms load the jars from outside the app classloader (transforms are isolated). Le 29 janv. 2018 22:04, "Lukasz Cwik" <[email protected]> a écrit : I wanted to bring back to the community that there are two competing PRs on how classloaders are being used to detect which resources needed to run a pipeline: * https://github.com/apache/beam/pull/4497 * https://github.com/apache/beam/pull/4514 PR/4497 uses the fact that in JDK 9 doesn't use a URLClassLoader if its the system class loader anymore and relies on the parsing the standard JAVA_CLASS_PATH system property. PR/4514 uses ClassLoader#getResources to find all "" and "META-INF" resources and then finds the appropriate path based upon the resource. As a community we have two questions: 1) If they handle different use cases, should we have a configurable way in which a user can specify which resource detection strategy we go with? 2) Which one should we go with? (or both and which one is the default) I have added Liam and Romain the authors of the two PRs to the thread. Would you please provide an argument for the merits and drawbacks of your approach.
