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 <[email protected]> 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...,
> 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.
>
> On May 28, 12:26 pm, Alen Vrecko <[email protected]> wrote:
>
> > 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
>
> > On May 28, 4:54 am, Steve <[email protected]> wrote:
>
> > > 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.
>
> > > On May 28, 12:44 am, Alen Vrecko <[email protected]> wrote:
>
> > > > 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
>
> > > > On May 27, 10:47 pm, Steve <[email protected]> wrote:
>
> > > > > 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.
>
> > > > > On May 27, 8:01 pm, Alen Vrecko <[email protected]> wrote:
>
> > > > > > 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 <[email protected]> wrote:
>
> > > > > > > Hey Guys,
>
> > > > > > > I've seen in another post:
>
> > > > > > >http://groups.google.com/group/google-guice/browse_thread/thread/f06a...
>
> > > > > > > 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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
