……我们从根本上说并不打算把Spring用户社区驱赶到任何方向。我们仅仅是给用户另一种选择。Spring的哲学是用户总是正确的。用户是聪明的，他们完全明白自己的需要。不管用户是否选择SpringSource应用平台，我们觉得用户总会欢迎多一点选择的……Java EE 6重点在模块性，这个方向是正确的。很可能SpringSource应用服务器会在一定程度上符合Java EE 6。Java EE 6分成A、B、C三种规格（profile）。我们几乎肯定会实现A和B规格，C规格里面我非常确定将实现Entity Beans 1.1模型以及一些遗留技术。我还不能说是100%确定，因为Java EE 6规范还没有定案。传统的应用服务器模型正逐渐过时。BEA和IBM正在用OSGi逐步重新实现他们的应用服务器。 SpringSource现在就提供OSGi支持。从统计数字上看，大多数人都不会部署到完整的平台上，他们部署到Tomcat。他们选择了Spring 编程模型而非Java EE。市场已经作出了选择，问题只是开发者还要和服务器斗争多长时间。
- 它是第一个建立在现代技术基础上的产品。符合Java EE规范已经不是至高无上的目标。干净的代码基础是我们的一项竞争优势。我们在设计和实现中满足的是现今的需求，而不是10年前的需求。
- POJO编程是现在行业的方向所在。过去POJO编程是被强行嫁接到其它产品上的。在我们的产品中，POJO编程是设计的前提。
- SpringSource应用平台采用的OSGi技术是下一代技术的基础。
……JPA和JMS都支持，但我们没有包含任何特定实现。对于JPA，我们支持Hibernate、 OpenJPA和Toplink。我们在OSGi环境中增加了对加载时织入的支持，而且会尊重应用的边界，因此不会意外污染应用间共享的库。不包括 JNDI，我们用OSGi Service Registry来取代它。Servlets是通过内嵌的Tomcat来支持的。JEE中有而SpringSource应用平台没有的东西包括 Entity Beans等等。这个平台引入了应用的概念，应用由一个或多个Bundle组成。应用中的包有明确的作用域，可以防止发生应用间的冲突。在应用把服务发布到OSGi service registry的情况下，防止冲突尤其重要，谁也不想见到服务之间发生冲突。
我 们引入了Import-Library语句，因此在应用中使用第三方库变得更加简单。你不需要再写一大串不直观的 Import-Package声明，Import-Library可以自动为指定的库引入所有必需的package。像Hibernate JPA这样的库还可以跨多个Bundle，可见Import-Library确实物有所值。
至于为了让Spring DM在平台中运行而进行的扩展，为数不多。Spring DM掌控下的Bundle（Spring DM powered bundles）是包含META-INF/spring/*.xml文件的普通OSG Bundle。Bundle启动的时候META-INF/spring/*.xml文件会自动成为该Bundle的 ApplicationContext。Spring DM提供了一种机制让各Bundle通过Spring NamespaceHandler导入和导出服务。
一个PAR（Platform ARchive）本质上是一组OSGi Bundle，通常其中有一部分是在Spring DM掌控下的。这些Bundle共同组成了一个逻辑上的应用。编程的时候完全是纯粹的OSGi、Spring和Spring DM——PAR没有改变什么。简单来说我们避免做这样的事。Buddy类装载、动态import、require-bundle，这些我们都明确回避，因为维持一致的类空间太困难了。我们也不会提供任何专有的替代机制。
相 反，我们给Equinox增加了一些低级的钩子，以实现典型的场景下的资源装载。我们扩展了类装载来支持加载时织入，并且把装载语义丢到一边。我们操纵 context classloader，让第三方一如既往地看到类。PAR是其中的核心角色，因为它定义了上下文类装载以及加载时织入的可见范围。
对于一些最糟糕的情况，我们会提供修补版的库，让它们能在OSGi中工作。修补版的库可以通过SpringSource Enterprise Bundle Repository获得，我们的修改也会提交回相应的项目。