Forwarding Issue to Servlets

[Steve]

Hey Guys,

I've seen in another post:

http://groups.google.com/group/google-guice/browse_thread/thread/f06a21d8edac640a/a2015de5b2c58999?lnk=gst&q=forward+#a2015de5b2c58999

that there is an issue forwarding with JSPs. I am having an issue
forwarding from one servlet to another.

I have migrated my servlet to Guice like so:

serve("/download").with(DownloadServlet.class);

from web.xml:

<servlet-mapping>
<servlet-name>DownloadServlet</servlet-name>
<url-pattern>/download/*</url-pattern>
</servlet-mapping>

But when I forward (using getRequestDispatcher) to this servlet in
Guice I'm getting a 404, it works fine when in web.xml.

I had the servlet forwarding issue outlined in the discussion above,
and used tchan's "hack" and it solved the jsp forwarding issue, but
I'm stumped on this. Any ideas? Is the "/download/*" pattern in the
web.xml significant in it's difference from the way it is served with
Guice?

Thanks.

[Alen Vrecko]

I assume you get the RequestDispatcher from the ServletContext. This
RD is the original one from the servlet container and as such it
doesn't know about the servlets you specified in your module.

One the other hand if you get the RD from the Request that one is
special (enhanced) and it does know about the servlets you specified
in your module. Try with getting RD from the request.

Cheers
Alen

On May 27, 4:49 pm, Steve <steveke...@gmail.com> wrote:
> Hey Guys,
>
> I've seen in another post:
>

> http://groups.google.com/group/google-guice/browse_thread/thread/f06a...

[Steve]

I'm grabbing the RequestDispatcher from the actual Request passed into
the original servlet (that went through the Guice filter chain), not
the ServletContext, but forwarding to the next Servlet gives me the
404.

[Alen Vrecko]

While I am not a fan of it works on my machine posts this is it.

Doing httpRequest.getRequestDispatcher("/bar") returns an instance of
com.google.inject.servlet.ManagedServletPipeline$2 and calling forward
on it works as expected.

I am not a servlet expert but

serve("/download").with(DownloadServlet.class); is not the same as

<url-pattern>/download/*</url-pattern>

the former will match only exactly for /download and nothing else but
the latter will match /download/foo, /download/bar , /download/....

serve("/download/*") is the same as <url-pattern>/download/*</url-
pattern> you put in serve method param what you put in url-pattern.

Cheers
Alen

[Steve]

Thanks for your response Alen.

I've double checked my request coming in, it's a ServletDefinition
that contains the ManagedServletPipeline (although what is returned
from request.getRequestDispatcher("/bar") is an
ApplicationDispatcher).

For the moment I'm using a redirect to the full URL which works fine.

With regards the url pattern, I'm new to this as well, but when I use
that pattern you suggest inside Guice it doesn't forward to the
download servlet at all, forwards or otherwise. It appears Guice does
not allow that pattern, which is why I am using the regular "/
download" pattern.

[Alen Vrecko]

AFAIK request.getRequestDispatcher("/bar") if Guice managed servlet /
bar is bound then you should get the ManagedServletPipeline$2 (The
special RD) but if it is not known then you should get
ApplicationDispatcher (original RD). I am guessing you dont have a
serve("/bar").with(...) call and you get ApplicationDispatcher
instead.

I am quite sure that "/foo/*" pattern works with Guice ;)

Cheers
Alen

[Steve]

Thanks Alen.

Your advice helped me isolate the issue.

If I try request.getRequestDispatcher("/download?
code=3vif9&msisdn=46733710212&language=sv&siteKey=essve_2") I am
returned an ApplicationDispatcher.

However if I try request.getRequestDispatcher("/download") I am
returned a ManagedServletPipeline, and it forwards with no issues.

If I access the URL directly through my browser,
http://localhost:8080/wap/download?code=jmtki&msisdn=46733710212&language=sv&siteKey=essve_2,
I am served the correct page through Guice.

Here are my servlet definitions:

serve("/download").with(DownloadServlet.class);
serve("/download/*").with(DownloadServlet.class);
serve("/downloadValidator").with
(DownloadValidatorServlet.class);
serve("/downloadValidator/*").with
(DownloadValidatorServlet.class);

(If I try to use just the "download/*" pattern my servlet is not
served at all).

So it appears to me that the forwarding has issues with parameters, it
does not return the ManagedServletPipeline when I have them.

[Alen Vrecko]

You're welcome.

I think you just found a bug. Indeed if you specify /download servlet
doing /download?myparam=a is a valid request for /download servlet and
should be handled.

Maybe you can try putting * at the end like serve("/download*").with
(....) this is ugly but it might work.

Keep in mind that when you forward the request will not reflect the
change in servlet properly unless you use the "hack" you mentioned.

Cheers
Alen

On May 28, 2:36 pm, Steve <steveke...@gmail.com> wrote:
> Thanks Alen.
>
> Your advice helped me isolate the issue.
>
> If I try request.getRequestDispatcher("/download?
> code=3vif9&msisdn=46733710212&language=sv&siteKey=essve_2") I am
> returned an ApplicationDispatcher.
>
> However if I try request.getRequestDispatcher("/download") I am
> returned a ManagedServletPipeline, and it forwards with no issues.
>

> If I access the URL directly through my browser,http://localhost:8080/wap/download?code=jmtki&msisdn=46733710212&lang...,