As far as I know, gwt uses relative paths wrt it's own context root. So the client calls should always be able to reach the gwt servlets. I've never had to configure anything to make that happen. If you setup apache2 to forward virtual name based hosts to tomcat, apache2 is nothing more than a proxy server to 127.0.0.1:8080. Then you can keep the tomcat fairly simple and straightforward. There are multiple examples online of how to deploy a .war file to tomcat on the internet. It's nothing more than that.
On Thu, Nov 9, 2023 at 6:34 PM 'dav...@googlemail.com' via GWT Users < google-web-toolkit@googlegroups.com> wrote: > yeah that sounds doable, I think it's along the lines I was already > thinking > > So* mydomain..com* is served by apache2 and includes the GWT javascript > > Apache2 also has a conf for *subdomain.mydomain.com > <http://subdomain.mydomain.com>* that creates a backend AJP to tomcat > where I serve subdomain.*mydomain.com/appA <http://mydomain.com/appA>* > and subdomain.*mydomain.com/appB <http://mydomain.com/appB>* > > So I just create a ROOT folder in webapps, pop a copy of my GWT code's > WEB-INF there and that does a job. > > But not the job! The servelet that GWT server code creates to pass the > remote ip to the client code is now running at *subdomain.mydomain.com/foo/bar > <http://subdomain.mydomain.com/foo/bar>* instead of *mydomain.com/foo/bar > <http://mydomain.com/foo/bar>*, so the GWT produced client javascript > served at *mydomain.com <http://mydomain.com>* and the servelet can't > talk. > > I feel there must be a solution, but just now I don't see it and even thus > far, I feel I'm jumping through hoops. Am I missing a *recommended way* > to do this? > > > > On Thursday, 9 November 2023 at 13:40:02 UTC Leon Pennings wrote: > >> You can deploy the web application on tomcat and use mod_proxy on apache2 >> to forward https (or http if required) to tomcat on 8080 (or another port >> if required) >> >> Op woensdag 8 november 2023 om 18:31:19 UTC+1 schreef >> dav...@googlemail.com: >> >>> hi Ed >>> >>> Yes understood and most of the "app" is GWT produced javascript, part >>> of a web page, which I've always run on apache2 and don't really want to >>> change that for the ip address supplying servelet which is a recent >>> addition. I already also run a backend tomcat with an AJP connection to >>> apache2 for a couple of java coded apps. So is setting up the WEB-INF >>> directory of my GWT "app" separately in tomcat the preferred way to do this >>> or at least a possibility? >>> >>> Prior to adding the server code the WEB_INF directory was not needed by >>> apache2 I believe, rather just the javascript, directory. so that does >>> appear to be a reasonable way to go? >>> >>> David >>> >>> On Wednesday, 8 November 2023 at 12:31:36 UTC Ed wrote: >>> >>>> jetty is application server while apache2 is a web server. tomcat is >>>> the apache app server. >>>> >>>> On Wed, Nov 8, 2023 at 4:48 AM 'dav...@googlemail.com' via GWT Users < >>>> google-we...@googlegroups.com> wrote: >>>> >>>>> On my development machine I test my code in jetty. The client code >>>>> calls a server to get the client ip address. This works fine and I see a >>>>> server at localhost:8080/foo/bar as I expect. If I browse to it I get a >>>>> 405 >>>>> as GET request are not allowed, but that's not a problem as it does the >>>>> job >>>>> it's supposed to do ie pass request address back to client code. >>>>> >>>>> It does not work in production were the code is run on apache; the >>>>> server is not created as on jetty, so that's not unexpected. I first >>>>> suspicion was that modsecurity is preventing the creation of the server, >>>>> but that proves to be not so. I also see the same failure over http as >>>>> over >>>>> https. >>>>> >>>>> I have a pretty basic apache2 setup on debian (apart from adding >>>>> modsecurity) and the site config is pretty bog standard for both http and >>>>> https. I'm guessing I need to tweak something somewhere to allow the >>>>> server >>>>> to be created? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "GWT Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to google-web-tool...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/google-web-toolkit/6aafe876-bff0-4b02-86f2-239e94201324n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/google-web-toolkit/6aafe876-bff0-4b02-86f2-239e94201324n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "GWT Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-web-toolkit/z7HMUEfBOZk/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > google-web-toolkit+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit/63dd206e-2a3c-4d5f-8fba-fbd036aa2d2an%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit/63dd206e-2a3c-4d5f-8fba-fbd036aa2d2an%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7T8K0yiM0zg-AiUt3vqmsT%2B6nOPz4q54k3WUbRSX8_dcg%40mail.gmail.com.
