On 4/7/17 17:50, Alan Ruttenberg wrote:
I'm using :mvn ASDF components and ran into a problem with having multiple versions of the same library.
The clearest path forward for conflicting dependencies would be for JAVA:ADD-TO-CLASSPATH to take an environment which would contain a new, dynamically added classloader for all java artifacts loaded in scope. This mechanism is used by Apache Tomcat to introduce a separate classloader for each Java Servlet instance. Even though the Tomcat developers presumably thought such a method would allow some degree of security, they failed. Partly because of the need for each servlet to use global resources in-process for efficiency gains (think JDBC), and partly because the security guarantees of the underlying JVM can be trivially broken (as can be seen by [abcl-servlet][1] which boots a swank servlet binding a listening socket on localhost). Symbolic bindings in ennvironments via the [five currently missing methods in ABCL for CtLv2][cltl2-env] could be presumably mimic the scoping of all possible desired classloaders. Some abstraction of this sort will be needed to run on Java 9, so we might as take a stab at supporting both at a profit to ultimate complexity. [cltl2-env]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html [1]: https://bitbucket.org/easye/abcl-servlet [java:add-to-classpath]: :has """" 4.1 JAVA 4.1.1 Modifying the JVM CLASSPATH The JAVA:ADD-TO-CLASSPATH generic functions allows one to add the specified pathname or list of pathnames to the current classpath used by ABCL, allowing the dynamic loading of JVM objects: CL-USER > ( add-to-classpath " / path / to / some . jar " ) N.b ADD-TO-CLASSPATH only affects the classloader used by ABCL (the value of the special variable JAVA:*CLASSLOADER*. It has no effect on Java code outside ABCL. """" . -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."