To create client certificates, you need to check if you have openssl installed. After this verification, you need to find where the auxiliary command CA and/or CA.pl is installed. On my Mac  it’s located in “/System/Library/OpenSSL/misc/CA.pl“.

1. First, we need to create a Certificate Authority (CA):

$ CA.pl -newca

After pressing enter, and following some instructions, a new folder “demoCA” is created with our newly created Certificate Authority.

2. Create a certificate signing request:

$ CA.pl -newreq

Follow the instructions to create the certificate signing request. Two files will be created: “Request is in newreq.pem, private key is in newkey.pem“.

3. Sign it with the CA:

$ CA.pl -sign

The signed certificate newcert.pem is generated.

4. Create a client certificate that our user will install in his browser:

$ openssl pkcs12 -export -inkey newkey.pem \
           -in newcert.pem -out clientCertificate.p12

As we can see, we use the private key newkey.pem and the CA signed certificate to create the client certificate.

Now that we have all the certificates created we need to use a tool to save our Certificate Authority that will be verified when someone asks for authorization with a certificate. I prefer to use the “keytool“. Verify that you have keytool command available before you begin:

5. Create a keystore:

$ keytool -genkey -keystore truststore.jks

6. Add CA to keystore

$ keytool -import -trustcacerts -alias "my CA" \
                -file demoCA/cacert.pem -keystore truststore.jks

7. Configure Play! Framework:

Add to the  application.conf file, the keystore configurations:

play.netty.clientAuth=need
keystore.algorithm=jks
keystore.file=conf/truststore.jks
keystore.password=mykeystorepassword

Conclusions:

Inside the keystore, there is the Certificate Authority that will be verified when the client tries to comunicate with the server, using a certificate signed by the CA. This is very helpful if you want to build a web application that is in the Internet, and you just want the people from inside the company to access to it. Off course, the disadvantage of this approach is that if your user steals the certificate, he also can access the application everywhere.

References:

• http://www.playframework.org/documentation/1.2.3/configuration#play.netty.clientAuth
• http://www.ipsec-howto.org/x595.html
• http://shib.kuleuven.be/docs/ssl_commands.shtml
• http://stackoverflow.com/questions/1666052/java-https-client-certificate-authentication

I have been developing in play, and I always feel the need of having a database in memory with test data being loaded each time I run the server. With this approach, I don’t need to have a SQL server running and I don’t need to be worried about changing my database model (for instance, conflict test data), so I just need to change my test data and run the play server again.

The new database manager that playframework uses is called H2. H2 is a Java SQL database which allows to access in-memory/embedded/server databases. In my case, which I use a memory database and I have test data already, I just need to have a line in my Application.conf:

The second thing is to do to access the H2 database manager inside the play is access the http://localhost:9000/@db url (I am supposing that the dev server is running on your localhost). After accessing the database you just need to configure the H2 login like the image:

Now you just need to press the connect button and voilá!

Conclusions:

1. Run your playframework: play run myproject (with the >=1.2 version of playframework)
2. Access http://localhost:9000/@db
3. Configure JDBC URL: jdbc:h2:mem:play (you can access other databases, for instance mysql)
4. Default authentication: username: sa / Password: (empty)

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.

1. After the controller is created (what I do is to copy the controller  “Application” and do a refactor rename to the name I want).

1. Create a file named MyController (what I do is to copy the controller  “Application” and do a rename to the name I want – in this case i chose the name MyController)
2. After this, you need to create a folder with the same name of the controller (in this case: MyController) – app/views/MyController
3. Now in the controller, you’ve to create an index method, where you’ll output data for the user, for instance:

   1. public static void index() {
          List users = User.all().fetch();
          render(users);
      }

   2. Now you need to create a method that will create the file, or get the file somewhere:

      public static void generateMyDocument() {
             File f = new File("myFile.xls");
             //now you've to edit the file, in this is case is an excel file,
             //so you can edit using a library like JExcelAPI

             //set the header with the size of the file
             response.setHeader("Content-Length", String.valueOf(f.length()));
             //set the content type, in this case is a microsoft excel
             response.contentType = "application/ms-excel";
             //send the file to the user
             renderBinary(f);
             //after I send the file, I want to return to the same page (index())
             index();
      }

4. Now we need to create a view, inside that folder we just created (create an index.html file):

   • <a href="@{generateMyDocument()}">Download file</a>

     We are calling the method from the controller. First we have the folder with the same name that will route directly to the method of the controller.Off course that we could do this:

         <a href="@{MyController.generateMyDocument()}">Download file</a>

   And that’s it. The magic on the Play Framework is done .

So, a great way to think out of box is to use those validation features inside the model, that every good MVC Framework has, and don’t trust to much on using hidden fields in the HTML that when changed can affect other users inside the web application. For instance, if you have an hidden field that has the id of the user, and if I change that, I can change others users data.

So, in conclusion:

• You can use cookies and sessions to know which user is authenticated (inside the model you can have the stuff he can do on the web application)
• Don’t trust in the client side. Use always server and client validation

1. Choose the JAR with the drivers according to your oracle’s database version and put in the lib/ directory of your web application
2. Configure your application.conf file,  located inside the conf/ directory
   • In the JPA Configuration Section you have to choose the JPA (Hibernate) dialect. In my case I was working with oracle10g so i had to insert in the configuration file:

     • jpa.dialect=org.hibernate.dialect.Oracle10gDialect

   • Now you just need to add the following lines, according to your database (including username and password).

     • db.url=jdbc:oracle:thin:@yourdatabaseserver:1521:dbname
       db.driver=oracle.jdbc.driver.OracleDriver
       db.user=yourusername
       db.pass=yourpassword

3. Now you just need to restart the server. He adds the database drivers automatically to the classpath of the project.
4. If you want, you can generate Netbeans or Eclipse projects, so you can open this projects with everything configured.

Really easy with no XMLs!

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;
    }
}