We went the proxy route. When deployed in production our GWT UI and
web service both sit behind a load balancer which makes them both
appear in the same origin. Requests actually get routed directly to
the web service. When running in hosted mode the same URL is caught by
a proxy servlet and forwarded to the real web service server side, and
the response is returned normally. We leave that proxy servlet enabled
and it gets used when needed (in development).
There's some tricks to getting a servlet mapped to the root ("/
service") instead of module relative ("/MyModule/service"), but it can
be done. (We use maven with the gwt-maven plugin which does this
automatically for us).
I used commons-httpclient. I have a blacklist of headers that get
filtered from the original request, everything else is copied over to
the outgoing request to the backend. Likewise, some of the response
headers are filtered out and the remaining are copied to the response
back to the browser. The filtered headers are things list
Server,Connection,Host, etc...
On Oct 21, 9:26 am, "Isaac Truett" <[EMAIL PROTECTED]> wrote:
> How is introducing an extra server layer of redirection going to speed
> things up? Or perhaps more to the point, what is it about using -noserver
> that you find slow and think would be improved under this scheme?
>
> On Tue, Oct 21, 2008 at 8:07 AM, obesga <[EMAIL PROTECTED]> wrote:
>
> > Hello
>
> > I've benn thinking and trying about using the GWT Shell with the
> > bussines server instead the
>
> > I've used -noserver option; but it has two caveats ( at least for me )
> > - It is very sloooo oo oooow
> > - Some static elements (f.e. Css files ) cannot be easily changed
>
> > So I've been researching for another way to make GWT Shell work with
> > external server.
> > I can see a way using the internal shell tomcat as a proxy server to/
> > from the bussines server
> > ( by handling the rpc calls from/to client to/from server )
>
> > I've looking at the into the web, and I found two ways to make it. I'm
> > not sure which can be the best ( easy to implement and deploy,
> > efficient, minimun error )
> > The 2 ways are
>
> > - First way: Use a socket sender/reciber:
> > Using the code on
> >http://www.java2s.com/Code/Java/Network-Protocol/Asimpleproxyserver.htm
> > and feeding the client input stream with the request stream
> > final InputStream streamFromClient =
> > this.getThreadLocalRequest().getInputStream();
> > final OutputStream streamToClient =
> > this.getThreadLocalResponse().getOutputStream();
> > Now, I don't know exaxtly how to seralize/deserialize the objects into
> > the stream
>
> > - Second way: use foward/redirect servlet handling
> > httpServletRequest.getRequestDispatcher("localhost:8080/
> > rpc").forward(httpServletRequest,httpServletResponse);
> > //OR
> > httpServletResponse.sendRedirect("localhost:8080/rpc");
> > ¿ Will an RPC work with a redirect or will fail / be blocked by SOP ?
> > ¿ Foward works between different servers ?
>
> > Well, I would appreciate any suggestion to make this work , because
> > now I'm a little stuck on what way should I try ( or why not attempt
> > to do it )
>
> > Thank you
>
> > Oskar
>
> > pd. yes, a simple RMI call will do the work - RMI is included into
> > J2SE - but it's very overkilling
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
