Mike Kaufman

Updated Feb 2018: OpenBrace Limited has closed down, and its ObMimic product is no longer supported.

The full 1.0 release of OpenBrace Limited's ObMimic library for plain-Java out-of-container testing of Servlet API code is now available from the OpenBrace website.

ObMimic is a library of plain-Java implementations of the Servlet API’s interfaces and abstract classes. It provides a comprehensive set of ready-made and fully-configurable test-doubles for accurately simulating the Servlet API in out-of-container testing of any code that uses the Servlet API (or frameworks or libraries that run on top of the Servlet API, such as JSF).

If you want to test code that uses the Servlet API but find that detailed testing of such code is harder, more restrictive or slower than for normal Java code - or even if you just want the simplest way for your tests to obtain fully-functional instances of Servlet API interfaces - ObMimic may be what you're looking for.

For full details, features, "Getting Started" and "How To" guides, Javadoc and other documentation see the OpenBrace website.

The "Community" edition of ObMimic is available at no cost for both personal and commercial use from the OpenBrace website's Download page. A free but time-limited evaluation licence-key for the "Professional" edition is also available.

Full licence-keys for the "Professional" edition and the "Enterprise" edition (which includes full source code) can be ordered from the OpenBrace website's Buy ObMimic Licences page.

Another way, if the form uses "POST", would be to use the request's input stream to read the posted data directly from the request's body content, and then parse it into parameter names and values yourself.

You'd need to avoid making any calls to "getParameter" beforehand, as the first such call causes the input stream to be consumed (it retrieves and parses the posted data, and merges it with any request parameters found in the query string - which leaves the input stream already-consumed and at end-of-file).

I can't think off-hand of many situations where this would be worthwhile, but if the request has both posted data and a normal query string this approach does let you access the two sets of parameters entirely separately from each other (even if they both have parameters with the same name) - i.e. retrieve the posted data from the input stream, then use getParameter to retrieve the query string parameters on their own. You could also use this regardless of the request's content type, whereas getParameter only reads posted data if its content type is specifically that expected for posted form data.

At any rate, reading the posted data directly from the input stream is another way to do it, and maybe (just maybe) that's what the interviewer was after.

Possibly more relevant: http://blogs.sun.com/foo/entry/i_want_to_see_my

Apparently the JSP-processing servlet defined in the Glassfish domain's config/default-web.xml supports an optional <init-param> named keep-generated that you need to set to "true". The source code should then get written into the domain's /generated/jsp directory structure (under the relevant app's subdirectory).

The default-web.xml has comments explaining all the JSP-processing servlet's init-param options, including a saveBytecode option for keeping the resulting class files as well (though it says that depends on JDK 6).

The blog article referenced above says that you also need to specify precompilation of the JSPs when deploying the app, but I'd be tempted to try it "normally" first (might be something the author needed but doesn't apply to your situation; or might depend on which version of Glassfish; or which of the various deployment mechanisms you use etc).

Shouldn't the class files be in WEB-INF/classes, rather than directly in root of WEB-INF?

i.e. I think it should be [tomcat]/webapps/Listener/WEB-INF/classes/com/example/MyServletContextListener.class

It's actually a more interesting question than it seems...

The javadoc for Servlet 2.4 onwards is indeed as quoted above. However, in Servlet 2.3 it was different - it said that this method is invoked to indicate that the session "was" invalidated. That sounds far more like it's called after the invalidation.

In practice there probably isn't much you could safely use this for if it's not called until the HttpSession has already been invalidated. So the "was" might have been deliberate, or it might have been a small mistake in the wording of the javadoc, or it might not have been thought about at all and was just that way by accident. I wouldn't be suprised if the actual behaviour differed between servlet containers (whether by mistake or by deliberately choice). In Servlet 2.4 this was "clarified" (fixed? changed?) to clearly state that the method is called before the invalidation.

So I think the answer is:
- For Servlet 2.4 and above it is called before the invalidation.
- In 2.3 (where it was first introduced) it's probably supposed to be after the invalidation, but you maybe can't particularly rely on it actually being done that way.

The getServletContext(String) method is on ServletContext itself.

That is, from the ServletContext of the servlet or filter that is going to do the dispatching (as given by its ServletConfig/FilterConfig), and subject to security restrictions, you can retrieve other ServletContexts and then use their own getRequestDispatcher to obtain request dispatchers for their resources as usual.

The string argument to ServletContext.getServletContext is not a "context name", but is a path relative to the container's document root. You get back the ServletContext of whichever web-app that path would invoke.

See the Javadoc of ServletContext for full explanation and details.

As per Ben Souther's reply, you need ServletContext.getServletContext(String).

But be aware that it can return null. The javadoc says the container can restrict which contexts can be accessed this way, and returns null if you're not permitted to do cross-context calls to the specified context (even assuming it exists). So you might, for example, need to set a container-specific configuration option to explicitly permit such cross-context dispatching, either in general or to the particular context involved.

There are other issues with cross-context dispatching that can be tricky due to being somewhat under-specified, and which you might need to watch out for e.g. how session-handling works across multiple contexts. I believe these issues caused a fair bit of grief for "portlets" in their time, though each new version of the spec tends to clear things up a bit.

One thing that occurs to me is that the code is calling "flush" (or "close") on the underlying output stream itself, rather than on the response.

I don't think this is necessarily going to be recognized by the response as having "committed" it. Depending on how the implementation works internally, there's no guarantee that the response will keep track of everything you do directly to its internal elements. It might only know that the output has been flushed when it has done it itself.

I'd expect you to get the expected exception if the call is changed from "os.flush()" to "response.flushBuffer()".

You could also try using some calls to "response.isCommitted" to see whether/where the response actually becomes committed.

Mike

Hi, I'm the guy that wrote the lengthy article that Christophe's "see here" points to. The exact difference between the two methods is still no clearer to me, it still looks very vague. You're not the only one puzzled by it!

I suspect whoever wrote the Javadoc might have had some very specific issue or situation in mind (possibly some gnarly detail of the W3C specs and how URLs are interpreted), but we're left just trying to guess what it might have been, and we're probably all wrong.

But unless you're trying to implement the API, I think all you need to worry about is making sure that you use the right method for each URL based on its purpose. I'd regard the result of these methods as opaque strings, whose precise details aren't entirely pinned down by the Javadoc but instead depend on mysterious, unspecified internals within each servlet container - and may be different for the two methods.

As for why these methods are on the response rather than the request, I think that's reasonable because they are adjusting values that are being put into the response. And whilst the session ID might have come in as part of the request, it could also be a new session created during the processing of this request and response. Also, any returning of the session ID to the client (to continue the session) mus t be part of the response, so the response does need to "know" the session ID anyway.

I think there is a more general issue that the request and response are inter-dependent in somewhat subtle and awkward ways - with response methods that can depend on details of the request; session-handling methods in the request that can depend on whether the response is committed yet; and session-handling methods in the request but with the response needing to use the session ID as well (e.g. for encodeURL). At the same time there's no explicit relationship between request and response instances, just a general notion that one request and one response are being processed together (e.g. in the HttpServletResponse Javadoc, what instance does "THE request" actually refer to?). So the split between request and response seems far from perfect, and I dare say it might be done rather differently if starting from scratch, but for now it's what we're stuck with.

[ March 17, 2008: Message edited by: Mike Kaufman ]
[ March 17, 2008: Message edited by: Mike Kaufman ]