Comments on: How to do Everything Wrong with Servlets

By: misko

misko — Thu, 31 Mar 2011 15:56:23 +0000

@Rajiv,

Glad to hear from you and happy to offer my thoughts on making servlets more testable. I will start a dialog on email.

By: Rajiv Mordani

Rajiv Mordani — Wed, 30 Mar 2011 22:54:27 +0000

Hi Misko,
I am the Servlet spec lead and I will try to address some of the issues that you have listed above –

For initialization of resources like Database connection you can use CDI / Resource injection to inject the data source for example. Similarly you can use CDI to inject all kinds of managed beans into servlets. So that will take care of initialization issues you list above like Christian noted above.

Another issue that you list about constructor – In servlet 3.0 we added ways to add an “initialized” servlet during context initialization phase dynamically. It is restricted but there is a way to do it.

For the single instance of a Servlet in the VM – sessions are useful for storing state. There used to be a SingleThreadedModel which did basically what you are suggesting. We deprecated that because there are a lot of issues with that.

We can talk more to see what we can improve in 3.1 for “testability” if that’s the main issue you are trying to address or about any other issues. Let me know.

- Rajiv

By: Christian Gruber

Christian Gruber — Thu, 16 Apr 2009 01:40:40 +0000

One of the reasons I’ve been loving Tapestry5 is that I can build “misko-friendly” apps. My components and pages don’t have to inherit from anything (not even interfaces), pages, components and services are all injectable dependencies and declare their dependencies quite nicely, etc. I want a reference to another page? I inject it. I want a DAO? I inject it. It also does really nice things like byte-code manipulate the classes at load-time (for pages and gui components) so that I don’t have to write a lot of boiler plate and then test it – it’s taken care of and the boiler-plate code weaving is well tested, so it’s SEP (somebody else’s problem). This means that my gui component classes are almost entirely consisting of declarations of dependencies (@Inject private MyFoo myFoo;) declarations of properties with getters and setters taken care of for me if they’re default boiler plate javabean style (@Property private MyLoopContent currentContent;) and actual methods which do something.The above means that I only have to write tests to test that which is unique about the class – Tapestry 5 pages and components follow SRP (well, they can – they’re not forced to break SRP), are easy to read, all abide by consistent convention, etc.Anyway – small plug for T5, but even if you’re not using T5, it’s a great proof that what Misko’s talking about isn’t just fantasy – you really can have frameworks which let you do this, and you can hammer out existing frameworks to be more like this.

By: misko

misko — Wed, 15 Apr 2009 17:44:14 +0000

@Przemek,

You are right on the money. I should probably talk more about this in a separate blog, but your conclusion are valid. As far as benefits go, you will find that the code is (1) easier to test (2) modifying the code becomes easier since you con deliver new date directly to the class which needs it without having to pass it through the stack or resolve to Globals.

By: Przemek

Przemek — Tue, 14 Apr 2009 22:02:05 +0000

A lot of good advice regarding servlet-like frameworks. But I’m not sure, where most of the evil really lies – in API or in particular apps? A very interresting question for me is: how to design those APIs in a better way?But this was not my main reason to comment your article. I was particularly puzzled by the piece about data travelling through the stack – called procedural-style by you. What? Methods with parameters are not OO? I’m a big fan of objects for 9 years and I haven’t expected many more surprises on that field, I have to confess – the credit goes to you, Misko I spent a while trying to understand your point and finally I think now I got it But please correct me, if I don’t. I think you would design a webapp in a following way:when a request comes in, a web of request-scoped objects are created, with all necessary data taken from HTTP request.Then, a method of a root request object is called and all of real processing happens. Then, results are collected and transformed into HTTP response.I hope I guessed, what you’ve meant. If yes, this could be extrapolated with very interresting consequences for whole OO programming (at least, if you want pure OO). In particular, following rules would apply:use arguments only in constructors and factory methodswhen you need an argument in other method, turn it into method-object (AKA command pattern)use all data you have to build a graph of request objects, then call a single method on it, to let it do its workI’m sure, I’ve still omitted many other interresting consequences, but these already challenge many of mine habits (and popular beliefs).Therefore I start to be curious, what benefits can give me this style of programming, to justify the transition.If I got the point of “Java is OO, use it in that way” correctly, could you enumerate few of the benefits?Or, please, correct me, if I misunderstood you.

By: Sakuraba

Sakuraba — Thu, 09 Apr 2009 09:59:35 +0000

I agree with all of the statements, however is this a real issue? Most of us are using something like SpringMVC and dont touch Servlets at all.

By: Sarah Happy

Sarah Happy — Thu, 09 Apr 2009 00:39:33 +0000

Personally I use a ServletContextListener to create an application object, most of which is testable outside of the servlet container, and in the servlets I look up the application object in the context attributes, and pass the request and response down to it, making the servlets very simple wiring. The container provided request and response objects typically do not remain visible past the first call level either.

By: Shantanu Kumar

Shantanu Kumar — Wed, 08 Apr 2009 21:24:27 +0000

Servlets are certainly bad candidates for testing. I generally test them by passing test config through constructor, and launching them through an embedded Jetty container.Today I attended a talk by Neal Ford at JAX 09 at Bangalore, where he showed how we can use MockRunner to test classes that depend on infrastructure.MockRunner URL: http://mockrunner.sourceforge.net/Cool stuff!