这个版本本不想做得这么大。最初我们打算叫它1.1.7，但当我们坐下来查看自1.1.6版本以来的变更日志大小，我们意识到这里的变化实在太多了，对于一个点版本来说。所以它得到了一个非常突然的品牌重塑；；)
警告：这不是承诺的带有WS和ESB集成的1.2版本！那将作为Seam 1.3在未来几个月推出。
Seam的开发进入了超高速：现在有三个人（我自己、Norman、Shane）全职在这个项目上工作，Pete Muir也即将加入，还有许多来自用户和来自Michael Yuan、Max Andersen和James Williams等JBoss人员的贡献。
说到用户贡献，这个版本中最大的新特性是由Michael Youngstrom开发的：备受期待的Spring集成。Michael做了惊人的工作，让两个组件模型协同工作，正如您在这里可以看到的
http://docs.jboss.com/seam/1.2.0.GA/reference/en/html/spring.html
从一开始，有些人就想把Seam看作是JBoss对Spring的回应。我一直强烈反对这种描述，因为我们真正瞄准的竞争者是.NET，以及在一定程度上是Ruby on Rails。Seam的目标是成为一个包含框架和工具的全套开发环境，其中一切都能“开箱即用”。在某种程度上牺牲了个人技术的选择，可以节省更多的时间来评估和争论产品，从而有更多的时间在更一致、更深入集成的编程模型中开发真正的用户可见的功能。
至少，这是理论。
在实践中，我们的大部分用户都是从基于Spring、Hibernate和Struts/JSF等的一些遗留架构迁移过来的。例如，以色列的一些人在将三个不同的客户项目从Spring和Hibernate迁移到Seam和EJB 3.0的过程中。如果这意味着一次重写整个业务层和表示层，这将是一项相当大的工作。我们所能做的一切来让这些人在Seam中以最少的工作量重用现有的Spring组件，都是值得做的。
同时，外面有一群人拒绝考虑使用包含字母 E
、J
和 B
的任何技术。他们甚至不会评估任何不允许他们用数千行Spring XML来微观管理组件的框架。尽管我认为这些人完全错过了整个 POJO
概念的要点（原本是关于简单性和减少代码行数），但我仍然希望他们能够使用Seam，并逐渐适应Seam的方式，以他们感到舒适的任何速度。
Michael的Spring插件让Seam可以像Seam核心那样将Spring bean视为Seam组件。这意味着您可以从Seam轻松调用遗留的Spring组件 - 您甚至可以在Spring bean中使用Seam注解，如@In、@Begin或@Scope。您可以将Seam的上下文用作Spring的自定义作用域。您可以将Spring注入到Seam中，也可以将Seam注入到Spring中。您甚至可以使用Seam管理的持久化上下文从您的Spring DAO中。
那么Spring和Seam是天作之合吗？嗯，不尽然。与EJB3或JavaBeans不同，它们都是作为有状态的组件模型设计的，Spring bean从未打算在上下文状态架构中使用。至少在集群环境中，最好坚持使用Spring bean作为无状态服务，由有状态Seam组件调用，而不是疯狂地使用会话作用域的Spring bean。但如果你真的想疯狂尝试，请告诉我结果如何！我认为这些新功能相当酷；-)
