Oracle Java and update-alternatives

Environment: Ubuntu 14.04

The Linux alternatives system is an excellent way to install and use different program equivalents. If you update Oracle Java quite often (or even once), it can be a tedious task installing new links and removing any old ones.

Since I always install the JDKs in the /usr/lib/jvm directory with the pattern jdk* (eg /usr/lib/jvm/jdk1.8.0_20), this can make it easy for a script to find all of the JDKs. The script shown below will search for all of the JDKs in /usr/lib/jvm and allow you to install or remove all of the programs in the JDK’s bin directory into the alternatives system.

The syntax is:

to install a JDK and

to remove a JDK.

The script will show the list of JDKs and prompt as to which JDK it should perform the install or delete. Selecting the number corresponding to the JDK and hitting Enter will start the operation.

Send message with SSL or STARTTLS using Java Mail

This note explains how to send an e-mail message using JavaMail, including using an SSL connection or the STARTTLS built-in security.

This note applies to:

  • Java version 1.7
  • JavaMail version 1.4.1

If using Maven, the JavaMail artifact can be obtained using the following dependency:

Often, a properties file is loaded to configure the SMTP transport layer. This allows a user to configure outgoing mail server without having to change the code. Here is a code excerpt to obtain a session and

Plain Text

For plain text access to the SMTP service, the following properties can be used:

STARTTLS

For sending a message using the STARTTLS built-in security, the following properties should be used:

SSL

For sending a message using SMTP over SSL, the following properties should be used:

Debugging

There is a property which sets the “debug” mode for JavaMail. It can be set with the following properties:

Uploading a Maven generated application on Google AppEngine

This note is written based on:

  • appengine-java-sdk-1.2.6
  • Apache Maven 2.2.1
  • Apache Ant 1.7.1

If you create an application destined to Google AppEngine using Maven, the use of the Google AppEngine SDK may not be optimal. This is because, in some instances, the generated artifact (a WAR file) is not what is expected from the SDK. In general, when generating a WAR file using Maven, an interim directory is created with all the files found inside the WAR archive. This interim directory is the expected input for the AppEngine SDK.

However, there are circumstances where an interim directory is not created. Using the Cargo Plug-in for Maven and generating an Uberwar is one example where the generated artifact does not naturally produce the needed interim directory. I find Cargo useful to build Google Wave Robots that include their own gadgets. Since Google Wave Robots must currently be hosted on Google AppEngine, I needed a script to load them automatically.

This note introduces an ANT script that unpacks the WAR file and upload the application on Google AppEngine. Two files are needed:

  • build.xml This is the script that uploads the application
  • build.properties This file includes user specific information

build.xml
Create a file called “build.xml” in the root directory of the Maven project. The content of the file should be as follows:

build.properties
Create a file called “build.properties” in the same directory as “build.xml”. The content of that file should look like:

The content of the file above should be adjusted to reflect the user’s specific SDK installation, appengine user name and password.

Running
After the files are configured correctly, uploading the application to AppEngine should be done with the following command, executed from the root directory of the project:

Setting up Apache Tomcat for Upgrades

Plan for Change.

Note: This article is based on Apache Tomcat 6.0.20

If you set up a lot of Tomcat sandboxes, here is a sample structure to make it easy to upgrade to a new version of Tomcat without having to reinstall all applications. The trick is to have a number of Tomcat sandboxes pointing to a symbolic link, which in turn points to the latest version of Tomcat.

Download Tomcat

Get latest version of Tomcat from Apache. Check signature. Decompress. Untar.

Now create a symbolic link to this latest version

Create a sandbox

A sandbox refers to a directory where you are testing a web application. Portions of the sandbox are linked back to the latest version of Tomcat. Other portions of the sandbox are original to it.

To add a WAR file to Tomcat, simply copy it to the tomcat.sandbox/webapps directory. It will be auto detected when Tomcat starts and deployed.

Finally, start Tomcat.

Obviously, there is more to configuring and running Tomcat. You can get more information by starting at the Tomcat Homepage.

Upgrading

When a new version of Tomcat becomes available, repeat the first step. Download, verify, decompress and untar the latest version, alongside the first version. Then, change the symbolic link of latest Tomcat to the new one.

Now, all sandboxes are pointing at the latest libraries. Restart all sandboxes.

Unless major changes have occurred in configuration files, this trick should let you upgrade painlessly.

Setting up Jetty for Upgrades

Plan for change.

Note: this article refers to Jetty-7

If you set up a lot of Jetty sandboxes, here is a sample structure to make it easy to upgrade to a new version of Jetty without having to reinstall all applications. The trick is to have a number of Jetty sandboxes pointing to a symbolic link, which in turn points to the latest version of Jetty.

Download Jetty

Get latest version of Jetty from http://www.eclipse.org/jetty/downloads.php Check signature. Decompress. Untar.

Now create a symbolic link to this latest version

Create a sandbox

A sandbox refers to a directory where you are testing a web application. Portions of the sandbox are linked back to the latest version of Jetty. Other portions are copied from the latest Jetty. Finally, some portions of the sandbox are original to it.

At this point, we must configure the sandbox. There are two steps to adding a WAR file:

  1. Copy WAR file to jetty.sandbox/webapps
  2. Create a context file (.xml) located in jetty.sandbox/contexts to enable application. Look at jetty-7-latest/contexts for inspiration.

Finally, start jetty.

Obviously, there is more to configuring and running Jetty. You can get more information by starting at the Jetty Homepage.

Upgrading

When a new version of Jetty becomes available, repeat the first step. Download, verify, decompress and untar the latest version, alongside the first version. Then, change the symbolic link of latest Jetty distribution to the new one.

Now, all sandboxes are pointing at the latest libraries. Restart all sandboxes.

Unless major changes have occurred in configuration files, this trick should let you upgrade painlessly.

GWT Module using Maven

Note, this discussion is based on:

  • GWT libraries 1.6.4
  • Apache Maven 2.2.1

I like Maven because it makes me much more productive. It takes care of a lot a project management details and makes the code saved in my repository smaller. When it comes to creating GWT modules (reusable libraries), I was hoping that I could use Maven to keep track of dependencies between applications and modules, as well as dependencies between modules. This discussion presents what is needed to make a GWT module in a Maven project.

There are two important points to remember when making a GWT module using Maven:

  1. The produced JAR file must contain a module file (*.gwt.xml)
  2. The produced JAR file must contain the source files needed in the module. This is because these source files must be compiled in the context of the application.

Maven Project

The first step is to set up a normal Maven project to produce a JAR file artifact.

This command will generate two java files called App.java and AppTest.java. You can delete them.

In an example:

Modules must be compiled using Java 6, therefore the pom.xml file must be modified accordingly. Edit the pom.xml file

and add the following content at the appropriate place:

Module File

A module file is required. In Maven, this file should be in the resource directory. Create a module file in the usual resources directory with an appropriate name and an extension of .gwt.xml

Use the following content as a starting point for the module file:

There is nothing else required in the module file. Note that the name of the module is “Module0”, in the global name space. If one wants to use a longer name space such as “com.example.Module0”, then the full modulfe file name would be: “src/main/resources/com/example/Module0.gwt.xml”.

Since the Java source files for the module are to be located in a subdirectory of the module other than the standard “client” subdirectory (in this case, the name of the directory is “gwt”), one must add a “source” directive to the module file, as such:

Include Source Files in JAR artifact

As stated above, source files must be added to the JAR artifact. Therefore, the pom.xml file must be augmented to include the source files as well as the standard resources directory. Edit pom.xml and add the following:

Test JAR generation

For example, create a Bean class to test:

with the following content:

Now, generate artifact:

You can verify the content of your JAR artifact:

Note that the module file, the source and compiled version of the class are included.

Include Module in an application

To include the new module in an application or another module, two steps are required:

  1. Add a reference to the module file in the upstream application/module.
  2. Add the module JAR as a dependency of the upstream application/module.

Edit the GWT module file (.gwt.xml) in the upstream application/module and add the following directive:

Do not forget to put the fully qualified name, including the name space, if required.

If the upstream application/module uses Maven, then adding the module as a dependency is simple. Edit the pom.xml file in the upstream project and add the JAR artifact produced by the module:

Create a module with GWT Widgets

In the module, if one wishes to create GWT widgets, then one must include the core Web toolkit module from GWT. Two steps are required:

  1. Add dependency in the module file
  2. Add dependency in the Maven pom.xml file.

Edit the module file

and add the following directive:

Then, edit the pom.xml file

and add the dependency

Set up GWT application with Maven

This demo is based on:

  • GWT libraries 1.6.4
  • Apache Maven 2.2.1
  • GWT Maven plugin 1.1

Before you start your GWT application, you need to figure out:

  • Package and name of your module, e.g. org.package.Module. In the example, ‘org.package’ is the package name; ‘Module’ is the module name; and, ‘org.package.Module’ is the full module name.
  • Maven group and artifact id for your application

To create a GWT application using maven, use the following recipe:

1. Create regular WAR project/module, using Java 1.5 or above.

1.a. Using maven create module

> mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=<group-id> -DartifactId=<artifact-id>

1.b. Use Java 1.5. Edit the pom.xml file created in the previous step and add:

2. Edit pom.xml:

2.a. Add maven GWT plugin

2.b. Add desired version of GWT as a property

2.c. Add dependencies on needed libraries

3. If a web.xml file was not created during module creation, then you must provide one. This is necessary to create a WAR module. In /src/main/webapp/WEB-INF/web.xml :

*** At this point, you have a GWT maven module.

> mvn package

will create a WAR file. However, no GWT code is generated. ***

4. Create a GWT module file. A module file is a XML file with a name that ends with ‘.gwt.xml’. In Maven, the GWT module file is a resource, therefore it must be located under /src/main/resource. One has to determine the location of the file from the package name. Therefore, if the fully qualified name of the module is ‘org.package.Module’, then one needs to create a file called ‘/src/main/resource/org/package/Module.gwt.xml’.

The location of the module file in relation to the entry point class is important. Consistency is really important in the names.

You have to adjust the values in the file: JS_DIR, ORG.PACKAGE.client.MainView and STYLE.css. Those values are dependent on your installation.

JS_DIR is the directory in the WAR structure under which generated files will be located.

org.package.client.Main is the name of the entry point class. (See point below)

STYLE.css is the style sheet used. This is a stylesheet added to page when the entry point class is run. This file should be found in the ‘public’ portion of the application. It is packaged with the generated javascript files by the GWT compiler.

5. Create a public directory. Under the resource directory that contains the module file, create a sub-directory called ‘public’. In this directory, put the resource files that need to be accessible by the application. For example, style sheets and images can be placed there. Files located in the public directory are copied in the generated directory by the GWT compiler.

6. Create a GWT entry point class. A GWT entry point class defines the mainline of a module. This is written in Java. Therefore, the file defining the entry point class must be located under /src/main/java. All Java files destined for the client GUI must reside in a sub-package of the module called ‘client’. Therefore, if one wanted to name the entry point class ‘Main’ for the ‘org.package.Module’ module, the the fully qualified name for the class would be org.package.client.Main. Therefore, one would create a file named ‘/src/main/java/org/package/client/Main.java with the following content:

*** At this point, the maven GWT plugin should be generating javascript code from the java source code. A number of files can be found here:

…/target/${project.name}/JS_DIR

Opening the war file, the same generated scripts should be found under …/JSDIR

***

7. Create an HTML file that uses the generated scripts. Under the directory …/src/main/webapp, create a file called “index.html” with the following content:

Above, you need to adjust the values for JS_DIR, as specified in previous points.

*** At this point, you have a complete GWT application. The WAR file is generated by:

> mvn package

The generated WAR file can be deployed on a servlet container (Tomcat, Jetty, etc.) The web.xml file specifies to load index.html as default, and index.html loads and runs the generated javascript module.

***

The complete directory structure is