As TomEE is Java EE 6 web profile certified, it supports the following technologies (all via Apache products) out of the box:

• CDI
• EJB
• JPA
• JSF
• JSP
• JSTL
• JTA
• Servlet
• Javamail
• Bean Validation

If you want / need to use JMS or JAX-RS/WS, then there’s an additional distribution called TomEE+ that provides support for these features.

I prefer to use Maven for project management / builds / testing etc which integrates well with NetBeans.

Using NetBeans, you can easily create a TomEE compatible Maven project by creating a new Maven Project from Archetype within the NetBeans New Project wizard.

The “tomee-webapp-archetype” will create a basic Web Application that’s defined and ready to deploy against TomEE.

Within the generated pom.xml file, we can see the important TomEE specific aspects are the use of OpenEJB for the EE api’s

<dependency>
      <groupId>org.apache.openejb</groupId>
      <artifactId>javaee-api</artifactId>
      <version>6.0-4</version>
      <scope>provided</scope>
</dependency>

and the use of the TomEE Maven plugin

<plugin>
        <groupId>org.apache.openejb.maven</groupId>
        <artifactId>tomee-maven-plugin</artifactId>
        <version>1.0.1</version>
</plugin>

Using the TomEE Maven plugin allows the project to be built and deployed to TomEE (without having to download TomEE!). This is useful for building and compiling from the command line. To get Maven to download TomEE, deploy your project to it and then start TomEE up, use the command

mvn tomee:run

Having said that, I prefer to use NetBeans to control running my projects as this provides more advanced features such as hot deployment of JSP/JSF, controlled execution of tests etc.

To run the project from within NetBeans, simply open up the pom.xml from the File | Open Project wizard in NetBeans. NetBeans is clever enough to open Maven projects which then function just like a standard NetBeans project. Select the “Run” option and NetBeans will ask which application server to run the application on. The is no direct support for TomEE, (i.e. you don’t see an Application Server of type TomEE in the NetBeans server configuration page) but since TomEE is based on Tomcat, to define a TomEE server, you just need to create a “Apache Tomcat” server and specify the server location to that of a previously downloaded TomEE instance.

That’s pretty much all that is involved in getting up and running with TomEE and NetBeans. TomEE offers a fast Java EE 6 certified stack that provides for rapid development and deployment of applications, whereas NetBeans 7.3 provides excellent tooling to support TomEE and Java EE development.

It turns out that its easy to add the relevant decryption libraries as this link describes.

From a terminal window, the steps to getting the relevant software installed to play a DVD are:

$ sudo apt-get install ubuntu-restricted-extras
$ sudo /usr/share/doc/libdvdread4/install-css.sh

After executing those commands, you should be able to play DVDs correctly.

When writing an Arquillian test, you create a deployment as in the following code sample:

@Deployment
public static Archive<?> createTestArchive() {
    return ShrinkWrap.create(JavaArchive.class, "test.jar")
    .addClasses(RandomNumberBean.class);
}

It’s not uncommon to see a lot of calls to .addClasses() or .addPackages(). When working with third party libraries, this list of classes/packages added to the archive can grow and grow (and can be a bit of a trial and error process to get a complete list of dependencies). The ShrinkWrap Maven Resolver overcomes this issue by allowing you to specify Maven dependencies in the createTestArchive() method rather than having to add each class/package at a time.

To use the ShrinkWrap Maven Resolver, the first stage is to add the relevant dependency to you Maven project’s pom.xml file.

<dependency>
    <groupId>org.jboss.shrinkwrap.resolver</groupId>
    <artifactId>shrinkwrap-resolver-impl-maven</artifactId>
    <scope>test</scope>
</dependency>

Having configured Maven, you’re ready to go and add dependencies to your Arquillian archive via code as shown in the sample below. In this sample, I’ve added the Apache Commons Math library to the Arquillian archive.

@Deployment
public static Archive<?> createTestArchive() {
    MavenDependencyResolver resolver = DependencyResolvers.use(
    MavenDependencyResolver.class).loadMetadataFromPom("pom.xml");
 
    return ShrinkWrap
        .create(WebArchive.class, "test.war")
        .addClasses(RandomNumberBeanCommons.class)
        .addAsLibraries(
            resolver.artifact("org.apache.commons:commons-math")
        .resolveAsFiles());
}

Looking at the code, you can see that the first stage is to create a MavenDependencyResolver from the project’s pom.xml file. Then all you need to do, is invoke the .addAsLibraries() method on the Arquillian deployment specifying which Maven dependency to resolve.

Hopefully, you can see that this technique allows you to create your Arquillian tests much faster and more reliably than without using the ShrinkWrap Maven Resolver.

“a free, cloud-based application platform for Java, Perl, PHP, Python, and Ruby applications.”

OpenShift uses git to publish files to your site, so the general approach is to make your application locally, commit files to git and then push them to OpenShift. In practice this works very well, but there are a couple of gotcha’s that I encountered – I’ll explain those later.

OpenShift express supports Java (with full AS7 support), Ruby, PHP, Perl and Python apps.

In this post, I’m going to show the steps needed to host WordPress at OpenShift Express.

Installing the client tools
So, the first stage in setting up on OpenShift is to install the OpenShift client tools. On Ubuntu, this is achieved with apt-get

$ sudo apt-get install ruby
$ sudo apt-get install rubygems
$ sudo apt-get install rhc

Creating a domain and an application
After installing the OpenShift tools, the next stage is to create a domain name to host the application in and the application itself.

Creating a domain is achieved with the rhc domain create command.

$ rhc domain create -n <domain> -l <emailaddress>

Where domain is the OpenShift unique domain name for your application and emailaddress is your login email address for OpenShift.

Next, you need to create an application. This is essentially a remote git repository which is cloned onto your local filesystem. When creating an application, you need to specify which “cartridges” you want to use. For WordPress, you will need to use the php-5.3 cartridge.

$ rhc app create -a <appname> -t php-5.3

Where appname is your application name.

If all goes well, your application will now be created and available on the internet at:

http://<appname>-<domain>.rhcloud.com

MySQL Support
The next stage of hosting WordPress on OpenShift is to create a MySQL database. This is again achieved using the OpenShift command tools:

$ rhc-ctl-app -a  "appname" -e add-mysql-5.1

This will give you MySQL support for your application. After running this command, you’ll be supplied details to your MySQL database. To help manage the database, the easiest way I found was to add PHPMyAdmin

$ rhc-ctl-app -e add-phpmyadmin-3.4 -a "appname"

Now that you’ve got PHPMyAdmin installed, a good security practice is to create a MySQL user with the appropriate access rights for accessing WordPress. We don’t really want WordPress running against the admin MySQL account.

Install WordPress
At this point, you’ve created a basic OpenShift PHP application with MySQL support. The next stage is to install WordPress. To install, simply download the latest archive of WordPress and unzip it into the php folder that has been created underneath your appname folder.

After unziping, its tempting to just access the OpenShift application and run the WordPress wizard to create the standard wp-config.php file. Unfortunately if you do this, when you next push your local code to OpenShift, any modifications made on the server will be lost. So, the general procedure is to always make changes locally and then push them to the server. This also applies for installing plugins to WordPress – always install them locally, commit them to git and then push them to OpenShift.

So, to get WordPress up and running, create a wp-config.php file locally within the WordPress installation folder. Its a very straightforward file to create, but check out the WordPress docs for more info.

Pushing to OpenShift
Having created the database configuration file, you can now commit everything to git and push it to OpenShift.

$ git commit -a -m "Initial installation of WordPress"
$ git push

Again, assuming everything has gone OK with no errors, you should be able to access your WordPress site at:

http://<appname>-<domain>.rhcloud.com

Publishing to a custom domain
OpenShift has recently added support to allow applications to be hosted at their own domain names rather than as a subdomain of rhcloud.com

To publish to a custom domain, you need to add an alias in OpenShift for your application to the domain name you want it hosted at.

$ rhc-ctl-app -c add-alias --alias www.somedomain.com -a <appname>

To complete the process, you need to edit your DNS records and add a cname pointing your domain (e.g. www.somedomain.com) to -.rhcloud.com

You should now have a working WordPress installation running on OpenShift

Uploading media to WordPress
One of the side effects of pushing local content to a git repository is that any changes made to the web site are lost when new code is pushed to it. For example plugins installed via the WordPress user interface are lost when you push new code to OpenShift. Also, any images uploaded to WordPress (by default stored in wp-content/uploads) are also lost when you push new code. To overcome this, edit the /.openshift/action_hooks/build file and add the following contents:

if [ ! -d $OPENSHIFT_DATA_DIR/uploads ]; then
    mkdir $OPENSHIFT_DATA_DIR/uploads
fi
   
ln -sf $OPENSHIFT_DATA_DIR/uploads $OPENSHIFT_REPO_DIR/php/wp-content/

Any uploaded data will now be stored outside of the OpenShift git repository and therefore won’t be overwritten each time you push to OpenShift.

Hopefully I’ve shown how straightforward is is to host applications on OpenShift Express. If you’ve got any questions, leave them as comments to the post.

Running this command shows a list of installed Java JDKs and JREs allowing one to be selected as the default that is used when java needs to be executed.

$ sudo update-alternatives --config javac

If you prefer to use a gui instead of the command line, you can execute galternatives instead and define the default versions of software with the following dialog.

$ sudo galternatives