Skip to main content

Rebuttal of Greg Wilkin's Blog about Servlet 3.0 PR

Posted by mode on December 15, 2008 at 11:34 PM PST

Someone just pointed me to Greg Wilkin's latest blog entry. I tried posting my response in his comments however it was tagged as spam and not displayed. So I am making the comments available her.

I am REALLY surprised at this blog. Let me try to answer some of these questions in the public forum.

"This public draft of the servlet-3.0 represents a thought experiment in API design unhindered by the complexities of implementation, trial usage or community feedback."

An implementation of this is available in GlassFish in the trunk.

"As a member of this Expert Group, I've been as guilty as the other members by looking at uncompiled/untested APIs and believing them to solve the issues at hand, only to later discover that these APIs prove to be unworkable when implemented and/or used."

The APIs are implementable. Take a look at the GlassFish trunk.

"Requests for test implementations have been denied"

I never saw a request from you. In fact YOU offered to implement some of the features in Jetty and showcase the technology.

"Any feedback received on the list have been kept private and not shared even with the EG, despite several requests. "

Please check your email carefully. All the mails that I have received I have forwarded to the EG. Also I never saw a request from you to share feedback that is received.

"EG members and community feedback raised concerns about the security and ordering aspects of the automatic deployment possible with the Annotations and Pluggability feature (see below). The response was not the "How can we address these concerns" discussion that I was expecting. Instead the response was more along the lines of Obe-wan Kenobi saying "these are not the concerns you are looking for. Move along!" "

Looking into the security concerns we introduced the enabled, flag that can enable and disable servlets. Also like some of the other EG members pointed out that if a user does not know how a framework works he shouldn't be using it in the first place. Or if a framework is authored badly then it shouldn't be used in the first place. The problem is that you never get PAST what YOU suggest as a solution and YOU always think of solutions keeping that in mind.

"Alternately, some unsubstantiated requirements (eg. wrapped asynchronous requests) have been included at a late stage without any use-cases or user demand, which have introduced whole new dimensions of complexity so that discussions have been ratholed for months chasing marginal edge cases."

I don't believe that you say this. Late in the game and we rat holed more on the use case that you had as opposed to the wrapped use case. In fact if you remember, members of the EG were opposed to the re-dispatch semantics that we had. So please don't provide an incorrect picture to the people reading your blogs.

"Accidental Deployment"

We have had no such experience with the use of annotations in JAX-WS, EJB, and other places in the Java EE platform. Also there are ways to turn off the accidental deployment - use the enable flag to enable / disable servlets. Are you even paying attention to the solutions that the EG is working on providing?

"Slow Deployment"

Please provide numbers of how deployment is slowed down. If you just "feel" that deployment will slow down significantly it isn't good enough. In the Java EE 5 days we did the analysis of scanning of annotations and the result was that we didn't see any significant slowing down. I can share the numbers in the EG if you are REALLY interested in the problem.


Yes this is a problem for the fragments. However there is a solution to use the web.xml to do the ordering. Also your blog seems to be getting confusing. On one hand you criticize the feature of pluggability with accidental deployment, slowing down deployment with scanning, and on the other hand you want to use the feature and not define everything in the web.xml? Make up your mind what you want? Use the feature or just keep using the web.xml as before.

As for the async rebuttal and everything else about the Async proposal just a few quotes from emails to the EG.

Quoting you -

"Excellent! This proposal is definitely better than suspend/resume!"

Quoting another EG member -

"Greg, I think you're being too aggressive. I do realize you care about the subject.

I think Rajiv's design is now quite fine, so using the "flood until he
agrees to my stuff" tactic is unfair. From what I've seen many have
stated a preference for his design (I have a coworker who's also not
very comfortable with your design). And the adapted code example looks
good to me too."

You have just taken this tactic outside the EG now because the EG members were starting to point this out to you.

I am really starting to agree with Bill Burke about the statement he made in his blog.


Maxim MoldenHauer, the IBM representative on the EG has also blogged on the issue.

Related Topics >>


IMHO it's a very poor show to engage in mudslinging and single-sentence quotes from some otherwise unaccessible list.. Either open the EG deliberations and mailinglists so that everyone can see for himelf, OR keep the quoting and mudslinging for the kindergarten :-( and stick to technical arguments. I, for one, am not interested in this pissing match. We have suffered long enough broken and pathetic "implementable" JCP specs (EJB 2 still hurts A LOT) to bear with BS (this is not to be taken as a comment on the merit of this specific JSR, only as a comment on the argument that if it is implemented, then that somehow implies that it's good or usable) Namecalling, labelling, you-did-that and you-too arguments belong to 8-year olds, not to spec leads, *regardless* of what the other person is doing.

Rajiv, not at all. I raised my concerns until you said you did not want to hear about them anymore, at which point I stopped raising them in the EG. The spec is now going to Public Review, so I'm raising my concerns again as part of that. I don't see why you think that ignoring these concerns would make them go away. I'm not flip flopping. My concerns about auto deployment are not 100% about security. As I say in the quote you use: Security and trust are just some of the reasons that you may want to change the default configuration baked into a jar! I stand by what I said!

mmolden: I know in hind sight I should not have put some of the messages from the EG. However what Greg has posted is really an unfair characterization of the work that the EG has done, and you know that as well as I do, specially when we had him in the thick of the discussions. Quoting him on another instance which is indeed public as a comment on my previous blog - "My argument is not so much about security or trust. These are just some of the reasons that you may want to change the reasonable default configurations baked into your jars. As it appears that I have not made my case on this issue, I've made my last word in my blog, and will move onto other features. Jetty however will support both auto-discovered and fully selective and parameterized modular configuration via annotations, fragments and listeners.". However the way he presented it in the current blog seems otherwise. He seems to be flip flopping. He is trying to just create a storm in the blogosphere about the JSR and the spec. Anyways enough said about this in the public forum.

If you want to see a safe, controlled, and yet easy way to use annotations for marking exposed classes, take a look at Spring's component-scan facility. It only scans the classpath for the specified packages (and you can add filters for classes, for example by regex matching). This way, you don't have to map classes in the XML file, but have a clear way to find which classes are exposed as action controllers. And you don't have the risk of exposing something you don't even know that exists (again, the blindly-ease-oriented-web-framework debug/backdoor thing).

I completely agree with Greg on the point about restricting which jars to scan. One of the recommended practices for developing web modules is to convert deployment by annotation to deployment by web.xml when you get to production. Annotations provide an ease of development, but how much ease do you get when it takes a substantial amount of time to redeploy the application each time you want to test something new. I do not agree with the all or nothing approach and the enable/disable flag for servlets is insufficient in my opinion. Also, I do think it is a bit unfair to take quotes from the private EG discussions and make them public. Doing so may make people hold their tongues in the future for fear of having things made public.

ronaldtm: We'll definitely use that disable flag ! That deployment by annotation is so crappy. I already deploy by API using Spring (1 servlet). I just don't deploy servlets. I deploy controllers.

gregwilkins: "but it's implemented in Glassfish" proves that an API is correctly (or cleanly, efficiently) implementable" Your claim was that the APIs are not implementable or that there was no implementation done and not what you are saying here.

ronaldtm: If that is something you want in your app you can continue to do so and not enable scanning and use the traditional web.xml approach to define everything that you need.

"Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/ant-1.6.5.jar End scan 592ms Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/core-3.1.1.jar End scan 2098ms Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/jsp-api-2.1-glassfish-9.1.1.B51.p0.jar End scan 111ms Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/jsp-2.1-glassfish-9.1.1.B51.p0.jar End scan 626ms Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/jsp-2.1-jetty-7.0-SNAPSHOT.jar End scan 3ms" The spec does not require scanning of classes in your classpath. It talks about WEB-INF/lib. If this is a feature that Jetty wants to provide then it is the problem of Jetty. As for the numbers we have I will post that soon.

Rajiv: not that I know enough about the issues to know for sure, but I do not think that "but it's implemented in Glassfish" proves that an API is correctly (or cleanly, efficiently) implementable. The original claim may be vague too, but rebuttal isn't really rebutting much either. There are unfortunately cases of JSR specs that have nominally been implemented -- as in, all methods of all interfaces have been stubbed out -- but where implementation is broken (specific case I am most familiar of is Stax, jsr-173, but there are others). So: I am just hoping that things do not get rushed through -- the spec will stay around for years to come, and getting new revisions out seems to be very hard to do.

Slow deployment: using ASM to scan for annotations takes between 10ms and 2000ms per jar. Many webapps have 10s of jars (I've seen upto 190!), and many web servers have many wars, so 10s of seconds is added to startup. Just to scan the glassfish JSP implementation takes 3367ms: Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/ant-1.6.5.jar End scan 592ms Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/core-3.1.1.jar End scan 2098ms Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/jsp-api-2.1-glassfish-9.1.1.B51.p0.jar End scan 111ms Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/jsp-2.1-glassfish-9.1.1.B51.p0.jar End scan 626ms Start scan of file:/home/janb/src/jetty-7/lib/jsp-2.1/jsp-2.1-jetty-7.0-SNAPSHOT.jar End scan 3ms So this is not the worst thing in the world, but it is slow enough that almost every container is going to have a list of jars NOT to scan. I'm suggesting is we look for a way to make that standard and configurable.

The deployment by annotations feature IS crap. You are blindly making developing servlets 'easier', and introducing many issues (security, performance, in-flexibility) while doing it. As if people still used servlets as controllers these days! Configuration via API and asynchronous requests, all good and nice. Annotations and fragments? First, I don't want to go back to 'Model2', I don't code Servlets anymore, thanks. Second, I don't want any ease-oriented-web-framework-a-la-Seam to start exposing backdoor (aka debug) servlets just because any of its jars ended up in my classpath. I WANT to have to register them somewhere, and WANT others to also do so, so I'll know where to even start when debugging someone else's code. This trend of trying to turn Java EE from infrastructure into an application framework (first EJB3, then the spec-lized Seam aka WebBeans, now this Servlet3 thing) WILL kill the platform.

Rajiv, I certainly admit that I have not always well argued my case and may well have flooded posts in the past. But that is not a recent quote and regardless you put the spec out for public review and I am simply stating my thoughts - which you well know. I do believe there are some significant improvements on the suspend/resume proposal and my blog goes to lengths to point those out and show how an almost alternative proposal could look without the complexities of wrappers and forwards. It's great that an implementation is now available in glassfish trunk. But it should have been made available to the EG before release for PR not after. It is really disingenuous of you to both accuse me of flooding the EG and then to say that I should have raised my concerns with the EG. I raised my concerns until you said that you wanted to move onto other things, at which point I stopped raising them. Now you are surprised that simply moving on has not resolved these concerns and appear to want me not to state them in the public review?