David Chandler's Journal of Java Web and Mobile Development

  • David M. Chandler

    Web app developer since 1994 and Google Cloud Platform Instructor now residing in Colorado. Besides tech, I enjoy landscape photography and share my work at ColoradoPhoto.gallery.

  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 223 other followers

  • Sleepless Nights…

    December 2009
    S M T W T F S
  • Blog Stats

    • 1,033,667 hits

Archive for December 4th, 2009

GWT-RPC exception handling gotcha

Posted by David Chandler on December 4, 2009

A few weeks ago, I posted some GWT-RPC serialization gotchas. At first, this looks like a GWT-RPC serialization problem:

SEVERE: [1259963134337000] javax.servlet.ServletContext log: Exception while dispatching incoming RPC call
com.google.gwt.user.client.rpc.SerializationException: Type 'javax.jdo.JDOFatalUserException' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be serialized.

Hmmm, GWT-RPC is probably trying to serialize JDOFatalUserException because one is being thrown somewhere. But why don’t I see it in my logs? I’m catching all RuntimeExceptions in my RemoteServiceServlet and logging a warning with the message.

On closer inspection, I found the warning message just prior to the stack trace; however, it was not clearly associated with JDOFatalUserException because I had used e.getMessage() instead of e.toString().

In the process, however, I discovered that GWT-RPC masks many exceptions. Here is the code in GWT’s RPC.class that actually executes your service method via reflection:

    try {
      Object result = serviceMethod.invoke(target, args);

      responsePayload = encodeResponseForSuccess(serviceMethod, result,
    } catch (IllegalAccessException e) {
      SecurityException securityException = new SecurityException(
          formatIllegalAccessErrorMessage(target, serviceMethod));
      throw securityException;
    } catch (IllegalArgumentException e) {
      SecurityException securityException = new SecurityException(
          formatIllegalArgumentErrorMessage(target, serviceMethod, args));
      throw securityException;
    } catch (InvocationTargetException e) {
      // Try to encode the caught exception
      Throwable cause = e.getCause();

      responsePayload = encodeResponseForFailure(serviceMethod, cause,

Note that the catch block for InvocationTargetException attempts to encode (serialize) the root cause exception to send it back to the client. If this fails, however, as in the case of JDOFatalUserException, RPC throws a SerializationException with no information about the root cause!

Moral: make sure your GWT-RPC service methods catch all RuntimeExceptions and log all the info you need. In light of this, I’ve now beefed up my gwt-dispatch service servlet to log a severe message and print a stack trace.

Posted in Google Web Toolkit | Leave a Comment »

Persisting enums with AppEngine Datastore

Posted by David Chandler on December 4, 2009

Much of Java’s appeal (not to mention JSF, ORM, and GWT with a little help) is the ability to code in terms of rich domain objects such as the enumerated type. My next several blog posts will demonstrate the use of enums throughout a GAE+GWT application, beginning with persistence.

According to the AppEngine docs,  Java enums are not one of the core value types, which might lead one to believe that they’re not supported. However, closer examination reveals that enums are indeed supported by DataNucleus JDO and JPA, which take care of mapping enums to Datastore core value types String (JDO + JPA) or Integer (JPA).


JDO mapping requires no special annotations and persists the enum as a String by name. One of the DataNucleus doc pages (search for “ordinal”) suggests it may be possible to persist by ordinal instead; however, I haven’t found this documented for JDO. Persistence by name is likely better, anyway, as it allows you the flexibility to add new enum values later in any ordinal position.

	public enum ScheduleMethod {RANDOM, FILL, CUSTOM};
	private ScheduleMethod scheduleMethod = ScheduleMethod.RANDOM;

Note that Google does have a unit test for enum persistence in JDO.


JPA mapping requires the use of the @Enumerated annotation, which additionally lets you specify whether to map by name (String) or ordinal (Integer).


Of course, you can always roll your own mapping strategy if for some reason you need special behavior. With AppEngine Datastore, you can persist any object class by making it Serializable or Embedded, although the former has the disadvantage that you can’t use object properties in queries. You can also create a custom enum class and persist the enum by any core value type as in the example below.

	public static enum Frequency
		private int periodDays;

		Frequency(int periodDays)
			this.periodDays = periodDays;

		public int getPeriodDays()
			return periodDays;
		public static Frequency getValue(int i)
			for (Frequency f : Frequency.values())
				if (f.getPeriodDays() == i)
					return f;
			throw new IllegalArgumentException("Invalid frequency period days: " + i);

	private Integer periodDays = Frequency.WEEKLY.getPeriodDays();
	 * Convenience method to get frequency as an enum
	 * @return Frequency
	public Frequency getFrequency()
		return Frequency.getValue(this.getPeriodDays());
	public void setFrequency(Frequency f)

Posted in AppEngine, Java Data Objects | 1 Comment »

%d bloggers like this: