Create a Flickr Application hosted on the Google App Engine

How I got here

At the start of the last NHL season I got myself an AppleTV to watch the games via my Gamecenter subscription. However, the AppleTV turned out to be much more versatile. Now I am using it also to stream videos from an iPad to the TV, listen to the iTunes Radio and also to watch a slideshow of our family photo library, a feature the whole family loves.

The photos are hosted on Flickr and due to the Flickr API restriction you can have at most 500 photos in the slideshow. This didn't make me happy as our photo library has several thousand pics. I did not find any satisfactory solution on the net so I decided to:

• create an application to periodically generate a random Flickr photo set
• host the application in the cloud to avoid dependency on the home IT infrastructure

In the following I'll describe how I got this done and share the project that contains the working code.

Connecting to Flickr

If you want to get an application work with Flickr (if you only came here because you are interested in the Google App Engine you may jump right to the next section) you have to follow these steps:

1. Register your application in the Flickr App Garden. This will get you an API key and a shared secret that you will need later to make the REST API calls.
2. If your application needs authentication then you also need to obtain authorization from a Flickr account owner. Whether you need authentication depends on what the application is doing. Some Flickr API calls require no authentication - for instance the method flickr.people.getPublicPhotos. The app described herein needs authentication since it creates a photo set in my Flickr account. See Authentication How-To for more information.
3. Make REST API calls to the Flickr API. You will need to sign the requests as described in the above Authentication How-To. You can see the example implementation in the method FlickrService.addSignedParams.

That's it! The application will talk to Flickr and create the desired photo set when the main servlet (PhotosetServlet.java) is invoked.

Hosting the Application on the Google App Engine

Choosing the hosting provider was a no-brainer since the Google App Engine comes with a free plan which is fully sufficient for this Flickr application. It is worth noting that the Google App Engine is a PaaS offering which means it provides the platform that your application runs on. Besides Java, which I chose for this Flickr application, the platform also supports Python, PHP and Go. The platform also supports couple of options for storing data (a proprietary data store, a cloud MySQL database and a large object storage).

If you require a specific infrastructure, like for instance a specific database server, then you should be probably looking at an IaaS offering instead.

To create a Java application for the Google App Engine you simply follow the steps from the Getting Started Guide. Here's a quick overview with links into the corresponding guide sections:

1. Sign up for a Google account (unless you already have one).
2. Create a project from the maven archetype appengine-skeleton-archetype — see Creating the Project.
   Tip: you can also create a project ID later, just before the first deployment to the Google App Engine (see step 5 below).
3. Add the code for your application — see Adding Application Code and UI.
4. Test the application locally using mvn appengine:devserver — see Building and testing the app
5. Deploy your application to the Google App Engine — see Uploading your Application

These are also the steps that I followed to create the photo set application. To enable scheduling I added the cron.xml file and I thought I was done.

Final Hurdle

Soon after the deployment to the Google App Engine I noticed I'm actually not done yet. The app was working fine locally but an attempt to create the same 500 picture photo set on the Google App Engine resulted in a Malformed URL exception. The problem is that the GET request receives the list of the photo IDs in the URL which gets truncated if the list is too long.

I wasn't able to find a solution until I went to Bucharest where I met my friend and former colleague Octavian. He hinted to use a different HTTP client which ultimately solved the issue. Ironically I've just found out while writing this post that according to the Flickr API documentation I should have used a POST request instead!

Conclusion

I hope this post was helpful for you if you are either developing a Flickr application or working with the Google App Engine. Both topics are actually quite big to be covered in a single post. Nonetheless, with the help of the code example and the provided documentation it should be relatively easy to get going - have fun!

Unit Testing Java EE Application with CDI

Java Enterprise Edition has undergone the much needed weight loss treatment in 2006 when Java EE 5 was introduced and it has continued evolving ever since. Today, developing of Java enterprise applications is easier than ever before. However, the rising popularity of Test Driven Development creates new challenges even for the revamped Java EE platform.

Things have improved, of course. Prior to EJB 3.0, there was virtually no other way of testing enterprise beans than actually deploying them in the container and testing them there.

The EJB 3.0 returned back to the roots by turning the enterprise beans into Plain old Java objects (POJOs). This revolutionary idea brings many advantages, one of them is making EJBs readily available to unit testing. You only have to mock the dependencies to the container.

The question arises though, how do you unit tests those parts that directly depend on the container, like the Data Access Objects (DAOs) which use container provided persistence services?

In this post, I will show on an example of a RESTful Web Service project with database persistence how it can be tested end-to-end without ever hitting the application server.

The Project
The example project contains the following RESTful Web Service and DAO to put under (unit) test:

 @Path("/employees")  
 public class EmployeeResource {  
     @EJB  
     private EmployeeDao employeeDao;  
   
     @GET  
     @Path("/{param}")  
     @Produces(MediaType.APPLICATION_JSON)  
     public Employee get(@PathParam("param") long id) {  
         return employeeDao.find(id);  
     }  
     @GET  
     @Produces(MediaType.APPLICATION_JSON)  
     public List<Employee> findAll() {  
         return employeeDao.findAll();  
     }  
     @POST  
     @Consumes(MediaType.APPLICATION_JSON)  
     @Produces(MediaType.APPLICATION_JSON)  
     public Map<String, Long> add(Employee employee) {  
         Map<String, Long> response = new HashMap<>();  
         response.put("employeeId", employeeDao.create(employee));  
         return response;  
     }  
 }  

 @Stateless  
 public class EmployeeDao {  
     @PersistenceContext  
     private EntityManager em;  
   
     public Employee find(long id) {  
         return em.find(Employee.class, id);  
     }  
     public List<Employee> findAll() {  
         return em.createNamedQuery(Employee.FIND_ALL).getResultList();  
     }  
     public long create(Employee employee) {  
         em.persist(employee);  
         return employee.getEmployeeId();  
     }  
 }  

Injecting Dependencies
The above classes are richly annotated. A naive attempt to test the classes with JUnit will succeed to compile but it will fail at runtime with a NullPointerException due to unresolved dependencies to EmployeeDao and EntityManager. So is there a way to resolve these dependencies outside of the application server?
Enter CDI — context and dependency injection. CDI was added in Java EE 6 as a general dependency injection mechanism. With CDI it is possible to annotate references to EJBs with @Inject instead of @EJB:

 public class EmployeeResource {  
     @Inject  
     private EmployeeDao employeeDao;  
 ...  

This solves the DAO dependency nicely. However, the reference to the DAO will still be null because JUnit tests run with Java SE which does not support CDI. By now you can probably guess the central idea of the approach described in this post — to run the tests inside a CDI container instead of an application server. In the example project I use the JBoss Weld CDI container with Apache DeltaSpike which provides an abstraction layer to bootstrapping the container. You can inspect the project's Maven pom.xml file to see the actual library dependencies.
How about the dependency to the EntityManager though? It is defined as a private field in the DAO class and it has to be set outside of the application server. Is there some way to do it, short of breaking the encapsulation?
Actually, the solution is simple if you think of the famous aphorism by David Wheeler:

All problems in computer science can be solved by another level of indirection.

The indirection is implemented, of course, with CDI. The DAO uses an @Inject annotation instead of @PersistenceContext:

 public class EmployeeDao {  
     @Inject  
     private EntityManager em;  
 ...  

The definition of the entity manager in production/application server environment moves to a resource class which defines a CDI producer:

 public class Resources {  
     @PersistenceContext  
     @Produces  
     private EntityManager em;  
 }  

In the test environment an alternative resource class is used:

 @Alternative  
 public class TestResources {  
     @Produces  
     @Singleton  
     private EntityManager createEntityManager() {  
         EntityManagerFactory emf = Persistence.createEntityManagerFactory("hr_test");  
         return emf.createEntityManager();  
     }  
 }  

There are two things to notice about the above class:

1. It is annotated with @Alternative. The alternative needs to be activated by specifying an <alternatives> tag in the beans.xml file. There are two beans.xml files in the example project — one in the production source code base (without <alternatives> tag so the persistence context is resolved using the Resources class) and another one in the test source code base.
2. The above class creates an entity manager factory for the persistence unit hr_test. Alike beans.xml, there are also two persistence.xml files, for production and test respectively, in the example project.

Writing Test Classes
The test classes also use CDI to resolve the references to the classes being tested:

 @RunWith(CdiTestRunner.class)  
 public class EmployeeResourceTest {  
     @Inject  
     private EmployeeResource employeeResource;  
   
     @Test  
     public void testFindAll() {  
         List<Employee> employees = employeeResource.findAll();  
         assertThat(employees.size()).isGreaterThan(25);  
     }  
 }  

Bootstrapping the Container
Since the test classes are managed by CDI they need a custom JUnit test runner (specified with @RunWith) that has two responsibilities:

1. Bootstrap the CDI container.
2. Create instances of test classes using the CDI container.

 public class CdiTestRunner extends BlockJUnit4ClassRunner {  
     static {  
         CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();  
         cdiContainer.boot();  
     }  
     public CdiTestRunner(Class<?> clazz) throws InitializationError {  
         super(clazz);  
     }  
     @Override  
     protected Object createTest() throws Exception {  
         return BeanProvider.getContextualReference(getTestClass().getJavaClass());  
     }  
 }  

Adding Transaction Support
Transaction service is another service typically provided by the application server. In the standalone CDI test environment it is easy to add transaction support using an interceptor. The test methods are annotated with @Transactional and they can also specify whether the transaction should commit or rollback when the test finishes:

 @Test  
 @Transactional  
 public void testCreate() {  
     final long employeeId = 401L;  
     Employee employee = new Employee(employeeId, "PKANE", "PR_REP", "Kane", new Date());  
     assertThat(employeeDao.create(employee)).isEqualTo(employeeId);  
 }  
   
 @Test  
 @Transactional(defaultRollback = false)  
 public void testCreateCommit() {  
     final long employeeId = 402L;  
     Employee employee = new Employee(employeeId, "JTOEWS", "PR_REP", "Toews", new Date());  
     assertThat(employeeDao.create(employee)).isEqualTo(employeeId);  
 }  

 @InterceptorBinding  
 @Target({ElementType.METHOD, ElementType.TYPE})  
 @Retention(RetentionPolicy.RUNTIME)  
 public @interface Transactional {  
     boolean defaultRollback() default true;  
 }  

 @Interceptor  
 @Transactional  
 public class TransactionalRollbackInterceptor {  
     @Inject  
     private EntityManager em;  
   
     @AroundInvoke  
     public Object manageTransaction(InvocationContext ctx) throws Exception {  
         try {  
             em.getTransaction().begin();  
             return ctx.proceed();  
         } finally {  
             em.getTransaction().rollback();  
         }  
     }  
 }  

 @Interceptor  
 @Transactional(defaultRollback = false)  
 public class TransactionalCommitInterceptor {  
     @Inject  
     private EntityManager em;  
   
     @AroundInvoke  
     public Object manageTransaction(InvocationContext ctx) throws Exception {  
         em.getTransaction().begin();  
         Object result = ctx.proceed();  
         em.getTransaction().commit();  
         return result;  
     }  
 }  

Conclusion
That's it. If you want to check the entire example project's source code, you can find it in Subversion or download it as a zip archive.

Bonus Picture
As I was taking a break while writing the example project, our cat leapt on the table and took a sharp look on the source code, as if she was reviewing it. I was lucky enough to have my camera at my fingertips and I captured the moment:

Links

• Bean-Testing von Java EE-Anwendungen mit CDI — this article (in German) describes a somewhat different approach than I have taken here: instead of using the Resource pattern, the authors resolve the dependencies by scanning the classes at runtime and adding the @Inject annotations programmatically.
• Java EE 7 Tutorial: Building RESTful Web Services with JAX-RS
• RESTEasy Hello World Example
• Jboss / Wildfly maven plugin to deploy on localhost/remote server

Display Busy Mouse Cursor with PrimeFaces during Ajax Requests

Today, I want to share a solution for displaying a busy cursor while an Ajax request is active in a PrimeFaces application. The solution is strikingly simple once all the pieces click in, but it took me some good amount of research and try and error, so I decided it is worthwhile to post it here.

The journey starts with a simple CSS which defines the busy cursor:

 // <web-app-root>/resources/css/progress.css
 html.progress, html.progress * {  
  cursor: progress !important;  
 }  

The above is based on this forum post - you may want to check it out for more details or if you wish to use the original solution. The solution I went for is slightly different - it uses JavaScript with the following self-explanatory functions:

 // <web-app-root>/resources/js/progress.js
 var handle = {}  
   
 function on_start() {  
     handle = setTimeout(function() {  
         $('html').addClass('progress')  
     }, 250)  
 }  
   
 function on_complete() {  
     clearTimeout(handle)  
     $('html').removeClass('progress')  
 }  

Note that the progress class is not set immediately when the request starts. I found it very distracting when the cursor "flashes" on short Ajax requests and I decided to change the cursor after a delay of 250 ms only. Of course, you may modify the delay as you see fit (or maybe make it an argument of the on_start function). The clearTimeout call is needed to cancel the delayed cursor change when the Ajax request is completed before the delay expires.

Now to activate the solution you only need to include the following in your JSF page:

 <h:outputStylesheet library="css" name="progress.css" />  
 <h:outputScript name="js/progress.js" target="head"/>  
 <p:ajaxStatus onstart="on_start()" oncomplete="on_complete()"/>  

Final note: for the above inclusion to work you must also have an <h:head/> tag on your JSF page.