|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 6
Only modified sources are recompiled, i.e., no new bytecode is generated for files that depend on your modified code. So, when you change the value of a global constant, let's say the value of a public final int field, you will not see this change in dependent files immediately.
Only modified sources are recompiled by GWT. That means that even a "Project clean" inside your Eclipse IDE does not help. You have to touch all dependent sources, e.g., by adding a new empty line.
Because this would be quite a cumbersome procedure, my advice is to follow these 4 steps when modifying global constants:
When modifying server-side code, the GWT bytecode cache is not affected. However, the embedded Tomcat instance will cache it, and therefore only your first code change after starting from scratch will be acknowledged when you use the Refresh button. So again, to be on the safe side, it's better to start your application from scratch after changing server-side code.
When you are working with a database system, you generally do not want to have hard-coded database connection parameters in your servlet source. Typically you will read them from a property file, or even better, you will supply them as init parameters to your servlet (as a part of your application's web.xml file). This works fine when running your application in web mode, but it fails in hosted mode. This is due to restrictions in the GWT hosted mode servlet processing. The good news is: you can overcome this obstacle by modifying the web.xml file that will be used by the embedded Tomcat instance. To do so, modify (or create if necessary) the web.xml file in the <ModuleName>-client/tomcat/webapps/ROOT/WEB-INF directory: in addtion to the GWTShellServlet mapping for the embedded Tomcat add a context section with the init parameters as shown in listing 3 for my JUnit2MR example. Because the context information is "global", and not targeted to a specific servlet, you have either only one section of init parameter information here, or you have to use a special naming scheme to relate parameters to different servlets. When using this new web.xml file, you can delete the old one in your src/web/WEB-INF folder.
In your servlet code you access the init parameters the same way they are read in web mode, e.g., final String host = getInitParameter("host")
The hack I used to make this happen is to modify GWT's RemoteServiceServlet in the same way as was done in tip 2. Now you
simply have to override GenericServlet's getInitParameter() method in order to use getServletContext() instead of getServletConfig(). That's all!
// new method added to RemoteServiceServlet
public String getInitParameter(String name) {
return getServletContext().getInitParameter(name);
}
My classpath settings guarantee that the modified RemoteServiceServlet class is executed instead of the one in gwt-user.jar. For the GWT web mode, the modified class is not deployed. When deploying your application to Tomcat, an Ant script (or my Gant script) can help you to deal with the different web.xml versions.
An additional tip: When testing different server code behavior in hosted and web mode, I found it saved time to skip the GWT compile part in my Gant script and to copy the pre-compiled JavaScript code from a "temp" location instead. This made sense with compile times of up to 10 minutes when having more than trivial client-side code. With Gant it is very easy to incorporate a switch in the script that controls whether you are compiling or reusing older JavaScript files. The parameter for this switch is provided on the command-line, e.g., as ">gant -D 'compileGWT=yes' deploy". For details on this Gant script see tip 8.
Most real web applications give you a way to produce and read a PDF file. In our context, I assume that this PDF file will be produced by the servlet, e.g., by means of JasperReport. The created file can be read later inside the Browser by clicking a specific hyperlink. If you want to test such a feature in both the hosted mode and in web mode I propose you adopt the following procedure:
1. Design your RPC interface to accept a boolean parameter that tells the server whether we are running in hosted mode or in web mode. The interface method should return a string with the name (i.e., the last part of the filename) of your PDF file created by the servlet.
2. Implement the servlet code according to the code presented in listing 4, depending on the boolean parameter "isScript".
3. On the client side: inside your widget code call the createXyzPDF() method with a GWT.isScript() parameter and create an external hyperlink containing the servlet result string.
Listing 4 shows an example where the interface method is called createSummaryPDF(). The string returned from the servlet is "summary.pdf".
Consistent with the Perl philosophy of "There's more than one way to do it", I do not claim that this is the only way to handle this case, but it currently works fine for me. Please note that before starting your application in hosted mode, you have to create at least a dummy "summary.pdf" file (the filename returned from the servlet) in your <ModuleName>-client project's src/.../public folder; otherwise you will get "HTTP 404 - The webpage cannot be found" when the GWT tries to read your PDF when clicking on the hyperlink in your browser ;-)
One crucial question when designing client/server web applications is "how to deal with session and state management?" In the Web 1.0 world the answer is obvious: session and state management is a server issue. But with GWT you have another choice. No longer does the server have to be a "web" service that only supplies HTML content. Using GWT RPC the server now supports services - implemented by servlets in our case - that only supply structured data.
Introduction to GWT development: Ease AJAX development with the Google Web Toolkit
GWT add-on for debugging, developed by Mat Gessel.
GUI-based GWT testing with Selenium
For a good Ant script to deploy your GWT applications to Tomcat see: Google Web Toolkit: AJAX Buzz Meets Real World Development
To get the Gant script and the corresponding build.properties file for easy GWT deployment to Tomcat, download sample code.
Archived Discussions (Read only)