To achieve the zero configuration and plugability goals, the specification proposes several new features including:
- Additional annotations: The Servlet 3.0 specification introduces a number of new annotations including @Servlet, which provides url-mapping information for the servlet - @Servlet(url-mapping=”/foo”) - and @ServletFilter which is used in conjunction with @FilterMapping to define a filter in a web application.
- Support for web.xml fragments: These can contain the definition of a servlet, filters, and listeners to be merged with the web.xml to allow a web framework jar to package up all its defaults, so that it can more easily be dropped in and used.
A flag (metadata-complete) is used to control the scanning of both annotations and fragments.
These features are causing considerable debate within the expert group, with some members concerned that they represent a serious security risk with accidental or deliberately obfuscated deployment of unintended filters and servlets. There is also some debate around whether the new features are sufficiently flexible. In consequence the expert group are asking for community feedback. Greg Wilkins has described the concerns, with particular reference to the automatic scanning and merging of web fragments, in some detail on his blog, and also outlines one of three possible solutions: using an optional <include> element to guide the automatic discovery of configuration:
"Without a web.xml or with a 3.0 web.xml that does not list any inclusions, the default would be to search all of WEB-INF for annotated servlets and filters, TLD listeners and web.xml fragments as currently proposed. If however, a web.xml contained <include> element, then the discovery process would be modified as the following examples illustrate:
<include src="WEB-INF/lib/dwr.jar"/>
<include src="WEB-INF/lib/cometd.jar"/>
<include src="WEB-INF/classes"/>
This include would scan only the dwr.jar and cometd.jar for annotations, TLD fragments and web.xml fragments, the WEB-INF/classes directory would be scanned for annotated servlets. No other jars or classes would be scanned unless listed in their own include elsewhere in the web.xml."
Specification lead Rajiv Mordani is unconvinced:
“The benefit that the include proposal from Greg Wilkins is very little specially if the main concern is that servlets and filters are being exposed without the user intending to do so. I think that it is the problem of the framework developer and not the user of the framework to make sure that they don't expose certain types of components. By using a flag to control scanning you can effectively get what the include mechanism provides except you don't get partial scanning of only a certain set of jars. The include mechanism would probably only make the descriptor more verbose in having to list the jars you want scanned.”
Two other possibilities were discussed by the expert group at this year's JavaOne conference. One option is to introduce a second flag in addition to metadata-complete, using one to enable/disable the scanning of web fragments and the other to do the same for annotations. As Rajiv Mordani points out however, the annotation mechanism can already be overridden by the web.xml file, providing a reasonable level of control:
‘When you use annotations to declare servlets and Filters then you must have a url-mapping / FilterMapping attribute on the corresponding servlet / Filter. In this way there is no convention by which a servlet is exposed without having an explicit mapping. Also, as with the rest of the Java EE platform, specifically technologies like EJB and Web Services, the deployment descriptor is used to override information that is specified via annotations.... If you didn't want any of the annotations to be processed at all by the container and wanted to specify all the configuration via the deployment descriptor, then, like with the rest of the Java EE 5 platform, we have the metadata-complete element in the descriptor. If the element is present and set to "true" then the container will not process any annotations and just use the configuration specified in the descriptor. This provides a way [to] disable the auto-scanning for those that have concerns about performance, and security.”
The other option is to provide a mechanism for disabling servlets and filters in the application's web.xml so that any servlets that aren't needed in production can be disabled via the main web.xml of the application, for example:
<servlet>
<servlet-name>FrameworkServlet</servlet-name>
<enabled>false</enabled>
</servlet>
Feedback should be sent to the expert group at jsr-315-comments@jcp.org.
