tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: question about inter-webapp communication
Date Wed, 19 Oct 2011 19:33:52 GMT
Hash: SHA1


On 10/19/2011 1:56 PM, Garey Mills wrote:
> I want to use /webapp_one as an authentication front end for 
> /webapp_two, since /webapp_two is a large, complex web app and I
> want to do authentication filtering on patterns in the query
> string. My scheme is to analyze the request URL in the body of
> /webapp_one. If it should be protected, rewrite it by adding a flag
> into the URI, so that it can be caught by my authentication filter
> in the web.xml, and redirect it back to /webapp_one. If it does not
> have to be protected, or if it has been protected by my filter,
> wrap the request so that it looks like a request to /webapp_two,
> get a   RequestDispatcher from /webapp_two's context, and 'include'
> the output from /webapp_two in the response from /webapp_one.

That sounds absolutely insane. Can you explain why all this is necessary?

> The problem is that this is not working, and I believe that the 
> problem is in how I am getting /webapp_two's ServletContext, or in
> how I am referring to the servlet in /webapp_two's context, since I
> am not seeing any activity from /webapp_two in the logs.
> Here are the particulars:
> * I have 'crossContext=true' set in /webapp_one's context * Here is
> my request wrapper
> public class MyRequestWrapper extends HttpServletRequestWrapper { 
> String queryString = null; String uri = null; String contextPath =
> null; String pathTranslated = null;
> public GSRequestWrapper(HttpServletRequest req) { super(req); }
> public void setRequestURI(String newUri) { uri = newUri; } public
> String getRequestURI() { return uri; }

Since this is a specialized filter, maybe this isn't a big deal, but
you probably want to call super.getRequestURI() when none has been
set. Similarly with the other methods.

> public StringBuffer getRequestURL() {
> StringBuffer sb = new StringBuffer(); sb.append(uri + "?" +
> queryString);


> * Here is the code I use to create the wrapper
> MyRequestWrapper myReq = new MyRequestWrapper(req);
> myReq.setRequestURI(req.getRequestURI().replaceFirst("webapp_one", 
> "webapp_two"));
> myReq.setContextPath(req.getContextPath().replaceFirst("webapp_one",
> myReq.setPathTranslated(req.getPathTranslated().replaceFirst("webapp_one",
> ServletContext twoContext = sc.getContext("/webapp_two");

What do you do with twoContext after this point?

> * In /webapp_two, the url-pattern intercepted is '/*', so this is
> how I am trying to create the RequestDispatcher
> RequestDispatcher rd = twoContext.getRequestDispatcher("/");

You want to use getRequestDispatcher() with a real path: I would
recommend using the path that you are really trying to reach -- either
the modified one (except that you don't want to have the context-path
in the path because the RequestDispatcher will already know it's bound
to a certain ServletContext) instead of just asking for "/".

Also, I'm not entirely sure what happens to the HttpServletRequest
when you get a request dispatcher using a path and then forward an
existing request. I suspect that the filters and servlets on the other
end see the path you used to fetch the dispatcher, otherwise you could
never forward or include content that didn't match the original URI.

> Trying all this out, I see that the RequestDispatcher I am
> creating is not null, but I am not seeing any activity in
> /webapp_two, and the page returned is blank.

Any error messages in the logs?

> Am I making a mistake in referring to the context of /webapp_two,
> or in how I am creating my request wrapper, or in how I am
> referring to the servlet in /webapp_two?

I think things in general are okay (notwithstanding the very strange
requirements, here) -- there must be some small detail that is

I would try using the desired path when you fetch a RequestDispatcher
instead of just using "/".

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message