Oops Null Pointer

Java programming related

Wiring Restlet JaxRs application with Spring

When wiring a JaxRs application from Spring I got most of the way using this post. My issue was different as  I already had a bean ref context for the rest of my application that I wanted to get my bean from.

I also wanted to respect the scope of the objects in the Spring configuration files and the example seemed to be always creating new instances when calling beanFactory.createBean(jaxRsClas).

The key was to convert the class name into a string and call beanFactory.getBean(classAsName) and then casting the bean it’s (generic) type.

import org.apache.commons.lang.StringUtils;

/**
 * Uses application content and bean ref context in web.xml to wire each new object from Spring.
 */
public class SpringRestletServlet extends ServerServlet {

  private static final Logger logger = Logger.getLogger(SpringRestletServlet.class);

  /**
   * Override the createApplication method to inject Spring objects
   * @param context - Restlet context
   * @return - application instance
   */
  @Override
  public Application createApplication(Context context) {
    JaxRsApplication app = (JaxRsApplication)super.createApplication(context);

    // set up spring to be the object creator
    app.setObjectFactory(new SpringObjectFactory(getWebApplicationContext().getAutowireCapableBeanFactory()));
    return app;
  }

  private static class SpringObjectFactory implements ObjectFactory {
    private final AutowireCapableBeanFactory beanFactory;

    public SpringObjectFactory(AutowireCapableBeanFactory beanFactory) {
      this.beanFactory = beanFactory;
    }

    @Override
    public T getInstance(Class jaxRsClass) throws InstantiateException {
      logger.debug( "Wiring JAX-RS class [" + jaxRsClass + "] using Spring." );

      String classAsName = StringUtils.uncapitalize(jaxRsClass.getSimpleName());
      return castBeanToType(classAsName);
    }

    @SuppressWarnings("unchecked")
    private T castBeanToType(String classAsName) {
      return (T)beanFactory.getBean(classAsName);
    }
  }

  private WebApplicationContext getWebApplicationContext() {
    return WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext());
  }
}

And here is the related parts if the web.xml file that use the bean ref content that is on the classpath to get beans used by the rest of the application:


<context-param>
 <param-name>contextConfigLocation</param-name>
 <param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>

<context-param>
 <param-name>locatorFactorySelector</param-name>
 <param-value>classpath*:beanRefContext.xml</param-value>
</context-param>

<context-param>
 <param-name>parentContextKey</param-name>
 <param-value>keyInBeanRef</param-value>
</context-param></em>

<listener>
 <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!-- Restlet adapter -->
<servlet>
 <servlet-name>RestletServlet</servlet-name>
 <servlet-class>com.company.SpringRestletServlet</servlet-class>
</servlet>

<!-- Catch all requests -->
<servlet-mapping>
 <servlet-name>RestletServlet</servlet-name>
 <url-pattern>/*</url-pattern>
</servlet-mapping>
<pre>

Is REST over or just re-dressed?

I just read Steve Klabnik’s REST is over article which, while not as dramatic as the title suggests, pitches the admirable idea of renaming “real” REST services to Hypermedia APIs. I like the idea as I have felt and seen reoccurring confusion caused by (mis)understanding what representation state transfer encompasses. Steve’s main point is that the term Hypermedia clearly excludes certain types of REST-ish APIs. It certainly took me a little while to let go of idea of invoking operations and instead focus on changing the state of entities resources.

Steve’s article was also a call to stop arguing and start building. I saw the argument as a symptom of the confusion around focusing on the best way to live up to REST-ful principals. There is clearly a love of getting things done http with (typically) human readable message formats. I’m more included to peek at systems via their REST / JSON interfaces to quickly gather information rather than going via a client.

We think we still need a bite sized term for Hypermedia API; I like HAPI. Adding a little developer happiness can’t be argued with, right?

Book review: ExtGWT Rich Internet Application Cookbook

ExtGWT cookbook

Overview:

The ExtGWT Cookbook from Packt Publishing covers the GXT UI framework version 2 (currently at 2.2.6) as well as a quick overview of key features of GWT and some ideas on building robust UI frameworks. While a good knowledge of GWT itself is recommended, this book could be used a basic primer of some of the required concepts.

I think it’s important to bring up that the version of GXT this book covers is now a major revision behind the latest: GXT 3.0.

A lot has changed in GXT 3.0 and thus some of the detail in the Cookbook is not applicable to projects using this version. Some examples are:

  • The GXT data model (BeanModel) is now replaced by POJOs (using GWT AutoBeans)
  • Wigets can now use UIBinder
  • GXT Event listeners are replaced by GWT handlers
  • The flash charts are replaced by a new JavaScript based chart package

So with that in mind, who is this book useful for? The GXT widgets are relatively unchanged and this book covers the set-up and options of nearly all the widgets in detail and is still helpful from this aspect. The book also covers some useful ideas for building robust UI frameworks; it explores the idea of an “action” that different views can share, each which their own set of supported options. For those who have existing investments in applications using GXT 2 or are just starting projects will find this book a great companion – I wish I had this book during the creation of my current application as it would of helped clarify some of the quirks in GXT and replace the rather lack lustre GXT documentation. It also would of added some depth in the architecture, reducing repetition and linking related components.

Layout:

The ExtGWT Cookbook’s layout is code heavy – in a good way. Each recipe follows the format of a description of a feature, a “how do do it” code section and a detailed “how it works” line by line breakdown of the code. In this way you are rarely left wondering what a line of code does and any GXT quirks are normally highlighted and explained.

The progression of the examples builds well through each chapter and in the same way the chapters tend to naturally flow on from one another, so the book can be read linearly, but each chapter is self contained enough that you can jump into a recipe with little reference to other sections.

The main documentation that GXT provides is the API and a set of examples with code. While better than nothing, they often are not enough to cover real life scenarios or they leave important options out. The ExtGWT Cookbook has more examples with a focus on building practical applications, and importantly the examples are detailed and backed by a comprehensive description.

I felt the detail and relevance was typically compelling enough to encourage reading through whole chapters. Nearly ever chapter covered a new aspect or feature that I hadn’t previously been aware of, making reading this book worthwhile.

Chapters:

The first three chapters cover the basic elements of panels, windows, tabs and “click-ware” (buttons, toolbars and menus). The section on tabs shows real world experience in the example which toggles the tab strip based on the number of tabs. The last recipe of chatper 3 “Bind a single action to several click-wares” introduces a useful pattern to relate an underlying action or behaviour to different representations that is elaborated and expanded in Chapter 11 in the recipe “A novel UI with MVP, actions and a bus”.

The next four chapters cover GXT specific layouts, trees and grids with enough thoroughness to provide a good head start in using these components.

Chapter 8 covers the GXT templates which allow the modification of views within components with easy access to model data properties. This was a topic that I found GXT’s own documentation was particularly unhelpful, while this chapter succinctly covered with several handy examples.

The built in charts are well covered in Chapter 9, although few would find this flash based package very useful (especially for mobile devices). The last recipe “Drawing on a canvas” hints at alternatives, but for detailed charts look to GXT 3 or an external library.

The chapters “Drag-and-drop”  (chapter 10) and “Theming” (chapter 12) adequately explain these topics and the appendices provide thoughtful coverage of topics that GWT developers need to know.

I found the “Advanced Tips” chapter (11) the most useful and insightful as it covered important architectural concepts for larger applications (MVP, History, working with persistence frameworks). Having gone through the pain of building similar patterns before they were more commonly discussed for GWT projects, I like the way this chapter helps lay the foundations of testable and robust GWT based software. The working server push recipe was also stimulates thoughts on building more interactive applications.

Summary:

In all the ExtGWT Cookbook is a very detailed and comprehensive overview of GXT 2.x. It inspired me to read the whole thing cover to cover and I only really didn’t learn something from the charts chapter as we have moved to Highcharts (and GXT has moved to a new JavaScript based charting framework in GXT 3).

There are some aspects of GXT’s layout system that were (for me) difficult to deal with that are not covered in this book – in particular deeply nested layouts and using components in resizable windows (say a grid in a portlet in a resizeable window). The GXT documentation avoided complicated layouts and the cookbook’s layouts are typically not too complicated either. This book is aimed at the beginner to intermediate as it lacks some depth in relation to constructing large / complicated GXT based applications, but it still has enough detail to learn some useful tips from.

I’d look forward to a GXT 3 version by the same authors, especially if it covered some more advanced patterns.

Quick guide to transforming XML with XSLT

As a reminder to myself for a quick pattern for transforming XML via XSLT:

Some setup:


public static final String XML_HEADER = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>";
public static final String XSL_HEADER = "<xsl:stylesheet version=\"1.0\" " +
    "xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\">";
public static final String ID_XFORM = "<xsl:template match=\"@*|node()\"><xsl:copy>" +
    "<xsl:apply-templates select=\"@*|node()\"/></xsl:copy></xsl:template>";

public static final String TRANS_ATTR = "<xsl:template match=\"ATTR_PATH@ATTR_NAME\">" +
    "<xsl:attribute name=\"ATTR_NAME\">ATTR_VALUE</xsl:attribute></xsl:template>";
public static final String XSL_END = "</xsl:stylesheet>";
public static final String XFORM_ATTR_XSL = XML_HEADER + XSL_HEADER + ID_XFORM + TRANS_ATTR + XSL_END;

And a usage sample transforming an attribute’s value:

String xsl = XFORM_ATTR_XSL.replace("ATTR_PATH", "");
xsl = xsl.replace("ATTR_NAME", "myAttribute");
xsl = xsl.replace("ATTR_VALUE", "newValue");

ByteArrayInputStream xslInputStream = new ByteArrayInputStream(xsl.getBytes("UTF-8"));
FileInputStream xml = new FileInputStream(new File("myXmlFile");
InputStream transformedXml = null;

try {
    transformedXml = transformXml(xml, xslInputStream);
}
finally {
    if (xml != null) xml.close();
}

and the transform method:

private InputStream transformXml(InputStream xml, InputStream xsl) throws TransformerConfigurationException, TransformerException {

    TransformerFactory factory = new org.apache.xalan.processor.TransformerFactoryImpl();
    Transformer transformer = factory.newTransformer(new StreamSource(xsl));
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    transformer.transform(new StreamSource(xml), new StreamResult(baos));
    return new ByteArrayInputStream(baos.toByteArray());
}

ExtGWT Cookbook Review in progress

I’m in the process of reviewing a GXT book called ExtGWT Rich Internet Application Cookbook.

Hopefully I’ll pick up a few tips on the way. It will be interesting to compare it to a book a did a technical review for around a year ago: Ext GWT 2.0 Beginners Guide.

XStream 1.3.1 to 1.4.3 ReflectionConverter changes

Recently while upgrading to Java 7 I had to upgrade XStream due to (I think) Oracle changing the name of the JVM or reflection providers. My converters that subclass the ReflectionConverter class started to fail. I had been omitting fields and then manually marshalling them in by overriding the marshall and marshallFields methods.

The 1.3.1 version of the RelectionConverter (in AbstractConverter) passed all non transient fields to the marshallField method. But in 1.4.3 it now checks if the fields should be omitted and will not pass omitted fields through to the marshallField method.

While mine was a relatively unusual case I hope this post can help others out stuck on similar issues.

C# Error Serialising IList

Recently I hit an error trying to Serialize a IList (with the actual type being an ArrayList) in C#. The only error I could get was:

System.InvalidOperationException: There is an error in XML document

which was not particularly helpful. As far as I can tell the System.Xml.Serialization.XmlSerializer can’t serialise IList as the root node, but has no issues if the IList is a child node.

I found one workaround here that uses a IXmlSerializable wrapper for IList.

(I tried to use a z in serialise when it refers to a method, but couldn’t bring myself to break with Australian English for other uses!)

EasyMock Generic(ish) Collection Matcher

I wanted to check that a collection is basically the same as another without knowing the collection type. I can only really check that the same elements are present, like a basic set.

The code below is based on the code here but with generics where possible (the matches method is not generic in EasyMock 2.5):


private static class CollectionMatcher<T> implements IArgumentMatcher {
    private Collection<T> collection;
    private String notFound = "";

    public CollectionMatcher(Collection<T> collection) { this.collection = collection; }

    public static <T> Collection<T> collectionEq(Collection<T> collection) {
        reportMatcher(new CollectionMatcher<T>(collection));
        return null;
    }

    public void appendTo(StringBuffer buffer) {
        buffer.append(notFound).append(" not found in {");
        String comma = "";
        for (Object o : collection) {
            buffer.append(comma).append(o.toString());
            comma = ",";
        }
        buffer.append("}");
    }

    public boolean matches(Object otherCollection) {
        if (!(otherCollection instanceof Collection)) return false;

        Collection<T> other = (Collection<T>) otherCollection;
        if (other.size() != collection.size()) return false; // Optionally check sizes
        for (T o : other) {
            if (!collection.contains(o)) {
                notFound = o.toString();
                return false;
            }
        }
        return true;
    }
}

Jackrabbit auto commit exception

At work I have been using a Jackrabbit (JCR) repository in our core product for a quite a few months. Recently we added features for managing financial publications which entails a bunch of CRUD activities using REST including creating versions and performing pessimistic locking.

With add the new activity occurring in the repository we starting seeing occasional auto commit errors. Our JBDC driver (JTDS) reports the following error on commit:

org.apache.jackrabbit.core.state.ItemStateException: commit() should not be called while in auto-commit mode.

Caused by: java.sql.SQLException: commit() should not be called while in auto-commit mode.

Hmmm.. it occurred in some orders of operation (create, edit, finish, find, edit, cancel) but not in others. Also it failed on the build machine and on other dev box, but I earned the “works on my machine” badge.

We use currently use Jackrabbit without a transaction as it turns auto commit on and off itself and thus needs to be unmanaged (see here for a raised issue). I’ve seen hints of using it via XASessions but have not yet found any clear documentation on how to do this.

We also had Jackrabbit using the database to store everything but the Lucene indexes and it shared the same database (SQL Server 2005 / 2008) and database connection as the rest of the application. It was this last point that was causing the issue – giving Jackrabbit it’s own data source to the same database fixed the issue.

The type of data source did not matter – I tried: no-tx-datasource, local-tx-datasource and xa-datasource.

TL;DR: Jackrabbit needs it’s own data source when sharing a SQL Server database.

I’m using:

  • Jackrabbit 2.4.2 (latest stable)
  • JBoss 4.2.3 (old and friendly)
  • SQL Server 2005 / 2008

Memory and wire size of message protocols

There are many studies of the speed of message protocols like protobuf, JSON, BSON, etc, but little in the way of measuring the memory usage required to get the in memory data out to the client. The simplest approach (and the worst in terms of memory usage) is buffering the whole data structure before sending. This typically requires at least the same amount of memory as the original data.

My data set at hand for testing was a large (82MiB) 2D array of decimal values represented as strings (about 10 decimal places).

The Java generated CORBA serialisation code I started with buffers everything at once in its write method. 82MiB is copied to 82MiB.

JSON mapped using Jackson had similar but slightly better memory usage.

Using an ancient version of  The Mind Electric’s GLUE SOAP toolkit  (don’t ask!), the SOAP wrapped JSON message also buffers the lot into memory and was horribly inefficient in creating the envelope (using 100′s of MiB’s).

*A note on wire size – the SOAP message compressed very well using GZip as the whole message is available.

BSON (using BSON4Jackson) by default requires the first element to be the message size and thus buffers the lot into memory. By disabling pure BSON using the BsonGenerator.Feature.ENABLE_STREAMING setting, streaming code can be used and the memory usage is about a third of the original data size again to send.

I couldn’t get Google’s protocol buffers to be very large data friendly. Strings appear to be unoptimised (it just uses String.getBytes()), so even sending an array “row” at a time did not yield great performance. Sending a field at at time with string size fields and row length prefixes was even worse.

The least memory usage was by sending the data via Jackson’s streaming API. This coupled with no content length header to enable chunking (a HTTP 1.1 feature) had almost no overhead. Sending 82MiBs took about 4KB! There is some clever code in the streaming API as it is exceptionally efficient at streaming to an output stream (in my case in a servlet or via Restlet’s OutputRepresentation class).

You can also use GZip on this and it produces half the wire size, but takes twice the time.

In summary: Plain JSON streamed with Jackson is the clear winner for my data set with it’s tiny memory usage sending data to a stream.

In practice I felt that it was much simpler that this article made it seem (but I’m sending a very simple message here). Here is my code to stream a JSON representation of a 2D string array:


JsonFactory f = new JsonFactory();
JsonGenerator g = f.createJsonGenerator(outputStream);
g.writeStartObject();
g.writeStringField("type", "JsonJacksonStreaming");
g.writeArrayFieldStart("vals");

for (int r = 0; r < a2d.length; r++)
{
    g.writeStartArray();
    for(int c = 0; c < a2d[r].length; c++)
    {
        g.writeString(a2d[r][c]);
    }
    g.writeEndArray();
}
g.writeEndArray();
g.writeEndObject();
g.close();

Note: I didn’t get time to try MessagePack, but I’d like to. Anyone who has tried message pack with large amounts of string-ish data care to comment?

Follow

Get every new post delivered to your Inbox.