Firefox Add-ons - Very useful for testing

Introduction

This article highlights the usage of Firefox add-ons which are useful for testing various Web applications. Firefox is one of the most important browsers for testers working in Web application domain. Specially, with all the add-ons around it, Firefox is certainly essential for testing Web applications. There are add-ons useful for security testing, analyzing page source, accessibility, debugging and pretty much everything you need for Web application testing.

Though IE is the most prominent browser used for browsing through internet, Firefox is catching up fast. Most of the Web developers and Testers use Mozilla Firefox due its user friendly features, add-ons and usability which make life easier for them. Mozilla Firefox is a free and open source Web browser descended from the Mozilla Application Suite and managed by Mozilla Corporation as of January 2010, Firefox had 21% of the recorded usage share of Web browsers.

Why FIREFOX Add-ons for Testing?

Firefox is an open source Web browser and the rate of development of various add-ons covering a wide variety of Web-age development and testing is very high. The variety of Add-ons provided by Firefox is just amazing due to the below factors:

1. Easy to use.

2. Provides even the minute things in detail.

3. Makes life easy for developers to debug, edit and troubleshoot while building Web-pages.

4. Testers find them easy for debugging.

5. Free download.

Apart from the above rich features, the add-ons can be used in various testing types like Security testing, Compatibility, Functional and Scalability testing. No other browser can even try to compete with Firefox add-ons. Knowing the complete list of add-ons would be a dream come true but utilizing the useful add-ons for testing our Web application should be good enough.

Important Add-ons

Picking up the correct add-on to test a feature is very important. Since there are hundreds of add-ons provided by Mozilla Corporation, some time has to be spent for selecting the best add-ons which suits our requirements. Picking up a few important add-ons to explain is also tough since each add-on cover its own area of Web testing. The below list should cover the basic Add-ons which help us in testing our application:

• Http Fox.
• Fire Bug.
• Measure IT.
• Add N Edit Cookie.
• IE Tab.
• Flash Tracer.

Lets look into the features provided by each add-on in detail.

Http FOX

• Used in incoming and outgoing HTTP traffic between the browser and the Web servers.
• Download Link
• Very much helpful in Functional testing

Description:

HttpFox monitors and analyzes all incoming and outgoing data between browser and the Web server. It enables us to profile Web server responses and dig into the headers to check out cookies involved in the requests as well as POST parameters. We need to install the application and Start the recording to analyze the data transmitted.

HttpFox add-on can also capture and reveal the following information’s:

• Time and duration of the query
• HTTP status codes
• HTTP method (POST/GET)
• Duration of the query
• Size
• Type
• URL
• Caching information

Each request has details like:

-URL: URL used to make the GET, POST, PUT methods.

-Type: Type of data being exchanged between the browser and server.

Typical examples are “text/html”, “image/gif” ,text/javascript” ,”image/png” .

-Result Code: Result code indicates the status of the HTTP call made. Fore more on result codes, please visit http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

-Method: Type of method made. (GET, POST, PUT, DELETE etc) .

For more on methods, please visit http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html.

-Start Time, Time – Time data provided to analyze the performance of the call.

-Sent, Received –Data transmitted

Information available per request includes:

- Request and response headers:

Explains the details of the headers used in the requests and responses made.

- Sent and received cookies

The details of the transmitted cookies between browser and server are listed here.

- Query string parameters

The Parameters sent to the server while making calls to retrieve data.

- POST parameters

Posted data in the HTTP call sent to the server.

- Response body (Raw and pretty)

The response sent from the server to the browser.

In addition to the above, the HttpFox has features to

1. Start and Stop recording.

2. Clear the call history.

3. Filter the calls.

4. Auto scroll.

5. Drop down to enable/disable the required data in the HTTP call.

Add N Edit Cookie

• Typical Add-on used to add new cookies, editing of both saved and live session cookies stored in a browser.
• Download Link
• Helpful in Security testing.

Description:

As the name suggests the Add N Edit cookie helps us in add, edit and delete a cookie. This tool is pretty much helpful in testing the cookie value and dependencies between the different cookies in a single Web application. This Tool provides flexibility to set a new value to a cookie by providing name, content, host and path information as well as new expiration time for a cookie which basically helps us in cookie validation and testing the session stability/expiry.

This tool has buttons to

1. Edit the cookie.

2. Add a new cookie.

3. Delete a cookie.

4. Filter helpful in finding a particular cookie.

Fire Bug

• A great add on which is helpful in debugging the CSS, HTML, SCRIPT and Http traffic on the Web page.
• Download Link
• Very much helpful in Functional testing.

Description:

Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. One can edit, debug, and monitor CSS, HTML, and JavaScript live in any Web page.

When installed on fire fox, it basically looks like a bug symbol in the bottom left hand corner. The add-on completely explains the total CSS part of the Web page. Basically helpful for developers in designing the Web page. Testers can be used to test the various Web elements in the page. Using the element inspector we can easily find out properties of any element in the page. Using the NET tab, we can observe all the HTTP calls made on the page.

Fire bug is very useful in finding out all the JS errors on the page for testers. It basically provides us the environment where we can edit the script of page and view how our changes affect the layout of the page. This particular add on is used by a very large set of audience.

IE Tab

• IE Tab allows users to view pages using the Internet Explorer rendering engine from within Firefox.
• Download Link
• Very much helpful in Compatibility testing.

Description:

This is an interesting add on which helps viewing an IE version Web page in Firefox browser. This will help both developers and testers in unit testing and compatibility testing. Developers can see the developed Web page in an IE browser. Testers can use this IE tab to view the page in FF so that at the same time can use many add-ons supported by Firefox which makes them easy for testing.

The IE Tab basically shows up a small Firefox icon in the bottom left hand corner of the page and has 3 options:

1. Left click of mouse to switch rendering engine of current page.

2. Center click to open the same page in a new tab.

3. Right click to open the IE tab options window.

MeasureIT

• Used in incoming measuring the element dimensions in pixels.
• Download Link
• Very much helpful in Compatibility testing

Description:

A typical measuring device, helpful in measuring dimensions of a Web page element. Once added to Firefox, the MeasureIT looks like a small ruler in the bottom left hand corner on the page. All we need to do is, click on the ruler and drag the ruler around the element to measure its dimensions. The dimensions will be provided in pixels as shown in below screen shots.

The ruler can be used in measuring both horizontal and vertical elements through a simple click. We need to click on the same ruler to de-activate the MeasureIT add-on.

Flash Tracer

• Used in to analyze the flash actions performed in a Web browser.
• Download Link
• Very much helpful in flash application testing.

Description:

The flash Tracer works along with the adobe flash debugger and informs the users about the various actions, warnings, errors performed by a flash application on a Web page.

Install the Flash debugged from Adobe and Flash tracer adds on to make the flash tracer working. Once the flash tracer is installed, we can see the flash errors reported in form of errors.

Error debugging becomes much easier with Flash tracer for Testers. Flash tracer will be available in Tool section in the browser.

Conclusion

So, in the above discussion we have seen some excellent add-ons provided in Firefox. The details provided while help us to use the add-ons in Web based testing. Although the list provided does not contain the total list, it will surely help us in testing a wide range of features in the Web application.

If you are testing a Web application, it is better to test the functional testing in fire fox first and then move for IE. This is easier than trying the other way round.

References

• www.wikipedia.com
• http://addons.mozilla.org
• http://blogs.imeta.co.uk

Read More

Firefox Add-ons - Very useful for testing

Introduction

This article highlights the usage of Firefox add-ons which are useful for testing various Web applications. Firefox is one of the most important browsers for testers working in Web application domain. Specially, with all the add-ons around it, Firefox is certainly essential for testing Web applications. There are add-ons useful for security testing, analyzing page source, accessibility, debugging and pretty much everything you need for Web application testing.

Though IE is the most prominent browser used for browsing through internet, Firefox is catching up fast. Most of the Web developers and Testers use Mozilla Firefox due its user friendly features, add-ons and usability which make life easier for them. Mozilla Firefox is a free and open source Web browser descended from the Mozilla Application Suite and managed by Mozilla Corporation as of January 2010, Firefox had 21% of the recorded usage share of Web browsers.

Why FIREFOX Add-ons for Testing?

Firefox is an open source Web browser and the rate of development of various add-ons covering a wide variety of Web-age development and testing is very high. The variety of Add-ons provided by Firefox is just amazing due to the below factors:

1. Easy to use.

2. Provides even the minute things in detail.

3. Makes life easy for developers to debug, edit and troubleshoot while building Web-pages.

4. Testers find them easy for debugging.

5. Free download.

Apart from the above rich features, the add-ons can be used in various testing types like Security testing, Compatibility, Functional and Scalability testing. No other browser can even try to compete with Firefox add-ons. Knowing the complete list of add-ons would be a dream come true but utilizing the useful add-ons for testing our Web application should be good enough.

Important Add-ons

Picking up the correct add-on to test a feature is very important. Since there are hundreds of add-ons provided by Mozilla Corporation, some time has to be spent for selecting the best add-ons which suits our requirements. Picking up a few important add-ons to explain is also tough since each add-on cover its own area of Web testing. The below list should cover the basic Add-ons which help us in testing our application:

• Http Fox.
• Fire Bug.
• Measure IT.
• Add N Edit Cookie.
• IE Tab.
• Flash Tracer.

Lets look into the features provided by each add-on in detail.

Http FOX

• Used in incoming and outgoing HTTP traffic between the browser and the Web servers.
• Download Link
• Very much helpful in Functional testing

Description:

HttpFox monitors and analyzes all incoming and outgoing data between browser and the Web server. It enables us to profile Web server responses and dig into the headers to check out cookies involved in the requests as well as POST parameters. We need to install the application and Start the recording to analyze the data transmitted.

HttpFox add-on can also capture and reveal the following information’s:

• Time and duration of the query
• HTTP status codes
• HTTP method (POST/GET)
• Duration of the query
• Size
• Type
• URL
• Caching information

Each request has details like:

-URL: URL used to make the GET, POST, PUT methods.

-Type: Type of data being exchanged between the browser and server.

Typical examples are “text/html”, “image/gif” ,text/javascript” ,”image/png” .

-Result Code: Result code indicates the status of the HTTP call made. Fore more on result codes, please visit http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

-Method: Type of method made. (GET, POST, PUT, DELETE etc) .

For more on methods, please visit http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html.

-Start Time, Time – Time data provided to analyze the performance of the call.

-Sent, Received –Data transmitted

Information available per request includes:

- Request and response headers:

Explains the details of the headers used in the requests and responses made.

- Sent and received cookies

The details of the transmitted cookies between browser and server are listed here.

- Query string parameters

The Parameters sent to the server while making calls to retrieve data.

- POST parameters

Posted data in the HTTP call sent to the server.

- Response body (Raw and pretty)

The response sent from the server to the browser.

In addition to the above, the HttpFox has features to

1. Start and Stop recording.

2. Clear the call history.

3. Filter the calls.

4. Auto scroll.

5. Drop down to enable/disable the required data in the HTTP call.

Add N Edit Cookie

• Typical Add-on used to add new cookies, editing of both saved and live session cookies stored in a browser.
• Download Link
• Helpful in Security testing.

Description:

As the name suggests the Add N Edit cookie helps us in add, edit and delete a cookie. This tool is pretty much helpful in testing the cookie value and dependencies between the different cookies in a single Web application. This Tool provides flexibility to set a new value to a cookie by providing name, content, host and path information as well as new expiration time for a cookie which basically helps us in cookie validation and testing the session stability/expiry.

This tool has buttons to

1. Edit the cookie.

2. Add a new cookie.

3. Delete a cookie.

4. Filter helpful in finding a particular cookie.

Fire Bug

• A great add on which is helpful in debugging the CSS, HTML, SCRIPT and Http traffic on the Web page.
• Download Link
• Very much helpful in Functional testing.

Description:

Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. One can edit, debug, and monitor CSS, HTML, and JavaScript live in any Web page.

When installed on fire fox, it basically looks like a bug symbol in the bottom left hand corner. The add-on completely explains the total CSS part of the Web page. Basically helpful for developers in designing the Web page. Testers can be used to test the various Web elements in the page. Using the element inspector we can easily find out properties of any element in the page. Using the NET tab, we can observe all the HTTP calls made on the page.

Fire bug is very useful in finding out all the JS errors on the page for testers. It basically provides us the environment where we can edit the script of page and view how our changes affect the layout of the page. This particular add on is used by a very large set of audience.

IE Tab

• IE Tab allows users to view pages using the Internet Explorer rendering engine from within Firefox.
• Download Link
• Very much helpful in Compatibility testing.

Description:

This is an interesting add on which helps viewing an IE version Web page in Firefox browser. This will help both developers and testers in unit testing and compatibility testing. Developers can see the developed Web page in an IE browser. Testers can use this IE tab to view the page in FF so that at the same time can use many add-ons supported by Firefox which makes them easy for testing.

The IE Tab basically shows up a small Firefox icon in the bottom left hand corner of the page and has 3 options:

1. Left click of mouse to switch rendering engine of current page.

2. Center click to open the same page in a new tab.

3. Right click to open the IE tab options window.

MeasureIT

• Used in incoming measuring the element dimensions in pixels.
• Download Link
• Very much helpful in Compatibility testing

Description:

A typical measuring device, helpful in measuring dimensions of a Web page element. Once added to Firefox, the MeasureIT looks like a small ruler in the bottom left hand corner on the page. All we need to do is, click on the ruler and drag the ruler around the element to measure its dimensions. The dimensions will be provided in pixels as shown in below screen shots.

The ruler can be used in measuring both horizontal and vertical elements through a simple click. We need to click on the same ruler to de-activate the MeasureIT add-on.

Flash Tracer

• Used in to analyze the flash actions performed in a Web browser.
• Download Link
• Very much helpful in flash application testing.

Description:

The flash Tracer works along with the adobe flash debugger and informs the users about the various actions, warnings, errors performed by a flash application on a Web page.

Install the Flash debugged from Adobe and Flash tracer adds on to make the flash tracer working. Once the flash tracer is installed, we can see the flash errors reported in form of errors.

Error debugging becomes much easier with Flash tracer for Testers. Flash tracer will be available in Tool section in the browser.

Conclusion

So, in the above discussion we have seen some excellent add-ons provided in Firefox. The details provided while help us to use the add-ons in Web based testing. Although the list provided does not contain the total list, it will surely help us in testing a wide range of features in the Web application.

If you are testing a Web application, it is better to test the functional testing in fire fox first and then move for IE. This is easier than trying the other way round.

References

• www.wikipedia.com
• http://addons.mozilla.org
• http://blogs.imeta.co.uk

Read More

GWT Profiling and Debugging Techniques

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/[MODULE_NAME]/[SERVICE_NAME]. 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

Read More

GWT Profiling and Debugging Techniques

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/[MODULE_NAME]/[SERVICE_NAME]. 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

Read More