Hi Daniel,
I am not sure if this is release but recently (i cannot remember
exactly how recently) i modified the Jersey JSPTemplateProvider to
have injected explicit ThreadLocal wrappers for HttpServletRequest/
Response:
public class JSPTemplateProcessor implements TemplateProcessor {
private @Context HttpContext hc;
private @Context ServletContext servletContext;
private @Context ThreadLocal<HttpServletRequest> requestInvoker;
private @Context ThreadLocal<HttpServletResponse> responseInvoker;
private final String basePath;
and the write method is as follows:
public void writeTo(String resolvedPath, Object model,
OutputStream out) throws IOException {
// Commit the status and headers to the HttpServletResponse
out.flush();
RequestDispatcher d =
servletContext.getRequestDispatcher(resolvedPath);
if (d == null) {
throw new ContainerException("No request dispatcher for:
" + resolvedPath);
}
d = new RequestDispatcherWrapper(d, basePath, hc, model);
try {
d.forward(requestInvoker.get(), responseInvoker.get());
} catch (Exception e) {
throw new ContainerException(e);
}
}
When i was developing the JSP integration to took a couple of head-
scratching moments to realize that the forward method does like to be
passed thread local proxies of HttpServletRequest/Response.
Other than that, i would need to look at your example to help you out
more,
Paul.
On Aug 1, 2009, at 10:03 PM, Daniel Larsson wrote:
> Hi,
>
> I'm trying to write a custom JSP template provider, and I noticed
> the standard JSP template provider gets the request in the
> constructor, and using the injected HttpServletRequest doesn't work
> very well (in the writeTo method, when dispatching the request to
> the JSP processor). Using the injected request object, it seems to
> loop endlessly (?). I haven't had much time yet to delve into what
> happens, but thought I'd make a quick post here first. I do have a
> small example project though.