Initial version of JSON-RPC 1.1 over HTTP for GWT

The implementation is as close to the JSON-RPC 1.1 working draft
as possible, while retaining a simple code base in both the GWT
client and the Java based server.

To use this module, build the JAR, place it into your classpath
and inherit the module:

  <inherits name='com.google.gwtjsonrpc.GWTJSONRPC'/>

Signed-off-by: Shawn O. Pearce <sop@google.com>
Allow JsonServlet to service methods from a non-subclass

This permits applications to develop their implementations as derived
from java.lang.Object, possibly allowing the implementation to also
be compiled by the GWT compiler for execution on the client, such as
in an offline mode supported by Google Gears.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Silence compile warning about unchecked cast in JsonServlet

Signed-off-by: Shawn O. Pearce <sop@google.com>
Upgrade to gson 1.2.3

Signed-off-by: Shawn O. Pearce <sop@google.com>
Make the HttpServletRequest,Response available during a service call

Some JSON service implementations may need the request or response
objects to read or set cookies.  Making them available through a
ThreadLocal gives efficient per-request global variables.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Implement a generic client and server side cookie access

This way cookies can be read by code from either side.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Refactor XsrfUtil to be a general token signing service

By making the utility a general token signing service we can reuse
it in other applications to sign other data, such as user identity
cookies.

The protected information used to create the token is left clear-text
at the end, as it is assumed that data is already available through
standard HTTP transport information, or is needed on the client side
in JavaScript (where general decryption algorithms aren't available).

XsrfException is now public so applications can catch and handle
any errors thrown by SignedToken's methods.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Expose the signed value of a cookie to application code

Within GWT we cannot validate against a forgery, so we trust that
the cookie stored in the browser cache is correct.

On the server side we have access to the private key and can verify
the cookie before returning its data.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Refactor JsonServlet's service startup to be easier to override

We now do the service handle init before the xsrf init, allowing
the service handle init to possibly populate information used in
the xsrf init code path.

We also allow the service handle init to throw any checked exception,
turning into a servlet exception.  This makes it easier to write
service factory methods.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Refactor Shared to be JsonUtil and expose a proxy binding function

The new JsonUtil.bind() can be useful after GWT.create to connect the
client proxy to the designated URL.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Support bi-directional JSON serialization of java.sql.Date, Timestamp

Signed-off-by: Shawn O. Pearce <sop@google.com>
Add cookie removal to CookieAccess

Signed-off-by: Shawn O. Pearce <sop@google.com>
Refactor the JsonServlet to make the current ActiveCall available

This permits extensions to subclass the ActiveCall and insert their
own data, especially as a cache for information within the request.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Change the time field of the XSRF tokens to be in 5 second units

Since our field is only 32 bits dividing by 5 gives us well past
2038; we should have time through the next 180 years.  We don't
need time granularity smaller than 5 second intervals as users
just cannot make requests that quickly.  We might also be based
on a server farm, where requests are round-robin distributed and
there is several seconds of clock skew between the servers.  A
5 second token would generally be too short in such an world.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Replace tokens only when they are at least 1/2 expired

This way we save CPU resources on the server by not creating new
on every request.  Instead we validate the current token and we
keep it in place until it is at least 1/2 expired.  Since any of
the XSRF tokens are likely to have a 12-24 hour time window this
means we will only produce a new token once or twice a day per
user, cutting our per-request costs.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Fix spelling of ServletCookieAccess class name

Signed-off-by: Shawn O. Pearce <sop@google.com>
Fix a missing println formatting error in generated serialize code

Signed-off-by: Shawn O. Pearce <sop@google.com>
Don't include comma generation in printJson if there is only 1 field

Its completely unecessary code if we can only ever print one field.
GWT's compiler might actually be able to strip this for us, but
why take the chance when we know up front this is dead code.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Push null handling for JsonSerializer.printJson to the caller

When outputting a JSON object we try to avoid putting a field
into the object dictionary if the field's value is null.  As
such the caller of any serializer has already done the "is it
null" test and handled the result of that decision, so we are
only wasting CPU time by putting it into the serializer's own
printJson method too.

However this means we must handle null at the parameter level
for any proxy methods.  Which is pretty easy to do since its
only a small if test around the argument.

Signed-off-by: Shawn O. Pearce <sop@google.com>
Implement support for Java 5 enums in JSON encoded objects

Signed-off-by: Shawn O. Pearce <sop@google.com>