前言
上一篇文章我们浅尝辄止模块化整体概览，所谓模块化基础设施则是基于Pf4j二次封装，我们具体到底要实现哪些，本篇我们从Pf4j开始讲解，我们深挖细节。
模块化基础设施
Pf4j官方有基本介绍以及对整个框架的架构等等，我们不再浪费口舌。如下是通过AI总结Pf4j的能力所导出的时序图，基本上算是那么回事，给不了解Pf4j能力的童鞋留个基本印象
基于上述Pf4j的基本能力概括（启动、停止、热加载/卸载、销毁、扩展点），我们先抛开封装涉及Web应用的基础能力，我们再来思考一个问题：模块化框架还应具备哪些能力？以此再对照深入P4fj实现细节确认是否能扩展增强或者对底层复杂实现进行简化等等，如下我们一一抽丝剥茧且化繁为简以及直接给出若不支持如何扩展实现（注：pf4j既支持jar包也支持将jar打包成zip，我们仅以原始jar包为例讲解，zip的jar包无非多了一步将jar包解压等等，逻辑大同小异）
插件目录自定义
public static final String PLUGINS_DIR_PROPERTY_NAME = "pf4j.pluginsDir"; public static final String MODE_PROPERTY_NAME = "pf4j.mode";public static final String DEFAULT_PLUGINS_DIR = "plugins"; public static final String DEVELOPMENT_PLUGINS_DIR = "../plugins";protected void initialize() {if (pluginsRoots.isEmpty()) {pluginsRoots.addAll(createPluginsRoot());} }protected final List<Path> pluginsRoots = new ArrayList<>();protected List<Path> createPluginsRoot() {String pluginsDir = System.getProperty(PLUGINS_DIR_PROPERTY_NAME);if (pluginsDir != null && !pluginsDir.isEmpty()) {return Arrays.stream(pluginsDir.split(",")).map(String::trim).map(Paths::get).collect(Collectors.toList());}pluginsDir = isDevelopment() ? DEVELOPMENT_PLUGINS_DIR : DEFAULT_PLUGINS_DIR;return Collections.singletonList(Paths.get(pluginsDir));}
当我们实现自定义继承PluginManager时，若我们已指定插件目录路径则按照手动指定的插件目录解析并加载插件，否则从JVM系统属性获取pf4j.pluginsDir，若已指定则按照指定路径解析并加载插件，否则默认的插件目录则为plugins或者../plugins（pf4j区分测试和生产模式，也是从JVM系统属性获取MODE_PROPERTY_NAME）。
插件与插件之间的目录自定义
我们设计的具体插件有2个层级，将插件jar包去除版本号的名称作为插件目录，其目录下放插件jar包，同时还有个lib目录，该lib目录用于存放插件的依赖，此依赖既可来源于插件引入独立依赖的mvn仓库包，也可来源于与外部对接时的私有包（不存在于mvn仓库）。 很显然，pf4j不支持（一句话概括：pf4j没有插件目录层级之分，所有插件jar包统一放到插件目录下以及依赖也统一放到插件目录下的lib目录下，在此不再做进一步的源码讲解），我们重写其方法实现
如上BasePluginRepository为pf4j提供的基本实现，同时pf4j进一步提供JarPluginRepository继承BasePluginRepository，仅仅只是作为构造函数传递插件目录路径，所以我们可以自定义继JarPluginRepository，重写上述streamFiles方法即可，该方法有2个参数，第一个则是插件目录路径，第二个则是文件类型过滤（jar）
上述我们已重写最终得到的将是具体插件jar包路径，这里我们可考虑做两方面处理，一是强校验插件目录的名称和jar包忽略版本号的名称是否完全一致，二是版本冲突处理即存在不同版本的jar包时，例如可以根据版本约定俗成的alpha、rc、release版本等规则取最新的jar包，其他各凭实际情况自由发挥。
插件独立依赖包解析
上述仅仅只是取到了具体插件jar包路径，接下来通过类加载器加载jar包以及加载依赖，首先需要讨论类加载器的事情，个人认为pf4j的类加载器考虑的很周到，设计的比较灵活，但我们实际可以稍微简化下，核心思路总结起来主要也就4点：遵循“双亲委派” 基础规则，先检查类是否已加载，避免重复加载→遵循双亲委派核心思想，优先从主应用（父类加载器）加载→插件专属类优先从插件加载（可选）→类从插件加载→自定义额外类路径兜底（可选）→最终加载失败抛异常。当然实际情况下我们可能也有其他考虑，可看看pf4j类加载器源码自行做取舍，如下自定义继承
public class GJPluginClassLoader extends PluginClassLoader {private static final Logger log = LoggerFactory.getLogger(GJPluginClassLoader.class);// 插件专属资源private static final Set<String> PLUGIN_FIRST_RESOURCES = Set.of("META-INF/extensions.idx");@Overrideprotected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {// 1. 检查是否已加载Class<?> loadedClass = findLoadedClass(name);if (loadedClass != null) {return loadedClass;}// 2. 优先从主应用（父类加载器）加载try {return parentClassLoader.loadClass(name);} catch (ClassNotFoundException e) {log.debug("Class {} not found in parent classloader, trying plugin", name);}// 3. 检查是否是插件专用资源（优先从插件加载）if (isPluginOnlyResource(name)) {try {Class<?> pluginClass = super.loadClass(name, resolve);if (pluginClass != null) {return pluginClass;}} catch (ClassNotFoundException ignored) {}}// 4. 尝试从插件中加载try {Class<?> pluginClass = super.loadClass(name, resolve);if (pluginClass != null) {return pluginClass;}} catch (ClassNotFoundException e) {log.warn("Class {} not found in plugin, trying additional paths", name);}// 5. 最后从额外类路径中查找Class<?> additionalClass = findClassInAdditionalPaths(name);if (additionalClass != null) {return additionalClass;}throw new ClassNotFoundException("Class " + name + " not found in parent, plugin or additional paths");}
既然我们已自定义类加载器，那么何时实例化类加载器呢，就在我们继承底层DefaultPluginManager自定义的PluginManager里面重写createPluginLoader方法
@Overrideprotected PluginLoader createPluginLoader() {return new GJJarPluginLoader(this);}
上述我们提供继承自底层的PluginClassLoader自定义类加载器，我们开始加载jar包及其依赖，此时又得需要自定义jar包加载类继承自底层的JarPluginLoader，全部代码一贴如下：
public class GJJarPluginLoader extends JarPluginLoader {private static final Logger log = LoggerFactory.getLogger(GJJarPluginLoader.class);private static final String LIB_DIR = "lib";public GJJarPluginLoader(PluginManager pluginManager) {super(pluginManager);}@Overridepublic boolean isApplicable(Path pluginPath) {return Files.exists(pluginPath) && FileUtils.isJarFile(pluginPath);}@Overridepublic ClassLoader loadPlugin(Path pluginPath, PluginDescriptor pluginDescriptor) {GJPluginClassLoader pluginClassLoader = new GJPluginClassLoader(this.pluginManager, pluginDescriptor, this.getClass().getClassLoader());pluginClassLoader.addFile(pluginPath.toFile());loadDependencyJars(pluginPath, pluginClassLoader);return pluginClassLoader;}void loadDependencyJars(Path pluginPath, GJPluginClassLoader pluginClassLoader) {// 插件 JAR 所在目录Path pluginDir = pluginPath.getParent();if (pluginDir == null) {log.warn("Plugin path has no parent directory: {}", pluginPath);return;}Path libDir = pluginDir.resolve(LIB_DIR);// 1. LIB_DIR不存在，说明无依赖，忽略加载独立依赖if (!Files.exists(libDir)) {return;}// 2. 从 MANIFEST.MF 读取 Class-Path 声明的依赖List<Path> declaredPaths = getDeclaredClassPathJars(pluginPath);if (declaredPaths.isEmpty()) {log.debug("No Class-Path found in MANIFEST.MF");return;}// 3. 提取 Class-Path 中所有指向 lib/ 下的 JAR 文件名（标准化为文件名）Set<String> declaredJarNames = getDeclaredJarNames(declaredPaths);if (declaredJarNames.isEmpty()) {return;}Set<String> loadedJarNames = new HashSet<>();try (Stream<Path> stream = Files.list(libDir)) {List<Path> libJars = stream.filter(Files::isRegularFile).filter(path -> path.getFileName().toString().endsWith(".jar")).toList();for (Path jarPath : libJars) {String jarName = jarPath.getFileName().toString();// 只加载 Class-Path 中声明的 JARif (!declaredJarNames.contains(jarName)) {log.warn("Ignored undeclared JAR in lib/: {}", jarName);continue;}// 避免重复加载if (!loadedJarNames.add(jarName)) {log.warn("Duplicate JAR in lib/: {}", jarName);continue;}// 使用 PF4J 标准方法添加 pluginClassLoader.addFile(jarPath.toFile());log.debug("Loaded dependency JAR: {}", jarName);}} catch (IOException e) {log.error("Failed to scan lib directory: {}", libDir, e);}}private Set<String> getDeclaredJarNames(List<Path> declaredPaths) {Set<String> declaredJarNames = declaredPaths.stream().filter(path -> {try {return path.startsWith(LIB_DIR) ||path.getFileName().toString().equals(path.toString());} catch (Exception e) {return false;}}).map(path -> {// 处理相对路径（如 "lib/xxx.jar"）return path.getFileName().toString();}).collect(Collectors.toSet());if (declaredJarNames.isEmpty()) {log.debug("No lib JARs declared in Class-Path");}return declaredJarNames;}private List<Path> getDeclaredClassPathJars(Path pluginJarPath) {try (JarFile jarFile = new JarFile(pluginJarPath.toFile())) {Manifest manifest = jarFile.getManifest();if (manifest == null) {return Collections.emptyList();}Attributes mainAttrs = manifest.getMainAttributes();String classPath = mainAttrs.getValue(Attributes.Name.CLASS_PATH);if (classPath == null || classPath.trim().isEmpty()) {return Collections.emptyList();}// 按空格分割（支持多个空格）return Arrays.stream(classPath.trim().split("\\s+")).filter(s -> !s.isEmpty()).map(Paths::get).collect(Collectors.toList());} catch (Exception e) {throw new RuntimeException("Failed to read Class-Path from plugin manifest: " + pluginJarPath, e);}} }
上述总结起来一句话：插件包先投入类加载器，再将插件lib目录独立依赖投入类加载器，但尤其需要注意2点涉及安全方面的考虑，一是防止路径穿越，二是在利用mvn自动化构建时将lib下所有依赖写入到JAR清单文件MANIFEST.MF（并不是随随便便放个JAR包到lib目录下我们就任意去加载，当然更重要的前置条件是当插件放到平台插件目录下时肯定要做SHA256等等一致性校验）
插件与插件相互依赖解析
pf4j以逆拓扑排序解析插件依赖，插件依赖由约定的plugin.properties中的plugin.dependencies属性定义插件依赖，若依赖插件gj.plugin.demo2和gj.plugin.demo3（可选是否带上版本号），那么：plugin.dependencies=gj.plugin.demo2@1.0.0-SNAPSHOT,gj.plugin.demo2@1.0.0-SNAPSHOT。注意多个依赖用英文半角符号隔开，同时若出现循环依赖则会抛出异常，不用担心死循环问题
插件加载异常自定义策略
多个插件加载，若某个插件出现加载异常我们可能并不希望影响其他插件的正常加载，pf4j提供了插件加载异常策略，默认是会抛出异常。
若需调整插件加载异常策略，我们在继承底层DefaultPluginManager自定义的PluginManager里面重写initialize方法，在调用父类初始化方法后重写其策略即可
@Overrideprotected void initialize() {super.initialize();// 覆盖默认设置解析依赖异常不影响其他插件正常加载this.resolveRecoveryStrategy = ResolveRecoveryStrategy.IGNORE_PLUGIN_AND_CONTINUE;this.configurationRepository = createConfigurationRepository();}
总结
还没完，留个彩蛋：pf4j默认的PluginManager对插件的相关操作非线程安全，所以请注意单个插件操作的原子性。如上对pf4j二次封装模块化大致设计思路，仅供各位参考，本文暂到此为止，感谢阅读。