play war myapp -o myapp.war

Now to deploy on JBoss, you need to do some changes on your WAR file:

• Create a file called jboss-web.xml in the myapp.war/WEB-INF/ directory container the following:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">



com.example:archive=myapp.war
java2ParentDelegation=false

• Download hibernate-validator and hibernate annotation using the compatibility matrix (Hibernate Compatibility Matrix). Play is using hibernate core 3.3.2 GA. Once you are done, place the relevant jars in the myapp.war/WEB-INF/lib directory. You should end up with:
  • hibernate-annotations.jar
  • hibernate-entitymanager.jar
  • hibernate-validator.jar
  • hibernate-commons-annotations.jar
  • hibernate-search-3.1.1.GA.jar
  • hibernate3.jar (Do not overwrite this library, as Play! has a modified version of it)
• Now that we’re prepared for WAR, you need to move your application to the deployment folder of JBoss. The default folder for it is: jboss_home/server/default/deploy (jboss_home == folder of jboss). There are some things you need to be aware of:
  
  1. Use a superior java version in JBoss to avoid class version errors
  2. Verify that the WAR folder has the necessary permissions. In my case I needed to make a “chown -R jboss myapp.war” where jboss is the user that controls the jboss application server
  3. Do a “tail -f jboss_home/server/default/log/server.log” to see if your application is being deployed. You’ve an Administration Console in http://yourserverip:8080
  4. Don’t change your routes file at runtime. Stop the war, change routes and then start the war (in the administration console I said before)
     
• Now you should have your application working. You can access to your app at: http://yourserverip:8080/myapp.war
• This tutorial was tested in JBoss 5.0.1
  

Thanks to Nicolas Leroux from lunatech.com for helping me to create this tutorial.

In every checkbox element I want to send a post message to my Play Framework.

jQuery.each($(':checkbox'), function() {
    $.post('@{myPlayMethod()}', { itemValue: $(this).val() })
});

This code sends the html element value property to method “myPlayMethod(String itemValue)“.

What about dividing this network application in two layers? One layer, with all the network code and the top layer with only the GUI? How is this possible? Using Java interfaces and the notion of events.

We can start by creating our event interface that will be waken up, when for instance we are receiving a message from the network:

public interface EventNetworkInterface {
	void receiveMessage(String msg);
}

Now it’s time to build our simplified network layer:

public class NetworkLayer {
	EventNetworkInterface gui = null;

	public NetworkLayer(EventNetworkInterface gui) {
		this.gui = gui;
	}

	public void receiveMessageNetwork() {
		//simulates receiving a message from the network
                String msg_received = "Hello World!";
		//wake up event in the GUI
		gui.receiveMessage(msg_received);
	}
}

Now with the network layer created you have to create the GUI:

public class GUI implements EventNetworkInterface {

	public static void main(String[] args) {
		new GUI();
	}

	private NetworkLayer nl;

	public GUI() {
		nl = new NetworkLayer(this);
		//issue a receiveMessage event:
		nl.receiveMessageNetwork();
	}

	@Override
	public void receiveMessage(String msg) {
		System.out.println("I sent the message: " + msg);
	}

}

In the GUI constructor we are simulating a receivedMessage event after we build the network layer and send the GUI that implements the events that will be waken up when a receiveMessage (in this case) happens.

With this approach you can separate the design code, from the processing code and simplify when you are adding more features to the layers beneath you.

If you want to have multiple classes to execute the same events, see more about the observer pattern.

public static Singleton getInstance() {
    if (uniqueInstance == null) {
       uniqueInstance = new Singleton();
    }
    return uniqueInstance;
}

In this code snippet, if you have a multithreaded application that executes the same class, some concurrency problems can occur. For instance if the two threads accesses to the condition at the same time, creates two different Singleton instances. How can you fix this problem? Newer virtual machines (like JVM 1.5) ensures this when you create the Singleton instance in a static variable outside of any method. The JVM guarantees that the instance will be created before any thread accesses the static uniqueInstance variable. The solution for this is:

public class Singleton {
    private static Singleton uniqueInstance = new Singleton ();

    private Singleton() {}

    public static Singleton getInstance () {
       return uniqueInstance;
    }
}