简短的回答是： 是的。
在本条目中，我将阐明我们的便携性目标，然后解决许多人在使用 Seam 3 在 GlassFish（和 JBoss AS）上遇到的问题。希望我能充满信心地解决您的挫折：
便携性是一个目标
Seam 3 不仅适用于 JBoss AS。 我们为 Seam 3 的主要目标之一是实现 CDI 所倡导的便携性合约，同时在提供与容器的强集成（CDI、Java EE 等）。这是一个基于 CDI 构建的便携式扩展库。因此，您应该能够使用它与任何兼容的 CDI 运行时。
我们坚持这一目标，因为它为您，开发者，提供了选择。这是我们坚信的事情。还有其他好处。它使 Seam 能够触及更广泛的开发者社区，并激励我们使 Seam 更加健壮。
显然，某些模块将故意提供非便携行为。这些特性在您的要求需要时存在，并在文档中适当指出。一般来说，我们希望您能够自由地使用 Seam 在最适合您的 CDI 环境中。
有了这个目标，我们无疑为这个项目设定了高标准。这不会总是容易，特别是在开始时。我们已经遇到了一些困难。我们也犯了一些错误。这些都是新兴技术的预期。我们正在追踪并解决这些错误。我们已经遇到的任何限制都已经在 CDI 1.1 中得到解决。
问题是什么？
Seam 3.0.0候选版本中的几个模块在GlassFish 3.1（甚至JBoss AS）部署时出现错误。我们正在解决这个问题，其中一些问题源于CDI实现或应用服务器。我们不想互相推诿责任，我们想要解决这些问题。
CDI是Java EE平台中最定义明确的规范之一，具有广泛的测试套件，几乎没有给实现留下越界的机会。然而，不一致性仍然存在。在我们致力于Seam 3并推动CDI的极限时，我们将这些不一致性带到表面。
幸运的是，你已经从Pete那里听说我们已经提交了CDI 1.1的JSR提案，该提案将关注一小部分广泛请求的功能，以及错误修复和澄清。在短期内，最快、最有效的方法是互相帮助理解正确的行为，并确保所有实现都正确支持它。只有当我们开始互相指责时，才会出现混乱。
无论问题出现在哪里，我们都会尽力尽快解决它们，主要是通过编写兼容性测试（在Solder模块中找到）使用Arquillian来传达预期的行为。然后我们使用这些测试作为基于CDI规范中定义的规则的支持或补充的假设的基础。我们还继续加强我们的测试套件，并利用Arquillian在更多容器上运行它。
随着时间的推移，可移植性不仅是一个目标，而且是可以信赖的。
为可移植性铺路
使Seam 3可移植的部分包括确保应用服务器遵循相同的规则。在所有情况下都没有做到这一点。（最近我们在GlassFish 3.1中遇到了一些问题）。以下描述的问题意味着Seam 3部署出现错误。我们并没有忽视这些问题。我们一直在积极工作，消除这些粗糙的地方，这对Seam 3和Java EE总体来说都是有益的。
我将尽量清楚地解释你可能在GlassFish或JBoss AS上运行Seam时遇到的问题，以及我们在最终发布之前已经做（或仍在做）什么来解决这些问题。我与你分享这些信息是为了让你了解情况。到目前为止，我们已经解决了其中大部分问题。
计划发布Weld 1.1.1版本，该版本专门修复这些问题。Brian Leathem提供了在GlassFish 3.1中更新Weld的说明，到时候会用到。
Alpha-bravo库可见性
影响：GlassFish 3.1（在Weld 1.1.1-SNAPSHOT中修复）
问题报告：GLASSFISH-15735
测试案例：JarToJarReverseAlphaVisibilityTest
解释
- 在某些情况下，一个Bean存档（jar）中的类型（类）在另一个jar中的Web模块中的Bean和扩展中不可见
- 可见性取决于存档名称的字母顺序
- 名为“alpha.jar”的存档可以查看名为“beta.jar”的存档中的类型，但反之则不行
- 名为“alpha.jar”的存档中的扩展可以观察来自名为“bravo.jar”的存档的AnnotatedType
后果
- 带有名称在字母顺序上先于“seam-solder.jar”的库（例如，seam-servlet.jar）的类型记录器和消息包没有被Solder处理
- 来自“seam-international.jar”的内置消息Bean无法注入到“seam-faces.jar”中的Bean中，因为“seam-faces.jar”在字母顺序上排在前面
解决方案
- 通过模块检查并找到了一种针对每种情况绕过该问题的方法
- 最坏的情况是，您可以组合所有Seam组件到一个单独的JAR文件中
库到应用程序的可视性
影响：GlassFish 3.1（未解决）
问题报告： GLASSFISH-15721
测试用例： VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest
解释
- WEB-INF/classes中的bean在同一个web模块中的bean存档（jar）的BeanManager中不可见
后果
- 几个Solder特性在GlassFish上不可用（EL评估器、默认bean、通用bean、解包、服务处理器）
解决方案
- 我们已经确保Solder不会引起部署问题
- 我们需要解决这个问题才能解锁所有Solder特性
缺少类型化日志记录器和消息包实现类
影响：Seam<=3.0.0.CR2（在Seam 3.0.0.CR3中修复）
问题报告： SEAMSERVLET-30，SOLDER-62
解释
- 目前有两个模块（Seam Solder和Servlet）使用了Solder提供的类型化日志记录器和消息包特性
- 实现类必须由代理或注解处理器生成
- 生成代理需要设置一个系统属性（jboss.i18n.generate-proxies）
- 注解处理器在Seam 3.0.0.CR2之前没有完成
后果
- 在部署时，您会收到ServletLog和/或AnnotatedMessages不满足依赖关系的错误
解决方案
- 注解处理器现在可用，我们正在生成具体的实现类（感谢James和Ken）
- 我们在Seam Solder中添加了文档，以指导您如何使用此功能，以及您拥有的选项
悬挂的web片段引用
影响：Seam<=3.0.0.CR2在GlassFish和Tomcat上（在Seam 3.0.0.CR3中修复）
问题报告： SEAMSERVLET-29，GLASSFISH-16201
解释
- Seam Servlet有一个包含一个排序子句的web-fragment.xml，它引用了一个名为WeldServlet的web片段
- 动机是确保在调用Seam Servlet监听器之前，Weld引导程序被启动
后果
- 在GlassFish和Tomcat 7上存在部署问题
解决方案
- 实际上我们根本不需要这个引用，因为Weld Servlet还没有使用web片段（过早优化）
- 这个引用已经暂时移除
间歇性的拦截器
影响：GlassFish 3.1（未解决）
解释
- 在beans.xml中列出的拦截器并不总是被启用（似乎每次部署都是随机的）
后果
- 在Seam预订示例中，如果@Begin/@End拦截器没有启用，预订的会话就不会激活
解决方案
- 目前，唯一的解决方案是重新部署应用程序
过度积极的类扫描器
影响：GlassFish 3.0.1（在GlassFish 3.1中修复）
解释
- 类扫描器在发现一个字段引用了类路径上不存在的类的类时失败；在考虑将类作为bean之前就会发生
后果
- 不能有基于可用性的可选bean被启用
- Seam Faces因为对Seam Persistence的可选依赖而崩溃
- Seam Solder因为对日志提供者的可选依赖而崩溃
- Seam Persistence因为对Hibernate的可选依赖而崩溃
解决方案
- 您需要添加大量不必要的依赖来满足这些找不到类的异常
- 我们强烈建议升级到GlassFish 3.1
向上
经过深思熟虑，我们决定进行CR3并推迟最终发布一周。请利用这个机会核实您遇到的问题已得到解决，以便我们能在Seam 3.0.0.Final中交付高质量的结果。
到达这个阶段的道路漫长，我们非常感激整个团队的付出。我特别感谢James Perkins和Ken Finnigan为设计并实现类型日志器和消息包的注解过程所付出的努力。我还想感谢Jason Porter，他实现了Arquillian GlassFish 3.1容器适配器，使我们能够在GlassFish 3.1上运行兼容性测试。
这确实是一个在所有意义上都是社区项目，我们非常自豪能够成为这个充满激情的开发者团队的一员。
Seam 3.0.0.Final并不是终点，而只是一个起点。Seam 3的参与度正在迅速增长。现有模块已经开始展望3.1，新模块也已安排。我们也在着手编写迁移指南。我鼓励您加入我们，帮助我们使Seam 3成为企业Java开发者的一款出色的扩展堆栈。
更新
我刚刚构建了最新的Weld，并替换了GlassFish 3.1中的OSGI包，Solder测试套件中只有两个失败的测试
这意味着几乎所有的Solder功能都是可用的。几乎就要完成了。
更新2
Weld OSGi包的快照现在可在JBoss快照仓库中找到。
