Java

HowTo: Setup GWT remote logging

I find the official documentation on remote logging wasn’t complete. Here are my notes based on various web sites I visited (here, here, and here). Hope this helps!

App.gwt.xml

You should add the inherits statement below. You should be able to adjust the log level to any of the following: ALL, FINEST, FINER, FINE, CONFIG, INFO, WARNING, SEVERE. I find the popup log console in the browser annoying, so I disabled it.

<inherits name=”com.google.gwt.logging.Logging”/>
<set-property name=”gwt.logging.simpleRemoteHandler” value=”ENABLED” />
<set-property name=”gwt.logging.logLevel” value=”FINEST”/>
<set-property name=”gwt.logging.enabled” value=”TRUE”/>
<set-property name=”gwt.logging.consoleHandler” value=”ENABLED” />
<set-property name=”gwt.logging.popupHandler” value=”DISABLED” />

web.xml

The following code is necessary for the server to receive log information and redirect to server log file.

<servlet>
<servlet-name>remoteLogging</servlet-name>
<servlet-class>com.google.gwt.logging.server.RemoteLoggingServiceImpl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>remoteLogging</servlet-name>
<url-pattern>/YOUR_MODULE/remote_logging</url-pattern>
</servlet-mapping>

java

Here is the example code you can use in GWT client-side.

import com.google.gwt.logging.client.SimpleRemoteLogHandler;
import java.util.logging.Level;
import java.util.logging.LogRecord;

SimpleRemoteLogHandler remoteLog = new SimpleRemoteLogHandler();
remoteLog.publish(new LogRecord(Level.INFO, “log message”));

Adding print feature to a GWT app

Enable print: I was able to add print feature to a GWT app by using gwt-print-it library. I used last example in the documentation to get the printing to work (see included code fragment below).

Print.it(“<!DOCTYPE HTML PUBLIC ‘-//W3C//DTD HTML 4.01//EN’ ‘http://www.w3.org/TR/html4/strict.dtd’>&#8221;, “<link rel=StyleSheet type=text/css media=paper href=/paperStyle.css>”, RootPanel.get(“myId”));

I had to use absolute URLs instead of relative paths for CSS href attributes. Although this library can potentially help me to eliminate the need to create a separate print friendly display code, this created several challenges:

CSS link difference: After attempted to print using several browsers, I discovered that different browsers will interpret href attribute for the CSS links differently. To avoid the need to create browser specific code, I tried the following workaround:

Element body = RootPanel.getBodyElement();
Print.it((Element) body.getParentElement());

This will print the whole page, which includes all the CSS references that are already working for the browsers and eliminate the need to define separate CSS links that does not work across browsers.  :)

Image link difference: I also discovered that the image links are also broken when attempt to print. This is a known “feature” according to gwt-print-it documentation. So, instead of defining images using <img> tags, I used background-image definition in my CSS file and use a div tag with an ID to associate with the CSS definition. See answer #7 in this page for code example. This effectively unified how browsers reference images, which always relative from where CSS file is located. This means I no longer need to create print specific URLs for images. :)

Background image printing: Once I started to use background images, Chrome stopped printing the images. A search on Internet led me to this solution, which worked great. :) For Mozilla, users can enable printing of background images by select Options tab in the Print window and check “Print Background Images”.

JavaOne 2010 Related Links

Here are some information that I found on the net about JavaOne 2010. Feel free to comment with additional resources. To start, Oracle posted some video highlights. If you have JavaOne login, you can view the full versions at On Demand site. If not, you can still see some of the contents here. Beyond that, here are posts from various speakers on their talks and related links.

NetBeans 6 beta 1 is more JavaScript friendly than earlier releases

I’ve been using NetBeans 6 beta 1 for a while now. Today I just found out that if I am working on a static file such as a JavaScript file, all I need to do is to redeploy the project to the local server instance to see the changes. No need to rebuild or recompile. This is very cool. I don’t have to wait for the compilation of all that Java code in the same project to see changes in JavaScripts. This saves me a lot of time and I don’t have to go to a command line and do the copy myself. Again, very cool!

webtest and jWebUnit: first impression

I spent a little bit of time check out both webtest and jWebUnit. Here are my first impression:

webtest is declarative and XML configuration file driven. If you like configuration management more than programming, you might like this format. All you need is edit the test definition and hit the run command, no compilation necessary. If you have well formed HTML and working JavaScript, then you should not have too much trouble running this. My initial simple test case works once I commented out the non-working and irrelevant JavaScript reference in the HTML. I tried to take another mini-step forward by attempting to “configure” a click to select one of the link items in a JavaScript widget. Webtest has 3 ways to click on a link, by ID, label, or xPath. The widget’s link item doesn’t have an ID, so I can’t use that. I tried label and that didn’t work. Then I tried xPath and that didn’t work for me either. So, that second mini-step didn’t go very far for me. Any one know an open source xPath validation tool or web site?

jWebUnit is one of the many unit testing frameworks based on jUnit/HtmlUnit. The interesting aspect of this framework is that it supports both HtmlUnit and Selenium test cases. jWebUnit uses similar programmatic model as jUnit, so you can stay comfortable within your favorite IDE. I was able to create a new project in NetBeans and leverage it’s jUnit feature, by creating an unit test and rewrite that as a jWebUnit test case, while using NetBeans to drive the test execution. jWebUnit, or the underlying HtmlUnit engine appears more picky about JavaScript than Webtest, I had to start tweaking YUI libraries in an attempt to load a page, which shouldn’t be something that I supposed to be doing anyway. Perhaps YUI engineers use a different unit testing framework. The test page actually loads without a major issue in Firefox.

Both frameworks do share one thing in common, both do not use actual browser instances to drive the testing. And that explains why they don’t work as well as some of testing frameworks that built within or on the real browser instance because of behavior differences when processing JavaScript. At the same time, both may have one advantage over browser based testing framework, which is the ability for non-interactive testing through ant and is very useful for continuous integration servers such as CruiseControl. Again, I’ve only looked a few testing frameworks and let me know if you know a browser based unit testing framework that works with ant. Thanks.