Comments on: Is it time for a next-generation Servlet API? http://closingbraces.net/2007/03/20/newservletapi/ After-hours notes and opinions on Java and system development Sat, 13 Feb 2010 02:18:24 +0000 http://wordpress.com/ hourly 1 By: closingbraces http://closingbraces.net/2007/03/20/newservletapi/#comment-67 closingbraces Thu, 22 Mar 2007 12:10:13 +0000 http://closingbraces.net/2007/03/20/newservletapi/#comment-67 Re unit-testing: Fair enough. Guess it depends what framework(s) you're using, whether any Servlet API objects are still involved, the nature of the testing, whether you're also writing "bare" filters/listeners etc. I'd imagine it's also an issue if you're developing a framework or a container rather than an app. Maybe the whole Servlet API is fading into the background, and doesn't actually matter to anyone but framework and container writers. I'm still inclined to think it'd be generally useful to be able to construct and configure instances of Servlet API classes. What has your experience been? Are you able to test everything without any Servlet API stuff, or do you also need e.g. mocks, or framework-provided test classes, or other tools like Cactus etc? Is this now a "dead" issue? Any view on this from framework/container developers? How is everyone finding JSF in this regard? Re unit-testing: Fair enough. Guess it depends what framework(s) you’re using, whether any Servlet API objects are still involved, the nature of the testing, whether you’re also writing “bare” filters/listeners etc. I’d imagine it’s also an issue if you’re developing a framework or a container rather than an app.

Maybe the whole Servlet API is fading into the background, and doesn’t actually matter to anyone but framework and container writers. I’m still inclined to think it’d be generally useful to be able to construct and configure instances of Servlet API classes.

What has your experience been? Are you able to test everything without any Servlet API stuff, or do you also need e.g. mocks, or framework-provided test classes, or other tools like Cactus etc? Is this now a “dead” issue? Any view on this from framework/container developers? How is everyone finding JSF in this regard?

]]> By: BlogReader http://closingbraces.net/2007/03/20/newservletapi/#comment-66 BlogReader Thu, 22 Mar 2007 04:27:57 +0000 http://closingbraces.net/2007/03/20/newservletapi/#comment-66 <i>Unit-testing of code that uses the Servlet API is far too difficult. The application code depends on objects that are “magically” constructed by the container</i> Is that a problem with the servlet API or just how the app was done? Using a framework like Spring or Tapestry you're working a layer above the servlet api and you don't have to be concerned with things like this. Thanks for the links to the new stuff in java 6, going to check them out. Unit-testing of code that uses the Servlet API is far too difficult. The application code depends on objects that are “magically” constructed by the container

Is that a problem with the servlet API or just how the app was done? Using a framework like Spring or Tapestry you’re working a layer above the servlet api and you don’t have to be concerned with things like this.

Thanks for the links to the new stuff in java 6, going to check them out.

]]> By: closingbraces http://closingbraces.net/2007/03/20/newservletapi/#comment-64 closingbraces Wed, 21 Mar 2007 23:17:21 +0000 http://closingbraces.net/2007/03/20/newservletapi/#comment-64 Thanks Patrick, that was a really interesting comment. I was intrigued to read your comment about it being unclear how to write non-Http Servlets - I had been wondering if I was the only one that saw any problems there. I hadn't really thought about other types of service container or a "Contained Agent Execution Engine", but that might be a useful viewpoint. Possibly my ideal would be a "plain java" way of defining and using a "service" (e.g. as a Java SE API using simple POJOs), without necessarily needing any kind of substantial container, but that could then also be put inside your "Contained Agent Execution Engine" when you need to provide clustering, management, load-balancing etc. Maybe there are three separate things here: the logical nature of a "service" (as general as possible), adapters for the various protocols through which you talk to such services, and the container that hosts the services and adapters (of which you might have a very thin and trivial one for embedded in-process use, and more sophisticated ones for large-scale stand-alone hosting or particular situations). Or is any/all of this already present in APIs or JSRs I'm not aware of? Surely this has already been done somewhere? As for how it happends, I really don't have any good answers at the moment. I'd guess that doing it properly would involve a period of gestation and discussion and a prototype solution, then when ready offer it as a specific product and/or raise a JSR. Care needed to avoid too much duplication or overlap with other APIs. It would probably also help if it could be used in a servlet container and interoperate with the Servlet API (probably fairly easy via a filter or servlet, similar to how all the various web-app frameworks do it). Not something I have time for at the moment, but maybe one day... Regardless of this, the existing Servlet API will continue anyway, so I'd still hope that at some point it would be radically modernized and simplified. Mike Thanks Patrick, that was a really interesting comment. I was intrigued to read your comment about it being unclear how to write non-Http Servlets – I had been wondering if I was the only one that saw any problems there.

I hadn’t really thought about other types of service container or a “Contained Agent Execution Engine”, but that might be a useful viewpoint. Possibly my ideal would be a “plain java” way of defining and using a “service” (e.g. as a Java SE API using simple POJOs), without necessarily needing any kind of substantial container, but that could then also be put inside your “Contained Agent Execution Engine” when you need to provide clustering, management, load-balancing etc.

Maybe there are three separate things here: the logical nature of a “service” (as general as possible), adapters for the various protocols through which you talk to such services, and the container that hosts the services and adapters (of which you might have a very thin and trivial one for embedded in-process use, and more sophisticated ones for large-scale stand-alone hosting or particular situations). Or is any/all of this already present in APIs or JSRs I’m not aware of? Surely this has already been done somewhere?

As for how it happends, I really don’t have any good answers at the moment. I’d guess that doing it properly would involve a period of gestation and discussion and a prototype solution, then when ready offer it as a specific product and/or raise a JSR. Care needed to avoid too much duplication or overlap with other APIs. It would probably also help if it could be used in a servlet container and interoperate with the Servlet API (probably fairly easy via a filter or servlet, similar to how all the various web-app frameworks do it). Not something I have time for at the moment, but maybe one day…

Regardless of this, the existing Servlet API will continue anyway, so I’d still hope that at some point it would be radically modernized and simplified.

Mike

]]> By: Patrick Wright http://closingbraces.net/2007/03/20/newservletapi/#comment-63 Patrick Wright Wed, 21 Mar 2007 20:42:53 +0000 http://closingbraces.net/2007/03/20/newservletapi/#comment-63 I like your notes/analysis, it feels (without having all the details presented) right. Regarding the idea that maybe we need a generalized container, I think this makes sense if for no other reason than that to be able to support HTTP-based services in the last few years, a whole layer of infrastructure has been developed which has nothing to do with HTTP in particular, and at the same time I think it's unclear to most of us how to easily and correctly implement something that is a Servlet that is not an HttpServlet that runs in one of those containers. I think the dynamic app loading (and isolation), clustering, request processing and dispatch would serve us well for a number of purposes--take Nailgun as one example, or Jini service containers--there are lots of interesting possibilities. On the other hand, I'm not sure how exactly this happens. I'm sure that an improved Servlet NG could come out of the JCP, but not sure that a Contained Agent Execution Engine--something related, but much more general--can come out of committee. Interesting to think about, and to remember we don't need to tie ourselves to solutions developed under other circumstances and for other problems many years ago. Cheers, Patrick I like your notes/analysis, it feels (without having all the details presented) right. Regarding the idea that maybe we need a generalized container, I think this makes sense if for no other reason than that to be able to support HTTP-based services in the last few years, a whole layer of infrastructure has been developed which has nothing to do with HTTP in particular, and at the same time I think it’s unclear to most of us how to easily and correctly implement something that is a Servlet that is not an HttpServlet that runs in one of those containers. I think the dynamic app loading (and isolation), clustering, request processing and dispatch would serve us well for a number of purposes–take Nailgun as one example, or Jini service containers–there are lots of interesting possibilities. On the other hand, I’m not sure how exactly this happens. I’m sure that an improved Servlet NG could come out of the JCP, but not sure that a Contained Agent Execution Engine–something related, but much more general–can come out of committee. Interesting to think about, and to remember we don’t need to tie ourselves to solutions developed under other circumstances and for other problems many years ago. Cheers, Patrick

]]>