This action will force synchronization from SOFAStack/sofa-ark, which will overwrite any changes that you have made since you forked the repository, and can not be recovered!!!
Synchronous operation will process in the background and will refresh the page when finishing processing. Please be patient.
SOFAArk is a light-weight，java based classloader isolation framework open sourced by Ant Financial. Please visit https://alipay.github.io/sofastack.github.io/
In Java world, dependency is always a problem, and can cause various errors, such as
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.
There are three concepts in SOFAArk:
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.
Ark Container would automatically recognize
Ark-Biz in classpath, and load them with the independent classloader. According to configurations brought by
Ark Plugin and
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.