Google App Engine for Java

By now I am sure everyone has heard that Google App Engine has supported Java and this is totally exciting for Java developers including myself.  Not only Java is supported, but one can use JPA to store/retrieve data from Google DataStore.  The current support has pretty much most of what one needs to build a useful Java web based application running on Google App Engine.

The next thing we need is some MVC framework for the presentation tier.  Surprisingly, there is a lot of folks trying to  use Spring MVC and Spring framework.  This seems to make sense because Spring Framework provides both web-tier support and back-send support like JPA integration and transaction management.  Maybe that’s why I haven’t seen many folks using Struts or JSF with Google App Engine.

There is a lot of buzz on google-appengine-java-group forum. Folks are trying out different technologies and exchanging tips and tricks.

As for myself, I ported the JDO Guestbook example to use Spring MVC + JPA and it is working just fine.  Check it out when you get a chance.

From what I have been seeing, the following technologies are working on GAE:

Spring MVC, Tile 2.0.7.

One of the most frustrating things that most folks encountered is that their GAE applications work on their local box and it doesn’t work when running on GAE production.  Most of the time it is related to security issue.  GAE allows a subset of JRE classes and their white list is on their site.

I have an application in mind and I will be busy in the next several weeks developing it.  Stay tune.

Understanding Spring Framework Hierarchical Context

Not many people are familiar with the support that Spring framework has for hierarchical context. The question is why do we need such feature. This feature is useful in the scenario where your product has multiple web applications and all of them depend on a common framework or library. Instead of deploy that framework or library in each web application, you can deploy it in the Tomcat top level class loader, which affectively makes the framework or library available to all web applications deployed in that Tomcat server.

This is when hierarchical context feature comes to the rescue. A very good write up about this feature is at this blog.

How Does Spring Bean Container Dispose Your Beans?

Spring bean container provides a powerful and flexible way to manage Spring bean’s lifecycle. If a Spring bean needs to clean itself up when Spring bean container is gracefully shutting down, it has several ways of specifying that intent. The intrusive and not recommended way is to implement the DisposableBean interface. A better way is to specify a call back method in the bean’s definition using the ‘destroy-method’ attribute. Spring 2.0’s convention over configuration model provides a very convenient way to eliminate the need to specify a call back method at the individual bean level. This new feature allows you to specify a convention at the application level using the ‘default-destroy-method’ attribute of the ‘beans’ XML element and if needed this convention can be overridden at the individual bean level.

So the question is how does Spring bean container knows when to shut itself down? The answer is it depends (I bet you heard that before). A Spring bean container usually is used in two environments: web-based application or standalone Java application. If it is the latter environment, then your application’s initialization step must call the method ‘registerShutdownHook’ of your choice of ApplicationContext implementation (BTW, method ‘registerShutdownHook’ is in the AbstractApplicationContext class). Then you may ask what exactly does the method ‘registerShutdownHook’ do? Apparently the Java JVM has a facility for a Java application to register a call back thread such that this thread will be given a chance to run during the JMV shutdown sequence. So method ‘registerShutdownHook’ calls ‘Runtime.addShutdownHook’ method and passes in anonymous class that extends Thread class and the ‘run’ method implementation contains a single call to a Spring bean container method to perform context closing, which publishes a ‘ContextClosedEvent’ and cleans up the singletons cache. During the singleton cache cleanup process is when Spring bean container will call each singleton bean’s cleanup call back method.

What’s about when a Spring bean container is used in web-based application environment? Does it have to call the same ‘registerShutdownHook’ method? Well, as it turns out, Spring bean container leverages the servlet context call back mechanism through the ‘ServletContextListener’ interface. Typically a Spring powered web-based application uses ‘ContextLoaderListener’ to bootstrap Spring’s root WebApplicationContext and ‘ContextLoaderListener’ implements ServletContextListener interface.

So now you understand how Spring bean container knows when to call your bean’s clean up method, my question is have you ever developed a Spring bean that needs to perform some sort of clean up? If so, what’s does your bean need to clean up?

Web Application Security

I’ve been poking around to learn about web application security framework and frankly I am kind of disappointed. Comparing with the number of open source frameworks for other aspsects of web application i.e MVC, testing, O/R, there aren’t that many security framework. Here is a list of what I have found so far.

1. Acegi Security
2. jGuard

I would interested in hearing your opinion on any these frameworks. If you know of a good security framework, please feel free to share.

I will post my opinion and findings as my journey in searching for a good security framework progresses.