Technical Beef -

In hosted mode, GWT redirects all the logging calls made with commons-logging to its own "TreeLogger", so that any useful logs emitted server-side are redirected to it (and most likely lost). Not only is this annoying, it also breaks the expected consistency with the normal deployment state.

Technically, the GWT makes a System.setProperty("org.apache.commons.logging.Log", adapterClassName) call. Fortunately, the apache commons logging library preempts this setting with its own configuration file.

Just create a file called "commons-logging.properties" at the root of your classpath, and add the following line:

[to use the Log4j backend]

org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger

[to use the JDK14 backend]

org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger

[to use the SimpleLog backend]

org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

etc. well, you got it.

(OK, the title of this article is misleading, we're not really asking the GWT to not redirect, but rather asking commons-logging to ignore the GWT request)

Link: http://code.google.com/p/abstractcanvas/

How frustrating is it to have on hand a tool as good as GWT, and still see that all the graphics libraries are tied to the browser! Take for instance chart libraries, it should be obvious that we don't want just some server-side charting engine that can create PNG or PDF, but looks awfully static in the browser, and we don't want either some smart javascript library that looks great in the browser, but can't even create any of the PNG we need to build offline reports. Indeed, we need both.

As it appears there is no such a beast, here is my suggestion to developers using the GWT to create graphics: choose an abstract graphics API, make sure there is an implementation available on both server and client side, and use it to build the next version of your library. That's it. Don't waste your time coding for only one platform when you have at your disposal a technology that can target several ones.

I'm so frustrated with the current situation, that I wrote a proof-of-concept and an example of what should/could be done. Let me introduce you to the AbstractCanvas, a very simple java library that provides a single interface (mainly a subset of the HTML canvas and a few extra methods), and two implementations, one based on the incubator's GWTCanvas, and another one on the standard AWT (but Java2D-powered). There is one single interface to create the graphics, but one just needs to instanciate the AWT implementation to create server-side graphics, or instanciate the GWT implementation to access the client-side counterpart that can dynamically display its data.

As a sample, I also wrote a very simplistic charting engine based on it. Of course, the main point is that the graphics generated server-side are static, but the graphics on the browser are fully dynamic, with some of the bells and whistles one can legitimately expect from a javascript charting engine: using reflection, the engine applies animation and dynamic annotationc when the implementation supports a specific interface.

You can try the demo here

And the project is hosted at Google Code.

A few words on the HTML Canvas implementation: The GWTCanvas provided by the GWT Incubator has a serious limitation on the text drawing (which is actually an understatement to say that there is NO SUPPORT AT ALL for drawing text). There is not such a limitation in the current WHATWG (HTML 5) Canvas specification and in recent Gecko-based (1.9+) browsers, but as long as Microsoft has decided to ignore the HTML Canvas, we're stuck to the limited set of features that are common to all the browsing platforms.

Anyway, to bypass this limitation, I extended the interface to add a basic text support based on some HTML div absolutely positioned above the canvas (on AWT, there is no such a trick, of course). I tried to stick closely to the current HTML5 specs, so when the time comes where the full Canvas API is available on IE as well, it shouldn't be too much trouble to implement it using the standard methods. Or even, to provide another implementation when another solution, better than VML, is found for IE.

The AWT implementation was built on top of Java2D. That was rather easy, the Java2D API already provides everything needed to emulate the Canvas, and I'm pretty satisfied with it, as the resulting graphics are very close to the HTML Canvas implementation of the browsers (on IE, Gecko, and WebKit).

Some screenshots:

Display in the JAVA2D AWT implementation (in a Swing window)

Display in the GWT implementation (IE and Firefox)

Despite the fact that the approach taken is very simple (it took me a few days to write the AWT implementation as well as the charting engine), it works finely (just try the samples).

However, I still wonder if the HTML Canvas is the best approach for the problem: what about using a Flash implementation when the HTML Canvas is not available, instead of the VML-based implementation used by the current GWTCanvas ? The current limitations, namely the poor performance on IE, the lack of text drawing, and the bugged gradient support are really annoying, and a web-wide initiative from the javascript developers, targeting pragmatic solutions, rather than expecting a futuristic standard that would possibly get the approval of Microsoft, would be more than welcome (IMHO).