Create your Gitee Account
Explore and code with more than 5 million developers,Free private repositories !:)
Sign up
Clone or download
Notice: Creating folder will generate an empty file .keep, because not support in Git

SOFAArk Project

Build Status Coverage Status Gitter license maven

SOFAArk is a light-weight,java based classloader isolation framework open sourced by Ant Financial. Please visit


In Java world, dependency is always a problem, and can cause various errors, such as LinkageError, NoSuchMethodError etc. There are many ways to solve the dependency problems, the Spring Boot's way is using a dependency management to manage all the dependencies, make sure that all the dependencies in the dependency management will not conflict and can work pretty well. This is quite a simple and efficient way, it can cover most scenario, but there is some exceptions.

For example, there is a project that need protobuf version 2 and protobuf version 3, and because protobuf version 3 is not compatible with version 2, so the project can not simply upgrade the protobuf to version 3 to solve the problem. There is same problem for hessian version 3 and version 4.

To cover those exceptions, we need to introduce a classloader isolation way, make different version of a framework loaded by different classloader. There are many framework that can do classloader isolation, perhaps the most famous one is OSGi, but OSGi classloader schema is too complex, beside classloader isolation, it also has ability to do hot deploy and a lot of other functionalities that we actually don't want.

So this is the origin of SOFAArk, it's goal is to use a light-weight classloader isolation mechanism to solve the problem that Spring Boot did not solve. And just a remind that SOFAArk is not bind to Spring Boot, actually it is a more general classloader isolation framework that can be used with any other frameworks too.

How SOFAArk Works

There are three concepts in SOFAArk: Ark Container, Ark-Plugin and Ark-Biz; they are organized as what the following graph shows:


First of all, we explain what roles these concepts play;

  • Ark Container: It's the runtime manager of total framework; it will startup in the first place, then it resolves Ark Plugin and Ark Biz in classpath and deploys them.

  • Ark Plugin: A fat jar packaged by sofa-ark-plugin-maven-plugin, generally it would bring with a class-index configuration which describes what class would be exported and imported. Ark Plugin can resolve classes from each other.

  • Ark Biz: A fat jar packaged by sofa-ark-maven-plugin, it mainly contains all staff what a project need in runtime. Ark Biz can resolve classes form Ark Plugin, but not inverse.

In runtime, Ark Container would automatically recognize Ark-Plugin and Ark-Biz in classpath, and load them with the independent classloader. According to configurations brought by Ark Plugin and Ark Biz, Ark Container would build a class-index table, so they can be isolated well. For example, if a project has two dependencies of A and B, but A depends on C (version = 0.1) and B depends on C (version = 0.2), so conflicts maybe emerge.


In this situation, we just repackage the dependencies of A and C(version=0.1) as an ark-plugin, and add the dependency of the ark-plugin to project, then this conflict would be avoided.





Comments ( 0 )

Sign in for post a comment


SOFAArk 是一款基于 Java 实现的轻量级类隔离容器,主要提供类隔离和应用(模块)动态部署能力 spread retract


No release




load more
can not load any more