How to run the Mojarra automated tests

26 February 2012, by: Arjan Tijms

The JSF RI implementation Mojarra comes with a very extensive test suite. There are some instructions available on how to actually run those tests, such as the entry “How do I run the automated tests?” in the official FAQ and the document “TESTING_A_BUILD.txt” at the root of the Mojarra repository.

Both sets of instructions are not overly detailed and they don’t seem to be entirely up to date either. For instance, the entry in the FAQ states the following:

This target will cause the JSF API and implementation to be deployed to the GlassFish server
that is downloaded as part of the build process

This however doesn’t happen for testing JSF 2.x anymore (there was code that downloaded GlassFish V2 for JSF 1.x, but this can’t be used for 2.x).

The TESTING_A_BUILD.txt document mentions:

Be sure to install glassfish with a password on admin
make sure that password.txt is found in container.home

But how do we install glassfish with a password? If GlassFish is distributed as a .zip there is no install script, and the version with an installer also doesn’t offer any option to specify a password. I guess that there once was an option in the installer for this but it seems to have been removed since. Additionally, the password.txt in container.home appears to be not entirely correct.

After some trial & error I got the tests to run (more or less, read below). For my own reference and in the hope it’ll be useful to someone, I’m jotting the instructions down here.

Download GlassFish 3.1.1 from http://glassfish.java.net/downloads/3.1.1-final.html (I choose the zip archive).

Unzip GlassFish somewhere; we’ll call the resulting directory [glassfish home] below. This will look something like:

glassfish3 <--- [glassfish home]
    bin
    glassfish
    javadb
    mq
    pkg

The tests assume a password is being used, so we're now going to set one:

cd into [glassfish home]/bin and execute the following command:

./asadmin start-domain domain1

On Mac OS X this may take a minute due to a reverse DNS lookup being attempted (there's a fix).

After GlassFish has started, execute the following command:

./asadmin change-admin-password

Press enter twice and enter adminadmin for the password as below:

Enter admin user name [default: admin]> (press enter)
Enter admin password> (press enter)
Enter new admin password> (enter adminadmin)
Enter new admin password again> (enter adminadmin)
Command change-admin-password executed successfully.

Most commands in the test suite that interact with GlassFish use a password file (--passwordfile option), but for some reason not all. For those an additional .asadminpass file is required to be in the home directory of the user as whom the tests are run. This can be created via the following command:

./asadmin login

Press enter once and again enter adminadmin for the password as below:

Enter admin user name [default: admin]> (press enter)
Enter admin password> (enter adminadmin)
Login information relevant to admin user name [admin]
for host [localhost] and admin port [4848] stored at
[/home/youruser/.asadminpass] successfully.
Make sure that this file remains protected.
Information stored in this file will be used by
asadmin commands to manage the associated domain.
Command login executed successfully.

You can shutdown the container now using the following command:

./asadmin stop-domain domain1

Mojarra has recently gone from being distributed as 2 jars to 1 jar. The Glassfish 3.1.1 that you downloaded still uses 2 jars. In the past the test code patched GlassFish, but probably in anticipation of GlassFish shipping with 1 jar this no longer happens. In the mean time, it's necessary to patch GlassFish yourself.

In [glassfish home]/glassfish/domains/domain1/config/default-web.xml and [glassfish home]/glassfish/lib/templates/default-web.xml remove the entries jsf-api.jar and jsf-impl.jar and replace them by a single javax.faces.jar. I.e.:

Replace

jsf-api.jar
jsp-impl.jar
jsf-impl.jar

With

javax.faces.jar
jsp-impl.jar

Make a backup of the resulting [glassfish home] directory now. The test suite occasionally corrupts GlassFish and you often need to restore a fresh version. In fact, to have reliable test results you might opt to use a fresh GlassFish for every test run.

The Mojarra tests depend a lot on Maven, so if haven't installed Maven then install it now. E.g. on Ubuntu:

sudo apt-get install maven2

(This is not needed on OS X, since it already comes with Maven)

Now we're ready to check out the Mojarra source code. I'll assume SVN knowledge here.

Check out: https://svn.java.net/svn/mojarra~svn/trunk

We'll rever to the directory where you checked out those sources as [source home] below. E.g.

 
Mojarra <--- [source home]
    jsf-api
    jsf-ri
    jsf-tools
    [...]
    password.txt
    build.properties.glassfish
    [...]

Prior to starting the tests, a few files need to be customized. First, put the following in [source home]/password.txt:

AS_ADMIN_PASSWORD=adminadmin

Now copy [source home]/build.properties.glassfish to [source home]/build.properties.

Set the following entries in the newly created [source home]/build.properties:

jsf.build.home=[source home]
container.name=glassfishV3.1_no_cluster
container.home=[glassfish home]/glassfish
halt.on.failure=no

For example:

jsf.build.home=/home/myuser/Mojarra
container.name=glassfishV3.1_no_cluster
container.home=/home/myuser/glassfish3/glassfish
halt.on.failure=no

If you haven't already set this up, define JAVA_HOME. This is typically not needed on OS X, but is needed on a e.g. a fresh Ubuntu installation. If you don't do this, Maven will let you think it can't find an artifact from a remote repository, while in fact it couldn't compile some source files.

Additionally set ANT_OPTS to allow more memory to be used. E.g. in Ubuntu (bash):

export JAVA_HOME=/opt/jdk1.6.0_31/
export PATH=/opt/jdk1.6.0_31/bin:$PATH
export ANT_OPTS='-Xms512m -Xmx786m -XX:MaxPermSize=786m'

Now we're *almost* ready to run the build and the test. Unfortunately the Mojarra trunk seems to have a circular dependency between the clean and main targets at the moment. To break this dependency, comment out two ant tasks in [source home]/jsf-test/build.xml (as of writing on line 119):

  1. <!-- ensure the api jar is deployed to the local maven repo -->
  2. <!-- COMMENT THIS OUT:
  3. <ant dir="${api.dir}" target="main">
  4.     <property name="skip.javadoc.jar"  value="true" />
  5. </ant>
  6. <ant dir="${api.dir}" target="mvn.deploy.snapshot.local">
  7.     <property name="skip.javadoc.jar"  value="true" />
  8. </ant>
  9. -->

Now cd to [source home] and execute the following command:

ant clean main

If you're lucky, the build will succeed without failures. Now undo the commenting in [source home]/jsf-test/build.xml, so the file will look like below again:

  1. <!-- ensure the api jar is deployed to the local maven repo -->
  2. <ant dir="${api.dir}" target="main">
  3.     <property name="skip.javadoc.jar"  value="true" />
  4. </ant>
  5. <ant dir="${api.dir}" target="mvn.deploy.snapshot.local">
  6.     <property name="skip.javadoc.jar"  value="true" />
  7. </ant>

cd to [source home] and execute the following command again:

ant clean main

If everything still went correctly, we can now run the tests. There are quite a lot of tests and running the suite till completion took 31 minutes on my 2.93Ghz i7 iMac and 48 minutes on an Ubuntu 11.10 installation running inside VirtualBox 4.1.8 on the same machine. The tests generate a whopping 1.6MB of logging, so if you want to scan it later you might want to divert it to a file:

ant test.with.container.refresh > ~/test.txt

If you want to follow the proceedings of the test run, you can use e.g. tail in a second terminal:

tail -f ~/test.txt

In my case, whatever I tried and however clean my system was, some tests were always failing. E.g. testFormOmittedTrinidad, TestLifecycleImpl, ScrumToysTestCase, AdminGuiTestCase.

Occasionally some tests don't honor the halt.on.failure=no setting that we did in the build.properties files. If this happens comment out the offending test. If you want to test your own changes to Mojarra, make sure to run the test suite a couple of times to get an idea of what tests are already failing for your system. I personally tried a couple of different machines and environments but none of them was able to pass all tests.

Finally, some extra information for Eclipse users. The tests can be run via Eclipse as well. If you initially check out the Mojarra project in Eclipse, you'll see a lot of errors. There are Eclipse project files, but they are obviously outdated (this is fixable, but I'll leave that for a next article). When working with Eclipse, you'll use Eclipse for editing the source code and for navigation (call references, navigate into and such). Even if the Eclipse project files are corrected, the actual compiler output will be thrown away.

To start the ant build via Eclipse, do the following:

Right click on build.xml, click Run As -> Ant Build… Go to the JRE tab and under VM arguments add the following:

-Xms512m -Xmx786m -XX:MaxPermSize=786m

On the same dialog go to the Environment tab and set JAVA_HOME to your installed JDK, e.g.
variable JAVA_HOME, Value /opt/jdk1.6.0_31 (this is not specifically needed on OS X or if you've already set JAVA_HOME globally for your system).

Go to the Targets tab and deselect everything. Then first select clean and then main. The target execution order in the bottom left corner of the dialog should list them in the right order. Having followed the instructions outlined above for command line ant (commenting out entries in [source home]/jsf-test/build.xml) now click Run. Follow the same instructions for restoring the file and again click Run. Finally, deselect both targets and select the test.with.container.refresh target.

Arjan Tijms

4 comments to “How to run the Mojarra automated tests”

  1. Tab Sweep – ArchBeat java EE podcast, Safer JVM with OSGi, building EE artifacts with Maven, WebSocket vs. REST, Mojarra tests, … « oracle fusion identity says:

    [...] (SL.com) • Lyon Jug du 21 février 2012 (Serli contributions to Open Source and GlassFish) • How to run the Mojarra automated tests (Arjan) • WebSockets versus REST? (InfoQ) • Build Java Enterprise Edition artifacts with [...]

  2. Manfred says:

    Arjan, have you tried the new test harness in the test directory of Mojarra?

  3. arjan tijms says:

    Hi Manfred!

    Haven’t run many Mojarra tests after ~a month since writing this article, but I’ll try again soon. Thanks for the pointer.

    One of the biggest problems with getting the ‘old’ tests to run was maybe not really the actual way to run those tests, but really the lack of coherent documentation and the documentation that was there containing some errors. In retrospect it’s all not such a big deal, but when initially trying to run the tests and having no idea where to start it was a little daunting.

  4. How to build and run the Mojarra automated tests (2014 update) | J-Development says:

    [...] comes with over 8000 tests, but as we explained in a previous article, building it and running those tests is not entirely trivial. It’s not that difficult though [...]

Type your comment below:


× five = 5

css.php best counter