Some questions about ContainerClassLoader

[masteryourself]

Your question

createContainerClassLoader 方法在创建 ContainerClassLoader 时传入的 父CL 是 null，这样做有什么好处？

ContainerClassLoader 加载了 SOFA-ARK/container 里的 jar 包，假如说我在这个包里用了一个 /jar/lib/ext 下的一个 class，难道不会报错吗？

Your scenes

com.alipay.sofa.ark.bootstrap.AbstractLauncher#createContainerClassLoader(com.alipay.sofa.ark.spi.archive.ContainerArchive)

Environment

• SOFAArk version:1.0.0

[sofastack-bot[bot]]

Hi @masteryourself, we detect non-English characters in the issue. This comment is an auto translation by @sofastack-robot to help other users to understand this issue.

We encourage you to describe your issue in English which is more friendly to other users.

Your question createContainerClassLoader The parent CL passed in when creating a ContainerClassLoader is null. What's the benefit of doing so? ContainerClassLoader loads the jar package in SOFA-ARK / container. If I used a class under / jar / lib / ext in this package, wouldn't it report an error? ### Your scenes com.alipay.sofa.ark.bootstrap.AbstractLauncher # createContainerClassLoader (com.alipay.sofa.ark.spi.archive.ContainerArchive) ### Environment-SOFAArk version: 1.0.0

[glmapper]

ContainerClassLoader 加载了 SOFA-ARK/container 里的 jar 包，假如说我在这个包里用了一个 /jar/lib/ext 下的一个 class，难道不会报错吗？

你这里说的报错是指什么？是找不到类还是找不到 ClassLoader? ContainerClassLoader 作为 URLClassLoader 的子类， ContainerClassLoader 加载类的过程是直接委托给父类(java.lang.ClassLoader) 来处理的。在 java 的双亲委派模型中，会优先将类交给父类加载，父类加载不到的情况下再由子类 load。ContainerClassLoader 虽然执行 parent 为 null，但是也不会影响加载的

[masteryourself]

这里的报错是指找不到类。ContainerClassLoader 确实是首先委托给 parent 加载，这里在构造 ContainerClassLoader 的时候传的是 null，所以父 CL 可以理解是 BootstrapCL，显然 BootstrapCL 是没有能力加载 /jar/lib/ext 目录下的类，ContainerClassLoader 显然也没有能力加载啊（构造时候指定的 urls 只有 SOFA-ARK/container 下的 lib）

 protected ClassLoader createContainerClassLoader(ContainerArchive containerArchive)
                                                                                       throws Exception {
        List<URL> classpath = getExecutableArchive().getConfClasspath();
        classpath.addAll(Arrays.asList(containerArchive.getUrls()));
        return createContainerClassLoader(classpath.toArray(new URL[] {}), null);
    }

[glmapper]

@masteryourself 理解你的问题了，ContainerClassLoader 目前作为 Ark 容器自身的 classloader，ContainerClassLoader 本身并不支持加载 /jar/lib/ext 目录下的类，这部分类在 sofa ark 中没有被特殊处理。

另外问下，你们是在什么场景下对此有需求吗？

[masteryourself]

需求目前还木有，疑问是有的 这个图是 SOFA-ARK/container 里的 fat-jar 包，里面显然用到了一些三方技术如 guava、log，你们是如何确定这些 jar 包不会去引用 /jar/lib/ext 目录下的类，主要疑问也是在此处，不知道这里的父 CL 传不传到底有何益弊？可以简单说一下这个优缺点吗

[glmapper]

这个图是 SOFA-ARK/container 里的 fat-jar 包，里面显然用到了一些三方技术如 guava、log，你们是如何确定这些 jar 包不会去引用 /jar/lib/ext 目录下的类，主要疑问也是在此处，不知道这里的父 CL 传不传到底有何益弊？可以简单说一下这个优缺点吗

目前 ark 容器所使用的包是 ark 自己管控的，不会用到 /jar/lib/ext 的类；另外 ContainerClassLoader 并不会去处理业务或者中间件层面的类，所以从设计上就没有使用 ext 作为父 classloader。当前的考虑是 ContainerClassLoader 不需要有复杂的继承关系，这块由 ark Container 容器自身的能力决定（简单）。

[masteryourself]

thank you