<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 9, 2017 at 6:10 AM, Mark Evenson <span dir="ltr"><<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 4/7/17 17:50, Alan Ruttenberg wrote:<br>
</span><span class="gmail-">> I'm using :mvn ASDF components and ran into a problem with having multiple<br>
> versions of the same library.<br>
<br>
</span>The clearest path forward for conflicting dependencies would be for<br>
JAVA:ADD-TO-CLASSPATH to take an environment which would contain a new,<br>
dynamically added classloader for all java artifacts loaded in scope.<br>
This mechanism is used by Apache Tomcat to introduce a separate<br>
classloader for each Java Servlet instance.<br></blockquote><div><br></div><div>There is OSGI which is able to do this sort of thing, and there is already prototype code in JSS to use it. However OSGI, or multiple classloaders, needs a fair amount of thought to use correctly, because you can easily arrive at situations where compatible classes can't be used because they were loaded into different classloaders.</div><div><br></div><div>The first step is to enable managing dependencies when it *is* possible to run without conflicts, as with the :<span style="font-family:monospace,monospace;font-size:12.8px">mvn-module </span>I showed above. In this case it turns out that the dependencies only *seemed* to conflict. With the appropriate use of Maven there is no conflict in this case.</div><div><br></div><div>The thing that is different in our environment as compared to the standard maven situation is that we don't have a central pom for an application that gathers all dependencies and resolves them at once. Instead we have separate ASDF systems which are loaded independently and yet may have intertwined dependencies. </div><div><br></div><div>I can't comment on the Java 9 issues as I've not studied them as yet.</div><div><br></div><div>Alan</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Even though the Tomcat developers presumably thought such a method would<br>
allow some degree of security, they failed.  Partly because of the need<br>
for each servlet to use global resources in-process for efficiency gains<br>
(think JDBC), and partly because the security guarantees of the<br>
underlying JVM can be trivially broken (as can be seen by<br>
[abcl-servlet][1] which boots a swank servlet binding a listening socket<br>
on localhost).<br>
<br>
Symbolic bindings in ennvironments via the [five currently missing<br>
methods in ABCL for CtLv2][cltl2-env] could be presumably mimic the<br>
scoping of all possible desired classloaders.<br>
<br>
Some abstraction of this sort will be needed to run on Java 9, so we<br>
might as take a stab at supporting both at a profit to ultimate<br>
complexity.<br>
<br>
[cltl2-env]: <a href="https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html" rel="noreferrer" target="_blank">https://www.cs.cmu.edu/Groups/<wbr>AI/html/cltl/clm/node102.html</a><br>
<br>
[1]: <a href="https://bitbucket.org/easye/abcl-servlet" rel="noreferrer" target="_blank">https://bitbucket.org/easye/<wbr>abcl-servlet</a><br>
<br>
[java:add-to-classpath]: :has<br>
""""<br>
4.1 JAVA<br>
4.1.1 Modifying the JVM CLASSPATH<br>
The JAVA:ADD-TO-CLASSPATH generic functions allows one to add the<br>
specified pathname or list of<br>
pathnames to the current classpath used by ABCL, allowing the dynamic<br>
loading of JVM objects:<br>
CL-USER > ( add-to-classpath " / path / to / some . jar " )<br>
N.b ADD-TO-CLASSPATH only affects the classloader used by ABCL (the<br>
value of the special<br>
variable JAVA:*CLASSLOADER*. It has no effect on Java code outside ABCL.<br>
""""  .<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
--<br>
"A screaming comes across the sky.  It has happened before, but there<br>
is nothing to compare to it now."<br>
<br>
</div></div></blockquote></div><br></div></div>