Maven and ABCL

[Alan Ruttenberg]

On Sun, Apr 9, 2017 at 6:10 AM, Mark Evenson <evenson at panix.com> wrote:

> 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.
>

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.

The first step is to enable managing dependencies when it *is* possible to
run without conflicts, as with the :mvn-module 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.

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.

I can't comment on the Java 9 issues as I've not studied them as yet.

Alan


>
> 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."
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20170417/8da8c0bf/attachment.html>