要在OSGi容器中动态的管理Web相关的元素,目前有两种方式。
一种是通过类似于bridge的方式,现在外层的Web Application中配置一个对应的元素,然后通过对这个元素将外部的访问桥接到OSGi容器内部。在OSGi容器内部,会有一个总控的service,通过这个service来提供Web元素的动态管理,以及对外界请求的响应和分发。Equinox的Servlet Bridge就是采用的这种方式。
另一种方式就是通过使用Web Container提供的原生的API来实现Web元素的动态管理,将Web Container的部分功能作为Service注册到OSGi中,然后在OSGi中通过这个Service来动态的管理Web元素。
两种方式各有利弊:
对于bridge方式来说,优点是与Web Container实现无关,在多种Web Container中均能正常使用;缺点也很明显,无法使用Web Container提供的各种特性,并且相当于自己要实现一部分Web Server的功能,不仅是重复造轮子,而且还是个不怎么好的轮子,能否满足企业级应用的需求,还只是个未知数。
对于使用原生API的方式来说,优点就是完全使用Web Server自身的机制,可以保证性能和功能需求;缺点同样也很明显,现在流行的Web Server开源的并不多,而且就算是开源的,也不一定提供了可以动态管理Web元素的API,就算是有相应的API,也不一定适合OSGi环境,而且同一个Web Server的不同版本,API也很有可能会变化,这直接导致了原生方式实现的多样性和不兼容性。
幸运的是,在Tomcat 5.5.x和6.0.x中都提供了这样的API,在以后的章节中,我会着重针对Tomcat 5.5.x、6.0.x版本以及对bridge方式这三个场景,来实现对Web元素的动态管理。
Servlet 2.4中描述了如下可以在web.xml中配置的元素,这也是我要实现动态管理的目标:
- Context Parameter
- Error Page
- Filter
- Filter Mapping
- Listener
- Security role
- Servlet
- Servlet Mapping
- Welcome Page