我正在尝试查看是否可以重构我继承的项目的体系结构，并且对 Apache Karaf 作为可能的解决方案感兴趣。
目前，我们为我们拥有的每个（非盈利）客户构建一个可执行 JAR，并 cron 让 JAR 在不同时间运行。每个“客户端 JAR”在其中使用多个“公共” JAR，并在其中包含特定于客户端的逻辑。总共有数百个客户端 JAR 和大约十几个常见 JAR。
这种架构的问题很多：
- 由于公共 JAR 只是作为库，因此客户端 JAR 没有可在其上运行的公共平台。他们中的许多人使用 Apache Camel 并使用这些 JAR 本地的路由，并且在所有 JAR 中复制了大量的 Camel 代码。如果有一个解决方案，所有客户端 JAR 可以共享相同的 Camel 路由，那就太好了。
- 它将何时运行每个客户端 JAR 的业务逻辑置于 cron 手中，这很好，但这是 Java，我更希望有一个主 Quartz“调度程序”来控制所有 JAR 何时运行。
- 每次我需要向其中一个公共 JAR 中添加依赖项时，我都需要检查每个客户端 JAR 的每个 crontab 条目并修改类路径参数以获取额外的依赖项。
- 名单还在继续……
- 我只是不喜欢 cronning 可执行客户端 JAR 的想法，因为如果它们被部署到同一个容器中，它们可以更加紧密地工作。
所以基本上，我需要一个解决方案：
- 允许我随时部署/取消部署和重新部署新版本的客户端 JAR，而不会中断系统的其余部分
- 部署/取消部署任何公共 JAR，以便任何开始使用的新客户端 JAR 获取公共 JAR 的新版本
- 允许我部署/取消部署 Quartz 调度程序（WAR 或 JAR），该调度程序可以 cron/调度每个客户端 JAR 以在一周的不同时间运行
- 允许我部署/取消部署消息代理，也许还有 ESB，例如 Camel 或 Mule，这样我的每个客户端 JAR 都可以使用相同的队列和路由
- 允许我部署/取消部署单个日志 JAR（log4j、commons logging 等）和单个 JPA 实现 JAR（Hibernate、MyBatis 等），并使其对所有客户端 JAR 普遍使用/可用
以上这些都可以用Karaf来完成吗？如果没有，我在这里有什么选择吗（Felix、Equinox 等）？还是我在追逐梦想？鉴于我的问题域，是否有任何警告或理由让我坚持当前的解决方案？提前致谢！
请注意：如果有人认为 EJB3 对我来说是一个很好的解决方案，而不是 OSGi，我当然愿意听取你的论点，但我的项目经理讨厌EJB（在 EJB2 沉重的日子里，他嘴里的味道很差）并且不会可能会批准这样的解决方案。