在 2012 年的北京 JUDCon 上，来自红帽的 Aleš Justin 介绍了 CapeDwarf 项目，该项目可以将 Google App Engine 上的应用迁移到 JBossAS7 平台上。在分享中，Aleš介绍了 CapeDwarf 提供的两种迁移机制分别是如何工作的，各自的优势和劣势在哪里，以及如何保持项目的可扩展性。
Aleš Justin 出生于斯洛文尼亚的卢布尔雅那，本科毕业于卢布尔雅那大学的数学系。他在十年前与 Java 相恋，将自己的大部分时间投入到了信息系统的开发当中，涉及从客户服务到能源管理等一系列领域。2006 年，Aleš加入 JBoss 团队，开始全职为 Microcontainer 项目工作。目前，Aleš主导着 CapeDwarf 项目，同时也在为应用服务器、Weld、Ceylon 及其他多个 JBoss 项目做贡献。
在下面的对话中，Aleš受邀分享了自己启动 CapeDwarf 项目的原因，项目目前遇到的一些问题，以及自己在整个 JBoss 开发领域的一些经历。
InfoQ：Aleš，你在 2006 年加入红帽，之后参与了多个 JBoss 相关的项目。能否简单介绍一下这些项目？比如你为什么会想参与 / 发起这些项目，它们使用的架构，你的技术选型等等。
Aleš：我刚加入 Microcontainer 项目的时候是跟着 Adrian Brock 和 Scott Stark 一起做，这个项目是 JBossAS5 和 JBossAS6 的内核。对于 2、3 个人的团队而言，这样一个项目要做的工作太多了。不过，这同时也是一个很好的学习期，我能够跟这些非常优秀的开发者在一起紧密的工作。
当然了，每个项目都有结束的一天，你会开始做新的项目，并不会对离开老项目感到后悔和留恋。总之，我开始做 Weld ，这是一个 CDI RI（实现参考）的项目。
我是个一直寻找新鲜事儿做的人，所以我当时做的另一件事就是帮助 Gavin King 做 Ceylon ——这是 JVM 上的一个新语言。我刚刚加入红帽的时候就认识 Gavin，他那时候会谈论自己在做些什么东西，而我一直对他说的东西很感兴趣。Ceylon 背后的理念就是，打造一个完整的平台，语言本身要完全模块化，同时有自己的运行时。由于我有做内核的背景，我能为 Ceylon 做什么就很明显了——它的运行时。当然，语言本身和编译器都是非常有趣的，我在念数学的时候也研究过这方面，但是我对运行时这方面要更加深入一些。所以，我致力于打造这个模块化的运行时，同时让代码库能够与 Ceylon 的模块化环境良好的结合。
所以我做了 Weld，做了 Ceylon，然后就是 CapeDwarf 。CapeDwarf 背后的整个理念是源于 Android 的流行，以及我对 CDI 和 Google App Engine 的关注。当时我就想，为什么不把这些东西都组合在一起呢？客户端有 Android，服务器端有 CDI 和 Google App Engine。最初，我采用了另外一种实现方式：一开始编写的 CapeDwarf Green 是一个针对 GAE 和 JEE API 的适配层。但是写出来之后我又想了，为什么不干脆做一套 Google App Engine API，让 JBoss 和其他的开源库直接可以调用呢？有了这个想法，我就开始研究，看 Google App Engine 的哪个 API 是最复杂的。如果这个最复杂的能做，其他的多半也就没问题了。所以，我挑选了 datastore。但是结果呢，这个 API 也不难做，因为有 Infinispan 这个项目（也是一个 JBoss 项目）。
这样做下去，CapeDwarf 逐渐被升级为一个正规的项目，有更多的资源被分配来帮我做这一块的工作。我现在基本上是 50% 的时间用于做 CapeDwarf，50% 做 Weld，剩下的时间做做 Ceylon。
由于 CapeDwarf 跟其他的几个 JBoss 项目都有关联，我们这几个项目之间都有很深的合作，互相贡献补丁、测试和反馈。
InfoQ：CapeDwarf 这个名字是怎么来的？
Aleš：名字是我和我的朋友 Dejan 一起讨论的。一开始有好几个备选。最初的名字是 Lhotse，全球第四大高峰的名字。结果我们发现没人认识这名字！那就改吧。剩下的几个备选当中，我看上了 Chameleon（变色龙），因为能适应环境变色嘛，我们的项目就是能适应各种变化，无论是 Google App Engine 还是 JBossAS 都能适应。所以，名字很般配。但是在红帽，项目名称是要提交法律部审查的，结果当然是没有通过——Chameleon 这个名字已经有很多企业在用了。
这个时候，Dejan 把不同种类的变色龙的名字都列了出来，其中包括 CapeDwarf，我很喜欢，就决定是它了。
项目图标的来历又是另一个故事了。一开始我们也想着用一张变色龙的图，但是画出来之后怎么看怎么觉得眼熟：这不就是 SUSE Linux 嘛！所以最后我们决定，就是一个披着披风（Cape）的矮人（Dwarf）吧。
InfoQ：真不错。现在 CapeDwarf 项目有几个工程师在做？
Aleš：两个半。我是发起人和团队的主导者——当然团队很小就是了。在斯洛文尼亚的办公室，一共也就 5 个工程师。CapeDwarf 的两个半分别是我，Marko 和 Matej。Matej 是 OpenShift 团队的，帮助把 CapeDwarf 弄到 OpenShift 上面去，所以算半个：）
InfoQ：整个开发的模式是开源的吗？有没有外部的工程师参与到这个项目里面来？
Aleš：这个项目从启动开始就一直是对外公开的。由于种种原因，我们没有在推广方面投入太多精力。项目初期，我们一直在等待JBossAS 7 的发布——也是由于种种原因，这事儿一直没落地。当然了，在项目最终发布的时候，我们肯定希望能够有更多的人参与进来，使用这个项目。
我认为我们提供的服务还是非常重要的——在Google App Engine SDK 和Appspot 之间提供一个方案。这个需求我觉得还是挺多的。比如说你在Google App Engine 上运行了一个Java 编写的商店系统，然后你想把这个系统作为一个独立的应用迁移到你自己的生产环境上，那么你就可以使用这个中间的组件CapeDwarf，做一些运行和调试，就可以直接迁移到Appspot 的环境上了。他们完全不需要修改代码。
InfoQ：这的确不错。你在这个项目进展中遇到过什么问题吗？
Aleš：我总是喜欢做字节码的 hacking，但我总是不确定这到底是不是正确的做法。总之，可能我们应该用更加正规的方式来做，但是目前我们处于一种 hacking 的状态。
另一个问题是有关测试——测试的问题总是像鸡跟蛋的问题一样，尤其是来自 AS 的问题，因为当前我们的开发都基于 AS 的快照版本。我们的开发环境是基于快照版本的构建配置的，所以如果上游对构建配置进行了修改，我们这边就会报错，然后就到处找到底是哪里变动了，再把相应的变动复制粘贴到我们的环境里。这是我们遇到的最大的问题。
InfoQ：用稳定版本来开发是不是会更好一些？
Aleš：是的，但是最新的稳定版本是 7.1.1，对我们来说太老了。我们完成的实现会被应用到上游，而上游最终会成为下一个正式版本。
InfoQ：所以，你正在努力让 CapeDwarf 进入上游？
Aleš：怎么说呢，针对这个问题，大家一直有不同方面的讨论。CapeDwarf 并非 AS 上唯一想要进入上游的插件 / 子系统。很多其他的项目，包括 TorqueBox 和 SwitchYard 这些，都是类似的情况，所以把所有的插件加入上游可能不是个好主意。与其说这样解决了问题，我觉得这样可能反而会导致更多的问题。
所以，我们建立自己的 AS 分支，我们的分支里面包含 CapeDwarf 的集成；然后，我们将 CapeDwarf 的部分抽离出来，形成 AS 之上的一层。我认为这是更好的方法。这样，一旦 AS 的新版发布，我们就无需进行改动了，这让我们的生活轻松了很多。
InfoQ：在启动这个项目之前，你有没有调研过其他类似的项目？
Aleš：当然了。我是不喜欢做那些已经有人做过的东西。不过有的时候，有人做过的事情我们仍然会去再做，前提是你能够做的更好。
对于 CapeDwarf 来说，之前是有一些类似的项目，比如 AppScale ，是一群圣塔芭芭拉加利福尼亚大学的学生们启动的项目。不过，他们的做法不同——AppScale 覆盖的范围更广，包括 Python、Java 和 Go 等多种语言，同时在后端支持不同的数据库。我去看过这个项目，并且尝试搭建它，但是整个过程非常痛苦。我觉得这不是我想要的。我希望用户点点鼠标就可以搞定。在我们的项目中，用户只需要一个命令行，进行很少的配置或者零配置就可以运行。如果你需要一个集群，那只要再创建几个节点就行了。对于熟悉 JBossAS 的用户而言，这不成问题。
InfoQ：你们跟 GAE 的工程师们交流么？有没有什么故事可以分享的？
Aleš：也谈不上有什么故事。我们跟他们交流的确很多，不过大部分都是个人层面的交流。
InfoQ：在你身为软件开发者的这十几年，有没有经历过什么瓶颈？
Aleš：我是做数学出身的，不过我全家（我的父亲和两个兄弟）都是软件工程师，从小我就一直接触电脑。不过，小时候的我从没想过要以这个谋生。
到了大三快结束的时候，我开始迷茫到底该做什么。搞学术还是做 IT？
一开始，我加入了斯洛文尼亚最大的 Java 公司之一，当时我成长的很快；这之后，我进入了一家小一点的公司，参与一个很有趣的能源项目。正是在这段时间，我开始为 JBoss 做大量的工作，因为当时我们的能源门户项目需要用到 JBoss。整个项目是用各种快照建立起来的：Hibernate 的快照，EJB 的快照，AS 的快照。我负责维护这些快照，并修补各种 bug。但是很不好意思的事情是，当时我还是 Spring 的用户：）
那么我就开发了一个库，项目名称叫做 Snowdrop，将 Spring 和 JBoss 进行了桥接。然后就有人邀请我去那一年的 JBoss World 做一个分享。分享完了之后，他们就邀请我加入 JBoss。
当时我确实考虑了很多。但是我想了想，我又没什么可失去的。这年头，只要你是好程序员，找到一个工作总是很容易的。所以我就去了。这才有了过去这非常不错的六年。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论