What's up?

I realize that it was a pretty long time that I haven't blogged.

So, you tell me, what's up?

First of all, our Play! talk has been accepted to JavaOne. So Guillaume and I will be speaking in the biggest Java conference ever. We will try to do our best to convert fellow Java developers to try out Play!. Once you tried it, you are addicted so our job is actually easier than other framework ;)

Second, I have just released a new module that I think is really useful (actually I hesitated to provide the functionality per default in Play! so you don't have to enable the module):

http://www.playframework.org/modules/db

In short:

* play db:export will generate a sql script to create your database based on your actual object model

* play db:import will import your database table into your domain model (so it generates java files that extends JPASupport)

It is necessary to enable the module and to configure your database connection in the application.conf file. I think that is pretty simple and that is why it is Play! "compatible".

There are plenty of options for the db:output command, but you need the latest play! version (so play! > 1.0.2.1).

The next step for this module will be to generate diff between the database and the object model automatically.

The obvious next step will then be to merge this module and the DB migrate module. David feel free to fork my module or to contact me ;)

In term of POJO generation, it would also be nice if this module could generates the CRUD controller if asked for. Another feature would be to generate the object model as scala objects.

Under the hood the module uses a modified hibernate tools (so it works with Hibernate 3.5). Hibernate tools uses freemarker to generate files, so I had to modified those as well. I will publish all the sources shortly.

As usual, please report all the bugs on http://github.com/pepite/play--database . Contribution and help are more than welcome :)

And so you know, we are working hard to make play! 1.1 the framework that will allow java developers to be the best web developers. I am currently working on a new binding mechanism where JSON is a first class citizen. More about this subject later...

Read more...

Play! Framework team leader on a JUG tour!

Hi all,

Just a small post to let you know that Guillaume will be on a JUG tour this year. I am myself will try to cover NL and BE. Don’t hesitate to contact me if you wish to have presentation organized.

Here are the dates of the next events he is covering:

• 18 March at the Riviera JUG - Nice Sophia-Antipolis - more information http://rivierajug.org/xwiki/bin/view/Main/201003%2Drestful
• 23 March at the Normandy JUG - eXia / CESI (à Mont Saint Aignan) - more information http://www.normandyjug.org/2010/03/10/7eme-reunion-du-normandy-jug-play/

I am trying to setup the first Play! ground in Holland / Benelux (probably in Rotterdam). Let me know if you are interested.

Happy Play!

Nicolas

Read more...

Upgrading your Play! applications without downtime

You have your Play! application deployed on production. It is a real success and you have loads of users. You are really happy, and, as Play! is quite fast you don't have any performance issue yet :)

However, you are receiving feature requests. Being an Agile developer, you implement them quickly, test them in acceptance and you are ready to let your users enjoy them. But, your web applications is so successful that you don't really want to plan a downtime...

Though choice, new features to keep your users happy or 100% uptime? Well it is quite simple to do both using Play!. This is because Play! is fully stateless.

My Play! web applications always use a front end proxy. Apache being the most popular I will illustrate how to do it with this web server.

The basic idea is to run 2 Play! instances of your web application and let the front end proxy load balance them. In case one is not available, it will forward all the requests to the available one.

Let's start our the same Play! application two times: one on port 9999 and one on port 9998.

I actually copied my application 2 times and edited the application.conf in the conf directory to change the port numbers.

For each web application directory:

play start mysuperwebapp

Now, let's configure our Apache web server to have a load balancer.

In Apache, I have the following configuration:

<VirtualHost mysuperwebapp.com:80>
ServerName mysuperwebapp.com
<Location /balancer-manager>
SetHandler balancer-manager

Order Deny,Allow
Deny from all
Allow from .mysuperwebapp.com
</Location>

<Proxy balancer://mycluster>
BalancerMember http://localhost:9999
BalancerMember http://localhost:9998 status=+H
</Proxy>

<Proxy *>
Order Allow,Deny
Allow From All
</Proxy>
ProxyPreserveHost On
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/
ProxyPassReverse / http://localhost:9999/
ProxyPassReverse / http://localhost:9998/

</VirtualHost>

The important part is balancer://mycluster. This declares a load balancer. The +H option means that the second Play! application is on stand-by. It will take over if the first one fails. This is exactly what I want.

Everytime I want to upgrade mysuperwebapp, here what I am doing:

play stop mysuperwebapp1

The load-balancer then forward everything to mysuperwebapp2. In the meantime I am updating mysuperwebapp1. Once I am done:

play start mysuperwebapp1

And I can now safely update mysuperwebapp2.

Apache also provides a way to view the status of your cluster. Simply point your browser to /balancer-manager to view the current status of your clusters.

Because Play! is completely stateless you don't have to manage sessions between the 2 clusters. You can actually easily scale to more than 2 play! instances. As we have seen, that is really easy to do.

Happy Play!

Read more...