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.
Community comments
less configuration is better
by serge ----,
Re: less configuration is better
by Yasin Hamid,
annotations
by Vic C,
Re: annotations
by William Smith,
... the idea is to make things easier .. not harder
by serge ----,
Re: ... the idea is to make things easier .. not harder
by vhi menon,
Re: ... the idea is to make things easier .. not harder
by serge ----,
Re: ... the idea is to make things easier .. not harder
by Sandeep Khurana,
Re: ... the idea is to make things easier .. not harder
by serge ----,
Re: ... the idea is to make things easier .. not harder
by Ronald Miura,
Nice to have element too in web.xml
by Yura Tkachenko,
less configuration is better
by serge ----,
Your message is awaiting moderation. Thank you for participating in the discussion.
the default should be to scan everything with the ability to override this with something similar to the *include*. This way things can work with minimal effort and if people are concerned about security they can tighten things up if they desire. I do however opt for scanning everything as the default (zero-configuration). If I have to go a put in the include to get things to work then I my as well just put in the entire serlvet mapping.
Re: less configuration is better
by Yasin Hamid,
Your message is awaiting moderation. Thank you for participating in the discussion.
I second that.
I absolutely agree that less configuration is better, more configuration is more error-prone and usually such errors are hard to track.
annotations
by Vic C,
Your message is awaiting moderation. Thank you for participating in the discussion.
That looks like a security issue, it should not be allowed.
Now I will be afraid to use a jar, I have to include source of a jar in my classes.
.V
Re: annotations
by William Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
I really like the look of these new features.
I don't understand this - could you elaborate on your concerns? In terms of annotations any annotation can be overridden by the web.xml. This is the same as EJB3 and the rest of the EE6 platform. Since EJB also allows this kind of deployment it would represent an equal and arguably greater security risk but doesn’t seem to have caused any issue for the EE5 platform. If you make a third party framework and think this is going to be a concern for your customers you can solve the problem by pre-compiling the .war file and generating a web.xml file using the metadata complete flag as described in the article.
... the idea is to make things easier .. not harder
by serge ----,
Your message is awaiting moderation. Thank you for participating in the discussion.
in order to effectively compete with other platforms the java platform needs to make things dead easy. The zero configuration approach is a good start. If people are so fixed on the security aspect then something like the *include* can override the default behavior. People should be able to get up and running with a framework with little to no effort. Are we not learning from frameworks such as rails where sensible defaults are the norm?
Re: ... the idea is to make things easier .. not harder
by vhi menon,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think it is a big big mistake making configuration-by-exception for security-related issues. Let's look at it as the following:
1. Why do we need this auto-scanning?
Easy to deploy: Unless you are doing some sample application, it is a non-issue. You don't spend most of the time writing web.xml. You do it once and be done with it! Are you sure you want to enable a security-senstive configuration by-default? Microsoft did the same approach for the Windows login environment. They enabled root user access by default, and it lead to huge problems.
It is possible that someone forgets to disable security-sensitive features and bingo, you have a backdoor!
2. I think a reasonable compromise is what I suggested in Rajiv Mordani's blog comments. Disable scanning by-default. Enable it according to package names (not JAR names). This way, you can say enabled="com.mycompany.publik.*". Which I think is a reasonable compromise.
We should not blindly follow zero configuration for ALL cases. Each has its benefits and drawbacks!
Re: ... the idea is to make things easier .. not harder
by serge ----,
Your message is awaiting moderation. Thank you for participating in the discussion.
What exactly have I gained in this self registration approach then? Instead of registering the servlet you’re asking me to register the directory to scan? Isn’t this defeating the entire purpose of this feature?
Re: ... the idea is to make things easier .. not harder
by Sandeep Khurana,
Your message is awaiting moderation. Thank you for participating in the discussion.
or instead of package name, it can be by a standard directory name under WEB-INF (like std directory names lib, classes one more std directory can be there) /a-conf (annotation configured) (or something like this) ?
Re: ... the idea is to make things easier .. not harder
by serge ----,
Your message is awaiting moderation. Thank you for participating in the discussion.
I was thinking about a standard directory like lib, tags etc. I wonder what the expert group thinks of that?
Nice to have element too in web.xml
by Yura Tkachenko,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi,
Above was mentioned how to tell web container what folders, files need to scan. But I really think it will be useful to have also < exclude> element. So this configuration can be build very easily:
Thanks,
Yura.
Re: ... the idea is to make things easier .. not harder
by Ronald Miura,
Your message is awaiting moderation. Thank you for participating in the discussion.
Configuration by annotations in this case is just stupid.
Nowadays, you code backing beans, or controllers, or actions. Who the hell codes Servlets anymore?
What do I gain enabling automatic classpath scanning? Even if I now have to register ten different servlets, filters, and listeners, from five different frameworks, in web.xml, I have to configure them anyway. One or two are just registered and are done. For most of them, you have to configure things like paths and init parameters, because they can't be hard coded in the frameworks' source.
Unless Sun now wants Servlets to compete with MVC frameworks, it just doesn't make sense. It opens a whole set of security problems, and adds nothing.
*** This is different from, say, JAX-WS (which also uses annotation configuration and automatic discovery). It IS competing with third-party WebServices libraries. When you Use JAX-WS you usually don't use Spring-WS or Axis. And, you rarely use a third-party, out-of-the-box WebService, you usually code them, because they have to expose a business-specific operation (or messaging endpoint, for the MOM-lovers :)). Servlets, instead, are completelly low-level infrastructure. Other frameworks build on it, instead of trying to compete with it.
What is really compelling about the new configuration mechanism is programmatic configuration. THIS may enable frameworks to simplify needed configuration, or even enable auto-configuration. It would be even better to have dynamic, 'hot' configuration (even programmatic configuration is loaded only once), but this is much, much better than the very limited web.xml mechanism.