spring文件服务器（SpringSource新应用服务器发布 摒弃Java EE）

……我们从根本上说并不打算把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获得    


     


   ，我们的修改也会提交回相应的项目 




 




。