Moving a web 1.0-style application to a web 2.0 model — by which I mean one that is Ajax-driven and interaction code is primarily found on the browser (perhaps this is web 3.0?) — can be a daunting challenge. GWT undoubtedly makes the process of creating a solid client-side application in Javascript easier, but the move to the browser brings some other, less obvious, challenges.
One of those challenges is logging. In the JSP world it was straightforward to add logging wherever you needed it; if you wanted to know what was happening during the processing of your servlets, it was easy to do: instantiate your logger and call the appropriate logging methods. Now much of the interaction happens on the browser and the only interaction you have with it is through RPC calls. You can log those on the server, but if any issues come up on the client, or you want to know why the RPC call happened in the first place, you suddenly run into one of the difficulties of the new browser-centric world.
Luckily there have been a few projects that aim to bridge the logging gap. There are several GWT projects that can provide remote logging, and it is also possible to roll your own if necessary.
The most interesting logging project for GWT so far is Fred Sauer’s gwt-log project. It provides a familiar logging interface as well as multiple methods for viewing the logs on both the client and the server. Over the last few months the remote logging component, which sends client logs to the server, has been enhanced, and an upcoming release will allow multiple GWT modules to use a single servlet for their remote logging RPC needs. (Currently each module needs to specify its own RPC target.)
There’s also a gwt-commons-logging project, which hasn’t seen much activity in the past year but may be suitable for your needs.
log4gwt is probably going to be THE standard for GWT logging in the future, but it’s currently just a placeholder project that recommends the gwt-log project. (Not surprising given that they are both owned by the same project owner.)
If you decide to roll your own remote logging, it is possible. In a future post I’ll list some of the things you’ll want to include if you go that route.
Keeping track of what your users are doing with your browser-based client can be difficult, but with the right logging tools in place you’ll be able to collect enough information to remotely troubleshoot many application problems.
Links:
