GWT 1.6 – Tomcat or Jetty ?

Bruce Johnson (tech lead of the Google Web Toolkit ) is asking the community if it would rather have Jetty or Tomcat as the hosted mode embedded HTTP. Unfortunately, I do not know Jetty enough to have an opinion. But if you know both Jetty and Tomcat, you should not hesitate to participate in this debate.

The GWT team has started putting together a 1.6 roadmap, which we’ll publish as soon as we have it nailed down. Two of the areas we want to work on for 1.6 are some improvements to hosted mode startup time and a friendlier output directory structure (something that looks more .war-like).

As part of this effort, we’ve all but decided to switch the hosted mode embedded HTTP server from Tomcat to Jetty. Would this break you? (And if so, how mad would you be if we did it anyway?)

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/604aec6b7460c133?hl=en&pli=1

GWT Profiling and Debugging Techniques

• This page has moved to
• http://vinaytechs.blogspot.com/2009/09/gwt-profiling-and-debugging-techniques.html
• Sorry for any inconvenience caused!

Profiling

The JVM is designed with a means to get information on running processes (JVMPI, and the newer JVMTI). Using these mechanisms many Java tools can report on exactly what is going on when a Java application is executing. This information includes number of objects in use, memory, threads, garbage collection and so on. Profiling can be invaluable in tuning and troubleshooting an application. The end goal of profiling is to determine exactly what is happening with an application at runtime, in great detail, and identify performance metrics and bottlenecks.

The Limitations of Hosted Mode Profiling

Profiling GWT though, is once again a bit different from what you might expect. With GWT you have access to the standard Java profiling you are likely accustomed to, but only in hosted mode. Using a Java profiler, when working in hosted mode, as you normally would (from within an IDE, or separately), yields only an intermediate sort of reference point. What happens in Java, before the GWTCompiler optimizes things, is not representative of what will happen in JavaScript. You might catch any glaring problems with your code using this method, but you will not be able to tweak end result performance.

In web mode, a JavaScript profiler can be used. This type of profiling does operate against the end result code of your application, and can yield a great deal of performance, and troubleshooting information, but also has it’s own GWT related differences.

Web Mode Profiling

For detailed information, and or troubleshooting purposes when working with GWT projects in web mode, you will want to use a JavaScript profiling tool. The Mozilla Venkman Project and Firebug are two examples of excellent JavaScript debugging and profiling tools.

Problem:

How do I profile a running GWT application in web mode?

Solution:

In order to profile GWT code in web mode you first need to make sure to use the -style command line parameter with the GWT compiler and set the format to PRETTY or DETAILED. PRETTY is the recommended setting for normal profiling. If you need extra troubleshooting help, or for any other reason want extra verbosity, you can use DETAILED. If you are using the “Compile/Browse” button from the GWTShell, you can also pass the -style parameter to the shell, which will in turn hand it off to the compiler. If you leave things in the default style setting of OBF (obfuscated), you do not stand much of a chance of following the output. Ultimately after you have profiled your code, before you deploy it to a production environment, you will want to switch back and compile with the OBF style.

For example purposes we will use the Firebug “web development” plug-in for Mozilla Firefox. Firebug includes CSS and DOM inspection tools, network traffic monitoring capabilities, HTML tools, and more, in addition to excellent JavaScript profiling capabilities. Firebug can be used on all platforms where Firefox is available.

Installation of Firebug is the same as that for any Firefox plug-in, select the .xpi file from the Firebug website (http://www.getfirebug.com/), and allow it to install. Once installed, the Firefox “Tools” element on the top menu will include a new Firebug sub-menu. To see Firebug in action, after it is installed, you simply invoke Tools->Firebug->Open Firebug. Figure 1 is a screen shot of the Firebug Console window open, on the lower half of a browser screen.

Figure 1 Firebug running in the lower half of the Firefox browser, Console section open

To use Firebug with a GWT application you simply direct your browser to the GWT application and open Firebug. The simplest way to do this, assuming Firefox is your default browser, is to invoke web mode from the GWTShell via the Compile/Browse button. Using a GWT app in the shell, and invoking web mode, will invoke the GWT compiler and open a browser window directed at the compiled code (and still run any service servlets in the hosted mode shell). Then you can start Firebug (recall, Tools->Firebug) and learn a great deal of useful information about your application.

Discussion:

Using the Firebug Console you can inspect many of the components of a running AJAX application. This includes XmlHttpRequest (XHR) calls, XML errors and JavaScript information. The XHR information, request and response, including the headers, is useful in understanding how the GWT moving parts are operating. This can be invaluable in terms of troubleshooting. For example, Figure 2 shows several XHR calls made while running GWTTestMe.

Figure 2 Firebug screen shot showing XHR POST operations, including full HTTP headers, in the Console

From the Firebug Console, as seen in Figure 2, we see several important GWT details. First, the “Headers” section shows the XHR response and request headers. These indicate that a POST response was returned from a local “Apache-Coyote” server, at the path http://localhost:8888/%5BMODULE_NAME%5D/%5BSERVICE_NAME%5D. This shows us exactly where our GWT RPC is ending up, if we were using -noserver we would expect to see our external server instance being invoked here. Also the POST request includes the “referer,” which denotes exactly which of the hash named “cache.html” files was used (which specific compiled version of the application). Finally, in the “Post” and “Response” sections we see the GWT IsSerializable/Serializable objects that are passed across the wire. These are not specifically profiling tasks, but are handy related features of Firebug that can be extremely useful when working on GWT applications.

Tip

Also note that when using Firebug you can use the Console XHR information to see if “content-encoding” gzip compression is in use. This compression can greatly reduce the size of textual content client user-agents have to download. Because HTML and JavaScript are text, compression should be used (it is the default on most HTTP 1.1 servers and clients, but you should check to make sure that it is working properly).

The Firebug Console can capture many of the details details you may ever want to know about a running GWT application. The HTML, CSS, and DOM sections of Firebug are also very useful, and somewhat self-explanatory. Additionally the Net section provides network traffic and asset size relation information about each part of a running application. And, the Script section provides not only insight into the JavaScript being used, but also a full fledged debugger, with breakpoints and variable contents. Though debugging in JavaScript can be helpful, it is usually more valuable for GWT developers to debug things as Java in hosted mode, something we will come to in the next section. To “profile” a JavaScript based application, you engage the Profiler by clicking on the “Profile” link in Firebug to start and stop the profiler’s data collection process.

By clicking on Profile a first time, you tell the profiler to begin paying attention. At that point you can then click around your application and perform some tasks. Then when you click Profile again, you instruct the profiler to stop and display the collected data in the Console. It is this data that can help you understand how your GWT application is working. Figure 3 is a screen shot showing the results of the Firebug profiler, which includes such concepts such as the number of calls each function received, percentage, time, and what file each is in. (Note that “own time” means time inside the function specified without recursive calls to other functions, while “time” means total time including recursive calls.)

Figure 3 Firebug Profiler screen shot showing sortable profiling data collection results

The manual profiling method using Firebug is often helpful, but you may also want to use it in a more automated fashion. To do so, you can include JavaScript methods to start and stop the profiler using the Firebug Console API. In GWT terms, if you are concerned, or curious, about a particular section of code you can use JSNI with the Console API to automatically stop and start the profiler in exact areas you specify. This, in addition to being automatic, focuses the results to just the specific portions of code you are interested in.

Once you have collected profiling data with Firebug you can then inspect the results to understand exactly how your application is operating. You need to keep in mind though, that what you are seeing is your code as optimized by the GWT compiler (unless you are using JSNI). This is key because you have to remember that the GWT compiler is fairly smart. The “optimizations” it performs should mean that you will not ever have much to “fix” as a result of your profiling, if you are using standard GWT code and allowing the compiler to do its job.

Profiling a standard GWT application, as JavaScript in web mode, is more about understanding the network calls, optimizing the number of HTTP requests made, and gleaning information to troubleshoot problems, than it is about making changes and optimizing code. You should generally see many core GWT functions at the top of the stack in your profiler results. These things you are not going to improve upon unless you start hacking on the toolkit itself. Farther down the line you should see your controller methods as JavaScript functions (again, if you are using a client side controller in the canonical GWT manner), and your actual serializable objects. Also, you will see service proxy functions and all other details concerning everything GWT is doing to manipulate the DOM, invoke RPC, and so on.

Overall Firebug, and other such JavaScript profiling tools, are very important to the GWT developer. You can use these tools to see the whole picture when it comes to your GWT application, making sure your code does what you expect. Along with profiling, another arguably even more important development tactic is debugging.

Debugging

The hosted mode browser is a running Java process, as is the GWT shell. There is a harness between these components that propagates browser based events to GWT projects running in the shell. Using this approach, you can run your GWT project and use a standard Java debugger in a variety of ways. The most common means to debug a Java project are either to run the project in process inside of an IDE, or to connect an IDE to a remotely running Java process with the Java Platform Debugger Architecture (JPDA) interface enabled and listening for connections.

These same methods can be used with GWT, to connect to, and debug your programs, through the GWT shell.

Many modern IDEs have all sorts of support for running applications, even servers, in process with the IDE; and then debugging from there. It’s good to also be aware, however, that you can debug external processes pretty easily as well. This is made possible by the Java Platform Debugger Architecture (JPDA – http://java.sun.com/j2se/1.5.0/docs/guide/jpda/architecture.html).

Basically, modern JVMs have a set of profiling interfaces (one for the front end, and one for the back end), and a protocol, that work together to enable external debugging. JVMs include a native interface implementation, based on JVMTI, on the back end, and a Java interface based on JDI is used for front end debugging. The protocol that enables communication between the two layers is JDWP. Using this setup debuggers can easily connect to remote Java processes, and perform their typical beloved duties.

Problem:

How do I configure the JVM to allow a remote process to be debugged.

Solution:

Use the JPDA support built into the JVM to pass the appropriate options to the Java process on the command line, and then connect to that process with a debugger.

Discussion:

To demonstrate the concepts, let’s step through an example using GWT-Maven to launch a GWT project, and then debug that project from Eclipse. To begin, an external Java process needs to be running, and that process must have been configured to pass the -Xdebug and -Xrunjdwp options to the JVM at startup (optionally the newer -agentlib:jdwp option is preferable on Java 5.0 and above VMs).

The exact options used for this example, which are passed automatically via Maven and the GWT-Maven plugin using the gwt:debug goal, are as follows:

-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,address=3408,suspend=y

More detail about all of the options is available in the JPDA documentation ( http://java.sun.com/j2se/1.5.0/docs/guide/jpda/conninv.html#Invocation).

Basically, in this case, we are telling whatever Java process we run with these options to start and wait for a debugger to connect before continuing. Because we will be using GWT-Maven here the Java process we are controlling will ultimately be the GWTShell. On the command line this looks like what is shown in figure 4 (notice the process stopped, and is waiting for a connection on port 3408):

Figure 4 Shell session showing JVM waiting for debugger connection.

Once the process is waiting for a debugger to connect, the stage is set. The next thing to do is simply to connect with a debugger to the port shown – this is where Eclipse comes in. To connect with Eclipse you must use the “Run dialog,” and select new “Remote Java Application.” From there simply specify a name for the project, and the port as shown in figure 5.

Figure 5 Configuration dialog for Eclipse that demonstrates connecting to a remote process for debugging.

(Note* this screen shot shows port 1941 from a previous run, in this case it would need to be changed to 3408 to connect to the process started above.)

With that, all the pieces are in place, the JVM is running as the back end, and the IDE has connected as the front end. In this example the GWTShell continues along and launches the application, and from there you can click around to exercise the Java code. As with any typical debugging you can use breakpoints and step into and out of the code, and inspect the state as you go. Though the screen shot in figure 6 is small, you get the idea with the blue breakpoint dot and green highlighted code line:

Figure 6 Typical Eclipse debugger in use showing breakpoints.

In total the technique is very easy once you understand the roles of the components. Though this example used GWT, and GWT-Maven (something where external debugging comes in very handy), keep in mind that these concepts can be applied to any external Java process (a Tomcat server, a JBoss server, a Swing app, even an Applet – with a few caveats).

Other Debugging Tools

• View HTTP, Watch HTTP , Monitor HTTP , Capture HTTP , Track HTTP and Analyze HTTP/HTTPS!
• Rich web debugging toolset for IE!
  
• JavaScript, VBScript and HTML scripts debugger
  
• The Microsoft Internet Developer Tool
• Fiddler – Web Debugging Proxy
• HTTP Debugger

Missings in GWT – Property Binding

Property Binding

As I mentioned above, one the first things I found missing in GWT was property binding. If you don’t know, property binding is a way of making state changes in one representation of data show up in another representation of the same data. This is commonly done in GUI code that uses the venerable MVC pattern. For example, say you had data that represented the personal information of somebody. That data would include stuff like their first, middle, and last names, street address, city, state or region, and postal code.

In MVC, you’d have a model, an object that captured just this information. A simple Person model might look like this:

public class Person
{
   public String firstName;
   public String middleName;
   public String lastName;
   public String address;
   public String city;
   public String region;
   public String postalCode;
}

You’d also have a GUI form that contained text controls for each one of these fields. In most GUI frameworks, including GWT, each of these controls (or widgets, in GWT terminology) contains a copy of that same data. A lot of GUI code is written that copies code from one to the other. Property binding is way to automate (some) of that boilerplate code and automatically copy the data from the first name widget to the Person.firstName field whenever the user enters a new value.

FYI.. property binding libraries

Gwittr is a project (hosted on Google code) that includes property binding support.

Metawidget is another project with property binding support.

gwtx is to provide drop in support for an extended set of the of the standard Java library classes on top of what is provided by the GWT distribution provided by Google.

Real-world Experience with Google Web Toolkit (GWT) – Tips

Technology adoption is an unpredictable process – part theater, part academic review, part marketing. In Java it is especially confusing becuase we have so many different “channels” to watch for new anouncements, there are conferences, there are web sites like Slashdot and TheServerSide, there are a zillion personal blogs like DHH, and O’Reilly’s Radar. An interesting technology might generate a huge buzz one week only to see this buzz fall off as people notice that the product wasn’t ready for prime time.

For a product to make it into the mainstream, early adopters have to like a product enough to undertake the often impossible task of convincing more cautious developers that new technology X is worth adopting. Technologies such as Hibernate or the Spring Framework take years to become established products. Some products, like Maven, have a hard time becoming established because they either lack sufficient documentation or have difficulty challenging well established products like Ant. I’m interested in this blind spot in the process, the time between the buzz producing introduction and early adoption to large-scale adoption usually takes months to years, and is difficult to chart because, in many ways, it is viral. HIbernate didn’t take the world by storm as much as it slowly reached a critical mass of self-sustaining adoption. A failed project like OJB certainly generated a buzz at one time, but it failed to make good on promises – in that case early adopters actively discouraged others from using it in favor of Hibernate. Turning our attention to the Google Web Toolkit (GWT)…

Where is GWT in this process?

GWT seems to be in the middle of this early-adopters stage. The initial buzz has worn off, we saw a flurry of articles and blog posts about GWT, and it appears that we’re waiting for this first class of GWT adopters to report back on experiences with the GWT. We’re waiting for the first public site to show us what is possible with the GWT. My more cautious colleagues are avoiding it altogether, actively disparaging it as a bad idea altogether. Risk averse developers tend to criticize most new technologies until they have been demonstrably proven to work in a real-world situation – “Maven ‘Sucks’ until they see that IBM is using it, etc”. Those developers that have the ability to take risks are taking the framework out for a test drive. Of these early adopters one has sworn it off completely as inappropriate for his organization, “It reminded him too much of Swing”. Another colleague has embraced the idea in principle, but doesn’t have the time to integrate it into his existing web application. In terms of adoption where is the Google Web Toolkit? What is the experience of the early adopter crowd?

To answer this question I spoke with Michael Podrazik of Grassroots Technologies, a consulting group based in New York City. Through his work with Grassroots, Michael has been using the Google Web Toolkit (GWT) for a new web application currently under development. In the following interview I asked him to communicate his own experiences with this product in an attempt to help others currently considering the GWT. I specifically asked him for an objective opinion of GWT, and to describe, in detail, the challenges he faced when developing with the GWT framework. Hopefully, this information will help you decide whether or not GWT is the right choice for your projects.

Read on, read the interview and share some of your own real experiences with GWT in the comment thread.

The Interview

Q: What made you choose GWT?

Michael: I subscribe to the Google blog, so I heard about GWT the day they announced it prior to JavaOne. After reading the documentation I became intrigued by the approach so I downloaded the ‘kit and started playing

with it.

I had just begun a project to replace a legacy Access/VBA desktop application with a webapp. The specs call for some Ajaxian features on the UI side so I thought I’d give GWT a shot. I figured that so long as I kept the architecture abstract enough I would be able to swap out the GWT layer for a more traditional webapp framework should GWT be too bleeding-edge but so far I’ve been very pleased.

Q: What challenges did GWT present? Did you design you web application around GWT? Did the GWT challenge your ideas about web application development?

Michael: You really can’t think of GWT as a webapp framework but more as a UI library with RPC and object serialization support. Because of that you need to change your assumptions about project organization, package structure, etc. We have a great deal of experience developing Java server applications with rich-client user interfaces in Flash/ActionScript, C++ and Director that speak XML to the server-side. The GWT metaphor is almost identical to that, so thinking about the project in those terms, (separate server and client applications rather than a monolithic webapp), is fitting.

Working in that direction, you need to draw a line between what work is going to happen on the client side and what on the server side. I believe a good philosophy is to keep as much on the server as possible so that the client only has to deal with the presentation.

You need to think about the design of your service interfaces, such as how granular each operation needs to be and what the efficiency implications are. Also what the caching strategy will be as far as keeping state in the client, how that will jive with server updates, but this is probably old-hat to a lot of Java developers…

Oh, and you can’t use Java5 syntax on the client code but that’s not such a big deal.

Q. What do you mean? You can’t use Java 5 syntax in GWT specific classes or in your web application in general?

Michael: You can’t use Java 5 syntax in client side classes. We are using many Java 5 features on the server side, but any code that will be translated to Javascript needs to restrict itself to 1.4 compliant code.

This also covers some classes that you actually use on the server, however. Since the RPC framework allows for the serialization of user-defined data types, this means that you’ll have a class that has been translated to Javascript instantiated in the browser passed as an argument, (or a return value), to a server-side RPC service implementation. In your server code you’ll be working with the same class but of course a compiled bytecode version of it.

This presents a choice as to how tightly you want to couple your domain model to GWT. What we decided was to keep value objects implementation-agnostic so as to avoid “infecting” the API and persistence layers with beans implementing GWT’s IsSerializable interface.

For example, on the server side we have a user modeled with an IUser interface that itself extends IPersistable. The GWT service implementations accept and return GwtUser instances that implement IsSerializable and copy the values back and forth to a server-side POJO using commons-beanutils.

It could be argued that this is an unnecessary complication but I felt that the little bit of extra busy work would give a cleaner separation of tiers. We could ditch GWT at any point and switch to SpringMVC or Struts or whatever without having to worry about repercussions “deeper” in the codebase.

Q. How did you overcome the fact that GWT had a Maven 1 plug-in but no Maven 2 plugin?

Michael: I initially attempted a port of Robert Cooper’s Maven 1 plugin, but soon after discovered this post by ’shinobu’ on the developer forums. I took that code and modified it slightly to better match our environment and it works pretty well for compilation.

It doesn’t launch the hosted mode, but to be honest I haven’t really been using that so much. I’ve incorporated the plugin mentioned above with the Jetty6 plugin and I find that this approach has the two advantages of 1) a faster iteration cycle (hosted mode is pretty slow to load) and 2) you’re having the same experience in development as users will once it’s in production so you can potentially catch problems much faster.

Q: What were your initial impressions of the codebase? Have you looked at the GWT codebase?

Michael: I haven’t dug around too too much in the source. I did look through the rpc package a bit because I wanted to make sure that I wasn’t going to break anything with the strategy I’m using on the server, (front dispatcher servlet routing RPC requests to Spring-managed GWT RemoteServiceServlet instances). I’ve also looked some at the UI classes because I was curious about the “native method” implementation. It’s certainly an interesting approach. Frankly I’m amazed that it works at all never mind how well it really does.

Q: Have you found any occasion where GWT produces Javascript that A.) isn’t cross browser compatible? or B.) Contains errors that must be debugged manually?

Michael: No, and that’s the truly amazing part. Cross-browser Javascript development is a PITA and GWT really manages to shield you completely from it.

I have had a couple of occasions where things didn’t look the same on Firefox and IE but it turned out to be differences in their CSS support and nothing to do with GWT. I did also have a couple of Javascript errors but they were due to variables not being initialized that was pretty quick to figure out and didn’t require a laborious debugging cycle. Most of the work that has been completed so far has not been all of the UI components so perhaps that will change when we really get in the thick of that, but so far I don’t have many complaints.

Q: Does your team consist of people who are more comfortable with Java or Javascript?

Michael: Java definitely, but there are people on the team who have JavaScript and ActionScript, (which is kind of a super-set of JavaScript), experience as well.

Q: Have you discussed the use of GWT with a designer? What was the designer’s input?

Michael: I haven’t. Luckily the project really is a Web-Application and not simply a website with dynamic components. There are wireframes, and I’m sure we will get to a UI tweaking stage with the relevant people but up till now we’ve had a pretty free hand to interpret the wireframes.

What I can’t really speak to yet, and what I think you’re driving at with this question, is how capable is it at implementing arbitrarily-complex very design-rich interfaces. My gut feeling is that you should be able to create your own widgets with any kind of complex internal layout, but I’m not sure what would happen if you need the pixel-precision that tends to come with trial and error HTML/CSS tweaks.

If all else fails you can drop down to the “native” API or else simply keep parts of the design outside of GWT. You can certainly do that but you’ll lack the programmability of those areas without explicitly building hooks yourself.

It’s interesting though that the trend in design of AJAX-enabled sites seems to be for very clean, simple interfaces. That’s certainly a welcome trend for anyone who’s put their time in mangling HTML tables to achieve some effect or another.

Q: All in all, what is your advice to someone considering GWT? Would you recommend it? What is your objective opinion about this technology? Thumbs up or thumbs down?

Michael: A thumbs up for now. We are still in the early stages of development and figuring things out day by day so I don’t want to claim that it’s perfection or won’t turn out to bite us in some unforeseen way down the road. That said it allows for some pretty compelling application architectures. It really is just like writing a desktop application in Swing or other UI toolkit.

We are generating the entire UI using GWT based on a Controller and IView “screen” or “page” implementations. There is literally *NO* HTML beyond the GWT module import.

That is a very significant departure from almost all mainstream web application paradigms, but if you are comfortable with UI programming it completely abstracts AJAXy/DHTMLy behavior into a very friendly and extensible API.

I guess I would say that if you do most of your web projects with something like PHP, ASP or other template or page-centric language then you may have a bit of a learning curve. If you are already an experienced Java programmer then you’ll probably be able to jump right in without much fuss.I guess I would say that if you do most of your web projects with something like PHP, ASP or other template or page-centric language then you may have a bit of a learning curve. If you are already an experienced Java programmer then you’ll probably be able to jump right in without much fuss.

Comments:

We have done some pretty serious stuff with GWT. The application is a consumer centric web-application, with demanded several thick client features. I choose GWT for following reasons:
- doing serious UI application development in a type-less language like JS is very error prone and not scalable. Swing paradigm, with all call-backs, event handling is great. GWT enables these key features for agile web ui development.
- Having been new to AJAX, the AsyncCallBack and RPC appealed greatly to me.
- JSNI is great and allows us to integrate libraries like scriptaculous
- While OO development is possible in JS with stuff like ‘prototype’, it is still type less and not as versatile as Java. For large development it matters.
- Eclipse IDE and JDT integration. Helps a lot in debugging.

So, far I have been happy with the out-come. However, we do need substantial expertise with JS/CSS/HTML – atleast a couple of folks in the project.
Weak point of GWT :
- slow hosted mode – even in 1.3. No host-mode support for FireFox.
- very rudimentary widget set. Compare this with scriptaculaous and Yahoo UI Widget Library. I had to write quite a few for my application to meet the styles and user behaviour. For example, trees did not have widgets embeddable in them. The generated HTML is strict table based layouts, which our design department haf shunned!
All in all, like any other AJAX based stuff, GWT is not for faint hearted. If you can leverage, it is a big pay-off.

GWT Tip: No Cookies Support

Q:  How do I maintain auth in my GWT web service.

A: Use a Dictionary class.

The Dictionary class is part of the i18n GWT package, but the big advantage it has is that it is resolved at runtime, rather than compile time. This means you can pass in values to your GWT app from the host page. In this case, the host page being a JSP.

What you want to do is create a script tag in a host JSP like this:

var services = {
service1 : “<%=response.encodeUrl( “[serviceURL1]“) %>”,
service2 : “<%=response.encodeUrl( “[serviceURL2]“) %>”
}

That means you can now use :

Dictionary services = Dictionary.getDictionary(“services”)

to get a lookup for your service URLs with JSessionID encoded and use that when you construct your stubs. This will give the service cals the same JSessionID as your JSP host page.

Note: In GWT 1.5 release added Cookies support