Despite my vigorous arguments for flexibility (or perhaps because of them :), I’ve not been able to make the case with those opposed to selective enabling of auto configuration.
Unfortunately my arguments keep getting cast as security arguments. While there is an element of that, my main point is that I would like to be able to use modularized configuration without losing total control. Even if I have to specify everything in web.xml, I would prefer to do so in fragments rather than 1 monolithic file. The counter argument appears to be that be that just because there will always exist some scenarios that will need a full web.xml, there is no point trying to offer a solution for any other scenario other than full automatic discovery and deployment.
As I’m not making the case and those that are unconvinced include the lead of JSR-315 and other EE JRSs, so I’m going to cease hammering on this issue as it is probably blocking discussion of features for Servlet-3.0 more important than ease of configuration.
But rest assured, Jetty-7 will support these features, but will make them optional, selective and able to be parameterized. So if you want to have control over what you deploy and you want to use modularized configuration mechanisms, then look no further than Jetty!
So when you find yourself to unzipping a jar file, just so you can change something in the reasonable default settings (as conceived by the framework developer) or copy them into your own web.xml… just remember I TOLD YOU SO!
7 Comments
rektide · 18/05/2008 at 09:50
Every java web app I’ve worked on uses Spring to manage almost all aspects of deployment. Spring is built for configuration management, my impression was that the Servlet team is duplicating a lot of infrastructure people already take for granted. Then again, you have to bake in your own "turn this piece on and off" properties where desired, and every projects config setup ends up looking a little different.
Greg Wilkins · 19/05/2008 at 03:04
Spring is indeed good for configuration, but in many circumstances it cannot be used to configure filters and servlets.
The web app init parameter mechanism is only suitable for the most basic of configuration… normally to point to a more specific application/framework configuration mechanism!
Also with the announcement from springsource that spring is now aiming to be an EE container, it may be that spring will be duplicating things already in web containers?
Anonymous · 21/05/2008 at 09:20
Will the servlet api provide a way to obtain the actual web.xml from a running web app (regardless if it is automagically setup or not)? Or at least provide all the info to construct it?
yoR · 22/05/2008 at 08:42
There are some things I really don’t like about it… mostly stuff to do with annotations. Just check my review : http://www.redcode.nl/blog16.html
yoR · 22/05/2008 at 21:37
I personally think there are more problems with the JSR-315 spec. The auto-discovery mode can be switched off if you don’t use it, so thats solved.
But my worries are mainly about the annotations that have been suggested: http://www.redcode.nl/blog16.html
Greg Wilkins · 24/05/2008 at 05:58
yoR – I tend to agree with your concerns about annotations and I fail to see what is wrong with using an interface.
However, the drive towards annotations is not coming from within JSR-315, but from the EE JSRs. For better of for worse, they appear to have to power to contribute large sections of the specification and the EG has to make the case for exclusion rather than the new features making their case for inclusion. It has always been this way with the servlet spec and it is a failing of the JCP in my mind.
But as you say… they can be turned off. If only they could be turned off selectively!
J. David Beutel · 30/07/2008 at 03:35
Selective inclusion sounds good (another reason to switch to Jetty). I also recommend selective exclusion/disablement. Example from a different area: Sun gives this policy file for jstatd:
grant codebase "file:${java.home}/../lib/tools.jar" {permission java.security.AllPermission;
};
But the policy file can only grant; there’s no way to deny a permission from All (e.g., SocketPermission from anywhere but my address), and Sun doesn’t list the permissions that jstatd needs, so configuring the full policy file is a daunting task of trial and error. Even Sun doesn’t bother with it
Comments are closed.