Here is a key deployment problem that the servlet spec needs to address in its next version.
So far, the servlet spec recognized only two classes of users:
- Containers developers: Developers who implement the spec.
- Web developers: Developers who program to the servlet API and develop web apps.
But there is a growing third category of users of the servlet spec, and this group needs recognition from the servlet spec.
This category includes developers that write web frameworks (like struts), or implement other containers (like portlets, JSF, or even a web services runtime). This class of users have special deployment requirements that are not met by the current servlet spec, and as a result, these frameworks/runtimes leave some configuration details to end developers. Here are some examples that come to my mind:
- Struts requires a servlet to be deployed for struts apps to work.
- JSF implementations require some implementation specific components to be declared in web.xml.
- Apache Axis requires a servlet to be deployed in your web app to receive web service requests.
- Most portlet containers are built on top of the servlet container, and require implementation-specific servlets and/or context listeners to be deployed.
Right now, it is usually the responsibility of the developer using these frameworks/runtimes to deploy some servlets/filters/context listeners etc. This is a shame, given that, as a developer using, let's say, Struts, I should not be required to deploy struts itself in my app. I should be able to treat the Struts framework like an add-on to the servlet container, and the Struts framework should worry about adding whatever is required to the web.xml to make it work. It should not be my responsibility.
I agree that this is a tooling problem, but cannot be solved cleanly without some help from the servlet specification. And, that brings to the point of asking for an SPI.
To let these frameworks/runtimes solve their deployment problem, IMO, the servlet spec should recognize this third category of users, and provide an SPI to let these frameworks configure the servlet container. Here are some requirements that I can think of for this SPI.
- Inject servlets, servlet mappings, servlet filters, context/session listeners, tag libraries, resource references etc during the deployment process of web applications.
- Allow multiple such SPIs to participate in the deployment process. For instance, it is not uncommon for a portlet runtime to require a portlet container, a web services runtime, and may be, a JSF runtime (e.g. to deploy JSF apps as portlets via some portlet bridge).
- Provide some automatic means for discovering and invoking each SPI, e.g. by way of adding a new SPI-specific descriptor in each SPI's jar file.
Once such an SPI is in place, the processing of configuring these runtimes/frameworks would be very much simplified. Such an SPI makes sense, given that more and more developers are programming to the layered APIs provided by these frameworks/runtimes, and not directly to the servlet API.