SpringDM笔记12-Spring DM’s web Extender运行机制
SpringDM把一个WAR作为一个Bundle, 其实是将对WAR的处理交给当前OSGi环境中的WEB容器去处理的，即：
WEB Application的创建和线程的管理委托给了WEB容器。那么SpringDMV是如何决定一个Bundle是要委托给
WEB容得的呢？实现这个功能主要是通过Spring的：Extender 机制：
如果一个安装的Bundle是以.war作为扩展名的，他将自动触发SpringDM's Web extender将对该Bundle的处
理委托给underlying的WEB 容器。
1.Structure of Spring DM web OSGi components
SpringDM Web Extender 部署bundle至内嵌的Web容器需要的条件：
■ The bundle location (filename) ends with .war ■ The bundle contains a WEB-INF directory
目录结构：
my-web-bundle
META-INF/
MANIFEST.MF
WEB-INF/
web.xmlWhen a bundle is detected as a web bundle, the web extender will trigger its deployment to the web container, letting the latter handle everything.
Bundle Context Path :
(1) SpringDM Web Bundle算法计算：
The default behavior of the Spring DM web extender, with respect to the definition of context
paths, is dictated by a context path strategy, the default being the DefaultContextPathStrategy
class (in the org.springframework.osgi.web.deployer.support package). This default strategy bases its decision first on the presence of the Web-ContextPath header, and then, if the header
isn’t present, on the location of the bundle, by removing the trailing .war or .jar (just like in our
example). After that it falls back on some of the other bundle metadata (name, symbolic name, or
identity) if it can’t use the bundle location.
(2)明确定义：
Web-ContextPath: mycontext
2. Classloading in web bundles
2.1 Traditional,Standerd Web Application ClassPath's Structure
■ WEB-INF/classes directory—Contains application classes (web controllers, such as servlets).
They’re under their .class file form (not packaged) and organized following the traditional
tree-like structure of Java packages. ■ WEB-INF/lib directory—Contains third-party libraries, packaged as JAR files.
2.2 OSGi Web Bundle Class Loading
When you deploy a web application using the Spring DM web extender,OSGi-specific classloading
mechanisms take precedence. Remember that before being a web application, your application was also an OSGi bundle; as such, its classpath is the OSGi classpath. It benefits from everything
OSGi provides for handling classloading (class visibility, versioning, reloading, and so on).
(1)The web application will be able to load classes from the following locations:
■ Its bundle space (classes in the JAR or WAR and classes from all the associated bundle
fragments)
■ClassesfromthepackagesimportedwiththeImport-Packageheader
■ All the exported classes from bundles appearing in the Require-Bundle header(2)实现将SpringDM Web Bundle做成标准的WAR:
The Bundle-Classpath header, which indicates to the OSGi platform where to find classes and
resources in the bundle. This header defaults to ".", meaning the root of the bundle. You can
override this default value and set it to the traditional locations of classes and libraries in WARs
(you should not forget to include the default location): Bundle-Classpath: .,WEB-INF/classes,WEB-INF/lib/libA.jar,WEB-INF/lib/libB.jar
3. OSGi-aware Spring web container
WAR Bundle 如何访问其他Bundle中的类？
SpringDM总是努力尝试去创建一OSGi上下文：OgiBundleXmlApplicationContext，这个Context包括
Spring Artifacts, 以及注册、消费的服务。而在WAR Bundle中，线程的管理被委托给了WEB容器，如果这个
Context不明确指定对其他Bundel而言是不可见的。
SpringDM解决这个问题是通过一个特殊的Context：OsgiBundleXmlWebApplicationContext，该Context
与某个Bundel的Context关联，而该Context常常配置在web.xml文件中。见下面配置。
In standard Spring-based web applications, the Spring container is started and stopped by the
web container itself, usually through a dedicated servlet listener, the ContextLoaderListener.
The ContextLoaderListener is part of the web module of the Spring Framework. You declare it in
the web.xml file of your web application, and in it you can set the location of your Spring
configuration files and, more importantly in our case, the implementation of ApplicationContext
you want to use. Spring DM comes with a specific application context implementation,
OsgiBundleXmlWebApplicationContext, which can communicate with the OSGi platform even
though its instances are created by a web container.
Configuring a web application to use the OSGi web application context：
<web-app (...)>
(...)
<context-param><!-- ContextLoaderListener 根据该参数判定是哪一种类型的Web应用上下文，这个参数默认是：
XmlWebApplicationContext,现在改成SOGi应用上下文，这样WAR Bundle则可以访问其它Bundle.
--> <param-name>contextClass</param-name>
<param-value>
org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext
</param-value>
</contxt-param>
<context-param><!--- 这个值默认为WEB-INF/applicationContext.xml，现在为自定义--->
<param-name>contextConfigLocation</param-name>
<param-value>
WEB-INF/applicationContext.xml,
WEB-INF/applicationContext-osgi.xml
</param-value>
</context-param>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener><servlet>
<servlet-name>PBWDP</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
<init-param>
<param-name>contextClass</param-name>
<param-value>org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext
</param-value>
</init-param>
</servlet><servlet-mapping>
<servlet-name>PBWDP</servlet-name>
<url-pattern>/APP/*</url-pattern>
</servlet-mapping>
(...)
</web-app>注意：If you use the ContextLoaderListener and the OsgiBundleXmlWebApplicationContext in
your web applications, you must include their respective packages in the Import-Package header
of your web bundle manifest.
4. Spring DM web deployer
SpringDM提供了一个用于指定Web上下文发布路径的Header:Web-ContextPath,默认下该值为：
http://localhost:8080/BundleName/
可自己定制该值，如：
Web-ContextPath: HelloWorld
访问路径为：http://localhost:8080/的HelloWorld/
The Spring DM web extender is implemented as a synchronous bundle listener,which is registered
by the activator of the bundle. The bundle listener doesn’t itself handle the deployment of web
bundles; it delegates this perilous task to a WAR deployer.(TomcatWarDeplouer,JettyWarDeployer)
Even though the activator of the web extender bundle coordinates and performs some of the
work (scanning of incoming bundles, thread management for deployment and undeployment), the
WAR deployer is in charge of truly deploying (or undeploying) web applications to the embedded
web container. Through the WarDeployer interface, Spring DM abstracts the action of deploying
and undeploying WAR files, allowing a separation of concerns,because WarDeployer
implementations just handle the deployment process for their web container, whereas the web
extender sticks to its primary goal: listening for bundles starting or stopping.
Spring DM provides two implementations of WarDeployer: one for Apache Tomcat (the default)
and one for Jetty.
WAR deployers interact directly with the underlying web container instance when the web
extender hands them a WAR bundle. They can manage their own instance of the web container,
buttheusualwayistolookitupintheOSGiserviceregistry.By“instanceofwebcontainer,”
we mean an instance of the core class of the web container—org.apache.catalina.Service forTomcat and org.mortbay.jetty.Server for Jetty.
5. 切换不同的Web容器
默认下，SpringDM将WAR委托给一个Tomcat实例，要切换成其他的Web容器，需要spring-osig-web
-extendr.jar, 当该JAR启动时，它将是这定位一个Tomcat实例，如果找不带将产生下面的异常：
Exception in thread "WebExtender-Init"`java.lang.NoClassDefFoundError:
org/apache/CatalinaLoader
如果找到一个Tomcat实例并且所有的依赖被Resolved,SpringDM将试着获取已经注册了得一个服务：
org.apache.catalina.Service,如果找不到该服务，将产生下面异常：
org.springframework.osgi.OsgiException: Cannot create Tomcat deployer
根据上述理解，SpingDM使用不同的Web容器时需要考虑下面两个问题：
(1) Override SpringDM默认的extender value，而使用另一个Web容器；
(2) 由一个服务注册Bundle去启动OSGi Web 容器；
解决第一个问题可以使用OSGi 的Fragment来实现，而解决第二个问题需要新开发一个启动Web容器的Bundle,
Tomcat和Jetty容器依赖于自己的配置文件(server.xml、jetty.xml)来制定Web容器的端口，SSL证书等信息；
因此该Bundle需包括启动Web容器的配置文件及将该Web容器注册为服务的一系列功能。 开发该Bundel可参考
Tomcat与jetty的实现：catalina.start.osgi-1.0.0.jar和jetty.start.osgi-1.0.0.jar。
