| Andrew Cooke | Contents | Latest | RSS | Twitter | Previous | Next

C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Lepl parser for Python.

Colorless Green.

Photography around Santiago.

SVG experiment.

Professional Portfolio

Calibration of seismometers.

Data access via web services.

Cache rewrite.

Extending OpenSSH.

Last 100 entries

Retiring Essentialism; Poorest in UK, Poorest in N Europe; I Want To Be A Redneck!; Reverse Racism; The Lost Art Of Nomography; IBM Data Center (Photo); Interesting Account Of Gamma Hack; The Most Interesting Audiophile In The World; How did the first world war actually end?; Ky - Restaurant Santiago; The Black Dork Lives!; The UN Requires Unaninmous Decisions; LPIR - Steganography in Practice; How I Am 6; Clear Explanation of Verizon / Level 3 / Netflix; Teenage Girls; Formalising NSA Attacks; Switching Brakes (Tektro Hydraulic); Naim NAP 100 (Power Amp); AKG 550 First Impressions; Facebook manipulates emotions (no really); Map Reduce "No Longer Used" At Google; Removing RAID metadata; New Bike (Good Bike Shop, Santiago Chile); Removing APE Tags in Linux; Compiling Python 3.0 With GCC 4.8; Maven is Amazing; Generating Docs from a GitHub Wiki; Modular Shelves; Bash Best Practices; Good Emergency Gasfiter (Santiago, Chile); Readings in Recent Architecture; Roger Casement; Integrated Information Theory (Or Not); Possibly undefined macro AC_ENABLE_SHARED; Update on Charges; Sunburst Visualisation; Spectral Embeddings (Distances -> Coordinates); Introduction to Causality; Filtering To Help Colour-Blindness; ASUS 1015E-DS02 Too; Ready Player One; Writing Clear, Fast Julia Code; List of LatAm Novels; Running (for women); Building a Jenkins Plugin and a Jar (for Command Line use); Headphone Test Recordings; Causal Consistency; The Quest for Randomness; Chat Wars; Real-life Financial Co Without ACID Database...; Flexible Muscle-Based Locomotion for Bipedal Creatures; SQL Performance Explained; The Little Manual of API Design; Multiple Word Sizes; CRC - Next Steps; FizzBuzz; Update on CRCs; Decent Links / Discussion Community; Automated Reasoning About LLVM Optimizations and Undefined Behavior; A Painless Guide To CRC Error Detection Algorithms; Tests in Julia; Dave Eggers: what's so funny about peace, love and Starship?; Cello - High Level C Programming; autoreconf needs tar; Will Self Goes To Heathrow; Top 5 BioInformatics Papers; Vasovagal Response; Good Food in Vina; Chilean Drug Criminals Use Subsitution Cipher; Adrenaline; Stiglitz on the Impact of Technology; Why Not; How I Am 5; Lenovo X240 OpenSuse 13.1; NSA and GCHQ - Psychological Trolls; Finite Fields in Julia (Defining Your Own Number Type); Julian Assange; Starting Qemu on OpenSuse; Noisy GAs/TMs; Venezuela; Reinstalling GRUB with EFI; Instructions For Disabling KDE Indexing; Evolving Speakers; Changing Salt Size in Simple Crypt 3.0.0; Logarithmic Map (Moved); More Info; Words Found in Voynich Manuscript; An Inventory Of 3D Space-Filling Curves; Foxes Using Magnetic Fields To Hunt; 5 Rounds RC5 No Rotation; JP Morgan and Madoff; Ori - Secure, Distributed File System; Physical Unclonable Functions (PUFs); Prejudice on Reddit; Recursion OK; Optimizing Julia Code; Cash Handouts in Brazil; Couple Nice Music Videos; It Also Works!; Adaptive Plaintext

© 2006-2013 Andrew Cooke (site) / post authors (content).

Java Annotations to Construct POJOs from HTTP Requests

From: "andrew cooke" <andrew@...>

Date: Wed, 20 Aug 2008 16:25:55 -0400 (CLT)

At work I'm writing code to provide a REST interface to a database (really
it's simpler than that - it's read only).  In the controller I want to
automate the construction of the model as much as possible.  This is
driven by the parameters in the request, so as a first step I want to be
able to set object attributes from the HTTP request.

I also want to be able to generate URLs from these same objects, when they
are modified (so that it is easy to generate URLs in the view to related
information).

So I need to (1) associate attributes with HTTP requests and (2) store
default parameters (so that the generated URI is no longer than
necessary).  After wondering exactly how to go about this I remembered the
rather excellent approach taken by args4j - https://args4j.dev.java.net/ -
which uses annotations on attributions.

It turns out that this is incredibly easy to do.  I now have some simple
annotations that let me define a tree of objects that will be
automatically generated with attributes populated from the request (which
tree is generated will depend on some other logic using the URI).

Here's the test (this is work's code, so it's (c) ISTI http://www.isti.com
and available under an attribution-based licence; contact ISTI for full
details).

public class BuilderTest
{

  @Test
  public void testAll()
  throws IllegalArgumentException, SecurityException, InstantiationException,
  IllegalAccessException, InvocationTargetException, NoSuchMethodException {
    MockHttpServletRequest request = new MockHttpServletRequest();
    request.setParameter("value-1", "one");
    request.setParameter("value-3", "3");
    request.setParameter("value-a", "a");
    request.setParameter("value-b", "5");
    Builder builder = new Builder(request);
    Outer outer = builder.build(Outer.class);
    assertEquals("Bad value for value1", "one", outer.value1);
    assertEquals("Bad value for value2", "default", outer.value2);
    assertEquals("Bad value for value3", 3, outer.value3);
    assertEquals("Bad value for valuea", "a", outer.inner.valuea);
    assertEquals("Bad value for valueb", 5, outer.inner.valueb, 0.001);
  }

  public static class Outer {
    @Parameter(deflt = "", name = "value-1")
    public String value1;
    @Parameter(deflt = "default", name = "value-2")
    public String value2;
    @Parameter(deflt = "", name = "value-3")
    public int value3;
    @Parameterised
    public Inner inner;
  }

  public static class BaseInner {
    @Parameter(deflt = "", name = "value-a")
    public String valuea;
  }

  public static class Inner extends BaseInner {
    @Parameter(deflt = "", name = "value-b")
    public double valueb;
  }

}

And you can see that:
1 - attributes are set from the HTTP request
2 - defaults are supplied as necessary
3 - a tree of objects can be created

The implementation is simple (the annotations themselves are trivial
interfaces).  All the work is done in the Builder, mainly in these
methods:

public <Type> Type build(final Class<Type> clazz)
{
  Type instance = clazz.getConstructor().newInstance();
  // if we use getDeclaredFields here we don't superclass fields.
  // unfortunately, this then restricts us to public fields (declared
  // seems to also include protected fields)
  for (Field field: clazz.getFields()) {
    setParameter(instance, field);
    extendParameterised(instance, field);
  }
  return instance;
}

private <Type> void setParameter(final Type instance, final Field field)
{
  logger.debug("Field {}", field.getName());
  Parameter parameter = field.getAnnotation(Parameter.class);
  if (parameter != null) {
    String value = getValue(parameter);
    if (field.getType() == String.class) {
      field.set(instance, value);
    } else if (field.getType() == Integer.TYPE) {
      field.setInt(instance, Integer.parseInt(value));
    } else if (field.getType() == Double.TYPE) {
      field.setDouble(instance, Double.parseDouble(value));
    } else {
      throw new BadParameterException(
        String.format("Bad type %s for %s = %s.",
                      field.getType().getSimpleName(),
                      parameter.name(), value));
    }
  }
}

private <Type> void extendParameterised(
    final Type instance, final Field field)
{
  if (field.isAnnotationPresent(Parameterised.class)) {
    field.set(instance, build(field.getType()));
  }
}

Andrew

Spring's Command Controller

From: "andrew cooke" <andrew@...>

Date: Wed, 20 Aug 2008 17:11:55 -0400 (CLT)

...is kind-of similar.  The differences (from the point of view of the
Spring class are):

- Proper Java bean support (setters rather than attributes)
- Wider range of values via Java bean property editors
- Dotted paths (rather than single flat namespace)
- No defaults (which makes constructing compact URIs hard)
- No annotations (as far as I can see) to restrict what is set
  (instead uses standard "public" interface)
- Validators (not needed in my read-only case, thankfully)

Validators and property conversion are the biggies, but in my case
constructing URIs and a flat namespace are what I need.

Andrew

Comment on this post