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获得    


     


     


     


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




 




 




 


。