Persistent Designs Inc.

Excel Report Via Simple Java Annotations

zen — Wed, 10 Feb 2010 19:51:18 +0000

Introduction

This is the second part of the two part series on creating Excel spreadsheets from objects in generic collection classes. In the first part Excel read-writeable Reports through Generics, Reflection and Apache POI we discussed the core aspects of creating the Excel spreadsheets through the Apache POI library as well as leveraging the benefits of generics and reflection. In this second part we are adding more control of what is persisted to the spread sheet and how it is displayed through the use of simple annotations.

Annotations

Annotations became available in the Java SDK in version 1.5. They have become very popular with good reason. They provide efficiently add function to programs. We are adding runtime annotations that will be able to analyse our generic collection for reporting.

We are adding the following two annotations:

@ExcelReport

Use the @ExcelReport annotation to designate the class as available for excel reporting. This annotation immediately marks all accessor methods in the class available for persistence to the Excel spreadsheet. The @ExcelColumn annotation, described below, allows the user to refine the reporting.

@ExcelReport Attributes

Attribute	Required	Description
reportName	true	The name of the Excel file the report is written to.

Example

@ExcelReport(reportName="test.xls")
public class TestClass { … }

@ExcelColumn

The @ExcelColumn annotation can be used in a class that has been annotated by @ExcelReport . @ExcelColumn allows the user to ignore an accessor method or provide a custom description of the field the accessor returns. The getter method must have a symantically equivlent field. So for instance if the accessor is getFoo () there must be a field foo.

@ExcelColumn Attributes

Attribute	Required	Description
ignore	false	false by default. This attribute will make the accessor unavailable to reporting
label	false	The value for label will be used as the column heading in the spreadsheet

Example

@ExcelColumn(label="Test Name")
public String getName() {…}

@ExcelColumn(ignore=true)
public Double getDoubleField() {…}

The code for the to Annotations are below:

@Retention(RetentionPolicy.RUNTIME)
@Target(value=ElementType.TYPE)
public @interface ExcelReport {
	String reportName();
}

@Retention(RetentionPolicy.RUNTIME)
@Target(value=ElementType.METHOD)
public @interface ExcelColumn {
	boolean ignore() default false;
	String label() default "";
}

Expand the section below for an example of a domain class with Excel Annotations:

package com.persistent.utils.excel;

import java.io.File;
import java.util.ArrayList;
import java.util.List;

@ExcelReport(reportName="test.xls")
public class TestClass {
	private String name;
	private String path;
	private String directory;
	private Integer containedFiles;
	private Double doubleField;

	public TestClass() {
	}

	public TestClass(String name, String path, String directory,
			Integer containedFiles, Double doubleField) {
		super();
		this.name = name;
		this.path = path;
		this.directory = directory;
		this.containedFiles = containedFiles;
		this.doubleField = doubleField;
	}

	@ExcelColumn(label="Test Name")
	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	@ExcelColumn(label="Path")
	public String getPath() {
		return path;
	}

	public void setPath(String path) {
		this.path = path;
	}

	@ExcelColumn(label="Directory")
	public String getDirectory() {
		return directory;
	}

	public void setDirectory(String directory) {
		this.directory = directory;
	}

	@ExcelColumn(label="Number of Files in Directory")
	public Integer getContainedFiles() {
		return containedFiles;
	}

	public void setContainedFiles(Integer containedFiles) {
		this.containedFiles = containedFiles;
	}

	@ExcelColumn(ignore=true)
	public Double getDoubleField() {
		return doubleField;
	}

	public void setDoubleField(Double doubleField) {
		this.doubleField = doubleField;
	}

	@Override
	public String toString() {
		return "TestClass [containedFiles=" + containedFiles + ", directory="
				+ directory + ", doubleField=" + doubleField + ", name=" + name
				+ ", path=" + path + "]";
	}

	public static List getTestData() {
		List testClasses = new ArrayList();

		String currentDirectory = System.getProperty("user.dir");
		File currentDirectoryFile = new File(currentDirectory);
		File[] files = currentDirectoryFile.listFiles();
		double dbl = 0;
		for (File file : files) {
			TestClass testClass = null;
			if (file.isDirectory()) {
				testClass = new TestClass(file.getName(), file.getPath(),
						"directory", file.list().length,dbl++);
			} else {
				testClass = new TestClass(file.getName(), file.getPath(),
						"file", 0,dbl++);
			}
			testClasses.add(testClass);
		}
		return testClasses;
	}

	public static void main(String[] args) {
		String currentDirectory = System.getProperty("user.dir");
		File currentDirectoryFile = new File(currentDirectory);
		File[] files = currentDirectoryFile.listFiles();

		System.out.println("Is there anything in the list:" + files.length);
		double dbl = 0;
		for (File file : files) {
			System.out.println(file.getName());
			System.out.println(file.getAbsoluteFile());
			System.out.println(file.getPath());
			if (file.isDirectory()) {
				System.out.println("Directory");
				new TestClass(file.getName(), file.getPath(),
						"directory", file.list().length,dbl++);
			} else {
				new TestClass(file.getName(), file.getPath(),
						"file", 0,dbl++);
			}
		}
	}

}

Annotations and Reflection

The change over the first implementation is the annotations. This information is resolved in the reflection process just as before but now we have that extra mark-up information to aid in presentation. Internally the report program does some simple manipulations and comparisons of the fields with the collected annotated methods.

Here is the method that extracts the information from the annotations:

	private  void processAnnotations(T object) {
		Class clazz = object.getClass();
		ExcelReport reportAnnotation = (ExcelReport) clazz.getAnnotation(ExcelReport.class);
		logger.info("Report Name  : " + reportAnnotation.reportName());
		String reportName = reportAnnotation.reportName();
		if((reportName==null)||(reportName.trim().length()<1)){
			// should never get here.
			logger.error("Invalid Worksheet Name");
		}
		setWorkbookName(reportAnnotation.reportName());
		for (Method method : clazz.getMethods()) {
			ExcelColumn excelColumn = method.getAnnotation(ExcelColumn.class);
			if ((excelColumn != null) && !excelColumn.ignore()) {
				getFieldLabelMap().put(excelColumn.label(),method.getName());
				getOrderLabels().add(excelColumn.label());
				logger.info("Annotation on method: " + method.getName());
				logger.info("Ignore: " + excelColumn.ignore() + "  label: "
						+ excelColumn.label());
			}
		}
	}

Additionally the Apache POI software does allow one to go deeply into the Excel standard markup to add style to cells here we have added some style for the column headers:

private CellStyle createColumnHeaderCellStyle() {
	CellStyle cellStyle = getWorkbook().createCellStyle();
	cellStyle.setFillPattern(HSSFCellStyle.SOLID_FOREGROUND);
	cellStyle.setFillBackgroundColor(new HSSFColor.GREY_25_PERCENT().getIndex());
	cellStyle.setBorderTop(HSSFCellStyle.BORDER_THIN);
	cellStyle.setBorderLeft(HSSFCellStyle.BORDER_THIN);
	cellStyle.setBorderBottom(HSSFCellStyle.BORDER_THIN);
	cellStyle.setBorderRight(HSSFCellStyle.BORDER_THIN);
	return cellStyle;
}

Ultimately are newly marked up domain object produces a spreadsheet that looks like the following:

Installing and Running

The program requires the following jar files:

poi-3.5-FINAL-20090928.jar
poi-ooxml-3.5-FINAL-20090928.jar
log4j-1.2.15.jar
JUnit 4

The POI file are available here. Log4J is available here.

The source code for this project is here.

The program runs as a JUnit test from the class AnnotatedExcelReportTest located under the test directory.

About The Author

David Sells is a computer consultant in Toronto, Ontario who specializes in Java Enterprise Development. He has provided innovative solutions for clients including: IBM, Goldman Sachs, Merrill Lynch and Deutsche Bank.

He holds the following certifications:

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 (2009)
Sun Certified Web Component Developer
Sun Certified Java Programmer.

Contact: david@persistentdesigns.com

Excel read-writable Reports through Generics, Reflection and Apache POI

zen — Thu, 04 Feb 2010 14:22:41 +0000

Introduction

In this article we use generics, reflection and Apache POI to construct a general utility to read and write a generic collection of objects to an Excel spreadsheet.

I was recently in a project that required a lot of data to be made available from the object model to both view and modify. There was already a utility in place that would dump the information into text files. This was nice but the number of columns of information that were required made text files difficult to use. The information would be far easier to view and manipulate in a spreadsheet. This led to the creation of the tool described in this article.

This is part one of a two part series. In the second part we will utilize Annotations to refine the information exported to the Excel spreadsheet.

Apache POI

The Apache POI project provides a very simple tool for interacting with the Excel format. The POI project extends beyond Excel servicing the Office Open XML standards (OOXML) and Microsoft’s OLE 2 Compound Document format (OLE2). These formats also include those for MS Powerpoint and Microsoft Word.

The Object Model for interacting with Excel spreadsheets is very intuitive. The primary classes from POI that we use are:

org.apache.poi.ss.usermodel.Cell;
org.apache.poi.ss.usermodel.Row;
org.apache.poi.ss.usermodel.Sheet;
org.apache.poi.ss.usermodel.Workbook;

In the code snippet below these classes are utilized with the facilities of Reflection to write the contents of a Generic collection to an Excel file. The code is fairly intuitive.

public  void writeReportToExcel(List data) throws Exception {
                Sheet sheet = getWorkbook().createSheet(
                                data.get(0).getClass().getName());
                setupFieldsForClass(data.get(0).getClass());
                // Create a row and put some cells in it. Rows are 0 based.
                int rowCount = 0;
                int columnCount = 0;

                Row row = sheet.createRow(rowCount++);
                for (String fieldName : fieldNames) {
                        Cell cel = row.createCell(columnCount++);
                        cel.setCellValue(fieldName);
                }
                Class classz = data.get(0).getClass();
                for (T t : data) {
                        row = sheet.createRow(rowCount++);
                        columnCount = 0;
                        for (String fieldName : fieldNames) {
                                Cell cel = row.createCell(columnCount);
                                Method method = classz.getMethod("get" + capitalize(fieldName));
                                Object value = method.invoke(t, (Object[]) null);
                                if (value != null) {
                                        if (value instanceof String) {
                                                cel.setCellValue((String) value);
                                        } else if (value instanceof Long) {
                                                cel.setCellValue((Long) value);
                                        } else if (value instanceof Integer) {
                                                cel.setCellValue((Integer)value);
                                        }else if (value instanceof Double) {
                                                cel.setCellValue((Double) value);
                                        }
                                }
                                columnCount++;
                        }
                }
        }

Reflection

We utilize reflection to set-up the columns. Reflection is used to gather the fields associated to the target class. These field names will also serve as the column headings too. The information is retained and used to obtain the getter and setters for each field as we obtain and set these values. There are two rules for classes to work with this utility :

For each field there must be a semantically standard getter and setter associated with it.
The fields must be of the supported domain types, currently: String, Long, Double and Integer.

Below is the code for gathering the field information.

private boolean setupFieldsForClass(Class clazz) throws Exception {
        Field[] fields = clazz.getDeclaredFields();
        for (int i = 0; i < fields.length; i++) {
                fieldNames.add(fields[i].getName());
        }
        return true;
}

Generic

Below is the JUnit test case for writing a generic collection to the Excel spreadsheet. As can be seen the only requirements made of the parameter to writeReportToExcel(List) is that the collection be generic and the class of the generic collection follow the rules stated above above. Internal to the utility, as described, we use the information from the parameter to extract the information required to construct the Excel table.

The test harness for this code is as follows. Note that we can dump any class consisting of simple types: String, Integer, Long and Double. It can be easily extended. The generic collection that is being exported to an Excel spread sheet is List.

public void testReadData() {
        ExcelReporter ExcelReport = new ExcelReporter("TestCaseData.xsl");
        try {
                List results = ExcelReport
                                .readData(TestClass.class.getName());
                for (TestClass testClass : results) {
                        System.out.println(testClass);
                }
        } catch (Exception e) {
                e.printStackTrace();
        }
}

@Test
public void testWriteReportToExcel() {
        setTestClasses(TestClass.getTestData());
        ExcelReporter excelReport = new ExcelReporter("TestCaseData.xsl");
        try {
                logger.info("The number of data elements is: "+getTestClasses().size());
                excelReport.writeReportToExcel(getTestClasses());
                excelReport.closeWorksheet();
        } catch (Exception e) {
                logger.error("Error: "+e.toString());
                fail();
        }
}

public List getTestClasses() {
        return testClasses;
}

Below is the the TestClass which is the class used in the Generic List. Note that it generates data from the files/directories in the current directory of the executing program.

package com.persistent.utils.excel;

import java.io.File;
import java.util.ArrayList;
import java.util.List;

public class TestClass {
        private String name;
        private String path;
        private String directory;
        private Integer containedFiles;
        private Double doubleField;

        public TestClass() {
        }

        public TestClass(String name, String path, String directory,
                        Integer containedFiles, Double doubleField) {
                super();
                this.name = name;
                this.path = path;
                this.directory = directory;
                this.containedFiles = containedFiles;
                this.doubleField = doubleField;
        }

        public String getName() {
                return name;
        }

        public void setName(String name) {
                this.name = name;
        }

        public String getPath() {
                return path;
        }

        public void setPath(String path) {
                this.path = path;
        }

        public String getDirectory() {
                return directory;
        }

        public void setDirectory(String directory) {
                this.directory = directory;
        }

        public Integer getContainedFiles() {
                return containedFiles;
        }

        public void setContainedFiles(Integer containedFiles) {
                this.containedFiles = containedFiles;
        }

        public Double getDoubleField() {
                return doubleField;
        }
        public void setDoubleField(Double doubleField) {
                this.doubleField = doubleField;
        }

        @Override
        public String toString() {
                return "TestClass [containedFiles=" + containedFiles + ", directory="
                                + directory + ", doubleField=" + doubleField + ", name=" + name
                                + ", path=" + path + "]";
        }

        // Generate some sample data.
        public static List getTestData() {
                List testClasses = new ArrayList();

                String currentDirectory = System.getProperty("user.dir");
                File currentDirectoryFile = new File(currentDirectory);
                File[] files = currentDirectoryFile.listFiles();
                double dbl = 0;
                for (File file : files) {
                        TestClass testClass = null;
                        if (file.isDirectory()) {
                                testClass = new TestClass(file.getName(), file.getPath(),
                                                "directory", file.list().length,dbl++);
                        } else {
                                testClass = new TestClass(file.getName(), file.getPath(),
                                                "file", 0,dbl++);
                        }
                        testClasses.add(testClass);
                }
                return testClasses;
        }
}

Running the JUnit Tests

To run this program download the jar file from the link at the bottom of the article. It was built in an Eclipse environment. If you are using that IDE then import it and run the unit tests. The output of the program is Spartan: yes there is lots of room here for enhancements but still it is useful as a tool in development as is.

As one is developing you can create classes for the purpose of reporting, according to the rules, and dump them to Excel spreadsheets. Another feature of this utility is that each Collection writes to a tab which holds the name of its’ class. This means that you can write several different class collections to the same workbook and see their data on separate tabs identified by their class name.

Here is the resulting output of the JUnit test:

The program is also capable of reading the information back from the Excel spread sheet and populating the Generic collection. In the case of multiple tabs the program uses the class name to select the appropriate tab. The details are left to interested developers.

Installing

The program requires the following jar files:

poi-3.5-FINAL-20090928.jar
poi-ooxml-3.5-FINAL-20090928.jar
log4j-1.2.15.jar
JUnit 4

The POI file are available here. Log4J is available here.

The source code for this project is here.

Enjoy!

About The Author

He holds the following certifications:

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 (2009)
Sun Certified Web Component Developer
Sun Certified Java Programmer.

Contact: david@persistentdesigns.com

Vaadin Web Application with Jersey REST

zen — Fri, 30 Oct 2009 12:14:57 +0000

Introduction

It was a pleasure to learn about Google Web Toolkit (GWT) and its ability to remove some of the drudgery from program the presentation layer. It was even more satisfying to look into Vaadin with it rich CSS and DHTML magic. This article just skims the surface of Vaadin’s offerings as it is used to implement the web front end in the integration of the REST client API developed in the previous article: Jersey REST Client.

Implementation

Vaadin was very easy to configure. All the HTTP requests are mapped through the Vaadin GWT servlet:

From the web.xml

 
  	Wow Application
  	
  	com.vaadin.terminal.gwt.server.ApplicationServlet
  	
  		
  		Vaadin application class to start
  		application
  		com.persistent.app.WowApplication
  	
  

  
  	Wow Application
  	/*

Integrating the REST API is just a matter of including the gclient dependency in the POM file and utilizing the RestCompanyDirectory class. This class relies on the Jersey REST API and there is no need for any Spring configuration in this application.

From pom.xml


	com.persistent
		gclient
		1.0-SNAPSHOT

The Vaadin API is well constructed and they have both an excellent demo page and downloadable book on the framework. I am just presenting a short exemplar of their products ease of use.

The resulting application looks as follows:

The link below contains the code required to render the user interface shown above as well as interact with the REST web service.

package com.persistent.app;

import java.util.ArrayList;
import java.util.Collection;
import java.util.StringTokenizer;

import org.apache.commons.lang.StringUtils;

import com.persistent.dto.Company;
import com.persistent.dto.Person;
import com.persistent.rest.client.RestCompanyDirectory;
import com.vaadin.Application;
import com.vaadin.data.Item;
import com.vaadin.data.Property;
import com.vaadin.data.Property.ValueChangeEvent;
import com.vaadin.data.util.IndexedContainer;
import com.vaadin.ui.Button;
import com.vaadin.ui.Component;
import com.vaadin.ui.DefaultFieldFactory;
import com.vaadin.ui.Field;
import com.vaadin.ui.Form;
import com.vaadin.ui.HorizontalLayout;
import com.vaadin.ui.NativeSelect;
import com.vaadin.ui.SplitPanel;
import com.vaadin.ui.Table;
import com.vaadin.ui.TextField;
import com.vaadin.ui.VerticalLayout;
import com.vaadin.ui.Window;
import com.vaadin.ui.Button.ClickEvent;

public class WowApplication extends Application {
	private static final long serialVersionUID = 2192808513028842236L;
	private Collection companies;
	private Table contactList = new Table();
	private Form contactEditor = new Form();
	private HorizontalLayout bottomLeftCorner = new HorizontalLayout();
	private Button contactRemovalButton;
	private IndexedContainer companyDirectoryData = retrieveCompanyDirectoryData();
	private ArrayList companyArray = null;
	private Collection persons = null;

	boolean updateFlag = false;

	public enum Column {
		id("Id"), first("First Name"), last("Last Name"), age("Age"), company(
				"Company"), companyId("CompanyId");
		private static Column[] visible = { first, last, company };
		private String displayName;

		public static String[] getVisibleColumnNames() {
			String[] visibleColumnNames = new String[visible.length];
			int i = 0;
			for (Column column : visible) {
				visibleColumnNames[i++] = column.displayName;
			}
			return visibleColumnNames;
		}
		Column(String displayName) {
			this.displayName = displayName;
		}
		public String getDisplayName() {
			return displayName;
		}
		public static Column[] getVisibleColumns() {
			return visible;
		}
	}

	private NativeSelect getCompaniesNativeSelect() {
		final NativeSelect companies = new NativeSelect("Company");
		companies.setWidth("30em");
		if (companyArray == null) {
			Collection theCompanies = getCompanies();
			companyArray = new ArrayList(theCompanies);
		}
		for (Company company : companyArray) {
			companies.addItem(company.getName());
		}
		return companies;
	}

	@Override
	public void init() {
		initLayout();
		initContactAddRemoveButtons();
		initAddressList();
		initFilteringControls();
	}

	private void initLayout() {
		SplitPanel splitPanel = new SplitPanel(
				SplitPanel.ORIENTATION_HORIZONTAL);
		setMainWindow(new Window("Address Book", splitPanel));
		// Left Side
		VerticalLayout left = new VerticalLayout();
		left.setSizeFull();
		left.addComponent(contactList);
		contactList.setSizeFull();
		left.setExpandRatio(contactList, 1);
		splitPanel.addComponent(left);
		bottomLeftCorner.setWidth("100%");
		left.addComponent(bottomLeftCorner);
		// other side
		splitPanel.addComponent(contactEditor);
		contactEditor.setSizeFull();
		contactEditor.getLayout().setMargin(true);
		contactEditor.setImmediate(true);
		contactEditor.setFormFieldFactory(new PersonFactory());
	}

	@SuppressWarnings("serial")
	private void initContactAddRemoveButtons() {
		// New item button
		bottomLeftCorner.addComponent(new Button("+",
				new Button.ClickListener() {
					public void buttonClick(ClickEvent event) {
						Object id = contactList.addItem();
						contactList.setValue(id);
					}
				}));

		// Remove item button
		contactRemovalButton = new Button("-", new Button.ClickListener() {
			public void buttonClick(ClickEvent event) {
				final Item item = contactList.getItem(contactList.getValue());
				final String personId = (String) item.getItemProperty(Column.id.displayName)
						.getValue();
				final RestCompanyDirectory companyDirectory = new RestCompanyDirectory();
				companyDirectory.deletePerson(Long.parseLong(personId));
				contactList.removeItem(contactList.getValue());
				contactList.select(null);
			}
		});
		contactRemovalButton.setVisible(false);
		bottomLeftCorner.addComponent(contactRemovalButton);
	}

	@SuppressWarnings("serial")
	private void initAddressList() {
		contactList.setContainerDataSource(companyDirectoryData);
		contactList.setVisibleColumns(Column.getVisibleColumnNames());
		contactList.setSelectable(true);
		contactList.setImmediate(true);

		contactList.addListener(new Property.ValueChangeListener() {
			public void valueChange(ValueChangeEvent event) {
				Object id = contactList.getValue();
				updateFlag = true;
				contactEditor.setItemDataSource(id == null ? null : contactList
						.getItem(id));
				contactRemovalButton.setVisible(id != null);
				updateFlag = false;
			}
		});
	}

	@SuppressWarnings("serial")
	private void initFilteringControls() {
		for (final Column column : Column.getVisibleColumns()) {

			if (!column.equals(Column.company)) {
				final TextField sf = new TextField();
				bottomLeftCorner.addComponent(sf);
				sf.setWidth("100%");
				sf.setInputPrompt(column.displayName);
				sf.setImmediate(true);
				bottomLeftCorner.setExpandRatio(sf, 1);
				sf.addListener(new Property.ValueChangeListener() {
					public void valueChange(ValueChangeEvent event) {
						companyDirectoryData
								.removeContainerFilters(column.displayName);
						if (sf.toString().length() > 0
								&& !column.displayName.equals(sf.toString())) {
							companyDirectoryData.addContainerFilter(
									column.displayName, sf.toString(), true,
									false);
						}
						getMainWindow().showNotification(
								"" + companyDirectoryData.size() + " matches found");
					}
				});
			} else {
				final NativeSelect ns = getCompaniesNativeSelect();
				bottomLeftCorner.addComponent(ns);
				ns.setImmediate(true);
				ns.setCaption("");
				ns.addListener(new Property.ValueChangeListener() {
					public void valueChange(ValueChangeEvent event) {
						companyDirectoryData
								.removeContainerFilters(column.displayName);
						if (ns.getValue() != null) {
							companyDirectoryData.addContainerFilter(
									column.displayName, (String) ns.getValue(),
									true, false);
						}
						getMainWindow().showNotification(
								"" + companyDirectoryData.size() + " matches found");
					}

				});
			}
		}
	}

	@SuppressWarnings("serial")
	private class PersonFactory extends DefaultFieldFactory {

		public PersonFactory() {
		}

		@Override
		public Field createField(final Item item, Object propertyId,
				Component uiContext) {
			Field result = null;
			if (Column.company.displayName.equals(propertyId)) {
				final NativeSelect companies = new NativeSelect(
						Column.company.displayName);
				companies.setWidth("30em");
				Collection theCompanies = getCompanies();
				ArrayList a = new ArrayList(theCompanies);
				for (Company company : a) {
					companies.addItem(company.getName());
				}
				companies.setValue(uiContext);
				result = companies;
			} else {
				result = super.createField(item, propertyId, uiContext);
				if (Column.id.displayName.equals(propertyId)
						|| Column.companyId.displayName.equals(propertyId)) {
					result.setVisible(false);
				}
			}
			result.addListener(new Property.ValueChangeListener() {
				public void valueChange(ValueChangeEvent event) {
					if (!updateFlag && isValid(item)) {
						updateFlag = true;
						getMainWindow().showNotification(
								"Updated Record: "
										+ (String) item.getItemProperty(
												Column.id.displayName)
												.getValue());
						WowApplication.this.updateDB(item);
						updateFlag = false;
					}
				}
			});
			return result;
		}
	}

	public boolean isValid(Item item) {
		String first = (String) item.getItemProperty(Column.first.displayName)
				.getValue();
		String last = (String) item.getItemProperty(Column.last.displayName)
				.getValue();
		String company = (String) item.getItemProperty(
				Column.company.displayName).getValue();
		String age = (String) item.getItemProperty(Column.age.displayName)
				.getValue();
		if (!StringUtils.isNumeric(age)) {
			getMainWindow().showNotification("Age must be numeric",
					Window.Notification.TYPE_ERROR_MESSAGE);
		}
		return StringUtils.isNotBlank(first) && StringUtils.isNotBlank(last)
				&& StringUtils.isNotBlank(company)
				&& StringUtils.isNotBlank(age) && StringUtils.isNumeric(age);
	}

	private IndexedContainer retrieveCompanyDirectoryData() {
		Collection persons = getPersons();
		ArrayList aperson = new ArrayList(persons);
		IndexedContainer ic = new IndexedContainer();

		for (Column p : Column.values()) {
			ic.addContainerProperty(p.displayName, String.class, "");
		}
		for (Person person : aperson) {
			Object id = ic.addItem();
			StringTokenizer tokenizer = new StringTokenizer(person.getName());
			if (tokenizer.hasMoreElements()) {
				ic.getContainerProperty(id, Column.first.displayName).setValue(
						tokenizer.nextToken());
				if (tokenizer.hasMoreElements()) {
					ic.getContainerProperty(id, Column.last.displayName)
							.setValue(tokenizer.nextToken());
				}
			}
			ic.getContainerProperty(id, Column.company.displayName).setValue(
					person.getCompany().getName());
			ic.getContainerProperty(id, Column.id.displayName).setValue(
					person.getId());
			ic.getContainerProperty(id, Column.companyId.displayName).setValue(
					person.getCompany().getId());
			ic.getContainerProperty(id, Column.age.displayName).setValue(
					person.getAge());
		}
		return ic;
	}

	public void updateDB(final Item item) {
		RestCompanyDirectory companyDirectory = new RestCompanyDirectory();
		String sid = (String) item.getItemProperty(Column.id.displayName)
				.getValue();
		String companyName = (String) item.getItemProperty(
				Column.company.displayName).getValue();
		if (StringUtils.isNotBlank(sid)) {
			Long id = Long.parseLong(sid);
			Person person = companyDirectory.getPerson(id);
			populatePerson(item, person);
			if (!companyName.equals(person.getCompany().getName())) {
				Company company = getCompany(companyName);
				if (company != null) {
					person.setCompany(company);
				}
			}
			companyDirectory.updatePerson(person);
		} else {
			Person person = new Person();
			populatePerson(item, person);
			Company company = getCompany(companyName);
			person.setCompany(company);
			Person newPerson = companyDirectory.createPerson(person);
			item.getItemProperty(Column.id.displayName).setValue(
					newPerson.getId());
		}
	}

	private Company getCompany(String companyName) {
		Company selectedCompany = null;
		for (Company company : companyArray) {
			if (company.getName().equals(companyName)) {
				selectedCompany = company;
				break;
			}
		}
		return selectedCompany;
	}

	private void populatePerson(Item item, Person person) {
		String first = (String) item.getItemProperty(Column.first.displayName)
				.getValue();
		String last = (String) item.getItemProperty(Column.last.displayName)
				.getValue();
		String age = (String) item.getItemProperty(Column.age.displayName)
				.getValue();
		person.setName(first + " " + last);
		person.setAge(Short.parseShort(age));
	}

	private Collection getPersons() {
		if (persons == null) {
			RestCompanyDirectory companyDirectory = new RestCompanyDirectory();
			persons = companyDirectory.getPersons();
		}
		return persons;
	}

	private Collection getCompanies() {
		if (companies == null) {
			RestCompanyDirectory companyDirectory = new RestCompanyDirectory();
			companies = companyDirectory.getCompanies();
		}
		return companies;
	}
}

Installation

There are three steps to install this application:

Starting the REST Web Service
Build REST Client Code
The Vaadin Application

Installing the REST Web Service

The REST Webservice was developed in previous articles. It can be downloaded by this link. Uncompress and run the following maven command:

clean install jetty:run -Djetty.port=9444

This command will download dependencies, compile the code and deploy the application in Jetty at port 9444.

We need to export the client API from the service to build the client code. This is done after the build through a script available in the src/main/resource directory called: installit.sh

This bash script simply installs the client jar into the appropriate location to be utilized in other programs. For more information see Simple Spring-WS Application.

Building REST Client Code

This is described in the previous article Jersey REST Client.

Building the Vaadin Project

Download the code linked here.

To build unzip and from the root directory type:

mvn clean install

A target directory will be created and within it there will be a war file called: vaadin_one.war

Take this war and deploy it in your web server. I am working with tomcat 6.0.20.

The Vaadin web application URL is: http://localhost:8080/vaadin_one

Enjoy! If you have any questions just send me a note.

About The Author

He also holds the following certifications:

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 (2009)
Sun Certified Web Component Developer
Sun Certified Java Programmer.

Contact: david@persistentdesigns.com

Jersey REST Client

zen — Thu, 29 Oct 2009 17:52:28 +0000

Introduction

In this article we are constructing a simple Jersey REST client API that will be available for use within projects that wish to take advantage of our Company Directory REST web service. This project is part of the continuing project whose purpose is to integrate technologies various technologies with in a Maven2 build environment. This article is extending a client project, presented in: Simple SOAP Client using XMLBeans, in this article we constructed client classes to interact with our SOAP interface into our web service. At the end of this article we will have a Maven2 dependency that will allow applications to interact with the Company Directory web service by either SOAP or REST.

When we introduced our our REST web service we created to client programs to interact with this service: one through Ajax calls and the other through Groovy. These articles are:

The Ajax client was in the original REST article: REST Project Digest and Generic Data Repository
The Groovy client was presented in: A Groovy Rest Client for the JPA, Jersey, Spring Integration Project

This solution is decoupled from the application such that it would be available to any java application. The product of this project will be used in our next article when we build our client application with VAADIN, a GWT deriviative, with REST communicating with the backend.

Implementation

One class is required for the implementation utilizing Jersey’s APIs. The coding is straight foward with a couple of places of interest. One being the use of Jersey’s GenericType. The GenericType class allows us to deal with type erase that happens in generic collections at run time. This loss of type information makes unmarshalling of collection data difficult as the type information has been removed.

The solution of this problem was done in steps.

The entity objects was mapped into Data Transfer Objects.
The data transfer classes have the JAXB annotations that will provide the XML utilized by Jersey’s JSON adapter.
The collection classes of entities types are preserved through Jersey’s GenericType class

The REST server has the following API for providing a list of Companies:

@GET
@Path("/companies")
@Produces("application/json")
public List getCompanies() {
	List companies = companyDirectory.getCompanies();
	List companyDtos = new ArrayList<();
	for (Company company : companies) {
		com.persistent.dto.Company companyDto = servermapper.map(company, com.persistent.dto.Company.class);
		companyDtos.add(companyDto);
	}
	return companyDtos;
}

The Jersey software intercepts the request and wraps the Generic collection with their GenericType. At the client side as shown in the code snippet below we are able to retrieve the Collection of Company objects through the use of the GenericType.

public Collection getCompanies() {
		WebResource.Builder builder = createWebResourceBuilder(UriBuilder
				.fromUri("http://localhost/").port(getPort(DEFAULT_PORT)).path(
						URL + "companies").build((Object[]) null));
		GenericType> genericType = new GenericType>() {
		};
		return builder.get(genericType);
	}

The remainder of the class is in the link below.

package com.persistent.rest;

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

import javax.ws.rs.Consumes;
import javax.ws.rs.DELETE;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.MultivaluedMap;
import javax.ws.rs.core.UriInfo;

import org.apache.log4j.Logger;
import org.dozer.Mapper;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;

import com.persistent.entity.Person;
import com.persistent.entity.Company;
import com.persistent.service.CompanyDirectory;

@Component
@Path("/")
@Scope("singleton")
public class CompanyDirectoryRest  {
	Logger log = Logger.getLogger(this.getClass());
	@Autowired
	Mapper servermapper;

	@Autowired
	private CompanyDirectory companyDirectory;
	@Context
	UriInfo ui;

	@GET
	@Path("/persons")
	@Produces("application/json")
	public List getPersons() {
		log.info("getPersons entered");
		List persons = companyDirectory.getPersons();
		List personDTOs = new ArrayList();

		for (Person person : persons) {
			personDTOs.add(getPersonDto(person));
		}

		return personDTOs;
	}

	private com.persistent.dto.Person getPersonDto(Person person) {
		com.persistent.dto.Person personDTO = servermapper.map(person, com.persistent.dto.Person.class);
		return personDTO;
	}

	@GET
	@Path("/companies")
	@Produces("application/json")
	public List getCompanies() {
		List companies = companyDirectory.getCompanies();
		List companyDtos = new ArrayList();
		for (Company company : companies) {
			com.persistent.dto.Company companyDto = servermapper.map(company, com.persistent.dto.Company.class);
			companyDtos.add(companyDto);
		}
		return companyDtos;
	}

	@GET
	@Path("/person/{id}")
	@Produces("application/json")
	public com.persistent.dto.Person getPerson(@PathParam("id") final String sid) {
		Long id = Long.parseLong(sid);
		com.persistent.dto.Person result = null;
		Person person = companyDirectory.getPerson(id);
		if(person!=null) {
			result = getPersonDto(person);
		}
		return result;
	}

	@PUT
	@Consumes("application/json")
	@Path("/person/update")
	public void updatePerson(final com.persistent.dto.Person person) {
		Person personE = servermapper.map(person,Person.class);
		companyDirectory.updatePerson(personE);
	}

	@POST
	@Path("/person")
	@Consumes("application/json")
	@Produces("application/json")
	public com.persistent.dto.Person addPerson(final com.persistent.dto.Person person) {
		Person personE = servermapper.map(person,Person.class);
		return getPersonDto(companyDirectory.addPerson(personE));
	}

	@DELETE
	@Path("/persons/{id}")
	@Produces("text/plain")
	public String deletePerson(@PathParam("id") final String sid) {
		Long id = Long.parseLong(sid);
		companyDirectory.deletePerson(id);
		final MultivaluedMap queryParams = ui
				.getQueryParameters();
		final List ids = queryParams.get("id");

		if (ids == null) {
			log.debug("\n\nThe ids is null");
		} else {
			log.info("The ids are: "+ids.size());
			for (String currentid : ids) {
				log.info("Delete: "+currentid);
				companyDirectory.deletePerson(Long.parseLong(currentid));
			}
		}
		return "finished";
	}

	@GET
	@Path("/company/{id}")
	@Produces("application/json")
	public com.persistent.dto.Company getCompany(@PathParam("id") final String sid) {
		log.info("Entering findByCompanyId Rest method");
		return servermapper.map(companyDirectory.getCompany(Long.parseLong(sid)), com.persistent.dto.Company.class);

	}

	@GET
	@Path("/company/count")
	@Produces("text/plain")
	public String countSCompanies() {
		return companyDirectory.countCompanies().toString();
	}

	@GET
	@Path("/person/count")
	@Produces("text/plain")
	public String countSPersons() {
		return companyDirectory.countPersons().toString();
	}

	// The Java method will process HTTP GET requests
	@GET
	@Path("/persons/test")
	public String simpleTest() {
		return "Hello Foo";
	}
}

The installation instruction are similar to those given in this link:Simple SOAP Client using XMLBeans. There are JUnit test cases that will exercise the newly added functionality.

The Source Code

Follow this link to down load the source code.

About The Author

He also holds the following certifications:

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 (2009)
Sun Certified Web Component Developer
Sun Certified Java Programmer.

Contact: david@persistentdesigns.com

Simple GWT Client integrated with Spring built with Maven

zen — Mon, 19 Oct 2009 19:31:14 +0000

Introduction

In this article we will integrate the SOAP client generated in the article: Simple Spring-WS Application [with JPA and Jersey REST] into a GWT-Spring web application. Again we are using Maven2 to build the application. The web application is broken into to two GWT projects: Server and Web which can be built through a Parent project. The Server project implments a GWT remote services with the Springframework working in the background to provide the SOAP connectivity. GWT provides servlets that the GWT persentation layer communicates.

Implementation

The structure for this article is based upon the build environment created by Sam Brodking. There are tools available which will allow for the building of the front and backend of Spring-GWT in a single project but I feel that there is value in this division from the perspective of unit testing and independent development.

The Server Project

The server side deals with the SOAP connection, extracts the entity objects from the SOAP messages, maps the entity objects into their DTO counter parts and makes operations available through a GWT servlet.

The SOAP connection is simple since it was solved in the last article: Simple SOAP Client Using XMLBeans. To utilize its’ services we need only to add it as a dependency. All the jar files related to enabling this dependency to perform are automatically installed through the definition of the dependency: this one of the great benifits to developing with Maven.


	com.persistent
	gclient
	1.0-SNAPSHOT

To create are service we need to provide the following:

Create the remote interface to the service we are providing extending: com.google.gwt.user.client.rpc.RemoteService
The implementation of that remote interface while also extending:import com.google.gwt.user.server.rpc.RemoteServiceServlet
Additionally we create the Async Interface that is registered in our ServiceRegistry through which our client screens will execute commands against the service this occurs in the Web project and we will discuss it in more detail in that section.

This application defines one service which is the CompanyDirectory service.

The remote interface CompanyDirectoryDTO:

import com.google.gwt.user.client.rpc.RemoteService;
import com.persistent.client.domain.CompanyDTO;
import com.persistent.client.domain.PersonDTO;

public interface CompanyDirectoryDTO extends RemoteService {
	public PersonDTO addPersonDTO(PersonDTO person);
	public Integer countCompanies();
	public Integer countPersonDTOs();
	public String deletePersonDTO(String sid);
	public ArrayList findByCompanyDTOId(Long id);
	public ArrayList findByCompanyDTOIds(ArrayList ids);
	public ArrayList getCompanies();
	public PersonDTO getPersonDTO(Long id);
	public ArrayList getPersonDTOs();
	public PersonDTO updatePersonDTO(PersonDTO person);
}

The implementation of the remote inter face CompanyDirectoryDTOImpl:

import com.google.gwt.user.server.rpc.RemoteServiceServlet;
import com.persistent.client.CompanyDirectoryDTO;
import com.persistent.client.domain.CompanyDTO;
import com.persistent.client.domain.PersonDTO;
import com.persistent.ws.client.SoapClient;

public class CompanyDirectoryDTOImpl extends RemoteServiceServlet implements
		CompanyDirectoryDTO {
	public PersonDTO addPersonDTO(PersonDTO person) {
		return SoapClient.addPersonDTO(person);
	}

	public String deletePersonDTO(String sid){
		return deletePersonDTO(Long.parseLong(sid));
	}

	public String deletePersonDTO(Long id) {
		if (id != null) {
			if (SoapClient.getCompanyDirectory() != null) {
				SoapClient.getCompanyDirectory().deletePerson(id);
			}
		}
		return "Success";
	}

	public ArrayList findByCompanyDTOId(Long id) {
		ArrayList result;
		if(id==null) {
			result = new ArrayList();
		} else {
			result = SoapClient.findByCompanyDTOId(id);
		}
		return result;
	}

	public ArrayList getCompanies() {
			return SoapClient.getCompanies();
	}

	public ArrayList getPersonDTOs() {
		return (ArrayList) SoapClient.getPersonDTOs();
	}

	public PersonDTO updatePersonDTO(PersonDTO person) {
		return SoapClient.updatePerson(person);
	}

	public ArrayList findByCompanyDTOIds(ArrayList ids) {
		ArrayList result = new ArrayList();
		for (Long id : ids) {
			result.addAll(findByCompanyDTOId(id));
		}
		return result;
	}
   :
   :
}

The CompanyDirectoryDTOAsync:

import com.google.gwt.http.client.Request;
import com.google.gwt.user.client.rpc.AsyncCallback;
import com.persistent.client.domain.CompanyDTO;
import com.persistent.client.domain.PersonDTO;

public interface CompanyDirectoryDTOAsync {
	public Request addPersonDTO(PersonDTO person,AsyncCallback callback);
	public Request countCompanies(AsyncCallback callback);
	public Request countPersonDTOs(AsyncCallback callback);
	public Request deletePersonDTO(String sd,AsyncCallback callback);
	public Request findByCompanyDTOId(Long id,AsyncCallback> asyncCallback);
	public Request findByCompanyDTOIds(ArrayList ids ,AsyncCallback> asyncCallback);
	public Request getCompanies(AsyncCallback> asyncCallback);
	public Request getPersonDTO(Long id,AsyncCallback callback);
	public Request getPersonDTOs(AsyncCallback> asyncCallback);
	public Request updatePersonDTO(PersonDTO person, AsyncCallback callback);
}

These server function work in conjunction to the SOAP client. We utilize the soap client through a simple api as generated in the: Simple SOAP Client using XMLBeans. To communicate through the GWT Servlet we need to make a data transfer object. Again we utilize the servces Dozer as described in a previous article here.

Here is a general picture of the classes in the Server project ( external classes are not included).

The Web Project

We will focus on the communication services of this layer and update and leave the GWT presentation code to the reader.

The web application has a ClientMain class setups the application entry loading the GWT module and constructing the main pane with the ServiceRegistry. The ServiceRegistry is were all communications with the server side are registered. In this application we have one service registered:

Service Registry:

public class ServiceRegistry {
	private CompanyDirectoryDTOAsync companyDirectoryDTO;
	public CompanyDirectoryDTOAsync getCompanyDirectoryDTO() {
		if(companyDirectoryDTO == null) {
			companyDirectoryDTO = GWT.create(CompanyDirectoryDTO.class);
			((ServiceDefTarget)companyDirectoryDTO).setServiceEntryPoint(GWT.getModuleBaseURL() + "companyDirectoryDTO");
		}
		return companyDirectoryDTO;
	}
}

The communciation with the server side is done asynchronously. The widgets are populated through AJAX callbacks as part of the GWT toolkit. Below is an example of such a call when we populate all the persons in a company.

private void retrievePersonsInCompanies(ArrayList selectedCompanies) {
	getServiceRegistry().getCompanyDirectoryDTO().findByCompanyDTOIds(
			selectedCompanies, new AsyncCallback>() {
				public void onFailure(Throwable caught) {
					Window.alert("RPC failed.");
				}
				public void onSuccess(ArrayList pPersons) {
					persons.addAll(pPersons);
					refreshPersonsTable();
				}
			});
}

An overview of the Web Project classes

PersonChangeEvent: keeping screen information current

We have two screens that alow us to interact with the CompanyDirectories. If we alter the information on one screen we want to insure that when we switch to the other screen that the information has been refreshed otherwise we will run into cached stale data. To accomplish this we have implemented a simple PersonChangeEvent. This is accomplished in the following way:

Each screen that maintains person information:

implements the PersonChangeListener interface adding the personChange method to handle the change to the Person information
registers themselves with the PersonChangePublisher
when a screen alters Person data they publish a change through the pubilsh with a notifyPersonChange

The Screens look as follows

The Checkbox Screen

The Tree Screen

Compiling and Running the Application

There are a number of steps required to get this application working. There are now two applications that need to run for both the JUnit test cases and the running application.

Prerequisite Tasks

Prior to building the GWT application we need to get the SOAP Service started. It is prerequisite to have this SOAP service installed in the system along with its client jar entered into the repository and the SOAP Client built . Below are the links to the instructions to perform these tasks:

Building the GWT Server and Web Project

Without running the test cases you can build the projects through parent directory with the following command:

mvn clean install -Dmaven.skip.test=true

This should build both projects. Unfortuantely I find that there are problems at times with this approach and would highly recommend build with the test cases.

To build with the test cases one will have to start the SOAP service for the test cases to complete successfully. We are going to have two web applications running the SOAP server and the GWT application. For the SOAP server we can alter the port that Jetty runs the application on with the following command run from the SOAP server’s root directory:

mvn jetty:run -Djetty.port=9444

We are now free to run the GWT build along with it’s test cases. The GWT application is coded to utilize the SOAP service on port 9444 of the localhost. Again the command to build the GWT application is from the Parent project root directory:

mvn clean install

I have found that sometimes there are problems in the building of the Web project. In this case I go into the Web project root directory and issue that same command. Hopefully this will resolve the problem. If not send me an e-mail and we’ll get it straightened out.

At this point we should have a war file in the Web project’s target directory which is ready for deployment in a tomcat6.x /Java 1.5 environment. I have not tested others so you’ll be on your own if you need to use an alternate.

Here is a trick part (part of the build process I didn’t get ironed out (feel free to send me the answer)). I copy the web-1.–SNAPSHOT.war into the webapp directory of tomcat and when it has deployed I copy the following two files from Server project:

server/src/main/resources/applicationContext.xml
server/src/main/resources/dozer-bean-mappings.xml

The application should not be available for use at:

http://localhost:8080/web-1.0-SNAPSHOT/com.persistent.Application/Application.html

Additionally the REST server should also be available, since it is included in the SOAP Server, at:

http://localhost:9444/general/crud.html

Source Code

Here is the source code.

Conclusion

That concludes the simple GWT user interface into the Company Directory SOAP Service. It is a complex setup. If you are interested in installing this on your local machine please don’t hesitate to contact me if you should have any difficulties setting it up.

About The Author

He also holds the following certifications:

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 (2009)
Sun Certified Web Component Developer
Sun Certified Java Programmer.

Contact: david@persistentdesigns.com

Separation of Concerns: Refactoring of Evolving Project

zen — Sun, 18 Oct 2009 21:45:10 +0000

Introduction

This article is in relationship to refactoring the SOAP/REST server presented in: Simple Spring-WS Application [with JPA and Jersey REST].

As the project has evolved some ugly coupling has reared its’ head. In an expedient way the entity classes were annotated with JAXB annotations to make them available for serialization for our REST implementation. Here the JAXB worked in conjunction with Jersey REST adapters to create JSON messages to serialize our objects.

The Refactoring

There are many draw backs to taking this direct approach:

Muddying the definition of entity objects
Need to use GenericEntity to handle type erasure in the entity class which alters the class signature
From using GenericEntity and JAXB Annotations these libraries would have to be included in applications using the entity object even if these features were not used.
Complicates extensions to the entity
From a REST perspective it does not give us clean control over the information we choose to serialize.

The Original com.persistent.entity.Company Class

@XmlRootElement(name = "company")
@XmlAccessorType(XmlAccessType.PUBLIC_MEMBER)
@Entity
@Table(name = "COMPANY")
@NamedQueries( { @NamedQuery(name = "Company.EagerFindByID", query = "SELECT c FROM Company c left join fetch c.employees where c.id =?1")
				}
			)
public class Company {
	private static final long serialVersionUID = -142950147106627846L;
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	private Long id;
	private String name;
	@OneToMany(mappedBy = "company", fetch = FetchType.LAZY)
	private List employees = new ArrayList();

	/**
	 *
	 */
	public Company() {
	}

	@XmlElement
	public Long getId() {
		return id;
	}
	public void setId(final Long id) {
		this.id = id;
	}
	@XmlElement
	public String getName() {
		return name;
	}
	public void setName(final String name) {
		this.name = name;
	}

	public GenericEntity> getEmployees() {
		return new GenericEntity>(employees) {};
	}

The standard solution to this problem is the Transfer Object pattern. Although we are changing the entity class annotations in an environment where it is being utilized by both REST and SOAP only the REST protion of the project is affected. The SOAP functionality generates its own JAXB annotated transfer objects through the use XJC.

The following steps were required to implement the refactoring:

Removed the JAXB annotations from the entity classes
Create the transfer objects for each of the entity classes with JAXB annotations
Added Dozer to facilitate the mapping from the entity classes to the transfer objects
execute the mappings in the CompanyDirectoryRest class were the conversion is required.

The com.persistent.entity.Company Class after the decoupling

@Entity
@Table(name = "COMPANY")
@NamedQueries( { @NamedQuery(name = "Company.EagerFindByID", query = "SELECT c FROM Company c left join fetch c.employees where c.id =?1") })
public class Company implements Serializable {
	private static final long serialVersionUID = -142950147106627846L;
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	private Long id;
	private String name;
	@OneToMany(mappedBy = "company", fetch = FetchType.LAZY)
	private List employees = new ArrayList();

	/**
	 *
	 */
	public Company() {
	}

	public Long getId() {
		return id;
	}

	public void setId(final Long id) {
		this.id = id;
	}

	public String getName() {
		return name;
	}

	public void setName(final String name) {
		this.name = name;
	}

	public List getEmployees() {
		return employees;
	}

The com.persistent.dto.Company Class for Data Transfer

@XmlRootElement(name = "company")
@XmlAccessorType(XmlAccessType.PUBLIC_MEMBER)
public class Company implements Serializable {
	@XmlTransient
	private static final long serialVersionUID = -142950147106627846L;

	private Long id;
	private String name;
	private List employees = new ArrayList();
	/**
	 *
	 */
	public Company() {
	}

	public Company(com.persistent.entity.Company company) {
		this.name = company.getName();
		this.id = company.getId();
	}

	@XmlElement
	public Long getId() {
		return id;
	}
	public void setId(final Long id) {
		this.id = id;
	}
	@XmlElement
	public String getName() {
		return name;
	}
	public void setName(final String name) {
		this.name = name;
	}

	public GenericEntity> getEmployees() {
		return new GenericEntity>(employees) {};
	}

The JUnit test cases proved their worth as these changes were made to quickly establish their effectiveness.

The interfaces between components is maintained so that the JUnit tests do not need to change. This refactoring mainly effects the maintainability and extensibility of the software. This application will work with the SOAP Client described in the previous article: Simple SOAP Client using XMLBeans.

A Note on Dozer

Dozer does implicit-explicit mappings between classes. It provides complex mapping between dis-similar classes. We are utilizing it simply but it is an application that does provide flexibility that will provide value in the long run when there may be more interest in interesting mappings. Even used simply it does provide an intuitive flow to the code which leads to maintainability as we show below.

By providing a simple mapping file, as in our case general-dozer-bean-mappings.xml, we describe the desired mapping. We rely on the implicit mapping fascilities of the tool:




  
    com.persistent.entity.Company
    com.persistent.dto.Company
    
      employees
      employees
    
  
  
    com.persistent.entity.Person
    com.persistent.dto.Person

Now performing the mapping is trivial in this snippet, taken from CompanyDirectoryRest.java, we map the entity object into a JAXB annotated transfer object for serialization.

@Autowired
Mapper servermapper;

@GET
@Path("/persons")
@Produces("application/json")
public List getPersons() {
	log.info("getPersons entered");
	List persons = companyDirectory.getPersons();
	List personDTOs = new ArrayList();

	for (Person person : persons) {
		personDTOs.add(getPersonDto(person));
	}

	return personDTOs;
}

private com.persistent.dto.Person getPersonDto(Person person) {
	com.persistent.dto.Person personDTO = servermapper.map(person, com.persistent.dto.Person.class);
	return personDTO;
}

Conclusion

We have decoupled the JAXB annotations from the entity objects and have utilized a data transfer object to provide the JAXB conversion. This decoupling leads to greater easy of extention to our entities and places the JAXB services closer to the point of use rather than bleeding them into other parts of the application.

Build Instructions

The build instructions are the same as before. Click here for the build instructions.

The Source Code

updated Source Code: October 29, 2009

About The Author

David Sells is a computer consultant in Toronto, Ontario who specializing in Java Enterprise Development. He has provided innovative solutions for clients including: IBM, Goldman Sachs, Merrill Lynch and Deutsche Bank.

He also holds the following certifications:

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 (2009)
Sun Certified Web Component Developer
Sun Certified Java Programmer.

Contact: david@persistentdesigns.com

Simple SOAP Client using XMLBeans

zen — Fri, 16 Oct 2009 20:46:46 +0000

Introduction

In this article we discuss the construction of a client API to the Soap Server constructed in the prervious article: Simple Spring-WS Application [with JPA and Jersey REST]. The product of this client project will be a jar file that can be included as a pom depenency (Maven) to provide easy access to the web services of that previous article. In the next article we will utilizes this client jar file to connect to the web service where we will see the benfit both of the sepration of concerns as well as the ease in which we can integrate through Maven.

Implementing the SOAP Client using XMLBeans

From the last article we created a service for a company directories which allowed the following functionality:

get all persons
get all companies
get persons in a company
update person
create person
delete person

In our client project we wish to make a request on a web service which will carry out the following basic behaviour:

dispatch a request to the web service
recieve a response from the web service

On the SOAP Server side we utilized XJC to generate from the XSD the classes that are used to serialize our entity objects in and out of SOAP messages. These intermediaries act as a sort of data transfer object which come with their own bean mapper: mapping the entity objects into the XSD generated schema objects.

On the client side we are utilizing XMLBeans services to provide the marhalling of our objects. XMLBeans xml beans is a technology that enables access to XML through binding it to Java types. Much of the work is automated by the xmlbeans-maven-plugin in the POM file. We include the general-client.jar that we created in the previous article. This jar contains the XSD file used by the XMLBean plugin to generate the schema classes that we will be populating with our SchemaUtil. Below are the related additions to the POM file.


	org.codehaus.mojo
	xmlbeans-maven-plugin
	2.3.2
	
		
			
				xmlbeans
			
		
	
	true
	
		
			com.persistent:general-client
		
		target/xmlbeans-xsds/schema
		target/generated/xmlbeans
		true

To send the message to add a person we will be serializing a person object from the client side. The following sequence diagram describes what is happening in process of dispatching an add person request and response:

To Connect with the Web Service we utilize WebServiceGatewaySupport from Spring. The WebServiceGatewaySupport is a convenient super class for applications that need Web services. We are utilizing it in a very generic way with our single endpoint.

The coding required to implement the client is minimal. As illustrated in the sequence diagram above here is the code that implements the add person function:

public Person createPerson(final Person person) throws DatatypeConfigurationException {
		logger.info("Entered SoapCompanyDirectory createPerson");
		Enum add = Operation.CREATE;
		PersonRequestDocument personRequestDocument = PersonRequestDocument.Factory.newInstance();
		PersonRequest personRequest = personRequestDocument.addNewPersonRequest();
		personRequest.setOperation(add);
		logger.info("Before null assert");
		assert(person!=null);
		logger.info("After null assert");
		personRequest.setPerson(SchemaConversionUtil.toSchemaType(person));
		PersonResponseDocument personResponseDocument = (PersonResponseDocument)getWebServiceTemplate().marshalSendAndReceive(personRequest);
		PersonResponseDocument.PersonResponse personResponse = personResponseDocument.getPersonResponse();
		return SchemaConversionUtil.toEntityType(personResponse.getPerson());
	}

The class SoapCompanyDirectory extends the WebServiceGatewaySupport class to provide the functions required to support the methods available on the SOAP server. We utilize this class in CompanyDirectoryImpl. This class implements the CompanyDirectory interface that we developed in the service project. This now provides us with the option of inject, in a Spring application, either a local or remote SOAP CompanyDirectory service.

The following is the class diagram:

Spring ApplicationContext

The Spring ApplicationContext file pulls the elements together setting the messageFactory used by the SoapCompanyDirectory ( derived from WebServiceGatewaySupport) to SaajSoapMessageFactory. SaajSoapMessageFactory provides the SSAJ-specific implementation implemention of the WebServiceMessageFactory utilized by SoapCompanyDirectory. Additionally the marshalling of the objects from schema to entity class representation is provided throught the XmlBeanMarshaller.

Installation Instructions

On down loading the source code which is in a zip filed called: gclient.zip uncompress it
To build type: mvn install -Dmaven.test.skip=true
Start the SOAP server as described in the previous article.
run the tests to validate the installation and build of the SOAP Client with: mvn test

The Source Code

Follow this link to down load the source code.

Update code (Addition of REST Client code see: Jersey REST Client) October 29, 2009

About The Author

He also holds the following certifications:

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 (2009)
Sun Certified Web Component Developer
Sun Certified Java Programmer.

Contact: david@persistentdesigns.com

Simple Spring-WS Application [with JPA and Jersey REST]

zen — Wed, 23 Sep 2009 18:50:35 +0000

Introduction

In this article we will add a SOAP service utilizing Spring-WS to our evolving project. This is a continuing series of articles whose purpose is to provide working examples of technologies integrated in a Spring based web application. Our latest edition will join the previously integrated technologies which include: Jersey (REST), JPA, Hibernate, JavaScript, AJAX and Groovy. These are developed in a Maven2 build environment with testing through JUnit4 and reporting via PMD and Cobertura. This installment will add a SOAP service but we will put off writing the client until the next article and in its place we will utilize an useful application called SoapUI to test our SOAP service. The following article will utilize XmlBeans and Spring MVC to create a web client for the SOAP service.

Using Spring-WS 1.5

Contract-First versus Contract-Last

There are two ways to implement web services:

The contact-last approach allows for the generation of the xsd and wsdl directly from the Java classes.
The contract-first utilize the wsdl as the contract. The java classes are constructed with respect to that contract.

Spring has chosen to implement the contract-first approach. They have,discussed this point in the Spring Web Services Reference in Chapter 2. Why Contract First? To summarize, from their article, the key advantages to this approach are:

Easing the Object/XML impedance mismatch by allowing explict handling of:
- xsd extensions
- unportable types
- cyclic graphs
Additionally the contract-approach provides a less fragile solution with reusable components.

Describing the Schema

In the schema we will model the entity classes and the messages that we wish to send through our SOAP service. Our domain model is simple and small consisting of two class Person and Company. Below is what they look like as encoded in the XMLSchema:

We also need describe the messages that will request data. We are limiting our web service operations to the following service api:

CompaniesResponse getCompanies(CompaniesRequest companiesRequest);
PersonResponse getPerson(PersonRequest personRequest);
PersonsResponse getPersons(PersonsRequest personSearchRequest);
TableCountResponse getTableCount(TableCountRequest tableCountRequest);

Through these methods we will be able to service the functions that we have been using in our previous REST implementation. The functions include:

get all persons
get all companies
get persons in a company
update person
create person
delete person

Note in the service api, above, we are utilizing the following classes:

CompanyRequest/CompanyRequest
PersonRequest/PersonResponse
TableCountRequest/TableCountResponse
PersonSearch

These are utility classes that are generated to pass the request and response information through our SOAP messages. These classes are not actually written directly in java but are generated from their XSD definition via the SUN xjc compiler. These elements are defined in the CompanySearch.xsd. To get a feel for writing the XSD definitions we will work through the definition of the PersonRequest/PersonResponse elements. First note that there are xml elements to deal with the Person class both singly and in a collection. The PersonRequest/PersonResponse elements deal with single Person operations such as: create, read, update and delete (crud). Looking first at the PersonRequest it contains a sequence that requires one-and-only-one operation defined and optionally a PersonCriteria or/and Person element. So first we have an Operation, this operation has been encoded as an enumeration with the CRUD methods we wish to apply to a Person element/entity . The operations that the PersonRequest can make are:

CREATE operation require that the person element be supplied
READ operation this will be done with a PersonCriteria element, this PersonCriteria element gives us the criteria for the search for the appropriate Person.
UPDATE operation requires the person element
DELETE operation requires the person element

Schema definitions of PersonRequest, PersonResponse and Operation

The entire CompanySearch.xsd can viewed in the link below.

SOAP Request to endpoint

Lets backup a bit and take a higher level view of what is happening here. Below is a diagram that helps provide context to the code, xml and configuration. In the diagram we see what happens as a message comes into our web service and is mapped to an endpoint in the application which services the requests and returns a response message. We will now step through these processes to get an understanding of how this sequence of events is encoded in our application.

Message to MessageDispacher

First the web server receives a SOAP Request. For example: PersonRequest. The web.xml file is configured as follows:


	spring-ws
	org.springframework.ws.transport.http.MessageDispatcherServlet
	
		transformWsdlLocations
		true
	


	spring-ws
	/companies/*

Soap Message would look like this (it is a create Person request):

The soap message is passed to a web service url which would be: http://localhost:8080/general/companies. The servlet mapping would map the soap request passing it on to determine its endpoint mapping.

EndpointMapping, EndpointAdapter and Endpoint

EndpointMapping

The interface EndpointMapping defines the mapping between a message request and their associated endpoint objects. PayloadRootQNameEndpointMapping and SoapActionEndpointMapping are implementation of this interface additionally, and most importantly for our case, AbstractEndpointMapping implements the interface which will serve Spring’s endpoint interceptor. Looking at the spring-ws-servlet.xml we are utilizing a specializting of the AbstractEndpointMapping called PayloadRootAnnotationMethodEndpointMapping. Below shows snippets from the configuration and a view of how the endpoint annotations are applied. From spring-ws-servlet.xml


        
            Detects @PayloadRoot annotations on @Endpoint bean methods. The CompanyDirectoryEndpoint
            has such annotations. It uses two interceptors: one that logs the message payload, and the other validates
            it according to the 'ComapnySearch.xsd' schema file.

From CompanyDirectoryEndpoint.java

@Endpoint
public class CompanyDirectoryEndpoint implements CompanyDirectoryService {
@PayloadRoot(localPart = "PersonRequest", namespace = "http://persistent.com/schema")
	public PersonResponse getPerson(PersonRequest personRequest)
			throws DatatypeConfigurationException {
		Operation operation = personRequest.getOperation();
		PersonResponse personResponse = objectFactory.createPersonResponse();
		if( operation.equals(Operation.READ)) {
			long id = personRequest.getPersonCriteria().getId();
			Person person = companyDirectory.getPerson(id);
			personResponse.setPerson(SchemaConversionUtil.toSchemaType(person));
		} else 	if( operation.equals(Operation.DELETE)) {
			long theId = personRequest.getPersonCriteria().getId();
			Person person = companyDirectory.getPerson(personRequest.getPersonCriteria().getId());
			deletePerson(theId);
			personResponse.setPerson(SchemaConversionUtil.toSchemaType(person));
		} else if(operation.equals(Operation.CREATE)) {
			Person person = createPerson(personRequest.getPerson());
			personResponse.setPerson(SchemaConversionUtil.toSchemaType(person));
		}  else if(operation.equals(Operation.UPDATE)) {
			updatePerson(personRequest.getPerson());
		}
		return personResponse;
	}

EndpointAdapter

The application uses the GenericMarshallingMethodEndpointAdapter. Given that the message is appropriate for the adapter the adapter transformes the message with the configured marshaller. In our application we are utilizing a Jaxb2Marshaller. Below is the configuration of the EndpointAdapter and its’ marshaller. The Jaxb2Marshaller builds the approprate factories to map and build the schema objects from the incoming xml elements and types.

   
	      
            This endpoint handles the Company Directory Service messages using JAXB2 marshalling.
        
        
	
 	
        
            Detects @PayloadRoot annotations on @Endpoint bean methods. The CompanyDirectoryEndpoint
            has such annotations. It uses two interceptors: one that logs the message payload, and the other validates
            it according to the 'ComapnySearch.xsd' schema file.

Endpoint

The final destination is one of the CompanyDirectoryEndpoints methods or as annotated @PayloadRoot. The java docs PayloadRoot marks an endpoint method as the handler for an incoming request. The annotation values signify the the request payload root element that is handled by the method. You can see the @PayloadRoot used in CompanyDirectoryEndpoint.java above.

WSDL Creation

Although the Spring-WS philosophy is Contract-First we do still get some xml automation and this comes in a bean which creates are WSDL file. All we need to do is provide a few parameters: the xsd file(s), port name, location uri and its’ target namespace. Here is the bean definition from spring-ws-servlet.xml:


	
		Builds a WSDL from the schema/CompanySearch.xsd.
	

	
	
	
	
	
	



	 This bean wrap the messages.xsd (which imports types.xsd), and inlines them as a one.

The entire spring-ws-servlet.xml can be viewed below:



	

	
		
			Builds a WSDL from the schema/CompanySearch.xsd.
		

		
		
		
		
		
		
	

	
		 This bean wrap the messages.xsd (which imports
			types.xsd), and inlines them as a one. 
		
		
	

	
	      
            This endpoint handles the Company Directory Service messages using JAXB2 marshalling.
        
        
	
 	
        
            Detects @PayloadRoot annotations on @Endpoint bean methods. The CompanyDirectoryEndpoint
            has such annotations. It uses two interceptors: one that logs the message payload, and the other validates
            it according to the 'ComapnySearch.xsd' schema file.
        
        
            
                
                
                    
                    
                    
                
            
        
        
    

    	
    
			
		
    
		
			
				com.persistent.schema.Company
				
				com.persistent.schema.CompaniesRequest
				
				com.persistent.schema.CompaniesResponse
				
				com.persistent.schema.CompanySearchCriteria
				
				com.persistent.schema.Person
				
				com.persistent.schema.PersonRequest
				
				com.persistent.schema.PersonResponse
				
				com.persistent.schema.PersonsResponse
				
				com.persistent.schema.PersonsRequest
				
				com.persistent.schema.PersonCriteria
				
				com.persistent.schema.PersonSearchCriteria
				
				com.persistent.schema.TableCountRequest
				com.persistent.schema.TableCountResponse

Notes on the Web Services Build

In the build of the web application Sun’s XJC compiler builds the schema objects from the xsd file. You can see the generated files off of the target/generated-sources/xjc directory. These classes are utilized in the application as shown above in the snippet from CompanyDirectoryEndpoint.java where we are utilizing classes such as PersonRequest and PersonResponse which are both products of this generation process. The xjc compiler is configured in the build section of our pom.xml:


	com.sun.tools.xjc.maven2
	maven-jaxb-plugin	1.1
	
		
			generate-sources
			
				generate
			
		
	
	com.persistent.schema
		src/main/webapp/schema

Additionally we have added a section to the POM file to create a client jar that can be added to the repository to be used as a dependency is a client to this webservice.


	org.apache.maven.plugins
	maven-jar-plugin
	
		
			package
			
				jar
			
			
				
	This plugin is being used to capture the information that will be used
 	in our client application.  Creating this jar will also create an associated
 	pom which will carry all its required dependencies so we will not need to deal
 	with in the client application.
				
 			client
			target/general/WEB-INF/classes
				
					**/*.xsd
					**/persistent/entity/*
					**/persistent/datasource/*
					**/persistent/service/*

Installing SOAP Stubs for client

The maven-jar-plugin will create a jar file called general-client.jar. I did see a way to automatically make it a first class repository item so I used the following script to install the jar file in the repository for easy access from a pom needing access to it. The installit.sh is located in the resource directory and is to be run from that location. Its contents are as follows: mvn install:install-file -Dfile=../../../target/general-client.jar -DgroupId=com.persistent -DartifactId=general-client -Dversion=1.0 -Dpackaging=jar -DgeneratePom=true

Two Models

There is a divergence from our REST implementation. There we marked-up the Entity object directly with JAXB annotations to make them available for serialization to our clients (albeit also transformed to JSON). To service the SOAP request we are using two models which we convert between. One model is assocated with the schema where the class are generated through the XJC compiler we just mentioned above. The other model the entity model which we have been working with. This decoupling of the schema and entity model can be viewed having both positive and negative attributes. There is a untility class that helps with the conversin between model called: SchemaConversionUtil. Its’ use can be seen in the CompanyDirectoryEndpoint.java class.

Running SoapUI against the SOAP Web Service

You will find how to get the SOAP server up and running from the Installation Instructions section below. To get the SoapUI client running we need to follow the following steps:
Down load and install the SoapUI application. There is a free version provided by EviWare located here.
Start the web application and start SoapUI
In the SoapUI interface select the menu item under File called New soapUI Project. Assign any project name you prefer and for the Inital WSDL/WADL enter: http://localhost:8080/general/companies/companySearch.wsdl as shown below:

On selecting OK the SoapUI application read the WSDL at the the URI provided. With the information from the WSDL SoapUI will provide a tree menu of SOAP request that you can send. Below is a picture of using the TableCountRequest where we have set the table name to the Enumeration (as defined in the CompanySearch.wsdl) Person. On the right hand side we can see that the web service returned a value of 10.

The other Soap requests of interest are:

Class Diagram

The class diagram builds out only a couple of classes from our previous project. It does however utilize the components available to it through programming to an interface and Springs IOC.

Installation Instructions

On down loading the source code which is in a jar filed called: general.jar uncompress it:

jar xvf general.jar

There will now be a new directory called general.

Database configuration. In the directory general/main/resources the file general.properties contains the information regarding your database configuration including: user, password, Driver and database name. If you are using MySQL locally then all that needs to change would be the username and password. You will also either need to change the jdbc.url to a database you have already or create the database jpa used by the project.

Go back to the general directory where the pom.xml file is and you are ready to compile and run the program. Maven2 makes this simple. To compile and run (the clear command is in here too. It isn’t important for the first build but is important as one begins development with the code).

mvn clean install

In this process the program will run through the JUnit test cases. If a test fails you will not be able to run the program until the defect is fixed. You can override the tests (and hope the program will run) by using a flag:

mvn clean install -Dmaven.test.skip=true

Now we are ready to run the program. Enter:

mvn jetty:run

The jetty server will startup and you will then be able to interact with the application’s REST webservice using cURL or the html webpage. To use the html webpage use this URL:

http://localhost:8080/general/

Additionally you will be able to run the SoapUI against the SOAP web service.

As descirbed above, for clients to this SOAP service, add the general-client jar into the repository to be available as a dependency:

The installit.sh is located in the resource directory and is to be run from that location. Its contents are as follows:

mvn install:install-file -Dfile=../../../target/general-client.jar -DgroupId=com.persistent -DartifactId=general-client -Dversion=1.0 -Dpackaging=jar -DgeneratePom=true

Running Reports

There are three report plugins configured in the pom.xml. Sample output of these reporting engines can be viewed through the links in the Project Reports section of the article. The simple Maven command to create each of these reports are as follows:

PMD Report

mvn pmd:pmd

Cobertura Report

mvn cobertura:cobertura

Surefire Report

surefire-report:report-only

Eclipse Integration

If you are interested in importing this project into your eclipse environment the following command will create the configuration files required to import the project into eclipse as an existing eclipse project. This command is run, as the others are, from the root directory general:

mvn eclipse:eclipse

Also when the application is imported into the Eclipse environment insure that the generate code directory is included as a source directory to the project. This is done by opening the properties dialog of the imported project and selecting the Java Build Path and from the Source tab select Add Folder and add the general/target/generated-sources/xjc directory.

Conclusion

That concludes this article. We now have an application that makes available the Company Directory information through SOAP services. This is in a environment which will also service REST requests. In the next article we will supply the client portion to this SOAP service which will utilize XmlBeans and Spring MVC.

The Source Code

The complete code listing is here. Note there has been a refactoring on this code. The refactoring pertains to the REST portion of the application but does effect the entity objects. For more information please see this article: Separation of Concerns: Refactoring of Evolving Project Refactored Maven2 Project.

About The Author

He also holds the following certifications:

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 (2009)
Sun Certified Web Component Developer
Sun Certified Java Programmer.

Contact: david@persistentdesigns.com

A Groovy Rest Client for the JPA, Jersey, Spring Integration Project

zen — Sat, 12 Sep 2009 02:32:13 +0000

Introduction

In this article we are presenting a simple Groovy client to use with our REST service created in the previous article: REST Project Digest and Generic Data Repository. In that last article we constructed a REST service that uses JPA/Hibernate in the backend to service a simple Company Directory. It is a two table one-to-many relationship between Companies and Persons. In that article the client was written with a combination of html and JavaScript, utilizing the services of Protocol.js.

We are using Groovy to render a REST client using Java Swing application. For communication we use HTTPClient from Apache. We also use a JSON library for encoding and decoding the transmitted data. Groovy is a wonderful utility for taking the drudgery out of using the Swing libraries. Although Swing is an excellent implementation the result/effort ratio is low.

Design

This is a utility program without a great deal of function so the design is slim. The progarm is broken into three parts: entity, REST client and a Swing script. All the parts are written in Groovy.

Entities

There are two entities: Person and Client. They are simple pojos. Part of the Person class is shown below the Company class is similarly straight forward.

public class Person{
	private int id;
	private String name;
	private int age;
	private Company company;

	public Person() {
	}
	public Person(String name,int age, Company company){
		this.name = name
		this.age = age
		this.company = company
	}
	public Person(int id, String name,int age, Company company){
		this.id = id
		this.name = name
		this.age = age
		this.company = company
	}
	:
	:

The REST Client

The rest client construction utlizes two tools: HTTPClient and a JSON library. The HTTPClient software provides an efficent api for our POST, PUT, GET and DELETE commands. The REST service we are using produces and consumes JSON objects, the JSON library helps us switch between JSON and beans in the application.

Below is the update method. We did have some difficulties using the JSON library to it’s full potential due to confusion between Numbers and Strings. The values from the REST service were surround, as Strings are, by quotations. This resulted in our POJOs being populated with the ASCII numeric of the number. In the snippet below we are using a brute force method to encode the JSON for transmission.

public List putUpdate(Person person) {
		def url = "http://localhost:8080/general/webresources/person/update"
		def brute ='{"id":"'+person.id+'","name":"'+person.name+'","age":"'+person.age+'","company":{"id":"'+person.company.id+'","name":"'+person.company.name+'"}}'

		PutMethod put = new PutMethod(url);
		RequestEntity entity = new StringRequestEntity(brute, "application/json", "ISO-8859-1");

		put.setRequestEntity(entity);
		execute(put);
		return getDirectory();
	}

The full class is below if you would like to take a closer look.

package com.persistent.client

import com.persistent.entity.Company
import com.persistent.entity.Person

import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.UsernamePasswordCredentials;
import org.apache.commons.httpclient.HttpMethodBase;
import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.httpclient.methods.PutMethod;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.DeleteMethod;
import org.apache.commons.httpclient.methods.StringRequestEntity;
import org.apache.commons.httpclient.methods.RequestEntity
import net.sf.json.groovy.JsonSlurper;
import net.sf.json.JSONArray;
import net.sf.json.JSONObject;
import groovy.text.SimpleTemplateEngine

/**
 * @author david
 *
 */

public class DirectoryClient{
	static String URL_BASE = "http://localhost:8080/general/webresources"
	def directories = [];

	public DirectoryClient() {

	}

	private void execute(HttpMethodBase method){
		HttpClient httpclient = new HttpClient();

		try {
			httpclient.executeMethod(method);
		} finally {
			// Release current connection to the connection pool once you are
			// done
			method.releaseConnection();
		}
	}

	public void deleteDelete(Integer id) {
		def url = URL_BASE+"/persons/"+id;
		DeleteMethod delete = new DeleteMethod(url);
		execute(delete);
	}

	public List putUpdate(Person person) {
		def url = URL_BASE+"/person/update"
		def brute ='{"id":"'+person.id+'","name":"'+person.name+'","age":"'+person.age+'","company":{"id":"'+person.company.id+'","name":"'+person.company.name+'"}}'

		PutMethod put = new PutMethod(url);
		RequestEntity entity = new StringRequestEntity(brute, "application/json", "ISO-8859-1");

		put.setRequestEntity(entity);
		execute(put);
		return getDirectory();
	}

	public List postAdd(Person person) {
		def url = URL_BASE+"/person"
			def brute ='{"id":"'+person.id+'","name":"'+person.name+'","age":"'+person.age+'","company":{"id":"'+person.company.id+'","name":"'+person.company.name+'"}}'
			PostMethod put = new PostMethod(url);
			RequestEntity entity = new StringRequestEntity(brute, "application/json", "ISO-8859-1");
			put.setRequestEntity(entity);
			execute(put);
			return getDirectory();
	}

	public List getCompanies() {
		def url = URL_BASE+"/companies"

		def get = new GetMethod(url)
		get.setRequestHeader("Accept", "application/json")

		def client = new HttpClient()
		client.executeMethod(get)
		JSONObject jsonObject = JSONObject.fromObject( get.getResponseBodyAsString().toString() );
		JSONArray jsonArray = JSONArray.fromObject(jsonObject.get("company"));
		return jsonArray;
	}

	public List getDirectory() {
		def url = URL_BASE+"/persons"
		def get = new GetMethod(url)
		get.setRequestHeader("Accept", "application/json")

		def client = new HttpClient()
		client.executeMethod(get)
		JSONObject jsonObject = JSONObject.fromObject( get.getResponseBodyAsString().toString() );
		JSONArray personJSONArray = JSONArray.fromObject(jsonObject.get("person"));

		def companies = getCompanies();
		def companiesNew = []

		for(Company c in companies) {
			def id = c.id;
		    def count = 0;
		    def personArray = [] 

			for(Person dude in personJSONArray) {
				if(id == dude.company.id) {
					// unfortunately the id for the JSON Company object is returned as a String such that 1 becomes 50 in ascii when converted to an integer
					// hence we re-construct the object correctly.
				    def person = new Person(id:dude.id.toInteger(),name:dude.name,age:dude.age.toInteger(),company:new Company(id:c.id.toInteger(),name:c.name));
					personArray.add(person);
				}
			}
		    companiesNew.add(new Company(id:c.id.toInteger(),name:c.name,employees:personArray))
		}

		return companiesNew;
	}
	public List getDirectories() {
		return directories;
	}
}

Groovy Swing Client

This is one place that Groovy really shines. It makes Swing a far more productive tool. In this example I have choosen a scripting style to produce the user interface. One could have also created a class but give the utility nature of the exersise I choose to use the less formal approach. Although Groovy does reduce the code required to produce your end result it does not relinquish you of the need to understand Swing framework.

import java.awt.Dimension
import java.util.LinkedHashMap
import javax.swing.*
import javax.swing.tree.DefaultMutableTreeNode as TreeNode
import groovy.swing.SwingBuilder
import groovy.model.ValueHolder
import groovy.model.DefaultTableColumn
import groovy.model.DefaultTableModel
import groovy.model.PropertyModel
import javax.swing.event.TableModelListener
import javax.swing.event.ListSelectionListener
import java.awt.BorderLayout
import java.awt.FlowLayout;
import javax.swing.JComboBox

import com.persistent.client.DirectoryClient
import com.persistent.entity.Person
import com.persistent.entity.Company

def directoryClient = new DirectoryClient();

def directoryList = directoryClient.getDirectory()

def employeeList = [];
def employeeTable;
def swing = new SwingBuilder()
def nameTF;
def ageTF;
def combo;
JTree directoryTree
Company currentCompany;
Person selectedPerson;

def addButton;
def updateButton;
def deleteButton;
def clearButton;

def updateTree = {
		directoryTree.model.root.removeAllChildren()
		directoryList.each {company ->
		    def node = new TreeNode(company)
		    company.employees.each { employee -> node.add( new TreeNode(employee));}
		    directoryTree.model.root.add(node)
		}
		directoryTree.model.reload(directoryTree.model.root)
}

def selectEmployee2 = { person ->
	if( person != null) {
		nameTF.text = person.name;
		ageTF.text = person.age;
		println "Select id with: "+person.company.id
		println "Or name: "+person.company.name

		println "Is the index"+directoryList.indexOf(person.company)
		// Too cool for school
		// The statement below find in the directoryList the company that the person is associated with and we
		// use that company to find the index in the list of that company.
		combo.selectedIndex = directoryList.indexOf(directoryList.find(){it.id==person.company.id})
		selectedPerson = person
		  deleteButton.visible = true;
 		  addButton.visible = false;
 		  updateButton.visible = true;
	}
};

def selectEmployee = { employeeId ->
	selectEmployee2(currentCompany.employees.get(employeeId))
}

def setEmployeeTableModel = { company ->
		employeeList = company.employees;
	    def listModel = new ValueHolder(employeeList)
	    def model = new DefaultTableModel(listModel)
	    model.addColumn(new DefaultTableColumn("Identifier", new PropertyModel(model.rowModel, "id")))
	    model.addColumn(new DefaultTableColumn("Name", new PropertyModel(model.rowModel, "name")))
	    model.addColumn(new DefaultTableColumn("Age", new PropertyModel(model.rowModel, "age")))
	    swing.table1.setModel(model)
	    currentCompany = company;
}
def selectFirstInCompany = { company ->
//Initialize the employee table and Employee section using first company in directory
//and the first employee in the companies employ.
setEmployeeTableModel(company);
selectEmployee2(company.employees.get(0))
}

swing.frame(title: 'CompanyDirectories', defaultCloseOperation: JFrame.DISPOSE_ON_CLOSE,
    size: [900, 350], show: true, locationRelativeTo: null) {
    lookAndFeel("system")
    menuBar() {
        menu(text: "File", mnemonic: 'F') {
            menuItem(text: "Exit", mnemonic: 'X', actionPerformed: {dispose() })
        }
    }
    splitPane {
        scrollPane(constraints: "left", preferredSize: [160, -1]) {
            directoryTree = tree(rootVisible: false)
        }
        splitPane(orientation:JSplitPane.VERTICAL_SPLIT, dividerLocation:40) {
        	scrollPane(constraints: "top") { textArea(id:'companyInfo') }
            scrollPane(constraints:"bottom") {
            	panel {
            		borderLayout()

            		employeeTable = table(autoCreateColumnsFromModel:true,id:'table1',constraints:BorderLayout.NORTH) {
            			current.selectionModel.addListSelectionListener({e ->
            				if(e.source.minSelectionIndex >-1){
            					selectEmployee(e.source.minSelectionIndex);
            				}
            			} as ListSelectionListener)
            		tableModel(list:employeeList) {
            			propertyColumn(header:'Name', propertyName:'name')
            			propertyColumn(header:'Age',propertyName:'age')
            		}
            	}
            	panel(constraints:BorderLayout.CENTER){
            	}
            	panel(constraints:BorderLayout.SOUTH){
            				name = label()
            				name.text = "Name:"
            				nameTF = textField()
            				nameTF.columns = 15

            				age = label()
            				age.text = "Age:"
            				ageTF = textField()
            				ageTF.columns = 2

            				combo = comboBox(items:directoryList)

            			    updateButton = button(
            			            text:'Update',
            			            actionPerformed: {
            			    			selectedPerson.age = ageTF.text.toInteger()
            			    			selectedPerson.name = nameTF.text
            			    			selectedPerson.company = combo.model.getSelectedItem();
            			    			println "The selected company is: "+selectedPerson.company
            			    			println "The id of the selected company is: "+selectedPerson.company.id
            			    			println "The name of the selected company is: "+selectedPerson.company.name

            			    			directoryList = null;
            			                directoryList = directoryClient.putUpdate(selectedPerson);
            			                updateTree()
            			                selectFirstInCompany(directoryList.get(0))
            			            }
            			        )
            			     addButton = button(
            			            text:'Add',
            			            actionPerformed: {
            							selectedPerson = new Person(nameTF.text,ageTF.text.toInteger(),combo.model.getSelectedItem())
            			                directoryClient.postAdd(selectedPerson);
            			                directoryList = directoryClient.getDirectory();
            			                updateTree()
            			                selectFirstInCompany(directoryList.get(0))
            			            }
            			        )
            			     addButton.visible = false
            			     clearButton = button(
            			    		 text:'Clear',
            			    		 actionPerformed: {
							ageTF.text = '';
	            			    		 nameTF.text=''
							deleteButton.visible = false;
							addButton.visible = true;
							updateButton.visible = false;
            			    		 }
            			    	)
            			    deleteButton = button(
            			    		 text:'Delete',
            			    		 actionPerformed: {
            			    			 ageTF.text = '';
            			    			 nameTF.text=''
            			    			directoryClient.deleteDelete(selectedPerson.id);
             			                directoryList = directoryClient.getDirectory();
             			                updateTree()
             			                selectFirstInCompany(directoryList.get(0))

            			    		 }
            			    	)
            			}
            }
           }

        }
    }
}

directoryTree.valueChanged = {
	node = (TreeNode) directoryTree.getLastSelectedPathComponent();
	if (node != null) {
		if(node.getUserObject() instanceof Person) {
			Person aselectedPerson = (Person)node.getUserObject();
			// The parent node is the Company to whom the selected person belongs.
			parentNode = node.getParent();
			currentCompany = parentNode.getUserObject();
			selectEmployee2(aselectedPerson);
		    	if( aselectedPerson.company instanceof Company) {
				def theDirectory = directoryList.find{ it.id == aselectedPerson.company.id }
				if( theDirectory != null ) {
		    			setEmployeeTableModel(theDirectory)
				}
			} else {
				println "UNEXPECTED: "+parentNode.getClass().getName()
			}
		} else {
		    	// the node has a key and a value.  The key is this id of the company selected.  The value is the Company object.
		    	if( node.getUserObject() instanceof Company) {
		    		setEmployeeTableModel(node.getUserObject())

			}
		}
		swing.companyInfo.text = currentCompany.name;
	}
}

updateTree()
selectFirstInCompany(directoryList.get(0))
swing.companyInfo.text = currentCompany.name;

A Picture of the User Interface in Action

Source Code and Instructions

Here is the source code in a jar file. I suppose that my choice of file name is questionable but here it is: groovy.jar.

Installation

Dowload the jar file
Extract the jar file with the command: jar xvf groovy.jar
There will now be a directory called groovy. Navigate into groovy and execute: mvn install. This will pull in the required jar files and build the project.
Start the REST service of the previous article.
Start the Groovy REST client with this command: mvn exec:java

Conclusion

That’s it! A simple user interface into a REST service utilizing Groovy.

About The Author

David Sells is a computer consultant in Toronto, Ontario specializing in Java Enterprise Development. His clients have included companies such as: IBM, Goldman Sachs, Merrill Lynch and Deutsche Bank.

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5

Contact: david@persistentdesigns.com

REST Project Digest and Generic Data Repository

zen — Tue, 01 Sep 2009 23:17:57 +0000

Introduction

In this installment we will review the progression made through the previous REST-Jersey-JPA-Spring articles. We will also be extending our sample program in two ways. First we are going to service two tables with a one-to-many association. The enhancement will present a few new challenges and provide a stronger base for future developments. Second we are adding some design elements to our application which will increase the extensibility, manageability and scalability of the solution.

Progression of the Project

Jersey,Spring and JPA

In this article we presented the integration of Jersey, Spring and JPA. An integration that was worth blogging to illuminate the conflict between jar versions blocking a quick efficient integration. The client code for this project was a simple webpage or through the user of cURL.

REST CRUD: Jersey, Spring and JPA

Here we extended our original project to include the full CRUD (create, read, update and delete) functionality through REST. An enhanced web client was introduced to demonstrate the functionality. The Ajax interaction was provided through a modified Prototype.js library.

Extending the CRUD Example Utilizing JAX-B and Jersey’s JSON

The previous article created json manually by constructing of a string. In this article we use JAX-B 2’s annotations to mark-up the entity to make these POJO’s available for serialization into XML and onto JSON.

Quality Control: get rid of the CRUD and get REST

Here we added proper unit tests and reporting tools. Additionally we returned are modified Prototype.js library to it’s prestent state and instead added our own Ajax REST javascripts (albiet heavily based upon Prototype.js).

Sample Application

To be more demostrative of the user of the technologies in the application another entity has been added to the model with a one-to-many association. In business terms a company(Company) can have many employees (Person). We will be able to interact with these entites through the CompanyDirectoryRest REST resource.

Design Considerations

Currently the project is a straight-up implementation to meet the needs of integrating the technologies of interests with a crude implementation of the core CRUD operations. Through design the components of the application can be considered with respect to its ability to respond well to service level requirements such as: extensibility, scalability and manageability.

Here are some loose requirements that the application must full fill:

Provide a way to create services for a variety of clients
flexibility in the application design such that it may switch between protocols to the client such as: HTTP and SOAP.
abstract our data source such that we can alter where our data arise from: JPA, Hibernate, JDBC, a Webservice, EJB etc.

J2EE Patterns

First off we leverage a lot of support in providing a component-oriented application through the use of Spring’s dependency injection (DI). The first two requirements are satisfied through utilizing DI along with the J2EE Pattern Business Object. In this design the REST resource, CompanyDirectory, is a consumer of the Business Object. The Business Object being the object that handles are the association of the datasources and higher level business function. The REST resource, CompanyDirectoryRest, is a simple GOF Adapter; it modifies the interface of the business object to serve its’ client’s needs. This same strategy can be applied to extend the application to support other protocols. It can easily be imagined how one might create a SOAP Adapter to service SOAP Clients. Again the SOAP Adapter would consume the services of the Business Object and provide the SOAP functionaliy for communication of the information to the SOAP clients.

The third item in the requirements list is about data source abstraction. Again we are programming to an interface and utilizing DI. We are also programming with generics which provide a big boost to productivity and provide a point for extension. There is a very good article by the author of this portion of the code at the Belgium Jugs website. So we have the oportunity here to support other database through the GenericRepository and through newly introduced datasource interfaces we can consider adding alternate datasource such as: EJB’s, webservices, DAO and so on.

Programming to an interface along with DI creates the ability to make configuration changes simple and in turn addressing those interests in: extensibility, scalability and manageability.

diagram Class Diagram of the REST Project

Implementation

For more details on the implementation please see the other articles identified at the top of the document. In this section we will discuss details which arose in this implementation that differed from the previous projects.

JAXB and Generic Collections

We introduced the Company entity that maintains a collection of employees (Person). The class is marked-up this class with JAXB Annotations as the Person class was. There is a difficulty with using Generics with JaxB which needs to be delt with. The problem arises from the fact that the class types declared in a Generic collection is available only at compile time and is erased at runtime (type erasure). So when we JAXB utilizes an accessor to a generic collection such as:

@OneToMany(mappedBy = "company", fetch = FetchType.EAGER)
private List employees = new ArrayList();

	public List getEmployees() {
		return employees;
	}

at runtime the information with respect to the type Person is no longer available. So as JAXB attempts to serialize the collection it throws an exception because it can not determine the class type of collection. This will occur whether the class is annotated for access through fields or members. I don’t know of a way of doing this borth adirect and clean way. The solution employed in this sample is through the use of the GenericEntity class. This class is part of javax.ws.rs.core and is used precisely for this purpose. We have altered the getEmployees() method in Company to the following plus we have annotated the class with XmlAccessType set to PUBLIC_MEMBER so that when the class is transformed by JAXB it will use the method rather than the field.

public GenericEntity> getEmployees() {
	return new GenericEntity>(employees) {};
}

The solution is a little unattractive since it alters are natural use of the entity class and bleeds the jax.ws.rs api into the model which now makes it coupled.

GenericRepository (DAO)

As mentioned earlier the DAO or repository for our project is using Generics heavily. Our implementation is from this Belgium Jugs website the efforts of Jurgen Lush and Stephan Janssen. The generics remove the code replication that appears among implementation of DAOs. Coding to the GenericRepository inteface we open the possabilites to many persitent providers. In the sample a JPA provider GenericJpaRepository is coded. The generics can make DAO as simple as implement the following class and interface:

@Service("personDS")
public class PersonJpaRepository extends GenericJpaRepository
		implements PersonDS {
	//we inherit the basic CRUD operations from the GenericRepository
}

And

public interface PersonRepository extends GenericRepository {
}

That is a very brief way to construct a DAO. Note that wehave the PersonJpaRepository implementing the PersonDS (Person Data Source). This interface gives us the ability to consider options such as EJB’s or Webservices as datasources whcih fall outside the perview of the DAO.

Additionally we have moved the transactional management of the methods out of the class and are apply them through annotation defined in the applicationContext.xml. The settings are shown below:

REST Web Client

The web client from the previous projects has been extended to include the Company information as shown below.

Performance Improvement

We do have a great inefficiency here with our one-to-many relationship. We have annotated the relationship as having an eager fetch mode. This does provide some conveniences for coding but we pay for them through a big performance hit. For instance when the web page above loads it requests a list of companies and when it is retrieves that list in an eager fetch all the associated employees are also retrieved. When you have all that information then sent to the web page in JSON format, well its just not a good idea. Changing our fetch mode is a simple change. Our new employee accessor is annotated LAZY:

@OneToMany(mappedBy = "company", fetch = FetchType.LAZY)
private List employees = new ArrayList();

Additionally since the data is loaded lazily we will need a query for loading the Company object eagerly. For this we have added a NamedQuery annotation at the the top of the Company class. We have also expanded the CompanyDS to include a method to access data through named queries. There are other options we could explore that would not expose the method as a JPA/ORM/SQL query which would fascilitate a better interface for non-JPA/ORM/SQL interfaces, such as adding a method to the CompanyJpaRepository class but for now we’ll take the short cut.

A left join of the Company and a Fetch over the employees does the trick. The query is name Company.EagerFindById for ease of entity association and purpse.

@Table(name = "COMPANY")
@NamedQueries( { @NamedQuery(name = "Company.EagerFindByID", query = "FROM Company c left join fetch c.employees where c.id =?1") })
public class Company {

Here is the expanded CompanyDS interface:

public interface CompanyDS {
	public List findAll();
	public Company findById(final Long id);
	public Company save(final Company person);
	public Company update(final Company person);
	public Integer countAll();
	public void delete(final Company person);
	public List findByNamedQuery(final String name,final Object... params);
}

This is the new query in action.

List companies = companyDS.findByNamedQuery("Company.EagerFindByID", companyId);
Company persistedCompany = null;
if(companies.size()>0) {
	persistedCompany= companies.get(0);
}

Conclusion

In conclusion we accomplished a few items to improve our ever evolving project they include:

re-structued the code for extensibility, manageablity and scalability.
introduced a one-to-many relationship and made adjust must to the entity to accommodate for type erasure with respect to JAXB.
added a generic DAO that dramatically reduces the coding required to support a entity
switched the application to use AOP for transaction management

Project Reports

The Source Code

The complete code listing is here.

Installation Instructions

On down loading the source code which is in a jar filed called: general.jar uncompress it:

jar xvf general.jar

There will now be a new directory called general.

Database configuration. In the directory general/main/resources the file general.properties contains the information regarding your database configuration including: user, password, Driver and database name. If you are using MySQL locally then all that needs to change would be the username and password. You will also either need to change the jdbc.url to a database you have already or create the database jpa used by the project.

Go back to the general directory where the pom.xml file is and you are ready to compile and run the program. Maven2 makes this simple. To compile and run (the clear command is in here too. It isn’t important for the first build but is important as one begins development with the code).

mvn clean install

mvn clean install -Dmaven.test.skip=true

Now we are ready to run the program. Enter:

mvn jetty:run

The jetty server will startup and you will then be able to interact with the application’s REST webservice using cURL or the html webpage. To use the html webpage use this URL:

http://localhost:8080/general/

Running Reports

PMD Report

mvn pmd:pmd

Cobertura Report

mvn cobertura:cobertura

Surefire Report

surefire-report:report-only

Eclipse Integration

mvn eclipse:eclipse

About The Author

Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5

Contact: david@persistentdesigns.com