Hosted debug of RPC

58 views
Skip to first unread message

imbrue

unread,
Jun 6, 2006, 11:42:02 PM6/6/06
to Google Web Toolkit
I've got a GWT RPC service that utilizes other business logic in a web
application in order to complete the RPC requests. This requires that
the service implementation class be running as a servlet in a container
(I'm using Tomcat right now) which also is running other non-GWT
services. I'd like to run the client-side code in hosted mode so that
I can debug the client-side of the application. However, I can't
figure out how to run the GWTShell so that it either maps the service
calls out to my externally running Tomcat server or so that it can host
the full configuration of my server-side code.

Has anybody done anything similar? Can someone shed some light on how
to configure so that GWTShell can host and debug the client-side while
sending RPC requests out to my external Tomcat container?
Alternatively, if there is a way to configure the internal shell's
tomcat to host a fully configured additional web application that needs
its own initialization, that would be helpful.

If anybody thinks they can help but needs further details, please let
me know.

Thanks!

andres...@gmail.com

unread,
Jun 7, 2006, 12:14:27 AM6/7/06
to Google Web Toolkit
I have just started working on this and haven't had luck. There is a
blog that talks about a solution but I'm not sure it gives me all that
I need.
http://jroller.com/page/masini?entry=deploy_and_debug_google_web

imbrue

unread,
Jun 7, 2006, 12:39:30 AM6/7/06
to Google Web Toolkit
Thanks for that info. I've read this blog entry and don't understand
the use of the gwt-hosted.jsp thing that he describes. I don't see how
this servlet configuration in my web-app would get used. I guess that
the shell hosting environment running with the -noserver option would
use this somehow?

Luca Masini

unread,
Jun 7, 2006, 12:42:11 AM6/7/06
to Google Web Toolkit
You don't have to modify the gwt-hosted.jsp, it's only a trick to let
the Google Shell think it is running in host mode.

imbrue

unread,
Jun 7, 2006, 12:49:01 AM6/7/06
to Google Web Toolkit
I'm not talking about modifying your gwt-hosted.jsp code you listed in
your blog. I just don't understand how GWTShell (which is just running
my client-side translatable Java code) would ever access the
/mypackage.google.GWTClient/gwt-hosted.html URI of my web application.
Can you elaborate?

Luca Masini

unread,
Jun 7, 2006, 1:33:04 AM6/7/06
to Google Web Toolkit
Sure, at startup the GWTShell internal browser will try to access a
dynamic page called gwt-shell.html with the module name as first
parameter (well, not really a parameter, it misses the =).
If it is successful in this then it will run "thinking" that it is
talking with its internal browser, otherwise it will stop working.
The same request is never done by the "generated" client.
I hope I was clearer, let me know.
Ciao.

andres...@gmail.com

unread,
Jun 7, 2006, 1:35:43 AM6/7/06
to Google Web Toolkit
The URI that the browser initially hits is the last parameter passed to
the GWTShell, so it will go wherever you want. -noserver keeps it from
starting tomcat. But I agree, I don't understand what gwt-hosted.jsp
is doing and I don't like depending on it. It might be the only way
though.

Seems strange. You'd think the google guys would have bigger web apps
with server side code that they would need to make available during
debugging as well. I just want to know how they have their dev
environment set up.

Luca Masini

unread,
Jun 7, 2006, 1:46:52 AM6/7/06
to Google Web Toolkit
What gwt-hosted.jsp does is really simple.
Once downloaded on the hosted browser, it calculate the module name
from the query string of the request, and then it initializes the
hosted engine.
This is strictly "unnecessary" when in deployed mode, because there the
work is done by real JavaScript and not emulated by the browser.
Ciao.

imbrue

unread,
Jun 7, 2006, 2:19:52 AM6/7/06
to Google Web Toolkit
Luca, I understand. I've got it basically working and only need to
tweak some of my setup due to a convoluted build process. Thanks for
your help!

The key here was understanding how to "trick" the shell using the fact
that it makes the request for gwt-hosted.html.

andres...@gmail.com

unread,
Jun 7, 2006, 12:09:16 PM6/7/06
to Google Web Toolkit
imbrue,
Are you using the gw-hosted.jsp to trick the shell or some other
method? Can you share your setup?

imbrue

unread,
Jun 7, 2006, 1:55:38 PM6/7/06
to Google Web Toolkit
Yes, I am using the gwt-hosted.jsp file that is servlet-mapped so that
gwt-hosted.html requests will hit that JSP. I'll post my setup here
soon, but I'm still working out some things to make my environment work
the way I want it.

imbrue

unread,
Jun 7, 2006, 4:16:47 PM6/7/06
to Google Web Toolkit
Okay, here is my setup for running my server-side code (including GWT
RPC services) inside an external Tomcat server while either using a
standard browser (with JavaScript) or the GWTShell (with Java) for my
client code...

First, let me explain my scenario. I have a seperate project which
produces a JAR file containing business logic for a variety of web
applications. Each new web application needs to put this JAR file into
its WEB-INF/lib folder so that it has access to this business logic. I
wanted to expose some of this business logic through GWT RPC services
so that I can write rich client apps as opposed to the standard
server-side access of these services (previously done through a Struts
architecture requiring new browser requests to actions that invoke the
services and return a new page to the browser). In order to do this, I
wanted the build of the business logic JAR file to also produce a JAR
file containing the client-side interfaces. Note that since these
interfaces are code that must be translated by the GWT Compiler, this
secondary product of the business logic project must contain Java
source (*.java and *.gwt.xml) instead of the compiled class files.

So, my source tree for the business logic project looks something like
this:

src/com/mycompany/services/*.java
src/com/mycompany/gwtrpc/BizLogic.gwt.xml
src/com/mycompany/gwtrpc/client/MyService.java
src/com/mycompany/gwtrpc/client/MyServiceAsync.java
src/com/mycompany/gwtrpc/server/MyServiceImpl.java

The BizLogic.gwt.xml file contains an empty <modlue> tag since the
"client" package is assumed for source, and I don't need any <inherits>
or <entry-point> definitions (at least at this point).

When I build the business logic project, I produce 2 jar files. The
first is named BizLogic.jar and contains all of the compiled classes
and the second is called BizLogicGWTClientLib.jar and it contains:

src/com/mycompany/gwtrpc/BizLogic.gwt.xml
src/com/mycompany/gwtrpc/client/MyService.java
src/com/mycompany/gwtrpc/client/MyServiceAsync.java

Now, for my GWT based web application (which is a seperate project), I
put the BizLogic.jar into the WEB-INF/lib folder and also add the
javax.* stripped version of gwt-user.jar, which I have named
gwt-user-stripped.jar. This application has a source tree that looks
something like this:

src/com/mycompany/gwt/MyModule.gwt.xml
src/com/mycompany/gwt/client/MyModule.java
src/com/mycompany/gwt/public/default.html

MyModule.gwt.xml:
<module>
<!-- Inherit the core Web Toolkit stuff. -->
<inherits name='com.google.gwt.user.User'/>

<!-- Inherit the BizLogic GWT Interfaces. -->
<inherits name="com.mycompany.gwtrpc.BizLogic"/>

<!-- Specify the app entry point class. -->
<entry-point class='com.mycompany.gwt.client.MyModule'/>

<!-- Specify the service RPC mappings. -->
<servlet path="/myService"
class="com.mycompany.gwtrpc.server.MyServiceImpl"/>
</module>

MyModule.java contains:
import com.mycompany.gwtrpc.client.MyService;
import com.mycompany.gwtrpc.client.MyServiceAsync;
...
MyServiceAsync myService = (MyServiceAsync)GWT.create(MyService.class);
ServiceDefTarget target = (ServiceDefTarget)myService;
target.setServiceEntryPoint(GWT.getModuleBaseURL() + "/myService");
myService.doSomething(...

Now, when I build the web application, I run the GWTCompiler with a
class path that includes the webapp's source directory (to find
MyModule), the BizLogicGWTClientLib.jar (to find the BizLogic module),
and the GWT Jar files. This produces a directory named
com.mycompany.gwt.MyModule containing the default.html, gwt.js, etc.
However, I did not want this in my webapp under a subdirectory, so I
copy all of these generated files directly into the root of my target
web application base directory (in other words, default.html is
accessible from http://localhost:8080/MyWebApp/default.html).

I also put a copy of Luca Masini's gwt-hosted.jsp into my WEB-INF
directory.

Now, my web.xml looks something like this:

?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<servlet>
<servlet-name>MyService</servlet-name>

<servlet-class>com.mycompany.gwtrpc.server.MyServiceImpl</servlet-class>

</servlet>

<servlet>
<servlet-name>gwt-hosted</servlet-name>
<jsp-file>/WEB-INF/gwt-hosted.jsp</jsp-file>
</servlet>

<servlet-mapping>
<servlet-name>MyService</servlet-name>
<url-pattern>/myService</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>MyService</servlet-name>

<url-pattern>/com.mycompany.gwt.MyModule/myService</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>gwt-hosted</servlet-name>
<url-pattern>/gwt-hosted.html</url-pattern>
</servlet-mapping>

<welcome-file-list>
<welcome-file>/default.html</welcome-file>
</welcome-file-list>
</web-app>

Note that the MyService servlet is mapped to both "/myService" (used in
normal situation) and "/com.mycompany.gwt.MyModule/myService" (when
running in hosted mode).

I run this web application in a seperate Tomcat server, and I can
access it through http://localhost:8080/MyWebApp. I can run the
GWTShell in debugger and use this same URL and the shell will hit
/gwt-hosted.html and be tricked as previously discussed. The code in
MyModule.java that sets the service entry point for my service will use
"/MyWebApp/myService" when running in normal browser and
"/MyWebApp/com.mycompany.gwt.MyModule/myService" when running in hosted
mode. Both map to the service in my external Tomcat server.

I can debug the client-side Java code for the application and I can run
the web app normally with no modifications.

Hope this helps!

andres...@gmail.com

unread,
Jun 7, 2006, 7:27:12 PM6/7/06
to Google Web Toolkit
Thanks. This is a very clear explanation. And of course thanks to
Luca for the original effort on this.

andres...@gmail.com

unread,
Jun 7, 2006, 10:28:34 PM6/7/06
to Google Web Toolkit
One question, your module xml differs from Luca's in that it does not
use the full path in the servlet path attribute. Is that correct?

imbrue

unread,
Jun 7, 2006, 11:42:59 PM6/7/06
to Google Web Toolkit
Andres, yes that is correct. I only specified the path "/myService" in
the MyModule.gwt.xml file. However, I just discovered something that I
hadn't completely thought through before. It appears to me that the
<servlet> tag inside the module definition XML files are ONLY for use
by the hosted tomcat instance. Since I'm running hosted mode with the
-noserver option in order to have the GWTShell only run my client code
and hit my external Tomcat server for the RPC services, this <servlet>
tag can actually be completely removed. It had worked set up as
"/myService" but I didn't think about it completely until your posted
question. I've now removed it from my module definition file.

I guess that since my services rely on other back-end services that I
can't easily host inside the "hosted-mode" tomcat, I can never really
hope to host the RPC Service by itself in "hosted-mode" and will never
be able to run the hosted-mode tomcat anyway (I'll always specify
-noserver).

Unless someone knows of some other reason the <servlet> tag needs to be
inside the module definition file (other than to configure the
hosted-mode tomcat server), I don't see any way I can use it.

imbrue

unread,
Jun 7, 2006, 11:48:04 PM6/7/06
to Google Web Toolkit
One other note: The documentation for the module XML file format
(http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.Modules.ModuleXml.html)
specifies that the <servlet> tag is "For convenient RPC testing" which
reinforces my assessment that this tag is only used for the
"hosted-mode" tomcat instance.

Message has been deleted

andres...@gmail.com

unread,
Jun 8, 2006, 2:16:20 PM6/8/06
to Google Web Toolkit
So I got it working with the -noserver option but I had to manually
copy the gwt.js and history.html to the directory my Gallery.html file
was in. Did you guys have to do that?

imbrue

unread,
Jun 8, 2006, 2:24:35 PM6/8/06
to Google Web Toolkit
Yes. My build copies ALL of the generated files that are in the
/com.mycompany.gwt.MyModule directory that the compiler produces into
the base directory of my web application. This was only done because I
didn't want the URL in the browser to show up as something like
http://localhost:8080/MyApp/com.mycompany.gwt.MyModule/default.html and
I wanted it to just look like http://localhost:8080/MyApp/default.html.

This includes the gwt.js and history.html files.

Hope that helps. Let me know.

Andres March

unread,
Jun 8, 2006, 2:46:49 PM6/8/06
to Google-We...@googlegroups.com
I haven't even used the compiler yet. I just want to run it in hosted
mode for now until I get a little farther along. That makes sense
though. You basically bootstrap your dev off of a successful compile
and deployment. DIdn't think it was necessary but that would have
been easier than the debugging I've done over the past 24hrs. Thanks
for the help.

br...@google.com

unread,
Jun 8, 2006, 5:32:44 PM6/8/06
to Google Web Toolkit
I tried to distill a step-by-step approach to using an external Tomcat
server here:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/338c4b765d7dfc39

-- Bruce

Reply all
Reply to author
Forward
0 new messages