Beware what you put in the endorsed dir!

We use docflex to build our XSD documentation, integrating with maven to produce XSD documentation in our maven site reports.

I recently had to upgrade some developers from docflex-re 1.8.0 to 1.8.5, this migration went fine.

For some reason it didn’t on my machine.

I received the following error:

java.lang.NoClassDefFoundError: org/apache/xml/resolver/CatalogManager

Anyway to cut a long story short it transpired that about a year ago whilst working on another project I had changed the jdk’s xerces jar by placing

  • xalan.jar
  • xercesImpl.jar
  • xml-apis.jar
  • serializer.jar

in the jre/lib/endorsed directory and completely forgot about it.

Removing these jars (which were probably older versions and I didn’t need in there anyway) and everything works fine.

I’d imagine putting a new version of xerces in endorsed would probably fix this as well….

Upgrading to Maven 3 Site Reporting

Whilst upgrading our build to use maven 3.0.3 and the reporting to use the maven-site-plugin 3.0-beta-3 I used the following steps to upgrade the reporting.

When I ran the build it failed

With the message


Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site
(default-site) on project webapp: failed to get Reports: Could not find goal
'index' in plugin org.jvnet.mcvp:maven-css-validator-plugin:1.0.0-SNAPSHOT
among available goals report, validate -> [Help 1]

The plugin I was using (a version of the maven css validation plugin that I have modified to generate reports) was defined in the maven 3 build as follows

....
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-site-plugin</artifactId>
    <version>3.0-beta-3</version>
    <configuration>
        <reportPlugins>
         ....
            <plugin>
                <groupId>org.jvnet.mcvp</groupId>
                <artifactId>maven-css-validator-plugin</artifactId>
                <version>1.0.0-SNAPSHOT</version>
            </plugin>
         .....
        </reportPlugins>
   </configuration>
    ....
</plugin>

When the plugin was configured under maven 2 (using the legacy reporting i.e. being in a <reporting> tag) it ran fine.

The fix

The last part of the exception states: among available goals report, validate

The “report” goal creates the report therefore modifiynig the pom so it specifies the “report” goal in a report set seems to work.

....
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-site-plugin</artifactId>
    <version>3.0-beta-3</version>
    <configuration>
        <reportPlugins>
         ....
            <plugin>
                <groupId>org.jvnet.mcvp</groupId>
                <artifactId>maven-css-validator-plugin</artifactId>
                <version>1.0.0-SNAPSHOT</version>
                <reportSets>
                    <reportSet>
                            <reports>
                                <report>report</report>
                            </reports>
                    </reportSet>
                </reportSets>
            </plugin>
         .....
        </reportPlugins>
   </configuration>
    ....
</plugin>

I assume that the Could not find goal ‘index’ portion of the error means that if I set the name of the goal to index perhaps the reportsets are not necessary?

Update: Changing the goal to “index” does indeed remove the need for the reportsets, however for legacy plugins you may not be able to modify the source code!

Another thing to note is that this plugin uses the Maven Anno Mojo

e.g.


@MojoGoal("index")
@MojoPhase("site")
public class CssReportingMojo extends AbstractMavenReport {

But I dont think this has anything to do with error.

I hope this is useful to anyone upgrading as I couldn’t find any info on this exception out there

Using maven to check facelets are valid

Although eclipse validates our xml documents, sometimes invalid xml documents can get committed into our source repository by accident.

Using the maven xml-maven-plugin we can force the build to break when xml documents aren’t welformed.

Currently we are only doing it for facelets files (with a .xhtml extension): The xml snippet below shows the configuration of the plugin for xhtml files.

Add this to the plugins element in the build section.

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>xml-maven-plugin</artifactId>
	<executions>
		<execution>
			<goals>
				<goal>validate</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<validationSets>
			<validationSet>
				<dir>src/main/webapp</dir>
				<includes>
					<include>**/*.xhtml</include>
				</includes>
			</validationSet>
		</validationSets>
	</configuration>
</plugin>

To Do:

Really we should be validating all xml files. Also we should investigate turning on schema validation, especially for facelets files.

Top reasons to adopt Maven 3

A great article was recently posted on the Sonatype blog on the top 10 reasons to move to Maven 3

It will be interesting to see if there is a significant speed increase, as it will be nice to reduce the time of our main nightly build which usually takes about 90-95 minutes.

Luckily, Hudson / Jenkins makes it easy to test out running builds using different versions of Maven, so there is no reason not to test it out. Remember that the reporting has changed significantly in Maven 3, so while your project may build successfully in Maven 3 without any changes to the pom, you will need to make changes to get the reporting working. This article on the Maven Site Plugin explains the changes and shows an example of the new configuration.

Maven pom Checkstyle configuration with Eclipse

In a previous post on Eclipse plugins, two excellent plugins were mentioned which can automatically set up your Eclipse project to use the same Checkstyle configuration that is configured in your pom file. However, the only problem with both of these plugins is that they will only be able to find your Checkstyle configuration if it is configured in the build section of the pom. If you just run Checkstlye as a reporting plugin, the plugins won’t pick up the configuration.

A very simple workaround for this is to take advantage of the skip parameter in the Checkstyle configuration. You can add the Checkstyle configuration into your build section of the pom and set the skip parameter to true. This will then prevent Checkstyle from running every time you build your project.

Example code to use in your pom.xml

<properties>
	<checkstylePluginVersion>2.6</checkstylePluginVersion>
</properties>
<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-checkstyle-plugin</artifactId>
			<version>${checkstylePluginVersion}</version>
			<executions>
				<execution>
					<goals>
						<goal>check</goal>
					</goals>
				</execution>
			</executions>
			<configuration>
				<skip>true</skip>
				<configLocation>customCheckstyle.xml</configLocation>
			</configuration>
			<dependencies>
				<dependency>
					<groupId>com.company.web</groupId>
					<artifactId>company-maven-resources</artifactId>
					<version>1.0.0-SNAPSHOT</version>
				</dependency>
			</dependencies>
		</plugin>
	</plugins>
</build>
<reporting>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-checkstyle-plugin</artifactId>
			<version>${checkstylePluginVersion}</version>
			<configuration>
				<skip>false</skip>
				<configLocation>customCheckstyle.xml</configLocation>
			</configuration>
        </plugin>
	</plugins>
</reporting>

In the above, we are also using a custom artifact as a dependency of the Checkstyle plugin. This artifact is a jar file which contains the customCheckstyle.xml file. We have also got the example code above in a parent pom file, which is in it’s own maven module with a packaging of pom, and artifactId of custom-super-pom. This way, any modules can specify custom-super-pom as their parent. Then when imported into Eclipse, they will automatically have Ckeckstyle configured, which will be referencing the customCheckstyle.xml file. Also, as these modules will inherit the reporting section from the custom-super-pom, they don’t need to have Checkstyle specified in them. This is great, since now all the configuration is in one single pom, making it much easier to maintain and update.

To change the customCheckstyle.xml file, all you would need to do is edit the file within the company-maven-resources artifact, and then install the artifact into your local repository. If you are also using a repository manager like Nexus, then deploy it there also. The following command takes care of it all:

mvn clean deploy

We have used a snapshot version for our super pom and custom maven resources modules so that when these are changed, we can just deploy new versions on top of the older ones. Then any modules that reference these snapshots should pick up the latest version of the artifcats the next time they are built.  You can also force the update to happen by passing in -U on the command line when building, if you find that it doesn’t seem to be checking for updates to snapshots automatically.

Useful Eclipse Plugins

A list of handy plugins for the Eclipse IDE

  • eCobertura – Allows Cobertura code coverage to be run from the IDE directly
  • eclipse-cs – Enforces coding standards using the CheckStyle tool
  • PMD – Scans Java code and reports potential problems
  • M2Eclipse – Maven integration from Sonatype
    • m2e-extensions – Works with version 0.10 of the M2Eclipse plugin. Can automatically setup Checkstyle and PMD configuration for Eclipse to match their configuration from the pom file if they are in it
    • m2e-code-quality – Same as m2e-extensions, except this one works with version 0.12 of the M2Eclipse plugin

Note: both m2e-extensions and m2e-code-quality only work if you have the pmd and checkstyle plugins configured in the build section of the pom. They do not currently work if you have pmd and checkstyle configured in the reporting section of the pom.

JSF, Iterating with tomahawk radio buttons, t:datalist, a4j:repeat

The standard JSF radio buttons h:selectOneRadio render a load of old school html (i.e. they use table tags to do layout, (all a bit 1996)).

e.g. JSF h:selectOneRadio tag

<h:selectOneRadio id="aRadio">
	<f:selectItems value="#{radioOptions.items}" />
</h:selectOneRadio>

Code for #{radioOptions}

import java.util.ArrayList;
import java.util.List;

import javax.faces.model.SelectItem;

import org.jboss.seam.ScopeType;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.annotations.Scope;

@Name("radioOptions")
@Scope(ScopeType.APPLICATION)
public class RadioOptions
{
	public List<SelectItem> items = new ArrayList<SelectItem>();

	public RadioOptions()
	{
		items.add(new SelectItem("1", "label 1"));
		items.add(new SelectItem("2", "label 2"));
		items.add(new SelectItem("3", "label 3"));
	}

	public List<SelectItem> getItems()
	{
		return items;
	}

	public void setItems(List<SelectItem> items)
	{
		this.items = items;
	}
}

Note: I’m using jboss seam in the example above, but you could easily remove the seam annotations and define the bean in using jsf managed beans or faces config etc. Also the examples here are a bit mickey mouse and could be better.

Under JSF 1.2 will be rendered as

<table id="myForm:aRadio">
	<tr>
		<td>
			<input type="radio" name="myForm:aRadio" id="myForm:aRadio:0" value="1" />
			<label for="myForm:aRadio:0">Label 1</label>
		</td>
		<td>
			<input type="radio" name="myForm:aRadio" id="myForm:aRadio:1" value="2" />
			<label for="myForm:aRadio:1">Label 2</label>
		</td>
		<td>
			<input type="radio" name="myForm:aRadio" id="myForm:aRadio:2" value="3" />
			<label for="myForm:aRadio:2">Label 3</label>
		</td>
	</tr>
</table>

Anyway this limitation is well known and as a result we’ve been using the apache tomahawk t:selectOneRadio (using the layout=”spread” attribute) and t:radio tags to provide more flexible layouts which can be styled by css.

Iterating through a list of select items

There are times when I want to render the radio buttons in a flexible fashion (offered by t:radio) using a loop tag such as t:dataList or a4j:repeat e.g.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:fn="http://java.sun.com/jsp/jstl/functions" xmlns:c="http://java.sun.com/jstl/core" xmlns:t="http://myfaces.apache.org/tomahawk" xmlns:a4j="https://ajax4jsf.dev.java.net/ajax">
<f:view>
<h:form id="myForm">
	<!-- radio button, layout spread  -->
	<t:selectOneRadio id="myRadio" forceId="true" layout="spread">
		<f:selectItems value="#{radioOptions.items}" />
	</t:selectOneRadio>

	<!-- data list, loops through all the radio button options -->
	<t:dataList var="helper" value="#{radioOptions.items}" rowIndexVar="idx">
		<!-- example html, not constrained to table layout -->
		<h1>Heading</h1>
		<t:radio for="myRadio" index="#{idx}"/>
		<h1>Another Heading</h1>
	</t:dataList>
</h:form>
</f:view>
</html>

Unfortunately this doesn’t work and throws:

java.lang.IllegalStateException: Could not find component 'myRadio' (calling findComponent on component 'myForm:j_id3:0:j_id5')

The Fix:

I almost always forget this which is why im blogging about it,

<t:radio for="myRadio" index="#{idx}"/>

needs to be replaced with

<t:radio for=":myForm:myRadio" index="#{idx}"/>

The tomahawk t:radio component must have the fully qualified component name of the t:selectOneRadio name otherwise it cannot find it.

Since the form is defined as:

<h:form id="myForm">

:myForm needs to be prefixed to the for attribute of the t:radio giving :myForm:myRadio

I take absolutely no credit for this because its explained here and on the Myfaces wiki this article is merely a note to self.

Btw, the above works with a4j:repeat as well as t:datalist

Currently tomahawk isn’t working in JSF 2.0 which is a shame as we are looking to upgrade very soon. Hopefully a decent radio button will become part of JSF 2 at some point.

The tomahawk component library now works with JSF 2.0

Update: Fully Qualified JSF Name

A bit of searching around on the web took me to Lincoln Baxter’s blog where he mentions rendering components outside of the form and explains that the first “:” tells JSF to start looking from the very top of the JSF View Root. Thanks for that!

Maven site generation error: DTDDVFactoryImpl does not extend from DTDDVFactory

When generating a site with Maven, we encountered the following exception when a particular reporting plugin was executed:

org.apache.xerces.impl.dv.DVFactoryException:
DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.

This basically meant that an incompatible version of xerces was trying to be run. We have everything set to use Java 1.6, which ships with its own version of xerces. After some debugging, it was tracked down to the maven-site-plugin which we had recently upgraded to use version 2.1 of the plugin by specifying it in our pom file like so:

<pluginManagement>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-site-plugin</artifactId>
			<version>2.1</version>
		</plugin>
	</plugins>
</pluginManagement>

The maven-site-site plugin has the following dependency structure:

  • org.apache.maven.plugins:maven-site-plugin:maven-plugin:2.1
    • org.apache.maven.doxia:doxia-module-xhtml:jar:1.1.2 (compile)
      • org.apache.maven.doxia:doxia-core:jar:1.1.2 (compile)
        • xerces:xercesImpl:jar:2.8.1 (compile)

It is the dependency of the xercesImpl jar 2.8.1 that is the problem. To get around this issue, you can tell the maven-site-plugin to exclude a particular dependency. This can be done like so:

<pluginManagement>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-site-plugin</artifactId>
			<version>2.1</version>
			<dependencies>
				<dependency>
					<groupId>org.apache.maven.doxia</groupId>
					<artifactId>doxia-core</artifactId>
					<version>1.1.2</version>
					<exclusions>
						<exclusion>
							<groupId>xerces</groupId>
							<artifactId>xercesImpl</artifactId>
						</exclusion>
					</exclusions>
				</dependency>
			</dependencies>
		</plugin>
	</plugins>
</pluginManagement>

There are a couple of maven reporting plugins that we found produced this exception when run with maven-site-plugin 2.1. These plugins are:

If you use an older version of the maven-site-plugin then the above mentioned reporting plugins should work ok. It is only when specifying a version of 2.1 or above that the exception occurs.

Some of the solutions suggested on the net didn’t work for us, like adding the xercesImpl jar as a dependency to the actual reporting plugin in question, so hopefully the solution mentioned in this post is helpful.

3D Secure and the PaReq field in Google Chrome & Safari Browsers

I recently had to implement the 3D Secure payment system.

In order to do this 3 fields must be sent to the 3D Secure ACS (Access Control Server)

  • MD
  • Term Url
  • PaReq (Payer authentication request)

Initally everything went well until we tested our pages in Google Chrome and Safari. Under both browsers the 3D Secure inline frame displayed the following message

“Error decoding PAREQ message”

A support page mentions that a PaReq contains newlines and that if any of these are missing the PaReq decoding will fail. The page also mentions that there are issues with Chrome and Safari but provides no solution.

So what is the problem?

The problem is indeed the newline.

In our markup we use and EL (Expression Language) to output the PaReq e.g.

<input type="hidden" name="PaReq" value="#{paReq}" />

If the PaReq returned a string such as

"I am
The PaReq
"

Note the quotes above mark the begining and end of the string. The string itself is terminated by a newline, in code it would be:

String paReq = "I am\nThe PaReq\n";

The browser should generate the following markup

<input type="hidden" name="PaReq" value="I am
The PaReq
" />

However Chrome and Safari generate the following markup (as both browsers do this I assume its a Webkit thing)

<input type="hidden" name="PaReq" value="I am
The PaReq" />

Note, the traililng newline has disappeared and herein lies the problem, the server fails to recoginse the PaReq as the trailing newline has gone (currently Chrome 4.0.429.89 contains the above bug).

The fix? Dont use Chrome or Safari, Only kidding

The way we overcame this was to use a “hidden” textarea

<textarea name="PaReq" style="display:none">#{paReq}</textarea>

Which renders

<textarea name="PaReq" style="display:none">I am
The PaReq
</textarea>

In all browsers and preserves the trailing newline. The style=”display:none” hides the textarea. Although this is crude it does provide a fix for Chrome and Safari.

Suppress logging in java unit tests

Here are a couple of different ways of suppressing logging when running unit tests. If you are using apache commons logging then you can suppress logging with the following code:

LogFactory.getFactory().setAttribute(
                "org.apache.commons.logging.Log",
                "org.apache.commons.logging.impl.NoOpLog");

If running your unit tests with JUnit, it is probably best to put this code in the setUp() method. However, if you only wanted it suppressed on particular tests, it could go at the top of the test method instead. Bear in mind that if the logger is a static in the class you are testing, you  may need to then reset the attribute at the end of the test method, otherwise, any tests being run after that one will also have their logging suppressed.

If you run your unit tests within an IDE, you may want to see the logging, but not see the logging when you actually run the build of your project with something like Maven. Thankfully, there is a very simple answer to this if you are using Maven. The maven-surefire-plugin is responsible for running the tests and there is a configuration option which needs to be specified to redirect all the test output to file instead of to the console. This keeps your build reports much cleaner as you aren’t interested in seeing the logging messages. As a bonus, since all output is saved to file, exceptions will also be output to file, so whenever exceptions are thrown in the methods being tested, the stack trace wont show up in the build report.

The configuration option that needs specifying is <redirectTestOutputToFile> and this needs to be set to true, as shown below.

<plugin>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<redirectTestOutputToFile>true</redirectTestOutputToFile>
	</configuration>
</plugin>