Atanas Roussev – Senior Java Developer, UI Engineer, Web Developer Resume – Vancouver

Just found another great example of HTML 5.

http://code.google.com/p/quake2-gwt-port/

Those guys have  ported Quake via GWT to pure HTML and JavaScript. I am pretty sure it will behave well only on WebKit, yet it shows the new approach the web is going, “sadly” without Adobe Flash.

Great news. HTTP4e was released few weeks ago. Today I found some time to post it.

New features:

Stay tuned for more news and examples.

Probably many of you needed to add Mootools, jQuery or Scriptaculous kinda effects within your GWT code.

I came across those two and I am spreading them to web:

Brand new, dead-easy to use library called GWT-FX:
http://code.google.com/p/gwt-fx/

A GWT wrapper over Mootools:
http://www.amateurinmotion.com/projects/gwt-mootools.html

I keep spreading the message. While Java gurus are still faithing on those religious best web framework wars , there is hidden winner already.

The best Java web framework award goes to … drumrolls … Finland.

Vaadin – When I saw it for a first time few months back, I was shocked. That what Java is meant to be – Innovative, slick, sexy.

An interesting idea. A blog post suggesting abandoning Stateful layer in favour of completly Stateless RESTful approach.

http://www.peej.co.uk/articles/no-sessions.html

“Developers became used to having sessions available to them, so when systems grew, became more complex, and started spreading over multiple servers, more and more hacks had to be introduced to keep the session support working, when in reality, sessions should never have been introduced in the first place.”

“Cart on the client

Using web2.0 RIA clients such as GWT, Vaadin or Cappuccino fit just perfect. I would only disagree with using the REST as a remedy for everything. While REST is great general purpose service architecture, decision should rather be based per technology. GWT f.i. has its first class optimized RPC API, so it’s natural for GWT to use its RPC over REST JSON.

Having explored the GWT RPC exception limitations, on this post we will take another route of simplifying GWT exception handling. In short the idea is by extending the parent RemoteServiceServlet we will inject a code so the RPC Servlet treat our business runtimes as a good friend. We are lazy developers and we would like to be able to throw business exceptions without having to declare them on the each RPC method (Which probably contradicts the whole Java exception contract.. ).

Hooking the business exception / Injecting it into GWT SerializationPolicy (aka fooling the GWT SerializationPolicy).

When an error propagates within a GWT service this error needs to be declared within the RPC method signature, otherwise bad things happen. The GWT SerilizablePolicy marshaling will complain about the type not being recognized and return 500 Server error response. Well we could easily overcome this limitation by creating a dummy hook method with only purpose of white-listing the business exception type within the given RPC signature Serialization policy:

interface AbstractRemoteServiceAsync {
   void hookException(AsyncCallback<Void> callback);
}

interface AbstractRemoteService extends RemoteService {
   void hookException() throws MyException;
}

class AbstractRemoteServiceServlet extends RemoteServiceServlet
                 implements AbstractRemoteService {
   /**
    * This method only reson vivre is to hook our business MyException type
    * into GWT Serialization policy
    */
   @Override
   public String hookException() throws MyException {
      // Blank
   }
}
/**
 * The business exception
 */
public class MyException extends RuntimeException {
	private static final long serialVersionUID = 1L;
}

From that point on, AbstractRemoteServiceServlet methods will treat MyException as a white-listed friend and no more SerializationPolicy warnings will happen.

Next thing we want to do is, automate this process so we don’t have to declare those hook methods on every RPC Servlet right? Well polymorphism on help.

Overriding RemoteServiceServlet default exception flow.

Let’s open the RemoteServiceServlet implementation. Luckily this class follows a template method pattern with hook methods ready for extending. What we will acomplish is extending RemoteServiceServlet class and inject a behaviour handling our business exceptions (code in red).

And this is my humble contribution to GWT community. All sources and project are hosted at Google Code:

/**
 * This class overrides RemoteServiceServlet to provide automatic exception
 * handling for known business exceptions
 */
public class AbstractRemoteServiceServlet extends RemoteServiceServlet
    implements AbstractRemoteService {

  /**
   * Overriding method so we can inject business exception type discovery
   * and handling
   */
  @Override
  public String processCall(String payload) throws SerializationException {
    try {
      RPCRequest rpcRequest = RPC.decodeRequest(payload, this.getClass(),
          this);
      return handleProcessCall(this, rpcRequest);
    } catch (IncompatibleRemoteServiceException ex) {
      log("Incompatible error was thrown while processing this call.", ex);
      return RPC.encodeResponseForFailure(null, ex);
    }
  }
  /**
   * Tis method digest the given throwable and tries to find any know business
   * exception. When a known business error is found it is being flushed (the
   * business type) to response stream, thus client callback receives the known
   * type but not the default GWT UnexpectedException.
   */
  @Override
  protected void doUnexpectedFailure(Throwable e) {
    discoverAndWriteError(e, e);
  }

  /**
   * This method reson vivre is to hook the recognized MyException type into
   * GWT Serialization policy
   */
  @Override
  public void hookException() throws MyException {
    // Blank
  }
  /**
   * Method handles GWT RPC call and on failure it digests the error,
   * finds supported business exception and handles them gracefully.
   */
  private String handleProcessCall(Object target, RPCRequest rpcRequest)
      throws SerializationException {

    Method serviceMethod = rpcRequest.getMethod();
    Object[] params = rpcRequest.getParameters();
    SerializationPolicy serializationPolicy = rpcRequest
        .getSerializationPolicy();
    try {
      return RPC.invokeAndEncodeResponse(target, serviceMethod, params,
          serializationPolicy);
    } catch (UnexpectedException ex) {
      Throwable cause = ex.getCause();
      // This could be a list of supported types ..etc..
      // Leaving it up to your imagination
      if (cause.getClass().equals(MyException.class)) {
        throw new MyException();
      }
      return encodeResponse(cause.getClass(), cause, true,
          serializationPolicy);
    }
  }

  /**
   * This method recursively iterates through given 'masterError'
   * finding any supported failures and handling the latter
   * appropriately.
   */
  private void discoverAndWriteError(Throwable masterError, Throwable e) {
    if (e == null) {
      writeError(new UnexpectedException(masterError.getMessage(),
          masterError));
      return;
    }

    Throwable cause = e.getCause();
    if (cause == null) {
      writeError(new UnexpectedException(masterError.getMessage(),
          masterError));
      return;
    }
    // This could be a list of supported types, etc..
    // Leaving it up to your imagination
    if (cause.getClass().equals(MyException.class)) {
      writeError((MyException)cause);
      return;
    } else {
      // continue with 'recursion' cause discovery
      discoverAndWriteError(masterError, cause);
    }
  }

  /**
   * This method writes known business exception the response HTTP packet
   * Code borrowed from com.google.gwt.user.server.rpc.RPCServletUtils
   */
  private void writeError(Throwable cause) {
    // Send SC_OK/200 status, serialize the gwt error, flush it to response,
    // and let the client deal with the business error
    HttpServletResponse resp = getThreadLocalResponse();
    try {
      resp.setContentType("text/plain");
      resp.setStatus(HttpServletResponse.SC_OK);
      String excMsg = RPC.encodeResponseForFailure(null, cause);
      resp.getWriter().write(excMsg);

    } catch (IOException e) {
      log("Failed to send failure to client", e);

    } catch (SerializationException e) {
      log("Failed to send failure to client", e);
    }
  }

  /**
   * Borrowed from RPC.java. Returns a string that encodes the results of an
   * RPC call. Private overload that takes a flag signaling the preamble of
   * the response payload.
   */
  private static String encodeResponse(Class responseClass, Object object,
      boolean wasThrown, SerializationPolicy serializationPolicy)
      throws SerializationException {

    ServerSerializationStreamWriter stream = new
              ServerSerializationStreamWriter(serializationPolicy);
    stream.prepareToWrite();
    if (responseClass != void.class) {
      stream.serializeValue(object, responseClass);
    }
    String bufferStr = (wasThrown ? "//EX" : "//OK") + stream.toString();
    return bufferStr;
  }
}

With the new RemoteService classes being created above, our GWT Services will derive from them as bellow:

@RemoteServiceRelativePath("greet")
interface GreetingService extends AbstractRemoteService {
  /* Notice, no exception is being declared*/
  String greetServer(String name);
}

interface GreetingServiceAsync extends AbstractRemoteServiceAsync {
  /* Notice, no exception is being declared*/
  void greetServer(String input, AsyncCallback callback);
}

class GreetingServiceImpl extends AbstractRemoteServiceServlet implements
    GreetingService {
  /* Notice, no exception is being declared*/
  public String greetServer(String input) {
    {
      throw new MyException();
    }
  }
}

The last piece of course is executing the service and see it in real browser:

Feel free to explore project sources at Google Code.

Something else not directly related to this post. You may have noticed, GWT RPC exceptions are being transmitted to browser as a JSON HTTP packet of 200 OK response with //EX[org.roussev.MyException|1|23|4|5] signature.

While developing GWT Remote Procedure Calls(RPC), many of you have experienced the limitations of the default GWT exception handling model. I will demonstrate this with a sample application. If you create the default GWT hello world application you will notice three RPC service classes being created for you:

interface GreetingServiceAsync {
   void greetServer(String input, AsyncCallback<String> callback)
          throws IllegalArgumentException;
}

@RemoteServiceRelativePath("greet")
interface GreetingService extends RemoteService {
   String greetServer(String name) throws IllegalArgumentException;
}

class GreetingServiceImpl extends RemoteServiceServlet
                 implements GreetingService {
   public String greetServer(String input) throws IllegalArgumentException {
      { // let's just throw an error for demonstration
         throw new IllegalArgumentException ("Bad arguments passed");
      }
   }
}

So, the error handling works this way. GreetingServiceImpl captures an error and throws a runtime failure, in our case IllegalArgumentException. So far so good. But, what if we need to throw a different error. Let’s say MyIllegalArgumentException? Well by design (GWT design), we need to declare it on each three RPC methods:

interface GreetingServiceAsync {
   void greetServer(String input, AsyncCallback<String> callback)
            throws MyIllegalArgumentException;
}

@RemoteServiceRelativePath("greet")
interface GreetingService extends RemoteService {
   String greetServer(String name) throws MyIllegalArgumentException;
}

class GreetingServiceImpl extends RemoteServiceServlet
                 implements GreetingService {
   public String greetServer(String input) throws MyIllegalArgumentException{
      { // let's just throw an error for demonstration
         throw new MyIllegalArgumentException("Bad arguments passed");
      }
   }
}

Which is not fun. It’s quite cumbersome. You need to declare the exception on each RPC method in 3 places – the Service, ServiceAsync and ServiceImp classes. To make the matter even worse as long as you have multiple methods and variety of exception types you end up into the “exception over-declaring hell” with methods looking this way myMethod() throws Exception1, Exception2, Exception3, Exception4 (and don’t forget, you need to declare this in three places – 3 RPC classes).

Being curious (and lazy) you may wonder what will happen if:

/* no exception being declared*/
greetServer(String input, AsyncCallback<String> callback)

class AnotherBusinessException extends IllegalArgumentException {
   ..
}
class GreetingServiceImpl extends RemoteServiceServlet
                 implements GreetingService {
   public String greetServer(String input) throws IllegalArgumentException{
      { // let's just throw an error for demonstration
         throw new AnotherBusinessException("Bad arguments passed");
      }
   }

The purpose of this post is to demonstrate interecepting GWT RPC native calls. This would help GWT developers better understand the low level packet communications, as well as help with debugging and and tampering the requests.

The post is based on the GWT 1.6 StockWatcher example. Tools used are:

• Fiddler (a web debugging proxy)
• HTTP4E (Eclipse HTTP RESTful client)

Assuming you successfully downloaded and installed the Google StockWatcher example and set the project into your Eclipse IDE, run the given StockWatcher.launch task.

And the regular hosted mode shows up.

Clicking SEND makes an AJAX call with a response popup being returned back.

So the question is, what kind of call is that GWT “Remote Procedure Call”? A regular XMLHttpRequest call, JSON, XML, binary? To anylize it, we need to intercept the http packets. So, let’s compile the project using the project ANT build.xml task and a fully compiled web project shows up

/StockWatcher
     /war
          __html's and css's__
          /stockwatcher
                 __compiled JavaScripts's__
          /WEB-INF
                 __servlets, libs, classes, etc..__

Deploy the web project to your favourite WEB container. I am lazy and I simply moved the /StockWatcher/war directory to /tomcat/webapps. Alternatively I could have created a WAR, etc.. That’s not important, the point is you need to have the StockWatcher example running on a web server. To test the app, open a web browser and run the URL http://localhost:8080/<the-name-you-gave-for-this-webapp>/

You should see the page bellow:

So far so good. What we want to accomplish is once again, intercept and tamper that native GWT Remote Procedure Call.

Intercepting GWT RPC call

Open Fiddler and attach it to your browser. Run the application again from your browser and Fiddler should list the GET HTTP calls being transmitted to server:

Click the [Send] button again and observe the HTTP call in Fiddler.

Having the RPC call in Fiddler, we want to dissect it, so let’s switch to HTTP4E, so we can replay it. Copy all the headers from Fiddler to Http4e/Headers Editor. Same for the packet body, copy it to Http4e/Body editor. Hit Run.

And Voila. Running the call from Eclipse HTTP client produced exactly the same response we received while intercepting it with Fiddler.

Few things to notice here:

• The response received is gibberish as it is gzipped.
• There are tons of headers being transmitted, but are they really needed?
• The content-type being send is: Content-Type: text/x-gwt-rpc; charset=utf-8, And this is the most important GWT header. Without it GWT Servlet is not happy and errors out.
• Did you notice the Accept-Encoding: gzip. header? Yes, that’s the one that tells the server we are cool with gzip and GWT server gets back with gzip payload. Removing it stripes out the GWT to a bare regular text

Tampering GWT RPC call

Let’s cut the weed headers and leave just the required content-type. What we are aiming is making a successful tampered GWT RPC call.

Eureka! The call returned 200 Success along with the unzipped RPC content. What’s interesting is that the native RPC response format is actually … drum rolls… JSON !!

There is the //OK or //EX prefix to indicate that response was Success //OK, or Error //EX. Other than that, it’s a well formatted JSON.

What we want to do next is,  tamperig the request and pretend we are a JavaScript native GWT client. The idea is to proove that we can fool the native RPC Servlet. So, modify the RPC argument String “GWT User” to “TAMPERED-REQUEST” and run it again.

RPC responds with 200 //OK !

And that’s all folks. For you, I leave the exercise of:

• exporting the HTTP call to Java (HTTP4E/Export-to-Java)
• make an infinite loop
• and use that expertise when bringing your favourite russian server down with DoS attack

Cheers