- 浏览: 330971 次
- 性别:
- 来自: 北京
最新评论
-
hoey168:
请问楼主,ICE 客户端连接多个服务端,tcp -h 172. ...
ZeroC ICE之旅------负载均衡及容错 -
iOracleSun:
makeC++SharedLib 增加 -G参数即可链接成功 ...
AIX apache module问题 -
fanyonglu:
不错,讲的很细,学习中
ZeroC ICE之旅------java -
click_guobin:
...
我在深圳,每月收入850元,怎么也花不完,晒一晒我是怎么开销和投资的(zz) -
hanyu332:
引用修改%apache%/conf/httpd.conf修改为 ...
awstats日志分析小结(1)
Introduction
All modern Java web applications use Servlets and Filters. They are the backbone of Java EE, the communication gateway to the World Wide Web.
Now there is a new specification coming, Servlet 3.0 (JSR-315). The Early Draft of this specification features some new really neat features, and in my opinion some mistakes. In this article I'm going to show the new additions to the EOD (ease of development), comment on them, and try to improve them.
Servlets
Since Servlet 2.3 we've been using the Servlet interface to create our Servlets. This interface has one main method called service(ServletRequest reand a ServletResponse. The abstract class HttpServlet helps us to create a HTTP suitable Servlet. It contains methods like doGet and doPost.
The easiest way to create custom behavior was to extend the HttpServlet and implement your own doGet and/or doPost.
public class GetPostServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { .... } }
To instruct a Servlet Container to use your Servlet you have to add them to a file called the web.xml. This file contains mapping information from URL to Servlet, so when a user requests the mapped URL the Servlet will be called and asked for a response.
JSR-315
Servlet 3.0 has a couple of proposed changes. One of the big changes is adding support for continuations, in the new API you can call request.suspend() to suspend the request, and later (from another thread) call request.resume(), the Servlet is then again called to resume the request.
The second important addition is pluggability. Servlets can now be added to the container during runtime. If you create an instance of the ServletContextListener you can call servletContext.addServlet() and servletContext.addServletMapping() to add Servlets on runtime. Of course this poses a security risk, because included JARs could register their own Servlets, something you definitely don't want. But the specification is aware of this, and working on making it safer (for example, giving you a switch to turn auto-detection off).
The third major addition are the new annotations. Here is an example of these annotations in use:
@Servlet(urlMapping={"/myServlet"}, name="MyServlet") public class PojoServlet() { @GET public void handleGet(HttpServletRequest req, HttpServletResponse resp) { .... } }
As you can see there are a couple of new features. First of all, the Servlet is a POJO; there is no more interface/abstract class. Also notice the url mapping in the @Servlet annotation; no need for the mapping in the web.xml.
Then there are the Filters:
@ServletFilter @FilterMapping(urlPatter="/myFilter") public class PojoFilter() { public void doFilter(HttpServletRequest req, HttpServletResponse resp) { .... } }
Here we can see a ServletFilter with the new annotations. This again has the mapping in the annotation, no need for the web.xml and it is a POJO again, no more interface/abstract class.
What is the problem?
So you might ask, what is wrong with this proposals new ease of development?
Well, maybe a couple of things. First of all, lets see what these new annotations add:
- The mapping information is in the Servlet
- The Servlets are POJO's
- You can specify which method handles the GET and POST
Well, first of all the mapping information, which is a great feature. Although the naming of the annotations is a bit unfortunate. Why does the @Servlet annotation have the mapping inside, and does the @ServletFilter have a seperate annotation @FilterMapping? It would be much cleaner to have one way of declaring these mappings.
The second and third change (the ability to specify the GET and POST with @GET, @POST, @HEAD, @PUT etc.) has only one small advantage. Who hasn't written the following code while creating Servlets:
public class GetPostServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { handleRequest(req,res); } public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { handleRequest(req,res); } /* Handle GET and POST */ public void handleRequest(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { .... } }
This could be done a lot easier with the new annotations:
@Servlet public class GetPostServlet { @GET @POST public void handleRequest(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { .... } }
So, nothing wrong here! Well, I asked if you could specify two of these annotation on one method during the launch of the specification on JavaOne 2008, but the spec-lead wasn't sure this could be done. So this is probably not the way its meant to be used.
And there is more, this also adds problems to the code, for example what if I coded this:
@Servlet public class GetPostServlet { @GET public void requestOne(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { .... } @GET public void requestTwo(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { .... } }
Now which method will be called? I have no idea! This will probably not even be documented, just like having two Servlets mapped on the same URL, you just can't predict what will happen, its up to the container.
These annotations are (supposed to be) added to help the developers, but there are more problems. The IDE doesn't know you are making a Servlet just because you add one annotation, so there is no support from the current generation of IDE's. When we had the interface or abstract class you would just override the methods you want, and you have code-completion. This is a huge advantage we'll loose when programming with these annotations!
It gets even worse if you look at the @ServletFilter. When you add this annotation to your code it turns the POJO into a Filter. But there is no check if you have implemented the doFilter() method. Also, it is much more error-prone, what if you accidently misspell "doFilter"?
The same thing also applies to the @ServletListenerContext, just look at this example:
@ServletContextListener public class MyListener { public void contextInitialized(ServletContextEvent sce) { .... } }
Again, nothing will check if you correctly spelled "contextInitialized" (which is a pretty hard word to type over and over without error-checking), you'll always have to manually double check. I'd rather type "implements ServletContextListener" instead of "@ServletContextListener" and then let my IDE write the implementing methods.
Okay, that is enough tough feedback. Next I would like to do something constructive and explain what direction I would like to see Servlet 3.0 go.
Proposal 1
The idea of having annotations for the url-mapping if very good. URLs are a good example of metadata, it doesn't say anything about the class or inner workings, but it does tell the container when to call it. This is something you would use an annotation for, also because its not mandatory to have mapping in the class, it would work perfectly without it. But as I said before, the naming is a bit off, I'd rather see this:
@ServletMapping(name="....", mapping={"...","..."}) //Use for both Servlets and Filters
The second thing is the annotations (@GET, @POST). I don't think this will help the user in any way, so just leave them out. I know the standard reply will be "Just don't use them if you don't like them...".
But there are already a lot of Java features we should just 'not use'. The problem is, people WILL use them, and it doesn't help them! In fact it will only add more choices/options for the programmers, making it all less clear if you incidentally have to work with Servlets. I personally haven't heard anybody complain about the interfaces/abstract classes before... And I can't seem to find any new advantage that it adds, only loosing the type-safety!
This was exactly the thing I was afraid of when they introduced annotations, people who start using them because they can, not because they have some metadata they want to have near the classes instead of in separate XML files.
Proposal 2
But *sigh* if they really want to use the annotations on the methods, then please add functionality to the Servlets. Currently they'll just serve as a (bad) alternative way of writing Servlets. But with a slight change you could actually add new features with these annotations, like this:
public class ExampleServlet { @ServletMethod(name="LoginServlet", mapping="/login", type={ServletType.GET, ServletType.POST}) public void handleLogin(...) { ... } //And: @FilterMethod(name="AuthorizationFilter", mapping="/login", type={ServletType.POST}) public void doAuthorization(...) { ... } }
This way you can have one class (POJO) with all the handling methods for a specific Use Case. More or less like the new Spring MVC Controllers. You'll still have the same functionality as the proposed JSR-315 annotations, but now you can group Servlet methods in one class! You still have the drawbacks I mentioned before, regarding the type-safety, but by using these annotations you actually gain some functionality and freedom.
Conclusion
My preference would still be not using annotations at all for GET/POST methods, but I've read the Java EE 6 specification is promoting the use of annotations like this and the JSR-315 writers have 'no choice' (bad excuse). The comments I made in this article have been send to the JSR-group, but I haven't got a response yet.
Also I've been unable to reach members for a reaction and/or explanation and/or clarification. Recently the Java EE 6 specification went on public review, and it contains references to this Servlet 3.0 specification, so it will become part of Java EE 6. This must mean they are working actively, maybe even franticly, to finish it on time. But I plead them to take the time to reconsider their choices about the annotations.
发表评论
-
apache 2.2.13
2009-08-10 13:41 2044Changes with Apache 2.2.13 * ... -
May 2009 Web Server Survey
2009-06-02 14:30 1054In the May 2009 survey we recei ... -
俄罗斯农民乘法
2009-02-10 18:29 3014规则:什么是俄罗斯农民 乘法?我要怎么使用它? ... -
Google搜索消耗的能量相当于烧一壶茶
2009-01-13 22:11 992两条Google 搜索真的能产 ... -
人保部:男女退休年龄或推至65岁
2008-11-06 14:03 937据《羊城晚报》报道 “相关部门正在酝酿条件成熟时延长法定退休年 ... -
王牌军排名
2008-10-28 08:59 1064第1名.王牌铁军--43军 43军在中国人民解放军中资历老 ... -
迪拜负债476亿美元超过GDP 阿拉伯财富神话破灭
2008-10-17 16:40 1691很长时间以来,迪拜债 ... -
红杉资本给CEO们的信
2008-10-16 14:48 945现在的形势非常严 ... -
AdSense 推介计划即将暂停
2008-07-02 16:52 950from http://adsense.googlechina ... -
7家顶级GPS软件企业大揭秘(ZZ)
2008-05-09 13:18 1748在揭秘前,首先给这国内顶级6家GPS企业分别冠名,之后在逐一阐 ... -
IBM架设second life私有土地(ZZ)
2008-04-11 19:05 1455SECOND LIFE,4月2号(路透社)——IBM声称,本周 ... -
4大技巧教你成为沟通中的说话高手(ZZ)
2008-04-07 15:59 1500有个故事讲,在酒足饭 ... -
贾鹏雷:请江南春停止撒谎(ZZ)
2008-04-02 11:30 1086上周老贾写了中心思想 ... -
我在深圳,每月收入850元,怎么也花不完,晒一晒我是怎么开销和投资的(zz)
2008-03-24 13:27 2369既然大家都在晒收入, ... -
51、校内、占座、海内、蚂蚁,中国sns谁能笑在最后?(ZZ)
2008-03-18 09:40 113151的用户基数据称已经过亿了,它的高明之处在于,为生活情趣匮乏 ... -
牛根生刁难马云俞敏洪:再创业你们谁会行?(ZZ)
2008-03-17 11:14 1303牛根生在做考官,他要 ... -
牛根生VS史玉柱:举重若轻俩巨人 千金散尽还复来(zz)
2008-03-04 13:41 1421篮子与蛋的关系 1997年 ...
相关推荐
赠送jar包:undertow-websockets-jsr-2.1.7.Final.jar; 赠送原API文档:undertow-websockets-jsr-2.1.7.Final-javadoc.jar; 赠送源代码:undertow-websockets-jsr-2.1.7.Final-sources.jar; 赠送Maven依赖信息...
赠送jar包:undertow-websockets-jsr-2.1.7.Final.jar; 赠送原API文档:undertow-websockets-jsr-2.1.7.Final-javadoc.jar; 赠送源代码:undertow-websockets-jsr-2.1.7.Final-sources.jar; 赠送Maven依赖信息...
JSR-315 专家组发布了规范的最终草案!glashfish v3 提供了全面支持,tomcat 7.0 jboss6.0 目前还在内测中;
JSR-168是适合于portlet开发人员的Java API集合。设计符合规范的JSR-168 portlet的原因有很多。可移植性就一个显而易见的好处。根据规范编写的代码更容易在门户服务器之间移动。多数基于Java的门户服务器都支持JSR-...
This document is the proposed final draft version of the JSR-133 specification, the Java Memory Model (JMM) and Thread Specification. This specification is intended to be part of the JSR-176 umbrella ...
java.lang.ClassNotFoundException: javax.measure.converter.ConversionException所需的jar
赠送jar包:undertow-websockets-jsr-2.2.14.Final.jar; 赠送原API文档:undertow-websockets-jsr-2.2.14.Final-javadoc.jar; 赠送源代码:undertow-websockets-jsr-2.2.14.Final-sources.jar; 赠送Maven依赖信息...
赠送jar包:undertow-websockets-jsr-2.2.14.Final.jar; 赠送原API文档:undertow-websockets-jsr-2.2.14.Final-javadoc.jar; 赠送源代码:undertow-websockets-jsr-2.2.14.Final-sources.jar; 赠送Maven依赖信息...
JSR133-memory_model-1_0-pfd2-spec.pdf JSR133中文版.pdf j-jtp02244-Java.theory...The JSR-133 Cookbook.pdf jsr-133-faq.pdf JSR-133-Appr-The Java Memory Model.pdf 深入理解Java内存模型之系列篇 - CSDN博客.pdf
This document is the JSR-133 specification, the JavaTM Memory Model and Thread Specification (JMM), as developed by the JSR-133 expert group. This specification is part of the JSR-176 umbrella for the...
JSR-75-135-172_Supported List 主流手机对JSR 75 135 172的支持!
JSR-000317 Persistence Specification Final 2.0 Final Release
本文是JSR-133规范,即JavaTM内存模型与线程规范,由JSR-133专家组开发。本规范是JSR-176(定义了JavaTM平台 Tiger(5.0)发布版的主要特性)的一部分。本规范的标准内容将合并到JavaTM语言规范、JavaTM虚拟机规范...
Servlet 3.0规范JSR文档,英文文档.
分布式缓存在提升性能和可伸缩性时举足轻重,但Java目前还没有任何完整、标准的...JSR-107这些年有些声名狼藉,因为它是一个很老的规范,但到现在还没有完成,不过随着对缓存的需求越来越多,JSR-107最终是要问世的。
Java EE Security (JSR-375) Specification.zip
spring3零配置注解实现Bean定义(包括JSR-250、JSR-330)
本文是JSR-133规范,即JavaTM内存模型与线程规范,由JSR-133专家组开发。本规范是JSR-176(定义了JavaTM平台 Tiger(5.0)发布版的主要特性)的一部分。本规范的标准内容将合并到JavaTM语言规范、JavaTM虚拟机规范...
手机定位(JSR-179 官方文档).pdf
webservice中用到的jar,xfire-jsr181-api-1.0-M1.jar,xfire-jsr181-api-1.0-M1.jar