JSF Blog » Java

Beware what you put in the endorsed dir!

paul — Thu, 12 Jan 2012 11:39:37 +0000

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….

Useful Eclipse Plugins

paul — Tue, 30 Nov 2010 12:52:11 +0000

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

paul — Fri, 14 May 2010 18:22:48 +0000

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

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 items = new ArrayList();

	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 getItems()
	{
		return items;
	}

	public void setItems(List 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


	
		
			
			Label 1
		
		
			
			Label 2
		
		
			
			Label 3

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.





	
	
		
	

	
	
		
		Heading
		
		Another Heading

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,

needs to be replaced with

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:

: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

Colin — Mon, 26 Apr 2010 11:35:01 +0000

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:


	
		
			org.apache.maven.plugins
			maven-site-plugin
			2.1

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:


	
		
			org.apache.maven.plugins
			maven-site-plugin
			2.1
			
				
					org.apache.maven.doxia
					doxia-core
					1.1.2
					
						
							xerces
							xercesImpl

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.

Suppress logging in java unit tests

Colin — Mon, 01 Mar 2010 15:22:05 +0000

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 and this needs to be set to true, as shown below.


	maven-surefire-plugin
	
		true