Sonatype Nexus2 Repository Manager OSS

To allow for repeatable, faster builds in a continuous build environment, it’s often a good idea to use a central repository to cache common assets and prevent the need to download assets from the internet for each build. Using Nexus allows for those transfers to occur over your local network for previously downloaded assets.

You can download the WAR from:
http://www.sonatype.org/downloads/nexus-latest.war

And install on your Java application server, such as Apache Tomcat, via normal means.

If you are using Maven, you’ll need to make appropriate changes in (/.m2/settings.xml) to direct your builds to use Nexus.

Jenkins and other build automation tools will require similar changes.

REFERENCES:

Code signing of java applets – using Ant

To sign your java assets during the Ant build process, you can add the following to the build.xml to make use of the values we established in the keystore creation step.

Something as simple as the following could be used:

<signjar jar="example.jar" alias="selfsigned" keystore="selfsignkeys.store" keypass="123456" storepass="123456"/>

I generally prefer to add the following:

In build.properties – I externalize the variables…

signing.alias=selfsigned
signing.keystore=selfsignkeys.store
signing.keypass=123456
signing.storepass=123456

Then, in build.xml – a ‘task’ for signing…


<property file="build.properties"></property>
... snip ...
<target name="signwar" depends="war">
<echo message="--- signing ---" />
<signjar jar="${build.dir}/${ant.project.name}.war" alias="${signing.alias}" keystore="${signing.keystore}" keypass="${signing.keypass}" storepass="${signing.storepass}" />
</target>

REFERENCES:

Code signing of java applets – using Maven

To sign your java assets during the maven build process, you can add the following to the pom.xml to make use of the values we established in the keystore creation step.

WARNING: for security and maintainability purposes, you should define the ‘configuration’ items in your local ‘settings.xml’ file instead of in the pom.xml as is done here for example only!


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign</id>
<goals>
<goal>sign</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<alias>selfsigned</alias><!-- ${project.name} -->
<keystore>selfsignkeys.store</keystore><!-- NOTE: you can also specify an absolute path here -->
<storepass>123456</storepass>
<keypass>123456</keypass>
</configuration>
</plugin>

REFERENCES:

Code signing of java assets – creating a keystore

This is generally done via the command line, though I’ve seen it done with Ant in some cases. Here are the specifics… you’ll want to change the passwords and likely take a look at the algorithm (RSA for this example and validity (365 days in this example) for your actual use.

Background, in order to sign your java assets, you will first need to generate a key. You can later get this verified by a CA (Certifying Authority) as needed, this example is selfsigned.

NOTE: I’ll use these example values in the Maven and Ant signing code examples to follow.


keytool -genkey -keyalg RSA -alias selfsigned -keystore selfsignkeys.store -storepass 123456 -keypass 123456 -validity 365

REFERENCES:

Maven build script for replacement of text in web.xml (and others)

Automated replacement of BUILD_LABEL token in web.xml <description> with Maven. For JAR’s the replacement is commented out, but can be any file.

NOTE: This proves to be rather difficult to do because of the way that Maven copies resources as it’s building the WAR. The most reliable manner I’ve found (so far) is below, it works by making a .tmp copy of the web.xml in a different path and then later uses it in the WAR.


<plugins>
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.3</version>
<configuration>
<quiet>false</quiet>
</configuration>
<executions>
<execution>
<id>replaceBuildLabel</id>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
<configuration>
<file>${basedir}/src/main/webapp/WEB-INF/web.xml</file>
<outputFile>${project.build.directory}/web.xml.tmp</outputFile>
<replacements>
<replacement>
<token>BUILD_LABEL</token>
<value>Maven-${maven.build.timestamp}</value>
</replacement>
</replacements>
<regex>false</regex>
<quiet>false</quiet>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.5</version>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
<webXml>${project.build.directory}/web.xml.tmp</webXml>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
<manifestEntries>
<url>${project.url}</url>
<Build-Label>${maven.build.timestamp}</Build-Label>
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>

Most importantly, you will want to have this token in the web.xml file for replacement, the description line is best used for this as such:

<description>ExampleWAR [BUILD_LABEL]</description>

during the build, that value would be replaced to something like:

<description>ExampleWAR [Maven-20141015-1700]</description>

REFERENCES:

Ant build script for replacement of text in web.xml (and others)

Automated replacement of BUILD_LABEL in web.xml <description> with Ant. For JAR’s the replacement is commented out, but can be any file


<replace file="${webapp.dir}/WEB-INF/web.xml" token="BUILD_LABEL" value="Ant-${DSTAMP}-${TSTAMP}" />
<war destfile="${jar.dir}/${ant.project.name}.war" webxml="${webapp.dir}/WEB-INF/web.xml" compress="true">

Most importantly, you will want to have this token in the web.xml file for replacement, the description line is best used for this as such:

<description>ExampleWAR [BUILD_LABEL]</description>

during the build, that value would be replaced to something like:

<description>ExampleWAR [Ant-20141015-1700]</description>

REFERENCES:

jboss-web.xml

If you support code for multiple java application servers, you might eventually encounter a file named:


/webapp/WEB-INF/jboss-web.xml

JBoss uses this file to control the path of the web application, whereas Tomcat generally uses the filename of the WAR itself.

Usually, the contents are pretty sparse, you might consider adding one to your projects should you ever wish to deploy them on JBoss:


<jboss-web>
<context-root>example</context-root>
</jboss-web>

NOTE: There are several other attributes that can find their way into this file for JBoss, notably security configuration, like JAAS.

WARNING: Unfortunately, I’ve tried to add a simple DOCTYPE jboss-web and XML preamble to this, file to make it validate, but the server (JBoss 5.1.x) fails to recognize them.

Problems uploading/deploying large WAR’s to Tomcat7?

I’ve run into this a few times as my web applications got larger. Often this has been seen when builds automated by Jenkins start failing as they increase in size. It has also occurred to me when doing manual deployments as the Jenkins WAR itself is larger than 50MB lately.

Let’s just go in and increase the maximum expected file size…

This change should work on any platform, but the following is from my experience with Ubuntu.

sudo vi /opt/tomcat7/webapps/manager/WEB-INF/web.xml

Default is:

<multipart-config>
<!-- 50MB -->
<max-file-size>62428800</max-file-size>
<max-request-size>62428800</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>

Change to something a bit larger (to your liking):

<multipart-config>
<!-- 50MB max 62428800, 100MB = 104857600 -->
<max-file-size>104857600</max-file-size>
<max-request-size>104857600</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>

Restart with either…
sudo /etc/init.d/tomcat7 restart
or
sudo service tomcat7 restart

Enable larger file uploads via Tomcat manager

Shortly after I automated code deployments in my Tomcat7 development testing environment, I found that some larger builds began failing with the following error:


org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (...) exceeds the configured maximum (62428800)

After a little digging, I found that the WAR files were exceeding the default maximum upload size, thankfully, this is trivial to increase.


sudo vi /usr/share/tomcat7-admin/manager/WEB-INF/web.xml

(Change 52428800 to a larger number, perhaps doubled like 104857600)

<multipart-config
<!-- 50MB max = 52428800 (100MB = 104857600) -->
<max-file-size>104857600</max-file-size>
<max-request-size>104857600</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>

REFERENCES:

Browser Performance/Capability Benchmark Testing

In the past few years the browser wars have heated up again. Performance and capabilities of some browsers varies greatly. There are several standard tests that are publicly available to benchmark your systems. WebKit (Safari, Chrome & Chromium) and Mozilla (Firefox) based browsers, as well as Opera perform pretty well, MSIE is currently trailing in most cases.

Here are a few common ones…