Building a Web Application in Java, Part 2

As I explained in Part 1, I started this project with the Play! framework.  Play! has a lot going for it, and there were some concepts I wanted to retain in a Restlet-based solution.

1. Play! has a very nice templating system for views (aka HTML pages).  Play!'s version is based on Scala, and it allows developers to mix Scala executable code with HTML, CSS, and Javascript.  While I wasn't concerned with maintaining the ability (or the requirement) to work in Scala, I did like the way the views and the code were so well integrated, and I particularly liked the way the views could be composited from separate parts.  For example, the main layout for all the pages could be saved as a kind of master template with a replaceable region for each individual page.  Each page, then, had to define only the portion rendered in this particular region.
2. Play! uses Ebean for Object-Relational Mapping (ORM) of classes to database tables.  I liked how Ebean was relatively light-weight compared with other ORMs I have used in the past.  (Disclaimer: I do not have extensive experience with any particular ORM, but what experiences I do have were not particularly pleasant.)  I also liked how Play! and Ebean dynamically updated the database anytime changes in code required a change to the schema.
3. Play! uses a configuration file to establish URL-to-handler routes.  Routes define how requests for resources are passed to the appropriate controllers in the application by associating an HTTP method with a parameterized URL.  I liked the simplicity and the flexibility inherent in this approach.
4. Play! uses Maven to manage dependencies, and I liked how this made it easy to create and maintain an environment where all of the necessary libraries (including implicit dependencies) are automatically downloaded and installed to the proper locations.
5. Play! applications are able to run stand-alone, using Play!'s own embedded web server, or in the context of another web server like Apache.  While I like the convenience of being able to run the application locally and stand-alone during development and testing, I will eventually need to support HTTPs in a cloud-based environment.

In addition to the above, I like to work with Eclipse, and I wanted to ensure that tests run in Eclipse yield the same results as when run from the command line.  Eventually I plan to configure a Continuous Integration system (probably Jenkins) to build and test the code after every commit.

With these main goals in mind, I downloaded Restlet and got started with "Hello, World!"

Getting a simple application up and running was a breeze, and there are many tutorials and examples, both on-line and in print, to help.  This gave me confidence to begin working towards creating an environment to satisfy my goals.

I'll go into more detail in future posts, but for now here's a quick run-down of my progress:

1. I opted to use Apache Velocity for view templates.
2. I have been able to continue using Ebean.
3. I have found Restlet's URL routing system to be just as easy to use and just as flexible as Play!'s.
4. I was able to configure Maven to work with Eclipse, and I am managing all of my project's dependencies with Maven.
5. I am able to run my project from within Eclipse, from the command line using Restlet's own web server, from the command line using the Jetty web server as the container, and as a war file deployed to a Tomcat server.

So far, running the tests in Eclipse and running them from the command line yield the same results (including Selenium tests involving Javascript, something I wasn't able to accomplish with Play!).  Finally, since I have some prior experience with Jenkins, I do not anticipate any problems moving this project to Continuous Integration.

I will say that I had to overcome several challenges in getting all of the above configured and working properly.  Velocity was straightforward and worked as advertised from the very beginning.  Maven with Eclipse also went relatively smoothly, primarily because integrating the two is fairly well documented on the Internet.  Getting Ebean to work with different databases depending on whether it is run stand-alone or inside the Tomcat server was somewhat difficult.  Getting the application running in Tomcat was not hard, but getting it to properly locate and serve static resources (like images, stylesheets, and javascript files) proved to be the most troublesome aspect of the project so far.