Draconian Overlord

todomvc in Tessell

2011-12-10T00:00:00-08:00

todomvc in Tessell

Update 2011/12/29: This post was originally about the gwt-mpv framework, which has since been rechristened Tessell, see tessell.org.

Recently I came across todomvc on HN, a nifty sample application that shows the same “todo app” functionality implemented in a number of different JavaScript UI frameworks.

It is a great way to compare JS frameworks, as Jérôme Gravel-Niquet’s initial todo application has a great balance of features to lightly tax a framework but not take forever to implement. Kudos to Addy Osmani for realizing this and gathering together the various implementations.

As a GWT user, I have a slightly different viewpoint on JavaScript application development (eh, it’s just assembly…er, C), but I nonetheless agree with these JS frameworks that intelligently structuring AJAX applications is important.

In the GWT world, Model View Presenter has been the hot way to do this since 2009, and I’ve obliged by hacking on Tessell, an MVP framework, for various apps we’re writing at Bizo.

Tessell shares a lot of the same ideas and goals as the todomvc JS frameworks, namely:

rich, event-driven models
data-binding models to views declaratively

So I thought it’d be fun to port todomvc to Tessell as yet another implementation to compare and contrast with the others.

In doing so, and doing this writeup, I have two goals:

Show GWT developers that Tessell’s code generation-driven MVP leads to minimal boilerplate
Show JavaScript developers that GWT can be a competent choice for rich-client development

Demo and Code

Although it looks just like the other implementations, the Tessell port’s code is currently hosted here:

http://todomvc.tessell.org/TodoMvc.html

And if you want to follow along in the source while reading this post, the source is on github:

https://github.com/stephenh/todomvc-tessell

Project Layout

The Tessell todo implementation uses an idiomatic Java/GWT layout. The primary packages are:

org.tessell.todomvc.client.app for presenters,
org.tessell.todovmc.client.model for models, and
org.tessell.todomvc.client.views for view templates.

For a small application like the todo app, having multiple files is likely harder to follow than the JS implementations, which typically have just one JS file + CSS file. However, this approach works best for GWT and means you already have a good setup if your project grows larger.

Models

To start with, all rich UI frameworks typically define models for the domain objects involved. In Tessell, this is done simply with a Todo class:

public class Todo {
  public final BooleanProperty done = booleanProperty("done", false);
  public final StringProperty name = stringProperty("name");

  public Todo(String name) {
    this.name.set(name);
  }
}

Instead of traditional Java fields + getters/setters, Tessell models have property objects. Property objects fire events when they change, which allows the rest of the application to react accordingly.

You can also have lists of model objects, which fire events when items are added/removed to the list, e.g. in AppState:

public class AppState {
  public final ListProperty<Todo> allTodos = listProperty("allTodos");
  public final ListProperty<Todo> doneTodos = listProperty("doneTodos");
}

As with the JS frameworks, Tessell also supports derived properties, e.g. in AppState:

numberLeft = integerProperty(new DerivedValue<Integer>() {
  public Integer get() {
    return allTodos.get().size() - doneTodos.get().size();
  }
});

Tessell models can also do validation of properties (required, length checks, etc.), but that wasn’t needed for the todo application.

Views

Tessell’s views build on GWT’s UiBinder, which uses HTML-like XML to layout your application. The main distinguishing feature of UiBinder is that it lacks any logic (either behavior or data binding) in the view–there are no <% if (...) %> tags or data-bind="..." attributes.

For example, ListTodoItem.ui.xml:

<gwt:HTMLPanel ui:field="li" tag="li" styleName="{style.todo}">
  <div ui:field="displayPanel">
    <gwt:CheckBox ui:field="checkBox" styleName="{style.check}" />
    <gwt:Label ui:field="content" styleName="{style.todo-content}" />
    <gwt:Anchor ui:field="destroyAnchor" styleName="{style.todo-destroy}" />
  </div>
  <div ui:field="editPanel">
    <gwt:TextBox ui:field="editBox" styleName="{style.editBox}" />
  </div>
</gwt:HTMLPanel>

(If you’re not familiar with the todo app, it alternates between the displayPanel when the user is viewing a todo and the editPanel when a user double-clicks to edit a todo.)

Some GWT specifics aside (widgets, etc.), this is basically HTML. A few things to note:

The ui:field attributes expose their annotated elements/widgets to your presentation logic.

(GWT eschews id attributes because a template may be included multiple times in the DOM and, ids being global, could collide.)
{style.todo} is a reference to the .todo CSS class defined inline within the ui.xml file. This means:
1. You have a good place to put per-view CSS (it all ends up bundled into one download in the end), which to me is a much saner alternative than the gigantic CSS files I usually see.
  
  It’s a locality principle: if CSS is used only once, it should be as close to that usage point, and none other, as possible.
2. The compiler checks all CSS class references–if .todo was renamed, you get a compile error.
3. The compiler ensures all CSS identifiers are globally unique–if you use .name in one ui.xml or css file, you don’t have to worry about it colliding with another .name in another ui.xml or css file.

The main feature that Tessell provides for views is generating derivative artifacts from the ui.xml files. In the MVP pattern, presenters code against an abstract IsXxxView interface, and then UiBinder needs a XxxViewImpl Java class, but Tessell can derive both of these from the ui.xml file.

For an example, the generated IsListTodoItemView looks like:

interface IsListTodoItemView extends IsWidget {
  IsHTMLPanel li();
  IsElement displayPanel();
  IsCheckBox checkBox();
  IsLabel content();
  IsAnchor destroyAnchor();
  IsElement editPanel();
  IsTextBox editBox();
  ListTodoItemStyle style();
}

Where each ui:field-annotated element/widget in the ui.xml file is exposed, but only as an abstract IsXxx interface which themselves can be substituted for fake DOM-less versions at test time. We’ll cover this more later when talking about testing.

Presenters

Presenters are the glue between your model and view. Ideally presenters simply bind the model and view together; but, if needed, they can also implement more complex logic.

An extremely simple presenter is AppPresenter, which just assembles the three separate panels of the application:

public class AppPresenter extends BasicPresenter<IsAppView> {

  private final AppState state = new AppState();
  private final CreateTodoPresenter createTodo = addPresenter(new CreateTodoPresenter(state.allTodos));
  private final StatsTodoPresenter statsTodo = addPresenter(new StatsTodoPresenter(state));
  private final ListTodoPresenter listTodos = addPresenter(new ListTodoPresenter(state));

  public AppPresenter() {
    super(newAppView());
  }

  @Override
  public void onBind() {
    super.onBind();
    view.createPanel().add(createTodo.getView());
    view.listPanel().add(listTodos.getView());
    view.statsPanel().add(statsTodo.getView());
    view.creditsPanel().add(newCreditsView());
  }
}

Obviously usually presenters do a bit more; in the todo app, the most busy presenter is the ListTodoItemPresenter, which, amongst other things, binds the todo.name property to the view:

binder.bind(todo.name).to(view.editBox());
binder.bind(todo.name).toTextOf(view.content());
binder.bind(todo.done).to(view.checkBox());

These three one-liners setup two-way data binding between the model and the view. If todo.name changes, both view.editBox() and view.content() will be updated with the new name. If the user enters a new name into view.editBox(), it will flow back into todo.name (and subsequently into view.content())).

Besides just binding fields, the binder DSL can also be used for performing other common view actions on model change, such as showing/hiding or setting/removing CSS classes:

binder.when(editing).is(true).show(view.editPanel());
binder.when(editing).is(true).hide(view.displayPanel());
binder.when(editing).is(true).set(s.editing()).on(view.li());

Finally, looking at ListTodoPresenter, keeping the view’s ul list of one-li-per-todo in sync with the allTodos list model can also be done with binding:

binder.bind(state.allTodos).to(this, view.ul(), new ListPresenterFactory<Todo>() {
  public Presenter create(Todo todo) {
    return new ListTodoItemPresenter(state, todo);
  }
});

Hopefully you can see that, besides view boilerplate reduction, rich models and a fluent binding DSL are the other main strengths Tessell brings to the table to succinctly, declaratively wire together your application’s behavior.

Testing

Finally, the reason for the extra abstraction of the Model View Presenter architecture, it is now ridiculously easy to test your model and presenter logic without the DOM.

For the todomvc port, this means we can test the “add a new todo” functionality by:

Setting up a test list model
Instantiating the presenter to test
Retrieving the stub (no DOM) view implementation (which is generated by Tessell from the ui.xml template file) that has fake versions of each of our components

So a test starts out looking like CreateTodoPresenterTest:

public class CreateTodoPresenterTest extends AbstractPresenterTest {
  final ListProperty<Todo> todos = listProperty("todos");
  final CreateTodoPresenter p = bind(new CreateTodoPresenter(todos));
  final StubCreateTodoView v = (StubCreateTodoView) p.getView();

And then goes right into testing features:

@Test
public void enterOnSomeContentCreatesTask() {
  // model starts out empty
  assertThat(todos.get().size(), is(0));
  // user enters a new task, hits enter
  v.newTodo().type("new task");
  v.newTodo().keyDown(KeyCodes.KEY_ENTER);
  // model now has a new task with the right name
  assertThat(todos.get().size(), is(1));
  assertThat(todos.get().get(0).getName(), is("new task"));
}

The newTodo().type(...) method emulates a user typing into the “new todo” text box. newTodo().keyDown(...) is the enter key being pressed. And then we can assert our model was changed, and the new model object created with the right name.

The Tessell port has ~30 presenter tests like this one. They all run in 1/10th of a second, no selenium, no browser, etc.

To me, this means its now actually feasible to develop your UI logic in a TDD fashion. Which is a huge win.

Okay, now the caveats:

Yes, this is a lossy abstraction. It doesn’t pretend to emulate cross-browser differences. It doesn’t realize that setting “display: none” on a parent makes the children invisible. In practice, that doesn’t matter for these sorts of tests.
Yes, this can’t test DOM-heavy logic. That logic should ideally be encapsulated within a component. Then you test the component with GWTTestCase (which has a DOM) or selenium or whatever, but then let your presenter tests be DOM-less by using a fake version of the component assuming the real one will just work.
Yes, you still need integration tests.

So, it’s not perfect. But if you had to choose:

500 unit tests + 50 selenium tests, or
550 selenium tests

I think it’s a fair assertion you’re much better off with the former.

Comparison with JS Frameworks

Reading through the various JS implementations of the todo app, and Tessell’s implementation, it’s encouraging to see that they are all trying to do basically the same thing: use event-driven models and views to wire together a rich client.

I think this approach of declaratively setting up view/model bindings is the key to doing non-trivial AJAX applications without loosing your functionality (or sanity, whichever is less important) to growing balls of spaghetti code. Changing the model should lead to the view updates just working.

That being said, each framework does things slightly differently. Here I’ll briefly cover how GWT/Tessell is different.

Templates

GWT’s ui.xml files seem like the most static/most dumb view templates. Whether this is good or bad is personal preference, although I like it because I think it forces as much view logic as possible into the presenter.

Some JS frameworks, like backbone, use more server-side-style templates:

<script type="text/template" id="item-template">
  <div class="todo <%= done ? 'done' : '' %>">
    <div class="display">
      <input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />
      <div class="todo-content"></div>
      <span class="todo-destroy"></span>
    </div>
    <div class="edit">
      <input class="todo-input" type="text" value="" />
    </div>
  </div>
</script>

Where others use data-binding attributes, like knockout:

<script id="todoitemtemplate" type="text/html">
  <li data-bind="css: {editing: editing}">
    <div data-bind="attr: { class : done() ? 'todo done' : 'todo'}">
      <div class="display">
        <input class="check" type="checkbox" data-bind="checked: done" />
        <div class="todo-content" data-bind="text: content, click: edit" style="cursor: pointer;"></div>
        <span class="todo-destroy" data-bind="click: viewModel.remove"></span>
      </div>
      <div class="edit">
        <input class="todo-input" type="text" data-bind="value: content, event: { keyup: editkeyup, blur: stopEditing }"/>
      </div>
    </div>
  </li>
</script>

These approaches typically require rendering the DOM elements to test the view logic. I generally think this is a bad thing, although I was surprised to learn that, if you avoid the traditional Selenium/etc., approaches, in-browser DOM testing can be quite fast these days.

Also with templates, in GWT you rarely re-render parts of the page to show changes, instead you just mutate the existing DOM (…unless using GWT’s Cell widgets, which are for bulk display for tables/lists, but are exceptions). Some JS frameworks re-render, some don’t, but in general I’m a fan of not re-rendering.

Avoiding re-rending is, in my opinion, more amenable to a rich, component-based UI because then your components (which have state) aren’t having their underlying DOM elements constantly swept out from under them.

This may not be an issue when re-rendering tiny, leaf parts of the DOM, but as you work your way up in the DOM of a complex app, I think it would become harder to remember all the state needed to faithfully re-render things from scratch (like the checked state in the above backbone example).

I can see where the sentiment of “eh, just re-render” comes from. Having been a server-side web developer, I certainly miss the simplicity of the “each response is a clean slate” model. And re-rendering entire parts of the page certainly worked well for Rails, albeit it was still doing rendering on the server-side. However, I don’t think it is as good of a conceptual fit on a stateful client.

No Selectors

In GWT, you typically already have references to the DOM objects you want to mutate (albeit usually encapsulated by widgets), so you rarely, if ever, need selectors.

The is different than most of the JS frameworks. For example, in the backbone implementation, to update a list item’s text when it changes, the code uses a selector to reach out and grab the text box:

this.$('.todo-content').text(content);

Where as in the ListTodoItemPresenter, the view kept a reference to the DOM element while building itself (done by UiBinder), so now we can just call it directly:

view.content().setText(view.editBox().getText());

(The content() method is just a getter than returns the view’s content field, which is a GWT Label component, which just wraps a DOM div tag.)

Several of the JS frameworks also like to use selectors for event handling, again backbone:

events: {
  "click .check"              : "toggleDone",
  "dblclick div.todo-content" : "edit",
  "click span.todo-destroy"   : "clear",
  "keypress .todo-input"      : "updateOnEnter"
},

Where as GWT typically uses old-school anonymous inner classes:

view.newTodo().addKeyDownHandler(new KeyDownHandler() {
  public void onKeyDown(KeyDownEvent event) {
    // ...
  }
});

Although if you’re just updating a model, this can be cleaned up by using the binder DSL:

binder.bind(done).to(view.checkBox());

Even though anonymous inner classes are not the most awesome thing ever, avoiding selectors has a few up-shots:

Your code more exactly denotes the elements it will change.

This is a lot like dynamic vs. static typing; selectors are dynamic, deferring the binding of the selector to underlying elements until execution time, while GWT’s known-references approach has a stronger assertion about which elements it will change.

And so if you refactor the HTML in your ui.xml file, your view interface changes, and any presenter logic that was depending on it may now break, vs. the magic selector string just silently not matching.
Your application doesn’t have to worry about selectors from various components overlapping each other.

Naive DOM selectors will select against the global DOM, which in a large, complex application is less-than-ideal. Better selectors will start with the component’s subtree of the DOM, and even better selectors will not continue searching within the component’s nested children components.
Testing is easier because you don’t need a fake DOM to run the selectors against. More on testing below, but if your code mutates explicit references, it’s easier for tests to fake these references out at test time.

Personally, I think selectors are leftover baggage from the Web 1.0 days. When people first started doing AJAX, 95%+ of the page was rendered server-side, so of course you don’t have JavaScript references to the things you want to change, the elements all came down in one big string of HTML. So selectors were a great way to reach back into a DOM you didn’t create and get at them.

However, for full-page AJAX applications, when 95%+ of the page is rendered client-side, the very act of rendering provides the perfect opportunity to grab explicit references to the DOM objects as they are created and hold on to them within your application logic (in widgets, components, etc.). In my experience, this negates any need for selectors.

Disclaimers

Per my earlier link to Ray Ryan’s 2009 Google I/O talk, I can’t take credit for the DOM-less testing approach. Tessell, and several other frameworks within the GWT sphere, are just running with a great idea.
In the todo application, I used a global AppState class to share the ListPropertys across presenters. Some GWT developers would probably lobby for even more decoupling by passing messages on an EventBus, but that seemed like overkill for this app.
The original CSS was in one massive file, and I may have butchered it when moving it into each component. It looks fine in Chrome, but YMMV.
Yes, Java isn’t cool anymore, but scala-gwt will make everything more awesome and terse when it ships.

Sane AJAX Testing in Selenium

2011-10-14T00:00:00-07:00

Sane AJAX Testing in Selenium

Let’s cut to the chase: testing AJAX applications can suck.

Selenium is great for Web 1.0 applications, which involve a page load after each significant user action. Selenium knows to block until the page is done loading, and so the page load provides an implicit “wait until crap is done” barrier to keep your test from getting ahead of the browser.

But that goes away in AJAX applications–no page load. There are a variety of ways to compensate, most of which are what I call pre-assertion waiting–before asserting “did X happen” poll for a little bit to ensure “X” is there. E.g.:

ajaxSubmit.click();
waitForErrorToShowUp();
assertErrorIs(...);

In my experience, pre-assertion waiting in tests is not ideal. They’re verbose, often fickle, and at a higher risk of rotting when the application is refactored (“Is this wait really needed? Better leave it in, just in case.”).

Instead, I think a good goal for functional UI tests is to never have explicit wait lines in your test methods. If you can pull this off, I think the resulting tests will be more readable, more reliable, and more resilient to change.

To accomplish this, I’ve been using two tricks that, in tandem, work really well:

Reintroduce the concept of “page loading”
Use post-action waiting instead of pre-assertion waiting

And also a heavy dose of Page Objects abstraction.

So, let’s see what this looks like.

Reintroduce “page loading”

First: reintroduce page loading. Not real page loading, obviously. But what was Web 1.0 page loading useful for? Knowing when the browser is waiting on the server. AJAX calls are the same thing–talking to the server. We just need to make it explicit and visible to Selenium.

There are a variety of ways of doing this, but you basically need a choke point in your application where all AJAX requests go through. Then:

Before any AJAX request goes out, increment an outstanding variable
Put the value of outstanding into a hidden div tag
When the AJAX response comes back, decrement outstanding variable
Again put the value of outstanding into the hidden div

Now Selenium has the ability to see the application’s “loading” state:

If outstanding.innerText == "0", all things are good, continue the test
If outstanding.innerText != "0", the application is waiting, block the test

I don’t have any JavaScript code to show how this works, as I do all my client-side programming in GWT, so use a gwt-dispatch-style approach that broadcasts AJAX events on an EventBus, which then OutstandingWatcher listens for and maintains the outstanding div appropriately.

For JQuery/etc., something in Extending AJAX would probably work. It’s probably 10-20 lines of code.

Anyway, once you have this in place, you’ve basically got page loads back–any time an AJAX request is in-flight, Selenium can know about it by watching if outstanding != 0. E.g. with Selenium’s new ExpectedConditions API, it might look like:

/** Waits until all async calls are complete. */
public static ExpectedCondition<Boolean> outstanding() {
  return new ExpectedCondition<Boolean>() {
    public Boolean apply(final WebDriver from) {
      final String outstanding = from
        .findElement(By.id("outstanding"))
        .getText();
      return "0".equals(outstanding);
    }
  };
}

So, then you could use this in a test like:

ajaxSubmit.click();
WebDriverUtil.waitFor(outstanding());
assertErrorIs(...);

Post-Action Waiting

Which brings us right to the second trick: the test is now doing post-action waiting. And not only is it post-action, but it’s generic waiting. This has several nice benefits:

It doesn’t matter whatever the application was doing while the request was in-flight–spinning a wheel for the user, doing nothing at all, whatever–Selenium can always look for outstanding != 0 and just work.
It doesn’t matter what the test is going to assert after this, so we don’t need to worry about all of our tests’ wait logic breaking if we change the application’s behavior.

Basically, we’re back to the convenience of Web 1.0 applications–we have an automatic, reliable way of keeping the browser and test in sync with each other.

Page Objects

So, that’s the core of the approach. I think this just by itself will work quite well and, in my opinion, better than pre-assertion/per-assertion waiting approaches.

However, I’ve also been going one step further and, with my pageobjects implementation, centralizing the waiting declarations within the page objects themselves. So, I might have:

// each page/fragment in the app has an XxxPage class
class EmployeePage extends AbstractPageObject {
  // each element on the page has a field of XxxObject
  public TextBoxObect name = new TextBoxObect("employeeName");

  // fluently add `outstanding` to submit
  public ButtonObject submit = new ButtonObject("submit")
    .afterClickWaitFor(outstanding());

  // cstr, other fields...
}

The afterClickWaitFor means there is just one place in all of the functional tests that says “after this button is clicked, we will probably have to wait for the server”.

So the test can now look even simpler, with no mention of waiting:

employeePage.submit.click();
assertErrorIs(...);

And if you’re extra spiffy, you might even encapsulate the error gathering logic into the EmployeePage as well, so then you’re test is:

employeePage.submit.click();
assertThat(employeePage.getErrors(), contains("..."));

To me, this is a pretty nice test to read. No explicit waiting, pretty high level (the ids/lookup logic are encapsulated in the page objects). It’s probably not as flowing as a GooS-style functional tests, which are awesome, but personally I find this level of abstraction to be a sweet spot in the trade off between effort and benefit.

Disclaimer

The one large disclaimer to this approach is that I haven’t had to deal with a lot of animation–all of my waiting really is on the server, and then things in the UI are generally displayed right away (within the same event loop that services the AJAX response).

If you’re doing anything with setTimeout, e.g. animation or progressive calculations, then you’ll probably have to fall back to pre-assertion waiting. Although hopefully you could find a wait to encapsulate it into a page object, perhaps some sort of beforeAssertionWaitFor method (which doesn’t exist yet).

Anyway, that disclaimer aside, I’ve found this approach to be very successful. My last few projects have had much more most robust Selenium tests than previous ones (that doesn’t mean perfect; but definitely much better). Part of that is likely due to the kick ass job the Selenium developers are doing, but I think the outstanding + post-action waiting approach has a large part to do with it as well.

If you try it out, I hope you find it useful. Feel free to download pageobjects, play around, and drop me an email/Github message if you run in to anything.

Why No One Uses Scala's Structural Typing

2011-10-04T00:00:00-07:00

Why No One Uses Scala’s Structural Typing

Recently I heard some Scala enthusiasts note that, anecdotally, not very many projects actually use Scala’s structural typing support.

In the subset of the Scala library that scalagwt supports (which is most of it), structural typing was only used once, and that turned out to be a bug.

Why is this? Aren’t structural types supposed to be awesome? The safety of static type checking, without the annoyance of manually adapting types?

To me, the reason is fairly obvious: Scala’s structural types are implemented on the declaration-side.

This means that, when declaring a method, you decide then whether or not all callers will use regular or structural typing. For example:

class SomeApi {
  // regular typing method, takes Foo, callers
  // can only pass a Foo, normal typing
  def regularMethod(foo: Foo) {
    // regular dispatching
    foo.doFoo()
  }

  // structural typing method, callers can pass
  // any type that has a "doFoo" method
  def structuralMethod(foo: { def doFoo(): Unit }) {
    // structural dispatching (reflection)
    foo.doFoo()
  }
}

Okay, so what?

To think about this, let’s introduce two developers: the API designer and the API user:

The API designer codes someMethod and decides regular vs. structural typing.
The API user calls someMethod and has to go with whatever the designer chose.

Now think, who needs structural typing?

The API designer does not need structural typing–he, by virtue of being the designer, controls the API and related codebase. If he needs someMethod to accept two separate types, he very likely controls each type, or at least controls someMethod, so, most of the time, can make his scenario work with regular types (having TypeA also extend TypeB or vice versa).

(Besides API designers, I think this also covers a programmer making any calls internally within a codebase–you just change the types of the methods/arguments to match what you’re trying to do with normal typing rules.)
The API user does need structural typing–not being in control of the API, he is most likely to have types that wouldn’t satisfy someMethod using normal typing, but would with structural typing.

And there’s the rub: structural typing’s forte, in my opinion, is calling APIs you don’t control; but that same lack of control means, in Scala, you won’t be able to actually use it.

Think of the API designer: it’s unlikely they’ll anticipate when API users will/will not want to use structural typing. And it’s unlikely that API designers will use structural typing for the entire API, just in case. So, in practice, it’s used for none.

So, what of structural typing then? Is it all for naught?

I’m not sure. Previously, I mulled about how some languages do Caller-Side Structural Typing, which moves the decision of “do I use structural typing here?” to the caller side, where I think it’s much more likely to be used. E.g. Heron’s as keyword:

interface Foo {
  doFoo();
}

// doesn't implement Foo
class LikeFoo {
  void doFoo() { ... }
}

// as generates a delegate that
// implements Foo for LikeFoo
takesFoo(new LikeFoo() as Foo);

However, these approaches (on a pre-interface-injection JVM anyway), usually just end up as the compiler/JVM auto-writing the adaptor for you (and can only be used for interfaces). Which is cool, but may/may not be structural typing anymore.

A colleague pointed out that Scala’s structural typing actually came about serendipitously, as a side effect of simplifying the Scala language spec (from this interview with Martin Odersky). I’m not an expert on the OO types vs. functional modules aspect Martin was talking about. But since my personal use case of “calling APIs you don’t control” doesn’t seem to be what Scala’s structural typing was introduced for, it makes sense that it doesn’t solve it very well.

My suspicion is that structural types may just never be a big hit on the JVM, due to the assumptions it makes about types being non-structural. Unless invokedynamic magic makes it possible; I have no idea. And I don’t have enough experience with a non-JVM/true structural language like Go to really comment any further, so I’ll leave it at that.

I’m sure others have more insightful thoughts on this; if so, please leave them, or links to them, in the comments.

A GWT Developer's Reaction to Dart

2011-10-03T00:00:00-07:00

A GWT Developer’s Reaction to Dart

The scheduled Dart keynote announcement made the rounds a week ago or so. If you didn’t catch it, Google wants to replace JavaScript, with a dual static/dynamic language named Dart.

This post has more details, but basically Google wants to combine its two primary tool chains, Closure (JavaScript-based) and GWT (Java-based) into a single project. This makes sense, as both tools have (AFAIK) separate teams within Google supporting them, and both share the same goal of making it easier for developer’s to build large, complex, browser-based applications.

While I’m not yet a front-end developer extraordinaire, GWT is my tool of choice for rich-client browser applications, and this means it’s been effectively deprecated.

Which, after my initial reaction (“What?! GWT rulez!11!!”), I realized, this is actually pretty damn cool. This post is my brief explanation of why.

Typing and Tools

To explain, here are the four primary reasons why I like GWT in the first place:

I’m a static typing bigot.
I’m addicted to Eclipse and not ashamed of it (although vi bindings FTW).
I like GWT’s components-based approach to widgets/UI.
I like GWT’s integrated “toolkit” approach of doing most things you’ll need (minification, spriting, i18n, browser tweaks, etc.) out of the box.

Now, if you cast each of these reasons to apply to Dart:

Static typing? Eh, optional, but, okay, good enough. Check.
Eclipse? With static types, JDT-level Eclipse integration should be doable; Google has an Eclipse plugin team, so hopefully they’ll have this sooner rather than later. Check.
Components? UI components aren’t, AFAIK, Dart-/language-specific, so I assume GWT’s Dart-based successor will follow a similar approach. Check.
Toolkit? Same thing as 3. Check.

They all hold up. Dart is still a language I would prefer using over JavaScript, which is primarily why I’m in GWT anyway. Plus Dart will be browser-based.

A Better DevMode

Also, stepping back, I realize that GWT, at some level, is a huge hack. Not because it trans-compiles Java to JavaScript (CoffeeScript does the same sort of thing), but because of its implementation of Developer Mode. (Developer Mode is where you run your webapp locally and can debug it in Eclipse.)

To do this, GWT performs some browser/extension magic to force your browser to talk back and forth with a running JVM (where your code actually runs as regular Java code, so Eclipse can see/debug it), often times in a very chatty manner.

Surprisingly, this normally works quite well. However, it also means you are paying an RPC cost for every cross browser/JVM call (anytime your Java code touches the DOM and vice versa), and that can add up to a less-than-fast developer experience.

If only GWT could run your statically-typed code directly in the browser…

…which is exactly what Dart will do. Nice!

A Better GWT

So, I’m optimistic: I see Dart as a way of getting an even better GWT.

Obviously, I’m speculating a lot since the keynote hasn’t happened yet, but, in a bit of naive projecting, I would assume the GWT users/developers within Google feel the same way I do. If you can provide a GWT-like experience, with less hacks and cruft, that sounds like a good thing to me.

Disclaimers

That being said, a few thoughts:

Just because it’s from Google doesn’t mean the language is going to rock; see Go. I’d be really surprised if this is the case with Dart, if only because the memo suggests a non-trivial amount of people are working on the project.

That being said, scala-gwt has made some great progress, so perhaps a scala-dart project could be started if the syntax is less-than-ideal.
Even if the other browsers don’t adopt Dart, I don’t care. If I can use Dart+GWT-next-gen to develop webapps in Chrome with a kick-ass developer experience, and fall back on old-school Developer Mode and JavaScript trans-compiling for the others, I’d be perfectly happy with that choice.
I’m really surprised the Dart VM will be for front-end servers as well; I assumed the JVM was king here and they’d stay with it. I’m unlikely to give up the JVM on the server-side, given the various libraries and APIs, all JVM-based, it uses to do its thing.

Which, while in theory the “same language on both client/server” sounded great, in practice I’ve rarely had a significant amount of code that could reused across each. Other than trivial validation, most code makes a surprising amount of assumptions based on the environment it’s in.

So, I’m looking forward to the Dart keynote. It’ll be interesting to see what it looks like, what the current progress is, and if/when real working prototypes will be available. As a GWT developer, it will also be interesting to see if any announcements are made about GWT next-gen, either in the keynote itself or by the GWT team afterwards.

Given the amount of GWT code Google itself has internally, and the amount of GWT code in other companies, I’m not worried about the GWT ecosystem dying on Oct 11th. Instead, depending on the GWT next-gen migration path/timeline, it might be a pretty happening place (well, as an introvert, I have a very loose definition of “happening”).

Modern Code Generation Talk

2011-04-21T00:00:00-07:00

Modern Code Generation Talk

I did a talk this week for the local JUG on Modern Code Generation.

My main assertion is that old-school, generating-.java-file code generation has been out of favor by the community for fancier alternatives (runtime CGLIB/ASM bytecode generation), and this isn’t necessarily a good thing.

Unlike my usual talks, I actually prepared for this one, and ended up with:

A slide show (tada!), and
Several example projects on github

The discussion during the talk was lively (always a good sign), and even wandered into discussing whether Java’s static typing inherently leads to the boilerplate common on many Java projects.

All in all, a lot of fun. Always curious why more professional programmers don’t go to/talk at these sort of things.

Command Query Responsibility Segregation with S3 and JSON

2011-04-15T00:00:00-07:00

Command Query Responsibility Segregation with S3 and JSON

We recently tackled a problem at Bizo where we wanted to decouple our high-volume servers from our MySQL database.

While considering different options (NoSQL vs. MySQL, etc.), in retrospect we ended up implementing a SOA-version of the Command Query Separation pattern (or Command Query Responsibility Segregation, which is services/messaging-specific).

Briefly, in our new approach, queries (reads) use an in-memory cache that is bulk loaded and periodically reloaded from a snapshot of the data stored as JSON in S3. Commands (writes) are HTTP calls to a remote JSON API service. MySQL is still the authoritative database, we just added a layer of decoupling for both reads and writes.

This meant our high-volume servers now have:

No reliance on MySQL availability or schema
No wire calls blocking the request thread (except a few special requests)

The rest of this post explains our context and elaborates on the approach.

Prior Approach: Cached JPA Calls

For context, our high-volume servers rely on configuration data that is stored in a MySQL database. Of course, the configuration data that doesn’t have to be absolutely fresh, so we’d already been using caching to avoid constantly pounding the database for data that rarely changes.

There were several things we liked about this approach:

We use Amazon RDS for the MySQL instance, which provides out-of-the-box backups, master/slave configuration, etc., and is generally a pleasure to use. We enjoy not running our own database servers.
We also have several low-volume internal and customer-facing web applications that maintain the same data and are perfectly happy talking to a SQL database. They are normal, chatty CRUD applications for which the tool support and ACID-sanity of a SQL database make life a lot easier.

That being said, we wanted to tweak a few things:

Reduce the high-volume servers’ reliance on MySQL for seeding their cache.

Although RDS is great, and definitely more stable than our own self-maintained instances would be, there are nonetheless limits on its capacity. Especially if one of our other application misbehaves (which has never happened…cough), it can degrade the MySQL instance to the point of negatively affecting the high-volume servers.
Reduce cache misses that block the request thread.

Previously, configuration data (keyed by a pre-request configuration id) was not pulled into cache until it was needed. The first request (after every cache flush) would reload the data for it’s configuration id from MySQL and repopulate the cache.

While not initially a big deal, as Bizo has grown, we’re now running in multiple AWS regions, and cache misses require a cross-region JDBC call to fetch their data from the MySQL server running in us-east.

Illustrated in code, our approach had, very simplified, been:

class TheServlet {
  public void doGet() {
    int configId = request.getParameter("configId");
    Config config = configService.getConfig(configId);
    // continue processing with config settings
  }
}

class ConfigService {
  // actually thread-safe/ehcache-managed, flushed every 30m
  Map<Integer, Config> cached = new HashMap<Integer, Config>();

  public Config getConfig(int configId) {
    Config config = cached.get(configId);
    if (config == null) {
      // hit mysql for the data, blocks the request thread
      config = configJpaRepository.find(configId);
      // cache it
      cached.put(configId, config);
    }
    return config;
  }
}

Potential “Big Data” Approaches

Given our primary concern was MySQL being a single point of failure, we considered moving to a new database platform, e.g. SimpleDB, Cassandra, or the like, all of which can scale out across machines.

Of course, RDS’s master/slave MySQL setup already reduces its risk of single machine point of failure, but the RDS master/slave cluster as a whole is still, using the term loosely, a “single point”. Granted, with this very loose definition, there will always be some “point” you rely on–we just wanted one that we felt more comfortable with than MySQL.

Anyway, for NoSQL options, we couldn’t get over the cons of:

Having to run our own clusters (except for SimpleDB).
Having to migrate our low-volume CRUD webapps over to the new, potentially slow (SimpleDB), potentially eventually-consistent (Cassandra) NoSQL back-end.
Still having cache misses result in request threads blocking on wire calls.

Because of these cons, we did not put a lot of effort into researching NoSQL approaches for this problem–we felt it was fairly apparent they weren’t necessary.

Realization: MySQL is Fine, Fix the Cache

Of course, we really didn’t have a Big Data problem (well, we do have a lot of those, but not for this problem).

We just had a cache seeding problem. Specifically:

All of our configuration data can fit in RAM, so we should be able to bulk-load all of it at once–no more expensive, blocking wire calls on cache misses (basically there are no cache misses anymore).
We can load the data from a more reliable, non-authoritative, non-MySQL data store–e.g. an S3 snapshot (config.json.gz) of the configuration data.

The S3 file then basically becomes our alternative “query” database in the CQRS pattern.

When these are put together, a solution emerges where we can have a in-memory, always-populated cache of the configuration data that is refreshed by a background thread and results in request threads never blocking.

In code, this looks like:

class TheServlet {
  public void doGet() {
    // note: no changes from before, which made migrating easy
    int configId = request.getParameter("configId");
    Config config = configService.getConfig(configId);
    // continue processing with config settings
  }
}

class ConfigService {
  // the current cache of all of the config data
  AtomicReference<Map> cached = new AtomicReference();

  public void init() {
    // use java.util.Timer to refresh the cache
    // on a background thread
    new Timer(true).schedule(new TimerTask() {
      public void run() {
        Map newCache = reloadFromS3("bucket/config.json.gz");
        cached.set(newCache);
      }
    }, 0, TimeUnit.MINUTES.toMillis(30));
  }

  public Config getConfig(int configId) {
    // now always return whatever is in the cache--if a
    // configId isn't present, that means it was not in
    // the last S3 file and is treated the same as it
    // not being in the MySQL database previously
    Map currentCache = cached.get();
    if (currentCache == null) {
      return null; // data hasn't been loaded yet
    } else {
      return currentCache.get(configId);
    }
  }

  private Map reloadFromS3(String path) {
    // uses AWS SDK to load the data from S3
    // and Jackson to deserialize it to a map
  }
}

A Few Wrinkles: Real-Time Reads and Writes

So far I’ve only talked about the cached query/reads side of the new approach. We also had two more requirements:

Very (very) infrequently, a high-volume server will need real-time configuration data to handle a special request.
The high-volume servers occasionally write configuration/usage stats back to the MySQL database.

While we could have continued using a MySQL/JDBC connection for these few requests, this also provided the opportunity to build a JSON API in front of the MySQL database. This was desirable for two main reasons:

It decoupled our high-volume services from our MySQL schema. By still honoring the JSON API, we could upgrade the MySQL schema and the JSON API server at the same time with a much smaller, much less complicated downtime window than with the high-volume services talking directly to the MySQL schema.
The MySQL instance is no longer being accessed across AWS regions, so can have much tighter firewall rules, which only allow the JSON API server (that is within its same us-east region) access it.

The new setup looks basically like:

Scalatra Servlet Example

With Jackson and Scalatra, the JSON API server was trivial to build, especially since it could reuse the same JSON DTO objects that are also serialized in the config.json.gz file in S3.

As an example for how simple Jackson and Scalatra made writing the JSON API, here is the code for serving real-time request requests:

class JsonApiService extends ScalatraServlet {
  get("/getConfig") {
    // config is the domain object fresh from MySQL
    val config = configRepo.find(params("configId").toLong)
    // configDto is just the data we want to serialize
    val configDto = ConfigMapper.toDto(configDto)
    // jackson magic to make json
    val json = jackson.writeValueAsString(configDto)
    json
  }
}

Background Writes

The final optimization was realizing that, when the high-volume servers have requests that trigger stats to be written to MySQL, for our requirements, these writes aren’t critical.

This means there is no need to perform them on the request-serving thread. Instead, we can push the writes onto a queue and have it fulfilled by a background thread.

This generally looks like:

class ConfigWriteService {
  // create a background thread pool of (for now) size 1
  private ExecutorService executor = new ThreadPoolExector(...);

  // called by the request thread, won't block
  public void writeUsage(int configId, int usage) {
    offer("https://json-api-service/writeUsage?configId=" +
      configId +
      "&usage=" +
      usage);
    }
  }

  private void offer(String url) {
    try {
      executor.submit(new BackgroundWrite(url));
    } catch (RejectedExecutionException ree) {
      // queue full, writes aren't critical, so ignore
    }
  }

  private static class BackgroundWrite implements Runnable {
    private String url;

    private BackgroundWrite(String url) {
      this.url = url;
    }

    public void run() {
      // make call using commons-http to url
    }
  }
}

tl;dr We Implemented Command Query Responsibility Segregation

With changing only a minimal amount of code in our high-volume servers, we were able to:

Have queries (most reads) use cached, always-loaded data is that periodically reloaded from data snapshots in S3 (a more reliable source than MySQL)
Have commands (writes) sent from a background-thread to a JSON API that saves the data to MySQL and hides JDBC schema changes.

For this configuration data, and our current requirements, MySQL, augmented with a more aggressive, Command Query Separation-style caching schema, has and continues to work well.

For more reading on CQS/CQRS, I suggest:

Both the Wikipedia article and Martin Fowler’s CommandQuerySeparation, however they focus on CQS as applied to OO, e.g. side-effect free vs. mutating method calls.
For CQS applied to services, e.g. CQRS, Udi Dahan seems to be one of the first advocates of the term. Since then, CQRS even seems to have its own site and google group.

(Note: this post was also cross-posted on the Bizo dev blog. If you’re interested in more posts on AWS/Java/Scala problems, you should check it out.)

Framework-less Dependency Injection

2011-03-17T00:00:00-07:00

Framework-less Dependency Injection

Overview

I’d like to present an alternative to framework-based DI that allows you to still have clean, decoupled, testable code without handing over control of every non-trivial object’s instantiation to a DI framework.

The key idea is to:

Make a single interface for retrieving all application-wide shared objects
Pass an instance of this interface around in your application

That’s it. This basically combines Fowler’s old school Registry pattern with the DI hipness of constructor injection. I don’t claim this is anything novel, nor perfect; but I’m surprised I haven’t seen it being used more.

I’ve been using this approach for awhile now (since my Changing My Style post from a year ago) and it has been working out quite well.

There are pros and cons, but first an example.

Example

To frame the example, let’s setup three class that respond to a user request. Something like:

public class Servlet {
  private Handlers handlers = new Handlers();

  // called when user hits the service
  public void handle(HttpRequest request) {
    handlers.handle(request);
  }
}

public class Handlers {
  public void handle(HttpRequest request) {
    // dispatches request to the right handler for the request type
    if ("bar".equals(request.getParameter("type"))) {
      new BarHandler(request).handle();
    }
  }
}

// instantiated per request
public class BarHandler {
  private final HttpRequest request;
  
  public BarHandler(HttpRequest request) {
    this.request = request;
  }

  public void handle() {
    databaseRepo.lookupId(...);
    emailRepo.sendAnEmail();
  }
}

This is completely made-up, but the idea is that we have several objects involved in servicing the request. Some of them are stateless (Servlet and Handlers) but some are stateful (BarHandler).

The problem then is how to get the databaseRepo and emailRepo dependencies passed down into the BarHandler.

Potential Approaches

Throwing out possibilities, we could:

Instantiate databaseRepo and emailRepo in Servlet and pass them to Handlers’s constructor, which Handlers can then pass to BarHandler. However, with more than a few application-scoped variables, this would become quite tedious, especially for intermediary classes like Handlers which wouldn’t use the dependencies but just pass them on.
Create a DatabaseRepo.getInstance() static singleton method, but we add coupling and lose easy testability.
Use a DI framework to inject DatabaseRepo and EmailRepo into BarHandler. This would mean no longer being able to call new BarHandler, so our Handlers class would have to be passed a Provider<BarHandler> in it’s constructor. Which means Handlers also needs to be instantiated by the DI framework, etc.

I’m sure there are other potential approaches I’m missing, but I think these are the most common. Per the comments with each approach above, I wasn’t satisfied with any of these and so was looking for something else.

AppRegistry Approach

The approach I’ve settled on lately is based around an AppRegistry interface. All of the shared, application-scoped objects (DatabaseRepo, EmailRepo) go into this interface:

public interface AppRegistry {
  DatabaseRepo getDatabaseRepo();

  EmailRepo getEmailRepo();
}

I use the term Registry in deference to Fowler’s pattern, but you could just as well call it AppContext, which is more Spring-like. Which, speaking of Spring, you can basically think of AppRegistry as making a plain, strongly-typed interface with a getXxx method for each bean in your Spring config file.

And now we just create a new instance of it and pass it around:

public class Servlet {
  // registry can potentially be shared via the ServletContext
  private AppRegistry registry = new AppRegistryInstance();
  private Handlers handlers = new Handlers(registry);

  // called when user hits the service
  public void handle(HttpRequest request) {
    handlers.handle(request);
  }
}

public class Handlers {
  private final AppRegistry registry;
  
  public Handlers(AppRegistry registry) {
    this.registry = registry;
  }

  public void handle(HttpRequest request) {
    // dispatches request to the right handler for the request type
    if ("bar".equals(request.getParameter("type"))) {
      new BarHandler(registry, request).handle();
    }
  }
}

// instantiated per request
public class BarHandler {
  private final DatabaseRepo databaseRepo;
  private final EmailRepo emailRepo;
  private final HttpRequest request;
  
  public BarHandler(AppRegistry registry, HttpRequest request) {
    this.databaseRepo = registry.getDatabaseRepo();
    this.emailRepo = registry.getEmailRepo();
    this.request = request;
  }

  public void handle() {
    databaseRepo.lookupId(...);
    emailRepo.sendAnEmail();
  }
}

And that’s it. Pros/cons are discussed next, but the short of it is that we can still test the BarHandler class–a fake (stub or mock, but, no, really, use a stub) AppRegistry can be passed into BarHandler with whatever fake versions of the dependencies you want to use for the test.

Briefly, the AppRegistryInstance class just instantiates the dependencies and holds on to them:

public class AppRegistryInstance implements AppRegistry {
  private final DatabaseRepo databaseRepo;
  private final EmailRepo emailRepo;

  public AppRegistryInstance() {
    databaseRepo = new DatabaseRepo(...settings...);
    emailRepo = new EmailRepo(...settings...);
  }

  public DatabaseRepo getDatabaseRepo() {
    return databaseRepo;
  }

  public EmailRepo getEmailRepo() {
    return emailRepo;
  }
}

And you could just as well create a StubAppRegistryInstance for all of your tests to reuse:

public clas StubAppRegistryInstance implements AppRegistry {
  private final DummyDatabaseRepo databaseRepo = new DummyDatabaseRepo();
  private final DummyEmailRepo emailRepo = new DummyEmailRepo();

  public DummyDatabaseRepo getDatabaseRepo() {
    return databaseRepo;
  }

  public DummyEmailRepo getEmailRepo() {
    return emailRepo;
  }
}

So that now instead of copy/paste setting up a lot of mock expectations/results, your test can pass a StubAppRegistryInstance to the BarHandler under test and then assert against the side affects that BarHandler makes to DummyDatabaseRepo and DummyEmailRepo.

Pros/Cons

Pro: No auto-wiring DI framework. No magic.
Pro: Intermediary classes (e.g. Handlers) don’t have to know about each individual app-wide dependency of the classes it instantiates (either directly or indirectly). new calls stay clean, with at most the extra AppRegistry parameter passed.
Pro: Only classes that require app-wide sharing are in the AppRegistry interface–unlike auto-wiring DI, if a class is not going to be doubled out (like BarHandler, which there is only ever one implementation of), we can just use new and not worry about a DI library/Provider creating it for us.
Pro: AppRegistryInstance is regular Java code, so can freely use configuration files, system properties, even if statements to configure the implementations of DatabaseRepo and EmailRepo appropriately.
Pro: “scopes” become a lot less confusing–where as DI frameworks will, to the client, arbitrarily return shared (singleton) or new (prototype) instances, everything in AppRegistry is by definition application scoped. If you need a “prototype” instance, just call new. If you need a request scope, make a new RequestRegistry (or RequestContext) interface that follows the same AppRegistry pattern and explicitly models the request-scoped dependencies.
Con: BarHandler’s constructor signature only declares that it’s dependency is the AppRegistry (meaning some number of application-scoped beans). This is not as clear or self-documenting as a traditional DI constructor signature which would specify each direct dependency as a separate parameter (e.g.DatabaseRepo and EmailRepo).
Con: You give up the DI container’s “more than just DI” features (like Spring’s automatic transaction management, aspect/proxy features, etc.). Although, personally, I don’t consider this a huge loss anyway.

Other Alternatives

There is a (at least one) variation of this “make an interface for your dependencies” approach.

Context IoC is a pattern than uses per-class interfaces instead of per-scope interfaces. Which addresses the con listed above of BarHandler’s explicit dependencies not being apparent from the API.

E.g. Context IoC would have a BarHandler.Context interface that declared the explicit DatabaseRepo and EmailRepo dependencies, plus extended the corresponding Xxx.Context interface of each object that BarHandler instantiated (so that BarHandler.Context could be used for constructing those instances as well).

I think the Context IoC approach is quite novel, but it leads to a lot of extra interfaces and so is a bit excessive in my opinion.

Conclusion

For me, this pattern has worked out very well to test-enable my code. I can switch out dependencies as needed without giving up the new operator and without making object instantiation so painful that only a DI framework can do it.

So I can apply “YAGNI” to a DI framework and stay with the simplicity of regular Java.

Preferred Build Setup

2011-02-28T00:00:00-08:00

Preferred Build Setup

I’m settling in to a build setup (for Java projects) that I’m reasonably comfortable with.

My current preference is:

An Ivy file to express dependencies
Buildr with ivy4r to do command line builds
Eclipse with IvyDE for Eclipse builds

Requirements

This satisfies my four key requirements:

Not be Maven

This is self-explanatory.
Pull dependencies from a Maven repository

As I’ve admitted before, I dislike Maven, but it’s repo concept has been awesome for the Java community. Except for initially screwing up the group ids (commons-lang/commons-lang), they did good.

While I think Ivy is generally over-engineered (every setting, repo layout, etc., is super extensible), I like having one file (ivy.xml) that is for dependencies, and only dependencies, that both a CLI tool and an Eclipse plugin can read in.

(I.e. I don’t like encoding my dependencies directly in Buildr’s buildfile, because then they can’t be leveraged by an “in-workspace resolution”-capable Eclipse plugin.)
Publish artifacts to a Maven repository

Buildr publishes very nicely to Maven repositories–with pure Ivy, this took some ugly hacks.
Eclipse “in-workspace” dependency resolution

This is my must-have feature. If project Foo depends on project Bar, and I have both of them open in Eclipse, Foo should not be using bar.jar, but should instead have the Bar project’s class files directly on it’s classpath. That way I don’t have to re-jar Bar each time I want to test the latest changes in Foo.

This is the primary flaw with any build solution that generates static .eclipse files (e.g. Buildr’s out of the box eclipse integration, or the old-school mvn eclipse:eclipse integration). An Eclipse plugin can tell which projects it does/does not have open, and update each project’s cross-project dependencies on the fly.

Admittedly, the m2eclipse plugin does this well for Maven. And it seems more solid than IvyDE. Kudos, it’s a great feature. But it’s still Maven.

Ant vs. Buildr

I used to have all of this working with Ant, but it was terribly verbose and involved a lot of copy/paste for each new project. That being said, it was simple and “just worked”, so I lived with it for quiet awhile.

However, after using Buildr for a few projects, I’ve been very pleased with it.

In my opinion, Buildr does an good job of having sane “Standard Java project” defaults that you can tweak when needed. Basically it’s a better Maven.

My two complaints with Buildr are:

Being an embedded DSL in a dynamic language, I find it hard to discover how to do new things. Once you know the right method_missing/whatever-backed incantation, it makes sense. But, personally, I think it is too flexible. I’d be willing to sacrifice some succinctness for a less magical DSL. (Of course, I’m a Java programmer.)
It has (currently) half-baked dependencies support–the pom it generates for you won’t contain any dependencies, making it useless. However, this isn’t a big deal since I use ivy4r to leverage the external ivy.xml file anyway. It’d just be nice if this was supported as a first-class setup.

Aether Possibilities

I really like the looks of Aether.

I’d love to see someone build a m2eclipse-lite Eclipse plugin that read in a minimal, ivy.xml-type file (not a huge pom.xml), and could replace the admittedly fickle IvyDE.

Buildr is also potentially getting Aether support. Granted, it’d use the buildfile-based dependencies and not an external XML file.

But if it did, and this m2eclipse-lite plugin showed up, I would switch.

Example

This is the build setup for my pageobjects project. It uses buildr/ivy, and is small and simple, so should be a good example.

`ivy.xml`

This is where dependencies are declared. The Ivy confs are a lot like Maven’s scopes, so you can differentiate compile-time vs. build-time dependencies.

<ivy-module version="2.0">
  <info organisation="com.bizo" module="pageobjects" revision="${version}"/>
  <configurations>
    <conf name="default" extends="compile"/>
    <conf name="compile"/>
    <conf name="sources"/>
  </configurations>
  <dependencies defaultconfmapping="%->default;sources->sources()">
    <dependency org="org.seleniumhq.selenium" name="selenium" rev="r9790" conf="compile;sources" />
    <dependency org="junit" name="junit" rev="4.8.1" conf="compile;sources" />
  </dependencies>
</ivy-module>

Things to note:

For your dependencies, use conf names that map to Maven scope names, so that the Ivy-generated pom.xml (for uploading to a Maven repo) maps your dependencies correctly.

Otherwise your dependencies will all be listed as <optional>true</optional>, which is terribly annoying.

`ivysettings.xml`

Ivy uses a separate file to configure, among other things, the repositories you want to pull artifacts from. The ibiblio resolver works great for any Maven repository.

<ivysettings>
  <settings defaultResolver="default"/>
  <include url="${ivy.default.settings.dir}/ivysettings-public.xml"/>
  <property name="version" value="SNAPSHOT" override="false"/>
  <resolvers>
    <ibiblio name="local-m2" m2compatible="true" root="file://${user.home}/.m2/repository" changingPattern=".*SNAPSHOT"/>
    <ibiblio name="joist-m2" m2compatible="true" root="http://repo.joist.ws"/>
    <chain name="default" changingPattern=".*SNAPSHOT">
      <resolver ref="public"/>
      <resolver ref="local-m2"/>
      <resolver ref="joist-m2"/>
    </chain>
  </resolvers>
</ivysettings>

Things to note:

changingPattern is required for snapshots

I always set this for at least my local-m2 resolver so that I can test local builds of other projects. Other than that, I’ve been using mostly timestamped jars of projects instead of snapshots.

`.classpath`

This, of course, is the Eclipse classpath file.

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
  <classpathentry kind="src" path="src/main/java"/>
  <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
  <classpathentry kind="con" path="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?ivyXmlPath=ivy.xml&amp;confs=*&amp;ivySettingsPath=%24%7Bworkspace_loc%3Apageobjects%2Fivysettings.xml%7D&amp;loadSettingsOnDemand=false&amp;propertyFiles="/>
  <classpathentry kind="output" path="target/eclipse"/>
</classpath>

Things to note:

Thanks to the IVYDE_CONTAINER line, this file is nice and short and won’t change any time you add/remove a dependency

`buildfile`

This is what drives the Buildr build. It’s like a build.xml file, but written in Ruby, and baked by Rake:

require 'buildr/ivy_extension'

VERSION_NUMBER = ENV['version'] || 'SNAPSHOT'

repositories.remote << "http://www.ibiblio.org/maven2/"
repositories.release_to = 'sftp://joist.ws/var/joist.repo'
repositories.release_to[:permissions] = 0644

# to resolve the ${version} in the ivy.xml
Java.java.lang.System.setProperty("version", VERSION_NUMBER)

define "pageobjects" do
  project.version = VERSION_NUMBER
  project.group = 'com.bizo'
  ivy.compile_conf('compile')

  package_with_sources

  package(:jar).pom.tap do |pom|
    pom.enhance [task('ivy:makepom')]
    pom.from 'target/pom.xml'
  end
end

Things to note:

You pass in the version number with an environment variable, e.g. version=x.y buildr upload
The line repositories.remote << ... is there because even though we use Ivy to get the project’s actual dependencies, Buildr still needs the standard Maven repo to bootstrap dependencies from.
ivy.compile_conf('compile') is what glues the Ivy-fetched dependencies into Buildr’s compile classpath. There is also a test_conf method, e.g. ivy.test_conf('test').
package(:jar).pom.tap is a small 4-line hack to tell Buildr to run ivy:makepom and that it’s output (target/pom.xml) will override Buildr’s default pom file for our project

That’s It

So, that is what is working well for me these days. I particularly like that my standard Buildr buildfile is only ~20 lines long.

For my joist ORM project, I was able to use a ~50-line buildfile to replace ~1200 lines of extremely boilerplate, copy/pasted Ant XML code.

That was quite gratifying–although, in retrospect, somewhat embarrassing that I had let that much Ant code accumulate and was still deluding myself that it was an acceptable setup.

Why I'm a Static Typing Bigot

2010-11-24T00:00:00-08:00

Why I’m a Static Typing Bigot

As most anyone who has had a conversation about programming languages with me knows, I’m a static typing bigot.

Briefly, here’s why.

What I Like About Static Typing

Types act as documentation.

When I read dynamically typed code, I feel completely lost looking at untyped variables and untyped method calls. What methods can I call on this variable? What does this method require of it’s parameters? What exactly is this parameter going to be? A map? An object? An int?

Granted, you can sometimes infer what it is based on the method calls made against it. For example, only the Employee class has a isFired method. However, this works well only in small, simple methods that are unfortunately rare in a lot of code.

This programmer-time type inference also requires mental overhead. Glancing up to a type declaration (or hovering for inferred types) tells you right away.

I do not buy the assertion that I should not care what the types of variables are–that, like Smalltalk, objects will react to whatever messages I send them and I shouldn’t care beyond that. While method_missing is occasionally very handy, in the majority of cases, simple method resolution semantics are going to be happen (foo.bar() calls the Foo.bar method), so the language might as well clue me when when this extremely common/simple case applies.

(Admittedly, I do pine for the static equivalent of method_missing–some sort of AST transformation or compile-time method_missing hook.)
A type system provides free, blazing-fast, pre-unit tests.

Of course you still need real unit tests. Just like having unit tests doesn’t not absolve you from having acceptance tests, having type check tests does not absolve you from having unit tests.

That being said, it’s all about quick feedback. No matter how fast my unit tests are, a compiler can follow me along and more quickly check for trivial errors. In a mature IDE like Eclipse’s JDT, this happens as you type, which is pretty darn quick.

Assuming the type tests check, then you proceed to unit tests. Just like after unit tests check, you proceed to integration tests. Gradually progressing to slower, but more encompassing levels of tests.
Deep down all programmers want the features of a type-aware IDE.

Look at IntelliJ’s RubyMine and Spring’s STS for Groovy. They make programmers who’ve been using dynamic languages drool with their (inferred) type-aware hints, navigation, and refactoring.

My assertion is that, if bolted-on type inference is such an awesome thing, shouldn’t it just be spec’d as part of the language, instead of leaving it up to ad hoc IDE implementations?

Furthermore, if type inference (and meta-programming, per my next point) was part of the language, then the type-aware IDE could check your entire program, not just the parts that were normal/bland enough (no instance_eval) for the IDE-based type inferencer to figure out.
Most dynamic meta programming is done relatively immediately at program startup time, and then things settle down and start to look more static in nature–hence most of it could just as well be done at compile-time.

To explain, I think a generic timeline for meta-programming is:
1. The programmer types input-program
2. Meta-programming magic transforms input-program to result-program
3. The result-program runs
In dynamic languages, 2 is done at runtime, so is very coupled with 3, to where people consider them the same thing–because they are. However, I naively think that 2 could run just as well at compile-time, after the programmer types, via compile-time meta-programming (AST transformations).

For example, I think it is unlikely that, after ActiveRecord adds database columns to a model class, and ActiveSupport opens up String to add helper methods, after two weeks of uptime, there will suddenly be new methods popping up in Employee, String, or other classes.

Furthermore, if meta-programming is done at compile-time, then the result-program is also available at compile-time. So now the compiler/type-aware IDE can type check your entire program, not just the parts that don’t use runtime method_missing, instance_eval magic.

(Note: I still think on-the-fly changing of code, e.g. via a console/debugger, etc., is a good thing, see the “Other Notes” section below.)

Update: This blog post by Loren Segal states this point much better than I do and includes links to papers/profiling results that back up the assertion.

What I Don’t Like About Static Typing

However, even in my bigotry, I will definitely concede static languages have their downsides:

Type-aware IDEs (Eclipse plugins, IntelliJ, etc.) are hard and become barriers to entry.

Compilers themselves, for either static or dynamic languages. are a very well-known, basically solved problem–lots of books, parser libraries, etc. The compilation environment is a very static: take input text X and transform it into output code Y.

IDEs, however, are really hard. The compilation environment is no longer static–the IDE still transforms X to Y, but while transforming X to Y, it also has to put errors on the right line, squiggles under the right words, pop ups at the right place, cache the entire program’s type data to provide instant navigation, and all while the user is flying around the source file changing things and trying to make the IDE developer’s life a nightmare.

Supposedly JVM-based languages can leverage Eclipse’s existing IDE infrastructure. But from looking at the Groovy and Scala IDE plugin histories, it still takes a really long time to get solid, quick integration with the Eclipse JDT.

Type-aware IDEs also stifle innovation as they become a barrier to entry for new languages. Designers of new languages can’t just have a great language, with a great library, with a great community–they also need to invest a very non-trivial amount of time into an Eclipse plugin.
Type systems are hard.

Type theory is a very academic field. You don’t see hobbyists sitting down and writing a new type system for their language over the weekend. But you see plenty of hobbyists sitting down and writing a new syntax for their language over the weekend.
Consequently, static languages always lag behind dynamic languages. Especially with regards to syntax.

I wish static languages evolved at the rate that dynamic ones do, as I like shiny new things as much as the next programmer.

This is mostly why I pine so much for compile-time meta-programming–that it would hopefully allow similar, programmer-driven productivity enhancements without having to build a new language each time.
Type systems can be too constraining. I’ll accept that they occasionally need to be circumvented for the better good.

(However, I don’t think needing to circumvent the type system maybe 5% (if that) of the time in your application means that the other, more normal, bland 95% of your program needs to also give up type checking.)
Compile-time meta programming is still a fringe technique.

Much to my chagrin, compile-time meta programming is not going to be in a mainstream static language anytime soon. Despite promising alternatives (boo, nemerle, lombok, groovy++), it’s lacking from more leading “Java next” contenders like Scala.

Other Notes

Dynamic languages are well-known for their “reload on the fly” productivity. Code can be changed without restarting a process, leading to a faster feedback loop for developers.

I think this is a great thing–and that static languages really should be able to do this as well. Unfortunately, for the JVM anyway, until this OpenJDK patch lands, you need JRebel or framework-level classloader gymnastics to get more than the JVM’s default “only method contents can be updated” behavior. Yeah, this is unfortunate, but a cough temporary cough limitation.

For static languages, applying the type changes, especially if any compile-time meta-programming is involved, likely means using an IDE debugger to change running types, instead of the “just retype the function in a console” approach some dynamic languages can use. But I think the effect is the same.
Dynamic languages often have better designed libraries.

Java in particular is known for it’s ugly APIs. However, very often, the problem is just that an API lacks higher levels of abstraction, and is not related an inherent language flaw.

For example, besides the typical Apache commons-io library, Rickard has an elegant alternative I/O API to the frequently-cited “I can’t succinctly read a file from Java” problem.

Perhaps there is a larger reason why dynamic languages have nice APIs, though my cop out assertion is just that their language designers are better at API design.
Language implementation choice is a very minor factor in resulting code quality.

Perhaps I should have written this up-front as a disclaimer, but I’ve read very good, good, bad, and very (very) bad code in both dynamic and static languages.

So, admittedly, the type checks, IDE tooling, etc. is quibbling, because a good programmer should be able to produce good code in either type of language.

Over Emphasis

I don’t think I have added anything interesting to the dynamic vs. static debate, though that wasn’t my intent–I just wanted to codify my opinion.

I do have a gnawing suspicion that most users of dynamic languages would, without realizing it now, prefer a static language, if there existed a sufficiently robust static language with a syntax, type system, and runtime that would allow them to keep their current style of development.

That being said, there are several developers I respect who are more self-aware than this, and still love dynamic languages.

Which probably just means I put too much emphasis on static vs. dynamic typing debates.

GWT Handler Registrations

2010-11-23T00:00:00-08:00

GWT Handler Registrations

Being a fat-client technology, GWT involves a lot of event listeners. The idiom for using them is pretty simple:

widget.addValueChangeHandler(
  new ValueChangeHandler<String>() {
    public void onValueChange(ValueChangeEvent<String> event) {
      // do logic here
    }
  }
);

One interesting question is what to do with the HandlerRegistration return value of the addValueChangeHandler method:

HandlerRegistration r = widget.addValueChangeHandler(
  new ValueChangeHandler<String>() {
    public void onValueChange(ValueChangeEvent<String> event) {
      // do logic here
    }
  }
);
// when do you call this?
r.removeHandler();

Is Calling `removeHandler()` Required?

There are two relative points about calling removeHandler() on a HandlerRegistration:

removeHandler is never required to avoid DOM-/browser-level memory leaks.

Per UnderstandingMemoryLeaks in the GWT docs, GWT’s event system ensures that you’ll never end up with circular references between your event handlers and unattached DOM elements.

In either Widget.onDetach or page unload, GWT will clean up the DOM event listeners so that garbage collections can happen.

So, it’s tempting to think removeHandler is a quaint but unnecessary capability. However:
removeHandler is required to avoid application-level memory leaks.

If you have a “global” event source, like an always-visible navigation bar widget or an application-wide EventBus, and you have a transient event listener, like a presenter listening for events, the presenter’s event handler will keep it from being garbage collected until the EventBus is also garbage collected.

For example, if you have a FooPlacePresenter in a framework like Tessell:

public class FooPlacePresenter {
  public void onBind() {
    super.onBind();
    eventBus.addHandler(
      BlahEvent.getType(),
      new BlahEventHandler() { ... });
  }
}

Each time the user visits the #foo place, a new instance of FooPlacePresenter will get created and it will start listening for BlahEvents on the application-wide EventBus.

When the user navigates away from #foo, the FooPlacePresenter instance should be garbage collected, so that the memory is freed up for the next place in your application the user visits.

However, because of FooPlacePresenter’s BlahEventHandler that did not get unregistered, the EventBus still thinks FooPlacePresenter is interested in BlahEvents, and so the presenter instance will not be garbage collected.

After a while of in-application navigation, you could potentially have a lot of presenter instances kept in memory due to their handlers listening on the application-wide event bus.

What To Think About

To avoid application-level memory leaks, when adding event handlers, you need to think about:

What is the scope of the event source (the widget or the EventBus)?
What is the scope of the event handler (the presenter)?

And then:

If the scopes are the same: you can ignore the HandlerRegistration and trust that GWT/the garbage collection will clean things up for you.
If the handler scope is longer-lived than the source scope: the handler would keep the source in memory, so you need to call removeHandler() when appropriate.
If the source scope is longer-lived than the handler scope: the source would keep the handler in memory, so you also need to call removeHandler() when appropriate.

Be Proactive

You should also take steps to pro-actively avoid application-level memory leaks.

The best way to do this is to avoid directly exposing application-scoped event sources to place-scoped presenters. If place-scoped code is unable to attach directly to applicate-scoped sources, it will be impossible for place handlers to stay in memory longer than they should.

For example, GWT 2.1 uses this in its ActivityManager implementation. Instead of handing the application-wide EventBus directly to an activity, it wraps the EventBus in a ResettableEventBus.

ResettableEventBus keeps tracks of any handlers the current activity registers, and then when that activity is done, the ActivityManager calls ResettableEventBus removeHandlers() to forcibly remove the old activity’s handlers from the EventBus.

Now the activity doesn’t have to worry about calling removeHandler() on either its widgets or the EventBus, so it’s much less boilerplate and not as prone to programmer error. Both are big wins.

Doubting GMail-style Loading Indicators

2010-08-30T00:00:00-07:00

Doubting GMail-style Loading Indicators

While building Bizo’s Bizads application, I occasionally looked to other AJAX applications for UI styles and patterns to reuse. I am not a UI/UX expert, so searching out best practice seemed like a pragmatic approach.

One pattern that seemed like a sure thing was the GMail-style orange “Loading…” box that pops in/out at the top of the page in GMail while you’re switching labels. It also shows up in Google Reader when switching feeds.

For Bizads, it ended up looking like:

I was originally attracted to it for a few reasons:

It gives the user a single “the app is doing stuff” place to look
It gives the dev a single “the app is doing stuff” place to implement.

So I implemented the global indicator in Bizads, asserting to myself that “oh, yes, this is for the user’s benefit–GMail does it, they’ll know the convention”.

However, I think in reality what attracted me most to the pattern was really the second reason–it made life easier for me as a developer.

With the global indicator, I no longer had to code boilerplate loading/spinning indicator logic for every button in the app. Which, given I was brand new to AJAX development, I’d been doing in kind of an ad hoc way.

Better yet, using gwt-dispatch-style RPC commands, and Tessell’s DispatchXxx events, I had one centralized class that, by listening to the event bus, could automatically handle “command went out, show indicator” and then “response came back, hide indicator”. One place, done.

It was really nice as it let me be lazy and stop thinking about indicators all the time.

That being said, I think it was the wrong choice. In retrospect, I have three complaints about a global indicator:

It jars the user’s focus away from where they are expecting the action to occur.

In GMail, you click “Inbox”, your eyes jump to that section of the page in anticipation–having loading elsewhere on the screen is not what you expected.
The global indicator is hard to get right–a naive implementation will show/hide it as soon as RPC/AJAX calls go out/come back. This results in a harsh flashing that, besides distracting the user, risks that most non-tech-savvy users will not even see it.
The global indicator pattern breaks down as soon as you have multiple activities happening at the same time.

If you let the user have some sort of multi-document/multi-view in your application, you could legitimately have multiple outstanding AJAX calls. To have these both queue up in the global indicator seems confusing and would potentially become bulky.

All of these problems, I think, can be solved by keeping the loading indicator in context.

If a button press led to the action, the indicator should go by that button. If a table is loading its rows, the indicator should be in the table table (which is what the GWT 2.1 CellTable does).

This might be more work for the developer, but I think it would end up being pretty simple once higher levels of abstraction are applied. E.g. the button widget should be a composite that automatically knows how to show/hide its indicator while work is being done.

I have not flushed these abstractions out yet, so I can’t be sure how elegant they will end up being. But so far I’m optimistic.

Joist Tip–Fast Database Resets

2010-08-22T00:00:00-07:00

Joist Tip–Fast Database Resets

I reread parts of Growing Object-Oriented Software, Guided by Tests (GOOS) today. The verbose name aside, it’s a great book.

I also like it because they share my opinion that persistence tests must commit to the database to be worthwhile. Yes!

Abusing Transactions for Resetting Test Data

Ruby on Rails, as nice as it is, seems to have popularized this notion that you can leverage transactions to get relatively quick database tests–instead of having to delete data after each test, you run the each test in its own transaction, and then roll the transaction back before continuing on to the next test.

This allows each test to have a clean database–which is very good for test independence and reproducibility. And rolling back uncommitted data is, admittedly, really fast.

But it also means that any commit-time persistence logic is being skipped–foreign key constraints, unique constraints, etc. Which, unless you’re just testing queries, is kind of the point of the test being a persistence test.

This approach also assumes that your test is not exercising any code that does its own transaction management. Depending on the feature/architecture, this may/may not be a good assumption–but it is definitely not always true.

So we need to find another way to get a clean database, preferably as quickly as possible.

Domain-Level Resetting Test Data

What GOOS suggests is a pretty common pattern of allowing each test to commit its data, and then in setUp, iterating over your domain objects to explicitly delete them:

for (Class domainClass : someListOfDomainClasses) {
  persistenceLayer.deleteAll(domainClass);
}

This can be a little tricky as you don’t want to trigger any foreign key constraints if you, say, delete the FooParent rows before the FooChild rows that have foreign keys to them. The usual hack is something like set foreign_key_constraints=0 for MySQL or deferred key constraints for PostgreSQL.

A large system I worked on used this technique, and it works well. However, as the system grew, things started to slow down. With 500+ tables, calling delete * from table for each table, before each test, adds up to a lot of SQL statements going over the wire.

Database-Level Resetting Test Data

To minimize the amount of SQL calls involved in a reset, we can go a level closer to the data and use a stored procedure to do database-level resetting of test data.

While I’m not usually a fan of stored procedures, in this case, it makes sense–there is 1 SQL call to kick off a slew of database operations:

// postgres
execute("select * from flush_test_database()");

// mysql
execute("call flush_test_database()");

The stored procedure then executes the 500+ delete calls directly against the database.

This is pretty easy to setup, especially if you generate the stored procedure an at opportune time in the developer’s workflow.

For example, Joist is an ORM purpose-built for large schemas. It already has a build-time code generator that generates the boilerplate aspects of domain objects by introspecting the database schema. After doing so, it is easy to add a final step that also creates the flush_test_database stored procedure.

Postgres Implementation

The stored procedure for Postgres looks like:

CREATE OR REPLACE FUNCTION flush_test_database() RETURNS integer AS
$BODY$
BEGIN
SET CONSTRAINTS ALL DEFERRED;
-- repeated for each domain class
ALTER SEQUENCE domain_table RESTART WITH 1 INCREMENT BY 1;
DELETE FROM domain_table;
RETURN 0;
END;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE
  COST 100;
ALTER FUNCTION flush_test_database() SECURITY DEFINER;

Note that the SECURITY DEFINER part is important as it will allow callers of the stored procedure (e.g. your application’s database user) to alter sequences that it does not own (e.g. because they are owned by the root postgres user).

See GenerateFlushFunction.java for the exact code.

MySQL Implementation

MySQL is even easier as TRUNCATE TABLE resets the auto increment column:

CREATE PROCEDURE flush_test_database()
BEGIN
SET FOREIGN_KEY_CHECKS=0;
-- repeated for each domain class
TRUNCATE TABLE domain_table;
SET FOREIGN_KEY_CHECKS=1;
SELECT 1;
END

Again, you can see GenerateFlushFunction.java for the exact code.

Time Savings

On a 500+ table schema, domain-level resetting with 1-call-per-table takes ~200ms.

Against the same schema, database-level resetting with just 1 call takes ~5ms.

So we save ~1/5th of a second. This is not a lot–until you have a huge test suite. If you have 5000 persistence tests, that’s ~16 minutes saved off your test suite runtime.

Limited Applicability

Thankfully, few projects get big enough to need this level of optimization. And, pessimistically, if they do, shaving 15 minutes off their build time is usually the least of their concerns. :-)

Nonetheless, Joist tries to get things like this right, to make your next enterprise project that much less painful.

git workshop

2010-08-21T00:00:00-07:00

git workshop

A few weeks ago I helped out with a git workshop at the Omaha Dynamic Languages User Group.

The format was a “hands on lab” where people installed git on their local machines and ran through a series of canned scenarios to introduce them to the various git commands. add, diff, reset, merge, rebase, etc.

Jay Hannah said a few members had suggested the lab format, and I think it went really well.

I have a tendency to try and explain things from the high/theoretical level, but sometimes it’s better to just ignore that and simply use a tool or practice for awhile. Then after you have some experience and context to work from, the high/theoretical level is much easier to grasp.

Joist vs. Hibernate SQL

2010-08-15T00:00:00-07:00

Joist vs. Hibernate SQL

Lately I’ve been mulling how/whether to implement prefetching in Joist.

To explore the idea, I tried out Hibernate’s subselect prefetching functionality, and it works really well.

But I’ve been using Joist for long enough now that I had forgotten what Hibernate’s SQL looks like. And how I’ve tweaked Joist to, out-of-the-box, just do things intelligently (especially for Postgres).

For example, my test case was inputting 1 parent, 2 children, and 4 grandchildren in an object graph, to see what the SELECTs would look like.

Here’s Hibernate (using hibernate.show_sql=true):

select nextval ('parent_id_seq')
select nextval ('child_id_seq')
select nextval ('grand_child_id_seq')
select nextval ('grand_child_id_seq')
select nextval ('child_id_seq')
select nextval ('grand_child_id_seq')
select nextval ('grand_child_id_seq')
insert into "parent" (version, "name", id) values (?, ?, ?)
insert into "child" (version, "parent_id", "name", id) values (?, ?, ?, ?)
insert into "grand_child" (version, "child_id", "name", id) values (?, ?, ?, ?)
insert into "grand_child" (version, "child_id", "name", id) values (?, ?, ?, ?)
insert into "child" (version, "parent_id", "name", id) values (?, ?, ?, ?)
insert into "grand_child" (version, "child_id", "name", id) values (?, ?, ?, ?)
insert into "grand_child" (version, "child_id", "name", id) values (?, ?, ?, ?)
select
   parent0_.id as id0_0_,
   parent0_.version as version0_0_,
   parent0_."name" as name3_0_0_
   from "parent" parent0_
   where parent0_.id=?
select
  childs0_.parent_id as parent3_1_,
  childs0_.id as id1_,
  childs0_.id as id1_0_,
  childs0_.version as version1_0_,
  childs0_."parent_id" as parent3_1_0_,
  childs0_."name" as name4_1_0_
  from "child" childs0_
  where childs0_.parent_id=?
select
  grandchild0_.child_id as child3_1_,
  grandchild0_.id as id1_,
  grandchild0_.id as id2_0_,
  grandchild0_.version as version2_0_,
  grandchild0_."child_id" as child3_2_0_,
  grandchild0_."name" as name4_2_0_
  from "grand_child" grandchild0_
  where grandchild0_.child_id in (
    select childs0_.id
    from "child" childs0_
    where childs0_.parent_id=?
  )

And here’s joist (using joist.jdbc=TRACE):

select nextval('parent_id_seq')
  UNION ALL select nextval('child_id_seq')
  UNION ALL select nextval('child_id_seq')
  UNION ALL select nextval('grand_child_id_seq')
  UNION ALL select nextval('grand_child_id_seq')
  UNION ALL select nextval('grand_child_id_seq')
  UNION ALL select nextval('grand_child_id_seq')
  UNION ALL select nextval('grand_child_id_seq')
  UNION ALL select nextval('grand_child_id_seq')
INSERT INTO "parent" ("id", "name", "version") VALUES (?, ?, ?)
  -- [TRACE] parameters = [1, p, 0]
INSERT INTO "child" ("id", "name", "version", "parent_id") VALUES (?, ?, ?, ?)
  -- [TRACE] parameters = [1, child.0, 0, 1]
  -- [TRACE] parameters = [2, child.1, 0, 1]
INSERT INTO "grand_child" ("id", "name", "version", "child_id") VALUES (?, ?, ?, ?)
  -- [TRACE] parameters = [1, grandchild.0.0, 0, 1]
  -- [TRACE] parameters = [2, grandchild.0.1, 0, 1]
  -- [TRACE] parameters = [3, grandchild.0.2, 0, 1]
  -- [TRACE] parameters = [4, grandchild.1.0, 0, 2]
  -- [TRACE] parameters = [5, grandchild.1.1, 0, 2]
  -- [TRACE] parameters = [6, grandchild.1.2, 0, 2]
SELECT p.id, p.name, p.version
  FROM "parent" p
  WHERE p.id = ?
SELECT c.id, c.name, c.version, c.parent_id
  FROM "child" c
  WHERE c.parent_id = ?
  ORDER BY c.id
SELECT gc.id, gc.name, gc.version, gc.child_id
  FROM "grand_child" gc
  WHERE gc.child_id = ?
  ORDER BY gc.id
SELECT gc.id, gc.name, gc.version, gc.child_id
  FROM "grand_child" gc
  WHERE gc.child_id = ?
  ORDER BY gc.id

So, Hibernate had 17 SQL statements, Joist had 8 SQL statements, ~50% less.

This can be a big difference since each SQL statement is typically another over-the-wire network call to the database server.

Granted, this is just Joist taking advantage of Postgres’s sequences and so batch-assigning and batch-inserting new instances. (Although Joist does a similar optimization with MySQL, batching inserts and using getGeneratedKeys to return all of the new ids).

The other difference is that Joist’s SQL is purposefully as much “like-a-human-wrote-it” as possible. Some of Hibernate’s generated SQL is just odd–select both child.id and child.parent_id twice in the same ResultSet for instance. Nothing that would really affect anything, but still odd.

At the end though, Hibernate uses prefetching to reload all of the grandchildren with 1 SQL statement, where as Joist has to issue 2 separate FROM grand_child queries for each child_id. Per above, I don’t have that implemented yet.

Joist can definitely never win feature-wise against Hibernate–the crazy thing does about anything you could possibly want from an ORM. But the idea is that Joist can pick an opinionated subset of functionality, and do that really well. And so far that has been working out (for my subset, of course).

Collecting User Actions with GWT

2010-08-13T00:00:00-07:00

Collecting User Actions with GWT

(Cross-posted from the Bizo dev blog.)

While I was at one of the Google I/O GWT sessions (courtesy of Bizo), a Google presenter mentioned how one of their internal GWT applications tracks user actions.

The idea is really just a souped-up, AJAX version of server-side access logs: capturing, buffering, and sending fine-grained user actions up to the server for later analysis.

The Google team was using this data to make A/B-testing-style decisions about features–which ones were being used, not being used, tripping users up, etc.

I thought the idea was pretty nifty, so I flushed out an initial implementation in BizAds for Bizo’s recent hack day. And now I am documenting my wild success for Bizo’s first post-hack-day “beer & blogs” day.

No Access Logs

Traditional, page-based web sites typically use access logs for site analytics. For example, the user was on a.html, then b.html. Services like Google Analytics can then slice and dice your logs to tell you interesting things.

However, desktop-style one-page webapps don’t generate these access logs–the user is always on the first page–so they must rely on something else.

This is pretty normal for AJAX apps, and Google Analytics already supports it via its asynchronous API.

We had already been doing this from GWT with code like:

public native void trackInGA(final String pageName) /*-{
  $wnd._gaq.push(['_trackPageview', pageName]);
}-*/;

And since we’re using a MVP/places-style architecture (see Tessell), we just call this on each place change. Done.

Google Analytics is back in action, not a big deal.

Beyond Access Logs

What was novel, to me, about this internal Google application’s approach was how the tracked user actions were much more fine-grained than just “page” level.

For example, which buttons the user hovers over. Which ones they click (even if it doesn’t lead to a page load). What client-side validation messages are tripping them up. Any number of small “intra-page” things that are nonetheless useful to know.

Obviously there are a few challenges, mostly around not wanting to detract from the user experience:

How much data is too much?

Tracking the mouse over of every element would be excessive. But the mouse over of key elements? Should be okay.
How often to send the data?

If you wait too long while buffering user actions before uploading them to the server, the user may leave the page and you’ll lose them. (Unless you use a page unload hook, and the browser hasn’t crashed.)

If you send data too often, the user might get annoyed.

The key to doing this right is having metrics in place to know whether you’re prohibitively affecting the user experience.

The internal Google team had these metrics for their application, and that allowed them to start out batch uploading actions every 30 seconds, then every 20 seconds, and finally every 3 seconds. Each time they could tell the users’ experience was not adversely affected.

Unfortunately, I don’t know what exactly this metric was (I should have asked), but I imagine it’s fairly application-specific–think of GMail and average emails read/minute or something like that.

Implementation

I was able to implement this concept rather easily, mostly by reusing existing infrastructure our GWT application already had.

When interesting actions occur, I have the presenters fire a generic UserActionEvent, which is generated using tessell-apt from this spec:

@GenEvent
public class UserActionEventSpec {
  @Param(1)
  String name;
  @Param(2)
  String value;
  @Param(3)
  boolean flushNow;
}

Initiating the tracking an action is now just as simple as firing an event:

UserActionEvent.fire(
   eventBus,
   "someAction",
   "someValue",
   false);

I have a separate, decoupled UserActionUploader, which is listening for these events and buffers them into a client-side list of UserAction DTOs:

private class OnUserAction implements UserActionHandler {
  public void onUserAction(final UserActionEvent event) {
    UserAction action = new UserAction();
    action.user = defaultString(getEmailAddress(), "unknown");
    action.name = event.getName();
    action.value = event.getValue();
    actions.add(action);
    if (event.getFlushNow()) {
      flush();
    }
  }
}

UserActionUploader sets a timer that every 3 seconds calls flush:

private void flush() {
  if (actions.size() == 0) {
    return;
  }
  ArrayList<UserAction> copy =
    new ArrayList<UserAction>(actions);
  actions.clear();
  async.execute(
    new SaveUserActionAction(copy),
    new OnSaveUserActionResult());
}

The flush method uses gwt-dispatch-style action/result classes, also generated by tessell-apt, to the server via GWT-RPC:

@GenDispatch
public class SaveUserActionSpec {
  @In(1)
  ArrayList<UserAction> actions;
}

This results in SaveUserActionAction (okay, bad name) and SaveUserActionResult DTOs getting generated, with nice constructors, getters, setters, etc.

On the server-side, I was able to reuse an excellent DatalogManager class from one of my Bizo colleagues (unfortunately not open source (yet?)) that buffers the actions data on the server’s hard disk and then periodically uploads the files to Amazon’s S3.

Once the data is in S3, it’s pretty routine to setup a Hive job to read it, do any fancy reporting (grouping/etc.), and drop it into a CSV file. For now I’m just listing raw actions:

-- Pick up the DatalogManager files in S3
drop table dlm_actions;
create external table dlm_actions (
    d map<string, string>
)
partitioned by (dt string comment 'yyyyddmmhh')
row format delimited
fields terminated by '\n' collection items terminated by '\001' map keys terminated by '\002'
location 's3://<actions-dlm-bucket>/<folder>/'
;

alter table dlm_actions recover partitions;

-- Make a csv destination also in S3
create external table csv_actions (
    user string,
    action string,
    value string
)
row format delimited fields terminated by ','
location 's3://<actions-report-bucket/${START}-${END}/parts'
;

-- Move the data over (nothing intelligent yet)
insert overwrite table csv_actions
select dlm.d["USER"], dlm.d["ACTION"], dlm.d["VALUE"]
from dlm_actions dlm
where
    dlm.dt >= '${START}00' and dlm.dt < '${END}00'
;

Then we use Hudson as a cron-with-a-GUI to run this Hive script as an Amazon Elastic Map Reduce job once per day.

Testing

Thanks to the awesomeness of Tessell, the usual GWT widgets, GWT-RPC, etc., can be doubled-out and testing with pure-Java unit tests.

For example, a method from UserActionUploaderTest:

UserActionUploader uploader = new UserActionUploader(registry);
StubTimer timer = (StubTimer) uploader.getTimer();

@Test
public void uploadIsBuffered() {
  eventBus.fireEvent(new UserActionEvent("someaction", "value1", false));
  eventBus.fireEvent(new UserActionEvent("someaction", "value2", false));
  assertThat(async.getOutstanding().size(), is(0)); // buffered

  timer.run();
  final SaveUserActionAction a1 = async.getAction(SaveUserActionAction.class);
  assertThat(a1.getActions().size(), is(2));
  assertAction(a1, 0, "anonymous", "someaction", "value1");
  assertAction(a1, 1, "anonymous", "someaction", "value2");
}

The usual GWT timers are stubbed out by a StubTimer, which we can manually tick via timer.run() to deterministically test timer-delayed business logic.

That’s It

I can’t say we have made any feature-altering decisions for BizAds based on the data gathered from this approach yet–technically its not live yet. But it’s so amazing that surely we will. Ask me about it sometime in the future.

Dammit, MySQL

2010-07-22T00:00:00-07:00

Dammit, MySQL

After being a happy PostgreSQL user for years, I’ve finally had to use MySQL for the last 6+ months.

I have to admit, I was starting to think it wasn’t all that bad–that the “MySQL is a toy” line was outdated.

It’s not.

Here is my current laundry list of “dammit, MySQL” complaints:

DDL Doesn’t Respect Transactions
No Deferred Foreign Key Constraints
No Deferred Unique Key Constraints
ANSI Mode Defaults Off
Not Really Not Nulls
Auto-Changing Timestamps
Crappy Error Messages

DDL Doesn’t Respect Transactions

My biggest complaint is that MySQL’s DDL operations (CREATE TABLE, ADD COLUMN, etc.) do not occur within transactions.

Well, probably–in typical MySQL fashion, you can execute CREATE TABLE/etc. within a transaction (e.g. after a BEGIN) and, instead of failing, MySQL will blithely commit all existing work in your transaction, create the table, and then let you continue on your merry way.

This makes deployments a crap shoot–whether you’re using migrations or a hand-coded SQL upgrade script, you better hope the whole thing applies cleanly, because if your script blows up halfway through, you’re stuck with a schema that is somewhere between versions.

Getting back to a deployable state, or even one where you can rerun the fixed upgrade script, means either manually teasing the schema back to the old version, or reverting to a snapshot and starting all over.

And this isn’t just MyISAM–this is the InnoDB engine as well.

PostgreSQL, on the other hand, executes all DDL within a real transaction, and if one CREATE TABLE/ADD COLUMN fails, from experience, I know the entire schema rolls back to the prior state.

No Deferred Foreign Key Constraints

Deferred foreign key constraints mean you can do:

BEGIN;
INSERT INTO child (id, parent_id, name) VALUES (2, 1, 'child');
INSERT INTO parent (id, name) VALUES (1, 'parent');
COMMIT;

Note that technically we’ve inserted child.parent_id=1, but parent.id=1 is not in the database yet.

Having deferred foreign key constraints means this is okay as long as the parent.id=1 row shows up before the transaction commits.

Not having deferred foreign key constraints means INSERT INTO child blows up right away. You instead have to ensure INSERT INTO parent comes first.

While this doesn’t seem to be a big deal, the ability to defer foreign keys and freely order INSERTs within a transaction makes technologies like ORMs much simpler.

It also becomes crucial if you have a two-way relationship between rows, e.g.:

BEGIN;
INSERT INTO child (id, parent_id, name) VALUES (2, 1, 'child');
INSERT INTO parent (id, name, current_child_id) VALUES (1, 'parent', 1);
COMMIT;

Both statements depend on the other–there is no way to execute these two statements if you lack deferred foreign key constraints.

You are reduced to making one of them nullable, e.g. parent.current_child_id, and then creating a partially-valid Parent and fully-valid Child, forcing your ORM to flush to SQL, then going back and updating Parent to point to the new Child, and doing a final flush+commit.

MySQL still doesn’t have deferred foreign key constraints, PostgreSQL has had them for as long as I’ve used it. Even SQLite has deferred foreign keys constraints.

No Deferred Unique Key Constraints

Deferred unique constraints are similar, but mean you can temporarily violate a unique constraint, as long as you clean things up before the transaction commits. E.g.:

BEGIN;
INSERT INTO user (id, username) VALUES (1, 'bob');
INSERT INTO user (id, username) VALUES (2, 'fred');
COMMIT;

-- want to change bob->fred, fred->bob
BEGIN;
UPDATE user SET username = 'fred' WHERE id = 1;
UPDATE user SET username = 'bob' WHERE id = 2;
COMMIT;

Without deferred unique constraints, changing bob -> fred would blow up immediately. Instead you have to dance around the issue by using a temporary value, e.g.:

BEGIN;
UPDATE user SET username = 'temp' WHERE id = 1;
UPDATE user SET username = 'bob' WHERE id = 2;
UPDATE user SET username = 'fred' WHERE id = 1;
COMMIT;

Like foreign key constraints, this extra hoop means two explicit unit of work flushes as you change User1 to a temp value, flush, change User2 to the right value, flush, and finally change User1 to the right value, flush and commit.

With deferred unique constraints, it is very simple to set User1 to the new value, set User2 to the new value, and have your ORM auto-flush. It will just work.

MySQL doesn’t have deferred unique constraints, PostgreSQL just got them in (the nearly released) 9.0.

ANSI Mode Defaults Off

I was dumbfounded to learn about MySQL’s sql-mode option.

What kind of product:

Lets users disable standards compliance as a feature?
Sets the default mode to not standards complaint?

With MySQL, you can use ANSI mode, which affects such non-trivial things as it actually uses the same escape character as the SQL standard. Amazing!

PostgreSQL doesn’t screw around like this, it just always implements the standard.

Not Really Not Nulls

Also hidden in the sql-mode docs was an option to make NOT NULL actually mean NOT NULL.

For example, adding the TRADITIONAL SQL mode restores the sanity:

mysql> create table user (username varchar(50) not null);
Query OK, 0 rows affected (0.00 sec)

-- this works when it really should not
mysql> insert into user () values ();
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> set sql_mode='ANSI';
Query OK, 0 rows affected (0.00 sec)

mysql> insert into user () values ();
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> set sql_mode='ANSI,TRADITIONAL';
Query OK, 0 rows affected (0.00 sec)

-- finally, it blows up
mysql> insert into user () values ();
ERROR 1364 (HY000): Field 'username' doesn't have a default value

So, does your MySQL database have some NOT NULL columns? Are you really sure they don’t have null values in them? Have you checked your SQL mode?

If you use PostgreSQL, you can be sure that your NOT NULL columns do not have null values in them.

(Update: I was wrong–MySQL will not insert null, but instead insert a default value, e.g. 0 for int or empty-string for strings. Personally, since I did not include a DEFAULT clause in my DDL, I did not expect the database to add a DEFAULT value for me.)

Auto-Changing Timestamps

What would most developers assume happens if today you run:

CREATE TABLE employee (
  id int,
  name varchar(50),
  created timestamp
);
INSERT INTO employee (id, name, timestamp) (1, 'bob', NOW());

Then tomorrow you do:

UPDATE employee SET name = 'fred';

Quick, what’s created? Yesterday, right? Ah ha! No. It’s today:

“With neither DEFAULT nor ON UPDATE clauses, it is the same as DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP.”

See that ON UPDATE CURRENT_TIMESTAMP? That means MySQL changes the column value each time you update the row.

What MySQL developer ever thought that this was a good default behavior? I’m trying to think if this is the worst offender of “least surprise” or the if NOT REALLY NOT NULL is worse. It’s close.

Crappy Error Messages

To top it all off, MySQL error messages are a joke. This beauty:

Can't create table 'foo.#sql-338_90' (errno: 150)

Simply means “you tried to reference a non-existent table”.

For as long as MySQL has been around, and how many countless users have run into this issue, you’d think they’d consider displaying a better error message.

Even git is better at fixing its ease-of-use issues than MySQL.

More often than not, PostgreSQL errors say plainly what really went wrong.

Dammit, AWS

Unfortunately, RDS is awesome, and RDS uses MySQL.

I, and many others, are pulling for Amazon to add PostgreSQL support. Maybe with the first-class replication in the 9.0 release, it will happen sooner rather than later. I can hope.

Publishing to Maven Repos with Ivy

2010-07-18T00:00:00-07:00

Publishing to Maven Repos with Ivy

Publishing to Maven repositories is a fact of life for projects in the Java community.

While I am not a fan of Maven itself, I readily admit that the standard shared repository/transitive-metadata approach they have driven has been a great thing for the community. While I was initially skeptical, downloading dependencies and keeping them out of source code repos is a good thing.

Using Ivy

That being said, I prefer to leverage Maven repositories from a safe, arms length distance via the excellent Ivy (and IvyDE) tool which, besides other features, can understand the Maven repository format both as a source for dependencies and destination for publishing projects.

While Ivy-to-Maven works well, it did take me a few tries to get it right, so here are the various settings/files that so far are doing the job.

`ivysettings.xml`

This is the gwt-mpv-dev ivysettings.xml, with comments added.

<ivysettings>
  <!--
    This property is used later in the ivy.xml file to set
    the project's revision. Unless overridden, it defaults
    to the Maven SNAPSHOT convention, as that it works well
    for publishing local test builds to ~/.m2/repository.
  -->
  <property name="revision" value="SNAPSHOT" override="false"/>

  <!-- "default" is defined later in the file. -->
  <settings defaultResolver="default"/>

  <!-- Pulls in the "public" resolver for ibiblio-hosted jars. -->
  <include url="${ivy.default.settings.dir}/ivysettings-public.xml"/>

  <resolvers>
    <!-- add any 3rd-party maven repos here... -->
    <ibiblio name="joist" m2compatible="true" root="http://repo.joist.ws"/>

    <!--
      for *retrieving* artifacts for local testing builds,
      we'll use maven's own .m2/repository.
    -->
    <ibiblio
      name="local-m2"
      m2compatible="true"
      root="file://${user.home}/.m2/repository"/
      changingPattern=".*SNAPSHOT">

    <!--
      for *publishing* artifacts for local testing builds,
      as the previous ibiblio resolver does not support
      publishing
    -->
    <filesystem name="local-m2-publish" m2compatible="true">
      <artifact pattern="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"/>
    </filesystem>

    <!--
      for publishing release artifacts via an sshfs-mounted share
    -->
    <filesystem name="share-m2" m2compatible="true">
      <artifact pattern="${user.home}/repo/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"/>
    <filesystem>

    <!-- strings the separate resolvers all together -->
    <chain name="default" changingPattern=".*SNAPSHOT">
      <resolver ref="public"/>
      <resolver ref="joist"/>
      <!--
        Potential gotcha: you want your local-m2 to be last, or at least
        after the public repo. Otherwise maven proper might partially
        download a project into ~/.m2, but not include sources, and if
        local-m2 is first, ivy will pull the artifacts out of ~/.m2 and
        cache the partially-downloaded view of the repo (i.e. no sources).
        If public is first, ivy will always try to get artifacts from their
        canonical source.
      -->
      <resolver ref="local-m2"/>
    </chain>
  </resolvers>
</ivysettings>

The primary gotcha in this ivysettings.xml was having to use two separate resolvers for the same ~/.m2/repository. This is because:

Only the ibiblio resolver will parse poms and follow the pom’s transitive dependencies.

(Technically the filesystem or url resolvers could retrieve jars with a Maven-ish artifact pattern, but the pom dependencies would be skipped.)
The ibiblio resolver does not support publishing, so we have to fall back to the filesystem resolver with a Maven-ish artifact pattern to publish.

So, with the current Ivy 2.1.0 capabilities, it takes two resolvers for a single Maven repo if you want to both retrieve from and publish to it.

`ivy.xml`

This is the gwt-mpv-dev ivy.xml, again with comments.

<ivy-module version="2.0" xmlns:m="http://ant.apache.org/ivy/maven">
  <!--
    We set the revision to the revision property from
    ivysettings.xml, which defaults to SNAPSHOT. This
    is overriden when publishing.
  -->
  <info organisation="org.gwtmpv" module="gwt-mpv-dev" revision="${revision}"/>

  <!--
    I'm not a huge fan of a separate sources conf,
    but that is how Ivy's ibiblio resolver converts
    poms, so we'll stay consistent with that.
  -->
  <configurations>
    <conf name="default"/>
    <conf name="sources"/>
  </configurations>

  <publications>
    <!--
      We explicitly list a pom as an artifact of our
      project. This way the Ivy publish task will
      upload the pom to the maven repo, along with
      the jars and sources.
    -->
    <artifact type="pom" ext="pom" conf="default"/>

    <!--
      This is the main jar, nothing special.
    -->
    <artifact type="jar" ext="jar" conf="default"/>

    <!--
      To publish sources to a maven repo, the
      m:classifier="sources" is required.
    -->
    <artifact type="source" ext="jar" conf="sources" m:classifier="sources"/>
  </publications>

  <!--
    defaultconf == we want the jars + sources for our dependencies
    defaultconfmapping == unless specified otherwise, our confs map
      to default for our dependencies
  -->
  <dependencies defaultconfmapping="sources->sources(),%->default" defaultconf="default,sources">
    <!--
      gwt-mpv-user is published simultaneously with
      gwt-mpv-dev, so depend on the same exact revision.
    -->
    <dependency org="org.gwtmpv" name="gwt-mpv-user" rev="${revision}" conf="default"/>

    <!-- other dependencies -->
    <dependency org="com.google.gwt" name="gwt-dev" rev="2.1.0.M1" conf="default"/>
  </dependencies>
</ivy-module>

`build.xml`

Finally, here is the Ivy-related part of the gwt-mpv-dev build.xml:

<property name="ivy.jar.version" value="2.1.0"/>
<property name="ivy.jar.name" value="ivy-${ivy.jar.version}.jar"/>
<property name="ivy.home" value="${user.home}/.ivy2"/>
<available property="ivy.installed" file="${ivy.home}/${ivy.jar.name}"/>

<!-- 
  this is called once and auto-installs the ivy jar into
  ~/.ivy2 so that users only have to have ant to build.
-->
<target name="ivy-install" unless="ivy.installed">
  <mkdir dir="${ivy.home}"/>
  <get src="http://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.jar.version}/${ivy.jar.name}" dest="${ivy.home}/${ivy.jar.name}"/>
</target>

<!--
  this is called automatically and just inits ivy
-->
<target name="ivy-init" depends="ivy-install">
  <taskdef resource="org/apache/ivy/ant/antlib.xml" uri="antlib:org.apache.ivy.ant" classpath="${ivy.home}/${ivy.jar.name}"/>
  <ivy:resolve/>
</target>

<!--
  called by the user to download jars into bin/lib/
-->
<target name="ivy-retrieve" depends="ivy-init" description="downloads jars for the project">
  <ivy:retrieve pattern="bin/lib/[conf]/[type]s/[artifact].[ext]" conf="*" type="*"/>
</target>

<!--
  makes a pom for the project based off the ivy.xml file
-->
<target name="gen-pom" depends="ivy-init">
  <ivy:makepom ivyfile="ivy.xml" pomfile="bin/poms/${ant.project.name}.pom">
    <!--
      Mapping confs to scopes is important, otherwise
      unmapped confs are included as optional. If you
      have private confs, the best option seems to
      be marking them as provided or system. See
      IVY-1201 for an ehancement request.
    -->
    <mapping conf="default" scope="compile"/>
  </ivy:makepom>
</target>

<!--
  publishes to ~/.m2/repository so that other testing
  builds on our local machine can see it
-->
<target name="ivy-publish-local" depends="jar,ivy-init,gen-pom" description="publish jar/source to maven repo mounted at ~/.m2/repository">
  <ivy:publish resolver="local-m2-publish" forcedeliver="true" overwrite="true" publishivy="false">
    <artifacts pattern="bin/[type]s/[artifact].[ext]"/>
  </ivy:publish>
</target>

<!--
  pubishes to the ~/repo directory, which should be something
  like an sshfs-mount of the public maven repository you are
  publishing to
-->
<target name="ivy-publish-share" depends="jar,ivy-init,gen-pom" description="publish jar/source to maven repo mounted at ~/repo">
  <ivy:publish resolver="share-m2" forcedeliver="true" overwrite="true" publishivy="false">
    <artifacts pattern="bin/[type]s/[artifact].[ext]" />
  </ivy:publish>
</target>

Making Poms

The build.xml file above uses Ivy’s makepom Ant task to convert our project’s ivy.xml into a project.pom before uploading it to the Maven repository.

This is generally acceptable, insofar as Ivy will get all of the dependencies translated correctly, but you’ll end up with a very minimal pom.

So if you want to add more elements to the pom, it is probably easiest to just hand-maintain a project.pom.template and use a simple Ant filter to update the version on each build before being uploaded.

For example, gwt-mpv-dev-0.1.pom was built automatically by makepom, while gwt-mpv-apt-1.3.pom was built from a hand-maintained template.

Local Testing Builds

So far I have not published SNAPSHOT versions publicly, but they are very handy for sharing in-development changes between projects on your local machine. Just doing:

ant ivy-publish-local

Will publish a jar to ~/.m2 for other local projects to pull in your latest/uncommitted changes.

Since we’re going through the local-m2 <ibiblio/> resolver, Ivy automatically handles latest-SNAPSHOT checking and we don’t have to bother with any ~/.ivy2/cache-busting tricks like I talked about in Ivy Is Useful.

Though if you’re using IvyDE and workspace resolution of dependencies, Eclipse should setup all of the cross-project references correctly and you won’t have to constantly publish SNAPSHOT jars just for local consumption each time you make a change.

Doing Releases

With the above setup, I can now publish gwt-mpv to the joist repo via:

ant -Drevision=x.y ivy-publish-share

It Works

While this looks like a lot of code, my inline comments added a lot–it is generally ~50 lines of ivysettings.xml and ivy.xml per-project and then ~50 lines of straight-forward build.xml Ant code.

While this is more than, say, 10 LOC, it hasn’t been burdensome enough for me to investigate anything else, e.g. Buildr, or even near burdensome enough to consider using Maven itself.

I should probably throw the common files into a shared git repository and then git submodule them around instead of being reduced to copy/paste. But I haven’t gotten around to it yet, and it seems like each project always has some tweak here or there that would be annoying to generalize.

Nonetheless, this has been working well for me. If I made any errors or omissions, please let me know.

Update 08/03/2010: Add gotcha about the local-m2 resolver being chained after public resolvers.

Update 01/13/2011: Add changingPattern="true" to local-m2 and default resolvers so that snapshots work without having Ant manually flushing the cache.

ORM Prefetching

2010-07-16T00:00:00-07:00

ORM Prefetching

Prefetching is pretty well-known technique for optimizing ORM/database access. However, I was surprised at how much thought and cool stuff people are doing with it.

`n+1` Selects

The problem prefetching solves is known as n+1 selects. It is best seen by a code example:

Blog blog = loadBlog(1); // load from somewhere
for (Post post : blog.getPosts()) {
    for (Comment comment : post.getComments()) {
        render(comment);
    }
}

This usage almost always means:

1 query of SELECT * FROM blog WHERE id = 1–loads 1 blog
1 query of SELECT * FROM post WHERE blog_id = 1–loads N posts
N queries of SELECT * FROM comment WHERE post_id = x–loads 1 comment, repeatedly for each post

If you have 20 blogs, you’ll end up with 22 SQL calls back/forth to the database. Each call is a network trip, so this can quickly slow down your application.

The goal of prefetching is to load the entire blog/posts/comments object graph with as few SQL calls as possible. Depending on the approach, you can have as few as 1 SQL call, which is a huge savings and will result in very real performance improvements.

Explicit Pre-Fetching

Traditionally, ORMs required explicit custom queries to prefetch an entire object graph.

For example, with Hibernate you’d do something like:

public Blog loadViaCustomQuery(int id) {
  List blogs = sess.createCriteria(Blog.class)
    .add(Restrictions.equal("id", id))
    .setFetchMode("posts", FetchMode.EAGER)
    .list();
  return blogs.get(0);
}

The code then becomes:

Blog blog = loadViaCustomQuery(1);
for (Post post : blog.getPosts()) {
    for (Comment comment : post.getComments()) {
        render(comment);
    }
}

This usage means:

1 query of SELECT b.*, p.* FROM blog b, LEFT OUTER JOIN posts p ON b.id = p.blog_id WHERE b.id = 1–loads 1 blog plus n posts
n queries of SELECT * FROM comment WHERE post_id = x–loads 1 comment, repeatedly for each post

So we removed 1 extra query, going from 22 calls to 21 calls, but we really we haven’t avoided the n+1 problem–I’m still poking around Hibernate docs to see if you can bring back sub-sub-collections via prefetching.

(Disclaimer: I don’t have an active Hibernate setup right now–I’ll come back and update this if I ever get it figured out, but until then, please correct any of the technical points I have wrong.)

Even so, there are several problems with explicit prefetching:

It requires up-front developer effort to write a custom query with correct prefetch semantics
It requires on-going developer effort to update the custom query as the code changes what parts of the object graph it does/does not need–performance could actually end up degraded if the wrong data is being prefetched

Implicit Pre-Fetching

What seems more novel to me is eschewing custom queries and the ORM just being more intelligent about its usage.

One trick that Hibernate actually already implements is subselect fetching. The idea is that when you’re mapping your Post class, you set fetch=subselect on the comments element:

<class name="Post">
    <!-- ... other mappings ... -->
    <set name="comments" fetch="subselect">
        <key column="post_id" not-null="true"/>
        <one-to-many class="Comment"/>
    </set>
</class>

Now our original code snippet:

Blog blog = loadBlog(1); // load from somewhere
for (Post post : blog.getPosts()) {
    for (Comment comment : post.getComments()) {
        render(comment);
    }
}

Will result in these queries:

1 query on loadBlog(1) of SELECT * FROM blog WHERE id = 1–loads 1 blog
1 query on blog.getPosts() of SELECT * FROM post WHERE blog_id = 1–loads n posts
1 query on the 1st post.getComments() of SELECT * FROM comment WHERE post_id IN (N post ids)–loads m comments

Update: I reproduced this behavior in a project with Parent/Child/GrandChild, here is SQL Hibernate generated:

select
  parent0_.id as id0_0_,
  parent0_.version as version0_0_,
  parent0_."name" as name3_0_0_
  from "parent" parent0_
  where parent0_.id=?
select
  childs0_.parent_id as parent3_1_,
  childs0_.id as id1_,
  childs0_.id as id1_0_,
  childs0_.version as version1_0_,
  childs0_."parent_id" as parent3_1_0_,
  childs0_."name" as name4_1_0_
  from "child" childs0_
  where childs0_.parent_id=?
select
  grandchild0_.child_id as child3_1_,
  grandchild0_.id as id1_,
  grandchild0_.id as id2_0_,
  grandchild0_.version as version2_0_,
  grandchild0_."child_id" as child3_2_0_,
  grandchild0_."name" as name4_2_0_
  from "grand_child" grandchild0_
  where grandchild0_.child_id in (
    select childs0_.id
    from "child" childs0_
    where childs0_.parent_id=?
  )

What happened is that Hibernate applied a heuristic of saying: “okay, you have Post A, and you want its Comments…but you also have Post B, Post C, etc., in your session, I’m going to go ahead and get the Comments for all of those Posts at the same time.”

From my perspective, this seems like a pretty sweet optimization.

It dramatically reduces the SQL queries–not all the way down to 1 query, but 3 is still a lot better than 22 (or whatever n is)
It’s automatic, and so requires no extra initial/on-going thought from the developers to maintain.
You risk over-fetching data, however I think this is not a big deal because:
- You’re already making a SQL call, which is dominated by the wire-call/latency
- The WHERE post_id IN (N posts ids) is still a very simple query–no outer left joins which can lead to data duplication–so should return very fast even if slightly more data is coming back than you need
- Extremely large collections that would ruin this approach should probably not be mapped via implicit object graph navigation anyway–as soon as a parent has >100-500 children, you probably don’t want to load them in a single UnitOfWork anyway and so should not map parent.getChildren() to prevent developers from accidentally causing session size bloat

Optimized Implicit Prefetching

What is even cooler than implicit prefetching, is profiled implicit prefetching.

I came across the paper Automatic Prefetching by Traversal Profiling in Object Persistence, where the authors extend Hibernate 3.1 to keep live statistics about the application’s object graph navigation.

So, initially you’ll get the worst case n+1 selects, but after a few iterations, their AutoFetch algorithm recognizes that, given the line number/stack trace of the loadBlog(1) line, it will soon need all of the posts and comments, so issues a single:

1 query of:

SELECT b.*, p.*, c.*
FROM blog b
LEFT OUTER JOIN posts p ON b.id = p.blog_id
LEFT OUTER JOIN comments c ON p.id = c.post_id
WHERE b.id = 1

That loads the entire blog/posts/comments object graph

This is pretty magically awesome.

I think the only downside is that technically that many outer joins in 1 query will lead to potentially large data duplication due to it being a cross product. I do not know how much of an issue this would be in real-world usage.

They might be better off sending a trio 3 simple statements:

SELECT * FROM blog WHERE id = 1
SELECT * FROM post WHERE blog_id = 1
SELECT * FROM comment WHERE post_id IN (SELECT id FROM post WHERE blog_id = 1)

Across the wire all the same time, then getting back 3 separate result sets. This would avoid the nested LEFT OUTER JOINs, but still get all the data in a single wire call.

However, I really have no idea how well multi-statement result sets are supported in JDBC and the various databases that Hibernate supports.

Active Research

What is most surprising to me is that ORM techniques are an active area of academic research. For example, the AutoFetch paper came out of the University of Texas at Austin and was supported by a National Science Foundation.

I never would have guessed that federal academic funding was going into such a real-world/everyday technology like ORMs.

Besides the AutoFetch algorithm, the AutoFetch paper is also interesting as it cites several other ORM papers that seem worth tracking down and reading. I definitely suggest anyone else interested in the ORM problem try and do the same.

Code Generation Is Not Evil

2010-07-15T00:00:00-07:00

Code Generation Is Not Evil

I’m a big fan of code generation (see joist, bindgen, Tessell, and interfacegen. I think active code generation can go a long way towards reducing boilerplate in a project.

Bad Reputation

However, it seems like code generation has a bad reputation these days. Especially in the Java community, most projects (Hibernate, etc.) have long preferred runtime byte code generation.

I will readily admit that most of code generation’s reputation is well-deserved, as done incorrectly it can be ugly and painful.

For example, this snippet from the Torque’s ORM templates:

#if ($objectIsCaching)
  #foreach ($fk in $table.Referrers)
    #set ( $tblFK = $fk.Table )
    #if ( !($tblFK.Name.equals($table.Name)) )
      #set ( $className = $tblFK.JavaName )
      #set ( $relatedByCol = "" )
      #foreach ($columnName in $fk.LocalColumns)
        #set ( $column = $tblFK.getColumn($columnName) )
        #if ($column.isMultipleFK())
          #set ($relatedByCol= "$relatedByCol$column.JavaName")
        #end
      #end

      #if ($relatedByCol == "")
        #set ( $relCol = "${className}${beanSuffix}s" )
      #else
        #set ( $relCol= "${className}${beanSuffix}sRelatedBy$relatedByCol" )
      #end
      #set ( $collName = "coll$relCol" )

  protected List#if($enableJava5Features)<${className}${beanSuffix}>#end $collName;

  public List#if($enableJava5Features)<${className}${beanSuffix}>#end get${relCol}()
  {
      return $collName;
  }

  public void set${relCol}(List#if($enableJava5Features)<${className}${beanSuffix}>#end list)
  {
      if (list == null)
      {
          $collName = null;
      }
      else
      {
          $collName = new ArrayList#if($enableJava5Features)<${className}${beanSuffix}>#end(list);
      }
  }

  #end
#end

Complex templates like this make both the initial development and long-term maintenance of code generators painful.

Another example is this generated output from GXP:

package com.bizo.selfservice.services.email.templates;

import com.google.gxp.base.*; // causes unused warning
import com.google.gxp.css.*; // causes unused warning
import com.google.gxp.html.*; // causes unused warning
import com.google.gxp.js.*; // causes unused warning
import com.google.gxp.text.*; // causes unused warning

public class FooEmail extends com.google.gxp.base.GxpTemplate {

  private static final String GXP$MESSAGE_SOURCE = "com.foo.templates"; // causes unused warning

  public static void write(final java.lang.Appendable gxp$out, final com.google.gxp.base.GxpContext gxp_context) throws java.io.IOException {
    final java.util.Locale gxp_locale = gxp_context.getLocale(); // caused unused warning
    // ...more generated output...
  }

Ugly, warning-filled output makes developers turn up their noses when they invariably glance at the generated output as they use it.

I don’t mean to pick on either project–Torque was awesome for its time, and I really like the idea of GXP. But neither necessarily endears users to code generation.

However, that does not mean the entire approach is flawed. With some effort and good techniques, code generation can be done well.

Benefits

Code generation has several benefits, for example making a program faster at runtime by performing logic at build-time, which projects like GWT excel at.

However, the biggest benefit from my perspective is that code generation excels at producing in-language abstractions (e.g. Java classes) from external primary source artifacts (e.g. some XML, a spec, etc.). Done well, it is a great way to percolate knowledge from source artifacts throughout the rest of your project without manual drudergy.

This is by no means a new idea–the first I’d read of it was in The Pragmatic Programmer, and that is probably just because I’m not old enough to have read about it in anything else.

This percolation becomes extra nice in IDEs like Eclipse/IntelliJ/etc., which see the build-time output of code generation. The IDE’s type-awareness can then guide the programmer while programming code that interacts with the external resources.

Good examples of this are joist making types that the mirror database schema so developers can write type-safe queries:

public Child findByName(String name) {  
  // the ChildAlias class is generated and contains fields (c.name)
  // for each column in the db. If the db changes, the fields change,
  // and this query would no longer compile
  ChildAlias c = new ChildAlias("c");  
  return Select.from(c).where(c.name.equals(name)).unique();  
}

Or Tessell making boilerplate Java classes based on HTML-like XML UI templates:

<ui:UiBinder ...>
  <gwt:HTMLPanel>
    <h2 ui:field="heading">Client</h2>
    <gwt:TextBox ui:field="name"/><br/>
    <gwt:TextBox ui:field="description"/>
    <div><gwt:SubmitButton ui:field="submit" text="Submit"/></div>
  </gwt:HTMLPanel>
</ui:UiBinder>

That is turned into, among other things, an interface for the developer to code against:

public interface IsClientView {
  IsElement heading();
  IsTextBox name();
  IsTextBox description();
  IsSubmitButton submit();
}

Or any of the SOAP/RPC projects like Axis, Thrift, or protobuf creating in-language DTOs for cross-process communications.

In all of these instances, the main goal of code generation is to cater to a static-typing bigot’s preference for a compile-time sanity check, while avoiding the manual grunt work of copy/pasting non-Java-source artifacts (database schemas, XML documents) into their equivalent Java-source form.

Done Well

To get the benefits of code generation without the flaws that led to its reputation, I think good code generation should strive for:

Be active

Whatever a code generator’s source artifact is (XML, a schema, etc.), it is pretty much guaranteed to change during the course of a project. When it does, updating the originally generated output should not be a manual process, which is tedious and error prone. Simply re-running the code generator should be quick, simple, and not overwrite any existing custom code that has been written.

Active code generators can be especially cool when run automatically by IDEs. For example, in Eclipse both Java annotation processors and Spring Roo will run as soon as a programmer hits Save. The updated output is recognized within seconds and any new artifacts/compile-time errors are immediately available to the developer.
Easy to read output

Even though it is generated, developers will inevitably look at the artifacts that code generation produces during the course of programming/debugging/etc. Opening up generated files should not cause their eyes to burn.

Generated output should have good formating, no warnings, and be generally as hand-written as possible. This will gradually reduce the “oh god no generated code” feeling that most developers have picked up.
Easy to read templates

Just like any code that developers write, code generation templates will have to be maintained. They should be easy to read, refactor, and test.
Abstraction in the templates

Part of having easy to read templates is being able to apply abstraction.

The previously cited Torque code snippet suffered from this: the template was a single pass “all decisions must be made inline and linearly”. While I’m normally a huge fan of Velocity, it purposefully works best on simple templates–too much complexity and things can get ugly.
Very little logic in the generated output

In my experience, code generation works best to flush out simple scaffolding. Not Rails-style throw-away/passive scaffolding, but active scaffolding that can be rerun as needed but is simple nonetheless.

The basic getters/setters/collections for an ORM a great example. Anything more complex than, say, a not null check should be left to the programmer to write via a hook. This keeps the code generation logic from getting out of hand and overly complex.

`sourcegen`

Over the last few years, I’ve embodied/stumbled upon these principles while working on a Java code generation library called, imaginatively, sourcegen. It is currently hidden away in the joist-util subproject, but is likely worth promoting to its own project.

The idea behind sourcegen is to break away from Velocity-style templates and apply some abstraction. Such as:

Any program generating Java code is going to have declare classes, fields, and methods. These should be easy to add these without worrying about boilerplate grouping, spacing, indentation, new lines, etc.

For example, implementing an interface with some methods is done via simple, DSL-ish calls:

outputClass.implementsInterface(List.class);

outputClass.addField("foo").type(String.class);
outputClass.addMethod("getFoo").returnType(String.class).body.line("return foo;");

outputClass.addField("bar").type(Integer.class);
outputClass.addMethod("getBar").returnType(Integer.class).body.line("return bar;");

sourcegen will then output the class declaration boilerplate:

import java.util.List;

public class Foo implements List {
  private String foo; // private by default
  private Integer bar;

  public String getFoo() {
    return foo;
  }

  public Integer getBar() {
    return bar;
  }
}

Any program generating Java code is going to have to handle imports. Instead of pessimistically including any possible import a template might need at the start of the file (e.g. single pass, and resulting in a slew of detested “Unused import” warnings), a program should be able to say half-way through the file “btw, I need foo.bar.Zaz imported”.
```
// we've already added methods/fields/etc. to outputClass
// but now we hit a conditional and need Zaz as well
outputClass.addImports(Zaz.class);
```
(sourcegen actually goes further and implements auto-import–if you add a field of type foo.bar.Zaz, sourcegen will change the type to just Zaz in the output if a) you are already in the foo.bar package or b) the Zaz class does not clash with an existing import.)

With this internal DSL in place, code generation can now read like regular programs. For example, this snippet from joist’s getter/setter/collection generation:

public void pass(Codegen codegen) {
  // Entity is a DTO for the domain object information sucked in from the schema
  for (Entity entity : codegen.getEntities().values()) {
      if (entity.isCodeEntity()) {
         continue;
      }

      // domainCodegen is the base class where we put all the
      // getters and setters, e.g. entity Employee will get
      // EmployeeCodegen. Real hand-written code can then go
      // in the Employee class, which extends EmployeeCodegen.
      GClass domainCodegen = codegen.getOutputCodegenDirectory().getClass(entity.getFullCodegenClassName());
      domainCodegen.setAbstract();
      domainCodegen.baseClassName(entity.getParentClassName());

      domainCodegen.getConstructor().setProtected().body.line("this.addExtraRules();");
      domainCodegen.getMethod("addExtraRules").setPrivate();

      this.addQueries(domainCodegen, entity);
      this.primitiveProperties(domainCodegen, entity);
      this.manyToOneProperties(domainCodegen, entity);
      this.oneToManyProperties(domainCodegen, entity);
      this.manyToManyProperties(domainCodegen, entity);
      this.changed(domainCodegen, entity);
      this.clearAssociations(domainCodegen, entity);
    }
}

Now instead of one huge template, code generation can be broken into discrete chunks, e.g. this.manyToOneProperties, and at the end all of the classes/methods/fields can be output at once via a single toCode() call.

When Applicable

Of course, code generation is like any other technique–it is not always applicable and will be painful if misused in a situation where it doesn’t make sense.

But, if you do have an appropriate situation, and can hopefully follow a good approach, code generation can be a powerful approach to building well-designed, easy-to-maintain systems.

Why I Don't Like Mocks

2010-07-09T00:00:00-07:00

Why I Don't Like Mocks

I am not particularly fond of mock objects. This gets me a few raised eye brows, given how wide spread their usage is these days.

The best I can do is link to Fowler’s Mocks Aren’t Stubs which does a great job of explaining state verification (stubs) vs. behavior verification (mocks) and the pros/cons of each. Typical Fowler, he does a great job of articulating what seems obvious in retrospect.

Nonetheless, I’ll reiterate a few things.

State vs. Behavior

For tests, I care more about state than behavior.

If during SomeFooTest, method foo(1, 2) got called or fooBar(3, 4) got called, I don’t think the test should care as long as the desired output/state was reached.

This will result in a test that is less brittle to refactoring, as typically any given test’s input/output conditions won’t change (think of them as requirements, stable, at least while refactoring), but how your program derived the output will.

I read once of an XP project that was extreme about unit tests, but that they’d reached a point where their tests were a burden. Always breaking and requiring lots of effort to refactor. My jumping-to-conclusions, probably-wrong, but I’ll throw it out anyway, hunch is that they had mock tested lots of the small, detailed behavioral interactions between classes. So each time the big picture changed (a new feature was implemented), they had myriads of nit-picky behavioral tests to go fix.

Higher Level of Testing

This leads to another point, that stubs allow you to test at a higher, courser level of detail than mocks.

This pushes your unit tests towards being more like integration tests. Which, as long as speed is not sacrificed, I find preferable because then your unit tests are closer to testing customer-specified input/output conditions, and not just the implementation details of your current class design’s approach.

In Fowler’s words:

“In essence classic xunit tests are not just unit tests, but also mini-integration tests. As a result many people like the fact that client tests may catch errors that the main tests for an object may have missed, particularly probing areas where classes interact. Mockist tests lose that quality. In addition you also run the risk that expectations on mockist tests can be incorrect, resulting in unit tests that run green but mask inherent errors.”

The primary reason stubs facilitate higher-level testing is that mocks, in my opinion, become too complex, verbose, and repetitive to setup and verify scenarios that are not trivial, 1-level of calls.

For example, say you have a IClient, and need to get an IEmployee from that and then a IAccount from that.

This would look something like:

IClient client = mock(IClient.class);
IEmployee ee = mock(IEmployee.class);
IAccount a = mock(IAccount.class);
when(client.getEmployee(1)).thenReturn(ee);
when(ee.getAccount(2)).thenReturn(a);

Contrast this with a stub (+ builder) approach of:

StubRepo repo = new StubRepo();
repo.addClientWithEmployeeAndAccount(1, 2);

Granted, domain objects are not usually a target for mocking (usually), but this is first example of an n-layer object graph that came to mind. Eh, I should come up with a better example.

Anyway, at first, it may seem like the mock is preferable. It is simpler, especially to get started, as it is just a few inline mock/when calls. Contrast this with the StubRepo which is a separate class and needs a separate addClientWithEmployeeAndAccount builder method. The stub requires some infrastructure.

However, the key is scale–as a project grows, the stub can be reused over and over in many different tests. The investment in building a stub pays off as soon as 5, 10, 100 tests are using it.

In contrast, the mock/when/etc. methods typically are not abstracted out and, in my experience, end up being repeated in each test.

This is just my opinion, of course–Fowler’s article points out I’m like showing my classicist bias:

“As a result I’ve heard both styles accuse the other of being too much work. Mockists say that creating the fixtures is a lot of effort, but classicists say that this is reused but you have to create mocks with every test.”

Dummy Behavior Scales

Stubs also scale better than mocks because they can contain dummy/default behavior that mocks otherwise to have to repeat in each test.

For example, take an HttpServletRequest and wanting to mock out the getAttribute/setAttribute methods.

With a mock, each time any business logic wants to use attributes, your test is going to have to contain setup code for each attribute involved in the test:

HttpServletRequest req = mock(HttpServletRequest.class);
when(req.getAttribute("foo")).thenReturn("bar");
doBusinessLogic(req);

And, if you have verify an attribute is being set via setAttribute, something like:

ArgumentCapture<String> key = ArgumentCapture.forClass(String.class);
ArgumentCapture<Object> value = ArgumentCapture.forClass(Object.class);
verify(req).setAttribute(key.capture(), value.capture());
assertThat(key.getValue(), is("foo"));
assertThat(value.getValue(), is("bar2"));

With a stub, you can have one class StubRequest which uses a map to implement simple getAttribute/setAttribute methods. Now all of your tests can use it:

StubRequest req = new StubRequest();
req.put("foo", "bar");
doBusinessLogic(req);
assertThat(req.get("foo"), is("bar2"));

Besides just the "foo" attribute, if the business logic under test was setting its own attributes that it later wanted to retrieve, the stub’s dummy map implementation scales even better as our test is encapsulated from those implementation details.

Spring even realized this, as they intelligently include for testing a MockHttpServletRequest that is actually a stub, though I can understand if they named it before the terminology of mocks/stubs/doubles had been settled.

Too Many Interfaces

Mocking encourages testing behavioral interfaces between classes, e.g. role interfaces.

However, I personally prefer to use real objects in tests as long as possible, and only create interfaces as a last resort when doubling is required. Otherwise I think you end up with the anti-pattern of interfaces that have only 1 implementation.

To me, these 1-implementation interfaces just clutter a code base and make life more tedious for the developer as they copy/paste the same method definitions, etc., between the two. (See interfacegen for my begrudging hack to help with these scenarios).

Fowler asserts that mockists actually like these extra interfaces:

“Mockists favor role interfaces and assert that using this style of testing encourages more role interfaces, since each collaboration is mocked separately and is thus more likely to be turned into a role interface.”

Which, in my current style, I just don’t see the benefit of.

Lately I don’t any more consulting-related project-hopping, so perhaps my data points are few/stale, but two of the worst “wtf were the architects thinking” systems I’ve seen involved 1-implementation/role interfaces. So until I see a convincing example otherwise, I consider them a bad thing.

Conclusion

So, that’s my take. I’ve changed my style before, so we’ll see if I end up being a mockist a few years from now. But for now I’m a classicist.

(Nothing like some good labels to throw around.)

GWT Seamless Deployments

2010-07-07T00:00:00-07:00

GWT Seamless Deployments

I’m deploying a GWT app on Amazon’s EC2 architecture behind an ELB and wanted to ensure the best experience for users while pushing out new code updates.

This is a short review of my most-likely-accurate findings. It is not well organized and basically a public mind dump vs. a private mind dump to my other team members.

RPC Key Points

I’m not going to review GWT RPC in detail, but the basic points for us are:

GWT automatically serializes Java objects to/from JavaScript objects
GWT on the server-side will serialize/deserialize:
1. Anything that implements GWT’s IsSerializable marker interface
2. Anything that implements Java’s Serializable and is in a serialization policy file (see this faq entry for more details)
GWT on the client-side will serialize/deserialize any type it knew about at compile-time

A Typical RPC Request

Here’s what a typical RPC request might look like:

POST https://app.com/gwtapp/dispatch
Content-Type: text/x-gwt-rpc; charset=UTF-8
Origin: https://app.com
Referer: https://app.com/gwtapp/361924868514EB67231B0C48DC4B136A.cache.html
X-GWT-Module-Base: https://app.com/gwtapp/
X-GWT-Permutation: 361924868514EB67231B0C48DC4B136A

<serialized-objects-here>

The interesting thing to notice is the X-GWT-Permutation header–this is the strong name (hash) of the browser/locale/etc. code base the client is currently running.

Case 1: Old Client, New Server

When an old client sends an RPC request to a new server, we would ideally like to fulfill it as long as we haven’t changed the contract of the RPC service it’s interacting with.

GWT’s deserialization execution flow for an old request is something like:

Read in the X-GWT-Permutation header
Try to load the serialization policy file based on the permutation header–however, this will fail because this is a new server that does not have the old serialization policy file
Fall back on LegacySerializationPolicy where only IsSerializable can be deserialized

For this reason, it’s important to still use the old IsSerializable marker interface even though GWT now supports Java’s Serializable.

Also, type name elision cannot be used because it also relies on the serialization policy file.

Then, assuming the RPC contract is the same, everything should still work.

If the RPC contract does change, i.e. the old client tries to use changed/removed functionality, they will get an IncompatibleRemoteServiceException which the GWT client-side code should handle and prompt the user to reload the application.

One additional wrinkle is code split points. If an old client tries to load part of the application it does not have yet, it will use the old code base name, which is no longer on the new server. The client-side GWT.runAsync will fail with a 404 and the application should prompt the user to reload. (See AsyncSplit for how gerrit handles this.)

Case 2: New Client, Old Server

The same scenario above can happen here, when the client has a newer serialization policy strong name than the old server, so the old server falls back to the LegacySerializationPolicy.

However, an added wrinkle is the application bootstrapping process.

A client might:

Request /app.html and get served by either a new or old server (fine so far)
Request /app/module.nocache.js and get served by a new server–this is the GWT bootstrapping code and, based on the user’s browser/locale/etc. combination, it tells the browser to load new-permutation-name.cache.html
Request /app/new-permuation-name.cache.html, however, this request gets served by an old server that only has the old application files
Client gets a 404 and the application bootstrapping stops

I currently know of no way to recover from this scenario. Because the error happens in between the GWT bootstrapping code and your application code, there is not a way for your application code to detect what has happened and recover.

Update: Thanks for Sripathi Krishnan for pointing out the gwt:onLoadErrorFn function where you can prompt the user to reload their browser to recover from this scenario.

For this reason, it’s very important to have a clean switch from old to new versions–no old servers should be serving requests once new servers have come online.

Summarizing

Based on my current understanding, to service both old and new clients during a GWT upgrade as elegantly as possible, you should:

Use IsSerializable and no type name elision in the RPC DTOs
Handle IncompatibleRemoteServiceException in the RPC AsyncCallbacks
Handle 404’s in the runAsync onFailures
Minimize/eliminate the window when both old and new servers are available

Any corrections, feedback, etc., is appreciated.

gwt-mpv-apt 1.1

2010-06-28T00:00:00-07:00

gwt-mpv-apt 1.1

Update 2011/12/29: This post was originally about the gwt-mpv-apt project, which has since been merged into/rechristened Tessell, see tessell.org.

gwt-mpv-apt is a annotation processor (natively supported by Eclipse and javac) that generates gwt-dispatch and GwtEvents for GWT projects.

The benefit is a 10x decrease in boilerplate code, which is something every GWT project needs.

The github page is pretty self-explanatory, but the basic idea is that gwt-mpv-apt can generate both your Action and Result command-pattern DTOs and then also your GWT event DTOs from “spec” classes that contain only the minimal amount of information needed to derive the resulting DTOs.

Manually Creating Action/Result DTOs

Let’s start out without gwt-mpv-apt and see how things typically work.

For example, if you were writing a gwt-dispatch Action/Result by hand for creating a new User, you’d have to:

Make a NewUserAction class
Have it implement the Action<NewUserResult> interface
Add a field/getter/setter for String username
Add a protected NewUserAction constructor for serialization
Add a public constructor for NewUserAction(String username) for real usage
Add a default serialVersionUID to avoid the Eclipse warning (assuming the warning is enabled)
Make a NewUserResult class
Have it implement the Result interface
Add a field/getter/setter for boolean success, and Integer newUserId
Add a protected NewUserResult constructor for serialization
Add a public constructor for NewUserResult(boolean success, Integer newUserId) for real usage
Add a default serialVersionUID to avoid the Eclipse warning (assuming the warning is enabled)
If you want caching add hashCode/equals to NewUserAction
If you want nice debugging add toString to NewUserAction
If you want nice debugging add toString to NewUserResult

In the end, you’ll end up with something like:

public class NewUserAction implements Action<NewUserResult> {
  private static final long serialVersionUID = 1L;
  private String username;

  public NewUserAction(String username) {
    this.username = username;
  }

  protected NewUserAction() {
  }

  public String getUsername() {
    return this.username;
  }

  @Override
  public int hashCode() {
      int hashCode = 23;
      hashCode = (hashCode * 37) + getClass().hashCode();
      hashCode = (hashCode * 37) + (username == null ? 1 : username.hashCode());
      return hashCode;
  }

  @Override
  public boolean equals(Object other) {
      if (other != null && other.getClass().equals(this.getClass())) {
          NewUserAction o = (NewUserAction) other;
          return (o.username == null && this.username == null)
                 || (o.username != null && o.username.equals(this.username));
      }
      return false;
  }

  @Override
  public String toString() {
      return "NewUserAction[" + username + "]";
  }
}

public class NewUserResult implements Result {
  private static final long serialVersionUID = 1L;
  private boolean success;
  private Integer newUserId;

  public NewUserResult(boolean success, Integer newUserId) {
    this.success = success;
    this.newUserId = newUserId;
  }

  protected NewUserResult() {
  }

  public boolean getSuccess() {
    return this.success;
  }

  public Integer getNewUserId() {
    return this.newUserId;
  }


  @Override
  public String toString() {
      return "NewUserResult[" + success + "," + newUserId + "]";
  }
}

So, roughly 15 steps leading to 60 LOC.

Which isn’t necessarily a big deal, until you have to repeat it for every Action/Result pair in your project.

Generating Action/Result DTOs

So, let’s try this again. If we think about it, what are we really trying to do?

We have 1 operation: creating a new user. We know it should take 1 input parameter (username) and return two output parameters (success and newUserId).

With gwt-mpv-apt, we can specify this directly by:

Make a new NewUserSpec class
Add a String in1username field (in1 == first input parameter)
Add a boolean out1success field (out1 == first output parameter)
Add a Integer out2newUserId field (out2 == second output parameter)
Add a GenDispatch annotation

So, it while look like:

@GenDispatch
public class NewUserSpec {
  String in1username;
  boolean out1success;
  Integer out2newUserId;
}

And that’s it.

gwt-mpv-apt will step in (if you’re in Eclipse as soon as you hit Save), and generate the NewUserAction and NewUserResult classes that look exactly like the ~60 lines of boilerplate above from this 6 lines of spec.

That’s an order of magnitude decrease in LOC (60 -> 6) and a 3x decrease in manual steps (15 -> 5).

Adding Up The Savings

Saving ~50 LOC for one example is good. But, even better, this savings is applied to every command Action/Result in your project.

I’m currently writing what I consider a small project, and it has 20 command patterns. So, 50 LOC x 20 commands = 1,000 LOC I didn’t have to write.

So, pretty quickly, we’re talking about real LOC that gwt-mpv-apt should save you.

Events Too

I’ll do another post sometime with the details of gwt-mpv-apt’s GWT event support, but for now I’ll leave you with a short of example:

@GenEvent
public class FooChangedEventSpec {
  Foo p1foo;
}

That will generate a FooChangedEvent, FooChangedHandler, and all sorts of other boilerplate that, if you’ve written GWT events before, you’ll know is a PITA to type out each time.

Getting `gwt-mpv-apt`

The github page is the best place to go.

GWT View Generation

2010-04-07T00:00:00-07:00

GWT View Generation

This will be brief, but lately I’ve been on a crusade to reduce the boilerplate in GWT MVP projects.

My current target has been the trio of FooView.ui.xml, FooPresenter.Display, and FooView, all of which are intrinsically linked. You end up making changes in one (usually FooView.ui.xml) and then dutifully percolating those changes to the other two.

Or other three, as in my case I throw in a StubFooView for testing (I find, after two or three uses, mocks get old and stubs are more pragmatic).

So, I did a short spike for the last two mornings and am becoming convinced I can generate everything from the single FooView.ui.xml file.

The steps are basically:

Scan FooView.ui.xml for ui:field declarations, record their type+name
For each ui:field, come up with its HasXxx (or really IsXxx, see later)
Create IFooView with a method HasXxx for each ui:field
Create FooView with a @UiField-annotated field + method for each ui:field
Create StubFooView with the stub version of each ui:field

I have this all basically working. It means for each presenter/view in your project, instead of 4+ hand-written files (presenter, ui.xml, interface, view, stub), you have just 2 (presenter, ui.xml).

For me, this would make GWT MVP drastically less painful.

`HasXxx` vs. `IsXxx`

Mapping a ui:field to a single HasXxx interface is problematic because each widget has multiple HasXxx interfaces. For example, Anchor has HasClickHandlers, HasAllFocusHandlers, HasName, HasHTML, etc.

If you put a gwt:Anchor in your ui.xml, which HasXxx should we expose to the presenter? What if the presenter needs more than one?

My answer is to introduce a new interface, IsAnchor, that extends all of these interfaces and, by returning just the one IsAnchor type, your presenter has access to all of its constituent HasClickHandlers/etc. methods.

To me this makes a lot of sense anyway, as I was always annoyed with having to return the same Anchor field multiple times in my view implementation, once for each HasXxx interface I needed for it.

The Problem

Turns out Anchor doesn’t actually implement IsAnchor. Of course, given IsAnchor is our own interface.

So, we have several options:

Composition: make a new class GwtAnchor implements IsAnchor, with a constructor GwtAnchor(Anchor anchor), then you implement a whole bunch of delegate methods in GwtAnchor that just call anchor.xxx.
Inheritance: make a new class GwtAnchor extends Anchor implements IsAnchor and your mostly done, though now your ui.xml file will have to have a foo:GwtAnchor declaration instead of the regular gwt:Anchor.
Forking: Add IsAnchor to the GWT code base and just make the real Anchor implement IsAnchor. Done.

I started out with composition only because I’ve only done a few minor widgets. But it involves a whole lot of boilerplate. Inheritance is probably what I should try next. But forking is awfully tempting because it, for the most part, just makes the problem go away.

Of course, even with forking, I’ll still have to implement a StubIsAnchor for testing. Hopefully that won’t be too bad. It is definitely an up-front investment, but I’m convinced the stub will pay off over the long term vs. mocking.

My ViewGenerator spike is currently 200 lines. Pretty simple really, it will not get much larger. The hard part is surgically inserting the IsXxx interfaces into the multitude of GWT widgets. Which is not so much hard, but potentially very time consuming to get full coverage of all of the widget.

GWT MVP Tables

2010-03-31T00:00:00-07:00

GWT MVP Tables

Update 2011/12/29: This post was originally about the gwt-mpv framework, which has since been rechristened Tessell, see tessell.org.

Update 2010/11/30: I’ve added docs for these two approaches to GWT MVP tables: row tables and cell tables in Tessell. (Tessell is a framework to reduce the MVP boilerplate I talked about in this post.)

I’m building a GWT application and, per the latest best practices, using a MVP (model view presenter) approach.

For awhile I was confused about how to build non-trivial views. For example, a dashboard-type table where each row is not just strings of text but an interactive unit.

Last week I finally found an approach that I like: per-row presenters. The trick with complex views seems to be searching for a sweet spot in the decomposition of your presenter/view pairs that is:

fine-grained enough to facilitate easy implementation and testing, but
not so fine-grained that it buries you in MVP/DI boilerplate.

I’ll add the disclaimer that if there is anything GWT is not, it is not succinct. Boilerplate seems to be the norm for GWT, and especially the MVP approach. I think the assertion is that, for large AJAX applications/codebases, you should be willing to accept some boilerplate as a tradeoff for gaining compile-time checking of type-safety and mockable views for extremely fast/non-browser-based test suites.

MVP Review

So, just to be on the same page, GWT MVP exists primarily to divorce your AJAX application’s business logic from the GWT UI widgets. This is imperative because, unfortunately, the widget are all concrete classes that rely on browser-provided behavior and will not run in a pure-Java unit test.

Since GWT itself does not put interfaces between your code and the browser, GWT MVP is how you by convention put interfaces between your code and the browser. With these interfaces in place, you can mock/stub them out and test your logic in a fast, browser-less unit test.

To show an example, a regular form that would edit a Foo object in GWT MVP is usually a FooPresenter/FooView pair that looks something like:

public class FooPresenter extends BasicPresenter<Display> {
  // inner-interface defines the UI contract
  // our FooPresenter modifies
  public interface Display {
    // these HasXxx are all interfaces
    HasValue nameField();
    HasValue descriptionField();
    HasClickHandlers saveButton();
  }

  private final Foo foo;

  public FooPresenter(Display display, Foo foo) {
    // display is an implementation of our view, either
    // provided by the real view that uses GWT widgets
    // (typically named FooView) or a mock/stub
    super(display);
    this.foo = foo;
  }

  // Called when the page/tab for our foo loads
  public void onBind() {
    // hook up business logic to the display's
    // HasXxx interfaces
    display.nameField().setText(foo.getName());
    display.nameField().addValueChangeHandler(new OnNameChanged());
    display.descriptionField().setText(foo.getDescription());
    display.descriptionField().addValueChangeHandler(new OnDescriptionChanged());
  }

  private class OnNameChanged implements ValueChangedHandler<String> {
    public void onChange(String newValue) {
      foo.setName(newValue);
    }
  }

  private class OnDescriptionChanged implements ValueChangedHandler<String> {
    // etc.
  }
}

public class FooView implements FooPresenter.Display {
  // uibinder code...
  @UiField
  TextBox nameField;

  public nameField() {
    return nameField;
  }
}

The idea is that the Display interface is easily mockable, so you can write a FooPresenterTest that creates a mock Display, with mock HasValue/etc., and test all of your FooPresenter business logic without actually using any GWT widgets that would require running in a browser environment (like GWTTestCase).

So, that was the review, on to tables.

GWT Tables

To me, it was not immediately obvious how to implement tables in GWT MVP. There is no HasTable interface that holds your hand like HasText/HasValue.

GWT tables are also complicated by the fact that UiBinder only does static templating–unlike nearly every other HTML rendering library out there, it lacks any notion of iteration or for loops or even if statements. You cannot just #for($row in $rows) <tr>row HTML goes here</tr> like you would in Velocity/JSP/etc.

Table Models

Instead, the usual MVP approach is to use a TableModel. The presenter gathers the domain objects (or creates an interface that can load domain objects on demand) and puts them into a TableModel instance. It then pushes the model into the view, which iterates over the model and creates widgets as needed.

One of the GWT examples uses a List<String[]> as a very naive TableModel, but it works well to show the basic idea:

// displays a parent and its list of Foo children
public class ParentPresenter extends BasicPresenter<Display> {
  public interface Display {
    void setData(List<String[]> model);
  }

  private final Parent parent; // set by constructor

  // Called when the page/tab for our parent loads
  public void onBind() {
    List<String[]> model = new ArrayList<String[]>();
    for (Foo foo : parent.getFoos()) {
      model.add(newLine(foo));
    }
    display.setData(model);
  }

  // translate Foo domain object into strings for each cell
  private String[] newLine(Foo foo) {
    return new String[] { foo.getName(), foo.getDescription() };
  }
}

public class ParentView implements ParentPresenter.Display {
  // uibinder code...
  @UiField
  HTMLTable table;
  public void setData(List<String[]> model) {
    table.resizeRows(model.size());
    int i = 0;
    for (String[] row : model) {
      table.setText(i, 0, row[0]);
      table.setText(i, 1, row[1]);
      i++;
    }
  }
}

The GWT incubator has a much more powerful, elaborate TableModel for their PagingScrollTable that is worth checking out if this approach works for you.

But, the basic idea here is that we’re shoving data into the view and pretty much stopping there.

Where Table Models Work

I think it works very well if your presenter can pre-format everything into basic Strings, which makes the view logic very dumb.

The GWT incubator TableModel certainly looks very nice if your auto-loading-on-scroll 100s/1000s of rows. They have a CachedTableModel wrapper that will ensure you only fetch rows from the server that you really need. Pretty neat.

However, I do start to get a little hesitant when the view interface starts looking more like setData(List<Foo> model) (or TableModel<Foo>) and the view starts interrogating domain objects directly, as this is more complex logic that won’t be under unit tests. But it’s not that big of a deal.

Where Table Models Don’t Work

The main problem I see with TableModels is that there is not an obvious way for the presenter that calls display.setData(model) to get back out HasXxx interfaces for each of the widgets the view creates.

For example, for a “dashboard”-style table, each row doesn’t have just read-only data, but interactive features where a user can start/stop/pause each row’s domain object, which then causes various row-specific style/images changes that are best performed and tested against HasXxx interfaces.

I looked at Hupa and others, but did not find anyone using a TableModel and then pushing per-row/per-cell HasXxx interfaces back into a presenter. Perhaps I just missed it, in which case please correct me.

There is an idiom where you can attach a listener to the entire table, and then ask the view to derive which element it is for:

public class ParentPresenter extends BasicPresenter<Display> {
  public interface Display {
    // fired for any click anywhere in the table
    HasClickHandlers tableClicked();
    // translate event -> int
    int getRowForClick(ClickEvent event);
    // then any changing row method requires an int
    changeStyle(int row, String otherParams);
  }

  public void onBind() {
    display.tableClicked().addClickHandler(new OnTableClick());
  }

  private class OnTableClick implements ClickHandler {
    public void onClick(ClickEvent event) {
      int row = display.getRowForClick(event);
      if (row != -1) {
        // perform action against row
        display.changeStyle(row, "foo");
      }
    }
  }
}

However this seems less than ideal to me. The view becomes more complicated, and the presenter no longer has concrete HasXxx interfaces that are easy to wire up and stub out. There is also no clear place to store per-cell/per-row state, except perhaps in maps or other fields in the parent presenter.

First Attempt: Per-Cell Presenters

My initial thoughts were that I wanted each cell to have its own presenter instance. This seems awfully intuitive, as the presenter would have its own view with the HasXxx interfaces for its cell.

It also fits very nicely with the GWT HTMLTable API, which is all about cells (e.g. the method setWidget(int row, int column, Widget widget) and friends).

This approach would look something like:

public class ParentPresenter extends BasicPresenter<Display> {
  public interface Display {
    void setCell(int row, int column, WidgetDisplay display);
  }

  public void onBind() {
    int i = 0;
    for (Foo foo : parent.getFoos()) {
      display.setCell(i, 0, new CellOnePresenter(foo).getDisplay());
      display.setCell(i, 1, new CellTwoPresenter(foo).getDisplay());
      i++;
    }
  }
}

public class ParentView implements ParentPresenter.Display {
  // uibinder code...
  @UiField
  HTMLTable fooTable;
  public void setCell(int row, int column, WidgetDisplay display) {
    fooTable.setWidget(row, column, display.asWidget());
  }
}

Just looking at this example, it doesn’t seem that bad. I thought it’d work out nicely.

However, several folks on the gwt-presenter mailing list warned me against going this route. And turns out they were exactly right.

The overhead of having a separate presenter-view pair for every table column was just too much boilerplate. After CellOnePresenter, CellOneView, CellOneView.ui.xml, CellTwoPresenter, and CellTwoView, I just couldn’t bring myself to implement the rest of the columns.

Second Attempt: Per-Row Presenters

After much complaining, I finally realized that the combination of HTMLTable’s per-cell API and my assumption that “this is a table because there is a <table> tag” was leading me astray.

A dashboard-style table is not really a table–it’s a vertical listing of per-row views. That the HTML code uses <table> tags is purely an implementation detail.

A per-row presenter, with its parent presenter as well, would look like:

public interace HasRows {
  void addRow(WidgetDisplay display);
}

// this is the parent presenter which
// has the dashboard on its page
public class ParentPresenter extends BasicPresenter<Display> {
  public interface Display {
    HasRows dashboard();
  }
  public void onBind() {
    for (Foo foo : parent.getFoos()) {
      FooRowPresenter p = new FooRowPresenter(foo);
      display.dashboard().addRow(p.getDisplay());
    }
  }
}

// this is the per-row presenter that will be instantiated once-per-Foo
// and have its view added to the parent's dashboard table
public class FooRowPresenter extends BasicPresenter<Display> {
  // here are the per-row HasXxx interfaces
  public interface Display {
    HasCss columnCss();
    HasText nameCellText();
    HasText descriptionCellText();
    HasClickHandlers actionFooLink();
  }
  private final Foo foo; // set by constructor
  public void onBind() {
    // finally here is our per-row business logic
    display.nameCellText().setText(foo.getName());
    display.descriptionCellText().setText(foo.getDescription());
    display.actionFooLink().addClickHandler(new OnActionClick());
  }
  private class OnActionClick implements ClickHandler {
    public void onClick(ClickEvent click) {
      // hit server, etc.
      display.columnCss().addStyleName("nowRed");
    }
  }
}

As far as how each row’s concrete view class is implemented, I did some hacking so that the entire row has its own UiBinder file. E.g. FooRowView.ui.xml might look like:

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder' xmlns:gwt='urn:import:com.google.gwt.user.client.ui'>
  <gwt:HTMLPanel tag="table">
    <tr ui:field="column">
      <td ui:field="nameCell" />
      <td ui:field="descriptionCell" />
      <td><gwt:Anchor ui:field="actionFoo"/></td>
    </tr>
  </gwt:HTMLPanel>
</ui:UiBinder>

This ui.xml file initially looks a little odd because each row has its own <table> tag–however, this is just a necessary hack because HTMLPanel does not like its tag attribute to be set to tr. I guess when browsers do innerHTML, they don’t like a tr running around without its parent table.

So, to get around this, plus HTMLTable’s lack of a per-row API, I wrote a RowTable widget that knows how to assemble rows (not cells) of content:

public class RowTable extends Panel implements HasRows {
  // copy/paste some boilerplate from HTMLTable

  // here is the key method--display is the HTMLPanel
  // with tag=table from FooRowView.ui.xml
  public void addRow(final WidgetDisplay display) {
    // get actual widget from the view interface
    Widget widget = display.asWidget();
    // Detaches if necessary
    widget.removeFromParent();
    // Logical attach
    rows.add(widget);
    // Physical attach (all TRs)
    final NodeList<Element> nodes = widget.getElement().getElementsByTagName("TR");
    for (int i = 0; i < nodes.getLength(); i++) {
      bodyElement.appendChild(nodes.getItem(i));
    }
    // Adopt
    adopt(widget);
  }

So, we logically attach the entire HTMLPanel widget (to get the usual Widget/attach magic), but for physically attaching we raid the HTMLPanel’s table element of all of its TR elements (which should be just one given this display is for one row) and append them to our own bodyElement.

Any Downsides?

So far, the only downside to per-row presenters is that it’ll require another presenter/view pair, each with its own class, DI entry, etc. This can be considered boilerplate, but, per my disclaimer, that is pretty much the name of the game for GWT.

I’m also implementing the table’s header row as its own presenter/view pair, meaning for one dashboard table I’ll have 4 classes: FooHeaderPresenter, FooHeaderView, FooRowPresenter, and FooRowView. I would not mind avoiding the extra header presenter/view, but so far it has been the simplest to get working with the RowTable (HasRows actually has two methods, addRow and addHeader for adding to tbody and thead respectively).

And, just to be clear, I’m not advocating per-row presenters for any and every table in a GWT app. E.g. I would stick with TabelModel and TableBulkRenderer for more typical “data” tables–hundreds/thousands of rows that are read-only (or near-read-only).

Wrapping Up

That’s about it. I’ve been very pleased with how things are going with this approach so far.

By stepping back and realizing the row was really its own view–finding the presenter/view decomposition sweet spot–I’m now able to unit test the in-row interactions on their own without even setting them up in the parent table.

The per-row display interfaces, so far, have been awfully simple and just as easy to stub out as the usual form-style name/description examples that make MVP look easy.

Lift Templating is a Joke

2010-03-10T00:00:00-08:00

Lift Templating is a Joke

I want to like Lift. I like Scala and Lift seems like the goto Scala web framework for now.

I have several nitpicks with it, the one I’ll rant about now is its templating syntax.

Disclaimer: I know “joke” is a harsh word–but given the combination of the author’s superior attitude towards other frameworks plus his own solution missing the very goals he sets forth, I felt compelled to respond in kind.

Lift’s Lofty Goal

First, let’s start with the author waxing poetic about his design goals in Lift’s Getting Started.

My first design goal with Lift was to make sure that no programming logic and no programming symbols make it into the static display templates.

ERB and JSP and ASP all have the fatal flaw of allowing code in the view. This is bad for a bunch of reasons. First, it makes editing the templates difficult with HTML layout tools unless those tools are familiar with the syntax being used. Second, there are “foreign” symbols in the layout, which tends to be less than optimal for the HTML designers.

So, the static templates in Lift are strictly for display only. They can be manipulated with standard design tools (e.g., Dreamweaver). They can never contain program logic.

So, cool, I can agree with that. Good goals.

Falling Short

But then you see the implementation:

<html> 
... 
<lift:Show.myForm form="POST"> 
<tr> 
  <td>Name</td> 
  <td><f:name><input type="text"/></f:name></td> 
</tr> 
<tr> 
  <td>Birthyear</td> 
  <td><f:year> 
      <select><option>2007</option></select> 
  </f:year></td> 
</tr> 
<tr> 
  <td>&nbsp;</td> 
  <td><input type="submit" value="Add"/></td> 
</tr> 
</lift:Show.myForm> 
</html>

And…what? What happened to no separation? Designer friendly? Is Dreamweaver really going to like that <tr> tag coming after a <left:Show.myForm> tag instead of a <table> tag?

I don’t see how this achieves the design goal of “no programming logic”. I consider the <lift:xxx> tags to be programming symbols just as much as curly braces.

Yeah, okay, they are tags, but they are not native HTML tags that any designer/web design tool will have seen before. They are programming symbols.

I wouldn’t care about the <lift:xxx> syntax that much–other projects take this approach as well, e.g. GWT off the top of my head.

But since Lift goes out of its way to assert, repeatedly, how designer friendly it is, when it’s not, just annoys me.

Pure Rocks

The Lift crowd needs to look at pure instead.

If you look at the demos, one of pure’s table examples is:

<table class="playerList">
  <thead>
    <tr><th>Player</th></tr>
  </thead>
  <tbody>
    <tr class="player">
     <td>Chloe</td>
   </tr>
  </tbody>
</table>

Now this is designer friendly. There really are no programming symbols in this.

Now, admittedly, pure requires a few hoops for the programmer to jump through, e.g. this directive:

{
  "tbody tr": {
    "player<-players": {
      "td": "player",
      "td@style": "\"cursor:pointer\"",
      "td@onclick": "\"clickLine(this);\""
    }
  }
}

And this could probably be cleaned up.

Even if the templating was driven entirely off of HTML id attributes, I think you’d have a usable solution.

I admit I haven’t fully thought it through, but I’m optimistic.

Code Generation

While I’m on the topic of templating, I like how GWT parses its templates at compile-time and ensures they type-safely match your usage of the templates.

What I don’t get is why this has to happen during the already-time-consuming GWT startup phase.

Even a project like Lift could build a code generator that, after parsing your templates at build-time, creates an XxxTemplate.scala class with type-safe elements for you to program against.

For example, take something like foo.html:

<table id="playerList">
  ...
</table>

And after running lift generate-templates on the command line (ideally ran automatically each time your HTML files change), Lift would spit out a class:

object FooHtml {
  val playerList = new TableElement("playerList")
  // other elements/etc.
}

This output may get somewhat ugly, but its basically going to be the same code Lift is interpreting at runtime (or, in the case of joys like Tapestry, are bytecode compiling at runtime).

All of Lift’s bind calls could then be made again, you know, actual objects instead of the String keys.

Magic Strings

Which again is ironic given how Lift just ragged on HttpSession, again from their Getting Started:

Lift has a type-safe mechanism for storing variables during the scope of a given session.

In Java, you would do something like casting a value retrieved from the HttpSession. For example: String myString = (String) httpSession.getAttribute(“Something”); The problem with this code is that a developer may not remember that Something is support to be a String and put a String[] in it. Additionally, there’s no well defined logic for creating a default value for the attribute.

Well, good for you, Lift, you avoid magic Strings in session usage–but then go right back to magic Strings all over your templating layer.

private def doList(reDraw: () => JsCmd)(html: NodeSeq): NodeSeq = 
  toShow.flatMap(td => 
    bind("todo", html, 
      "check" -> ajaxCheckbox(
              td.done, 
              v => {td.done(v).save; reDraw()}), 
      "priority" -> ajaxSelect(
              ToDo.priorityList, Full(td.priority.toString), 
              v => {td.priority(v.toInt).save; reDraw()}), 
      "desc" -> desc(td, reDraw) 
  ))

See "todo", "check", "priority", etc.–all untyped, magic strings.

And, again, I wouldn’t care so much had they just not touted their SessionVar, and, also making the wording such that “oh, you’d do this crappy approach in Java”, when, no, Java can have a SessionVar abstraction just as well as Scala/Lift can.

I don’t mention this because I have a chip on my shoulder about Scala. I actually really like Scala. But I do have a chip on my shoulder about the last 10 years of people bitching about how crappy Java is when really the problem with Java is not some inherent flaw but instead the self-inflicted complexity J2EE devs love foisting on their projects.

Anyway, build-time code generation really isn’t that bad. It just needs to be easy to run (automatic if possible), fast, and not produce crap code.

I’d love to see Lift, or some other Java/Scala project, pick up this approach and run with it.

Moving an existing git repo into svn

2010-03-05T00:00:00-08:00

Moving an existing git repo into svn

I’ve found myself lately making local git repositories to prototype things that I later need to promote into Bizo’s internal Subversion repository.

git-svn supports this really well, with just a slight variation on the usual git svn clone.

Instead of the standard project/trunk|branches|tags we use a slightly different parent/trunk|branches|tags/project so you’ll see I specify the -T/-t/-b flags.

git svn init

Here is what I do, from the existing local git repo:

# Create the project directory in subversion
$ /usr/bin/svn mkdir https://foo.com/svn/parent/trunk/project -m "Make project directory."
Committed revision 200.

# Initialize git-svn, doesn't fetch anything yet
$ git svn init https://foo.com/svn/ -T parent/trunk/project -t parent/tags/project -b parent/branches/project --prefix=svn/

# Set authors so we get prettier authors
$ git config svn.authorsfile ../authors

# Now pull down the svn commits
$ git svn fetch
W: Ignoring error from SVN, path probably does not exist: Filesystem has no item: File not found: revision 100, path '/parent'
W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
This may take a while on large repositories
r200 = (guid) (refs/remotes/svn/trunk)

# We should now see our svn trunk setup under our svn remote
$ git branch -av
* master            c3a7161 The latest git commit.
  remotes/svn/trunk 3b7fed6 Make project directory.

# Now we want to take all of our local commits and rebase them on top of the new svn/trunk
$ git rebase svn/trunk
First, rewinding head to replay your work on top of it...
Applying: First git commit
Applying: The latest git commit

# Now we should see our local commits applied on top of svn/trunk
$ git lg
* 52b7977 (HEAD, master) The latest git commit
* a34e162 First git commit
* 3b7fed6 (svn/trunk) Make project directory.

# Everything is cool, push it back to svn
$ git svn dcommit
Committing to https://foo.com/svn/parent/trunk/project
...

–prefix=svn

One flag I especially like lately, which you can also use with git svn clone, is --prefix=svn/.

This will prefix all of your tracking branches of the remote Subversion branches, tags, and trunk with svn/, making it look a whole lot like the usual origin/ idiom used by regular git remotes.

With the tracking branches having a prefix, you can also use them as local branch names, e.g.:

# Name your copy of svn/trunk "trunk" instead of "master"
$ git checkout -b trunk master
Switched to a new branch 'trunk'

$ git branch -d master
Deleted branch master (was 33c3136).

$ git branch -av
* trunk             33c3136 Latest svn commit
* remotes/svn/trunk 33c3136 Latest svn commit

Then if you have other branches you want to track:

$ git checkout -b featurea svn/featurea

Almost Really Sweet

Overly, I’ve been very pleased with git-svn over the last few years I’ve been using it.

My one regret is that git-svn will not push merges back to svn, so I have to break down and use the svn command line client to do that.

Surprisingly, Bazaar actually writes back svn:mergeinfo, which I’m very jealous of. Assuming it works well, it’s pretty nifty.

git config

2010-03-04T00:00:00-08:00

git config

I’ve got an enjoyable git environment set up, with various .gitconfig/etc. hacks. This is just a post to document those for my future self and others.

First, you should start with git-sh. It adds some bash shell customizations like a nice PS1 prompt, tab completion, and incredibly short git-specific aliases. I’ll cover some of the aliases later, but this is the thing that started me down the “how cool can I get my git environment” path.

I’ve included commented versions of my .gitconfig and .gitshrc, but you can get the raw versions here and here.

Example Shell Session

A lot of my customizations are around aliases, so this is a quick overview, and then the aliases are defined/explained below.

Here is a made up example bash session with some of the commands:

# show we're in a basic java/whatever project
$ ls
src/ tests/

# start git-sh to get into a git-specific bash environment
$ git sh

# change some things
$ echo "file1" > src/package1/file1
$ echo "file2" > src/package2/file2
$ echo "file3" > src/package3/file2

# see all of our changes
$ d
# runs: git diff

# see only the changes in package1
$ dg package1
# runs: git diff src/package1/file1

# stage any path with 'package' in it
$ ag package
# runs: git add src/package1/file1 src/package2/file2 src/package3/file3

# we only wanted package1, reset package2 and package3
$ rsg package2
# runs: git reset src/package2/file2
$ rsg package3
# runs: git reset src/package3/file3

# see what we have staged now (only package1)
$ p
# runs: git diff --cached

# commit it
$ commit -m "Changed stuff in package1"
# runs: git commit -m "..."

That is the basic idea.

Most of the magic is from the [alias] section of .gitconfig, along with my .gitshrc allowing the git prefix to be dropped.

`.gitconfig`

The .gitconfig file is in your home directory and is for user-wide settings.

Here is my current .gitconfig with comments:

[user]
  name = Stephen Haberman
  email = stephen@exigencecorp.com
[alias]
  # 'add all' stages all new+changed+deleted files
  aa = !git ls-files -d | xargs -r git rm && git ls-files -m -o --exclude-standard | xargs -r git add

  # 'add grep' stages all new+changed that match $1
  ag = "!sh -c 'git ls-files -m -o --exclude-standard | grep $1 | xargs -r git add' -"

  # 'checkout grep' checkouts any files that match $1
  cg = "!sh -c 'git ls-files -m | grep $1 | xargs -r git checkout' -"

  # 'diff grep' diffs any files that match $1
  dg = "!sh -c 'git ls-files -m | grep $1 | xargs -r git diff' -"

  # 'patch grep' diff --cached any files that match $1
  pg = "!sh -c 'git ls-files -m | grep $1 | xargs -r git diff --cached' -"

  # 'remove grep' remove any files that match $1
  rmg = "!sh -c 'git ls-files -d | grep $1 | xargs -r git rm' -"

  # 'reset grep' reset any files that match $1
  rsg = "!sh -c 'git ls-files -c --with-tree=HEAD | grep $1 | xargs -r git reset HEAD -- ' -"

  # nice log output
  lg = log --graph --pretty=oneline --abbrev-commit --decorate

  # rerun svn show-ignore -> exclude
  si = !git svn show-ignore > .git/info/exclude

  # start git-sh
  sh = !git-sh
[color]
  # turn on color
  diff = auto
  status = auto
  branch = auto
  interactive = auto
  ui = auto
[color "branch"]
  # good looking colors i copy/pasted from somewhere
  current = green bold
  local = green
  remote = red bold
[color "diff"]
  # good looking colors i copy/pasted from somewhere
  meta = yellow bold
  frag = magenta bold
  old = red bold
  new = green bold
[color "status"]
  # good looking colors i copy/pasted from somewhere
  added = green bold
  changed = yellow bold
  untracked = red
[color "sh"]
  branch = yellow
[core]
  excludesfile = /home/stephen/.gitignore
  # two-space tabs
  pager = less -FXRS -x2
[push]
  # 'git push' should only do the current branch, not all
  default = current
[branch]
  # always setup 'git pull' to rebase instead of merge
  autosetuprebase = always
[diff]
  renames = copies
  mnemonicprefix = true
[svn]
  # push empty directory removals back to svn at directory deletes
  rmdir = true

`.gitshrc`

This is my .gitshrc file, heavily based off Ryan Tomayko’s original.

Ryan’s original comments are prefixed with #, I’ll prefix my additions with ###, most of which are aliases to my [alias] entries above and some git-svn aliases.

#!/bin/bash
# rtomayko's ~/.gitshrc file
### With additions from stephenh

# git commit
gitalias commit='git commit --verbose'
gitalias amend='git commit --verbose --amend'
gitalias ci='git commit --verbose'
gitalias ca='git commit --verbose --all'
gitalias  n='git commit --verbose --amend'

# git branch and remote
gitalias  b='git branch -av' ### Added -av parameter
gitalias rv='git remote -v'

# git add
gitalias  a='git add'
gitalias au='git add --update'
gitalias ap='git add --patch'
### Added entries for my .gitconfig aliases
alias aa='git aa' # add all updated/new/deleted
alias ag='git ag' # add with grep
alias agp='git agp' # add with grep -p
alias cg='git cg' # checkout with grep
alias dg='git dg' # diff with grep
alias pg='git pg' # patch with grep
alias rsg='git rsg' # reset with grep
alias rmg='git rmg' # remove with grep

# git checkout
gitalias c='git checkout'

# git fetch
gitalias f='git fetch'

# basic interactive rebase of last 10 commits
gitalias r='git rebase --interactive HEAD~10'
alias cont='git rebase --continue'

# git diff
gitalias d='git diff'
gitalias p='git diff --cached'   # mnemonic: "patch"

# git ls-files
### Added o to list other files that aren't ignored
gitalias o='git ls-files -o --exclude-standard'    # "other"

# git status
alias  s='git status'

# git log
gitalias  L='git log'
# gitalias l='git log --graph --pretty=oneline --abbrev-commit --decorate'
gitalias  l="git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative"
gitalias ll='git log --pretty=oneline --abbrev-commit --max-count=15'

# misc
gitalias pick='git cherry-pick'

# experimental
gitalias mirror='git reset --hard'
gitalias stage='git add'
gitalias unstage='git reset HEAD'
gitalias pop='git reset --soft HEAD^'
gitalias review='git log -p --max-count=1'

### Added git svn asliases
gitalias si='git si' # update svn ignore > exclude
gitalias sr='git svn rebase'
gitalias sp='git svn dcommit'
gitalias sf='git svn fetch'

### Added call to git-wtf tool
gitalias wtf='git-wtf'

Since I defined most of the interesting aliases in the .gitconfig [alias] section, it means they’re all usable via git xxx, e.g. git ag foo, but listing alias ag='git ag' in .gitshrc means you can also just use ag foo, assuming you’ve started the git-sh environment.

It results in some duplication, but means they’re usable from both inside and outside of git-sh, which I think is useful.

That’s It

Leave comments if you have any similar hacks/links/etc.

Caller-Side Structural Typing

2010-01-17T00:00:00-08:00

Caller-Side Structural Typing

Intro

Structural typing is an interesting approach to static typing that I’ve been thinking more about lately.

The basic gist of structural typing is that type names don’t matter–only type structures matter.

Though first a disclaimer: being a JVM guy, I’m mostly interesting in hacking structural types into the JVM environment. If you’re in a language like Go, which has native structural typing, then my points are moot.

In Java

I think structural types are best explained with an example. Let’s start with Java. Say you define an interface Closeable:

public interface Closeable {
  public void close();
}

And then you write some nifty library routines for working with Closeables:

public class YourLibrary {
  public static void doClose(Closeable closeable) {
    // other nifty stuff
    closeable.close();
  }
}

Now, let’s say somebody else wants to use your doClose method, e.g. they have a class:

public class SomeClass {
  public void close() {
    // want this to be called by doClose
  }
}

With traditional static typing, they cannot pass instances of SomeClass to your doClose useless SomeClass explicitly has an implements Closeable declaration.

Which, okay, yeah, most of the time its fairly easily to add this line.

But, sometimes, it gets annoying–and this is where structural typing steps in.

Let’s say you try to call:

SomeClass s = new SomeClass();
// stuff
YourLibrary.doClose(s); // usually a compile error

Structural typing notices that doClose wants a Closeable, and while SomeClass does not directly implement Closeable, it does have all of the methods required (specifically void close()) to meet the structural requirements of implementing Closeable.

So, the idea is that this is good enough, and you should be able to go ahead and pass an almost-Closeable SomeClass to doClose.

Obviously Java doesn’t do this today, but Scala and a few other languages do, so let’s look at what they do.

In Scala

Scala’s approach to structural typing doesn’t quite work like my above description. It requires you do declare up-front what types are structural. E.g. if you define a method:

object YourLibrary {
  def doClose(closeable: { def close(): Unit }) = {
    // other nifty stuff
    closeable.close()
  }
}

The type of the argument closeable does not an have an explicitly named type. The { def close(): Unit } is Scala’s syntax for inline structural types. It means “any type that has a close method on it”.

Also note that if you don’t like the inline syntax, or need to reuse the closeable structural type a lot, you can define a type alias like so:

object YourLibrary {
  // this is a type alias for the structural type
  type Closeable = {
    def close(): Unit
  }
  // now use ': Closeable' like regular syntax, but its still
  // a structural "anything that has close on it" type
  def doClose(closeable: Closeable) = {
    // other nifty stuff
    closeable.close()
  }
}

Since the Scala compiler understands structural types, per our Java example above, you can now do:

val s = new SomeClass()
// stuff
// compiles because SomeClose.close matches structurally
YourLibrary.doClose(s)

Without explicitly declaring SomeClass extends Closeable. So, this is it, we’ve got structural typing.

However, this is just compile-time. At runtime, Scala now has to cater to the JVM and figure out how to pass “any-type-that-is-basically-Closeable-but-not-really” to doClose.

To the JVM, doClose has to accept “any-type”, because there is no single interface/class name we could put here without forcing our callers to implement that type–which is exactly what we’re trying to avoid.

So, in the class file, the YourLibrary.doClose’s closeable argument is actually a plain java.lang.Object. Then inside of doClose, Scala uses cached reflection grab the closeable argument’s close method and invoke it.

So your code at runtime basically becomes:

// Runtime view
object YourLibrary {
  def doClose(closeable: Object) = {
    Method m = getMethodWithFancyCaching(closeable, "close");
    m.invoke();
  }
}

Note that while the reflection side of things looks a lot like Ruby/Groovy-style dynamic language duck typing, the compiler (assuming you stay within Scala) still statically enforces that any types you pass to doClose do actually have the close() method.

So the getMethod call is guaranteed to work, it just happens to be reflectively-dispatched at runtime to hack around the JVM’s lack of native structural typing.

Summarizing, Scala has definition-side structural typing (I’m blatantly making up terms here). You declare what types/arguments in your library you wish to be structural and it becomes statically-checked compiler syntax sugar for runtime reflection calls.

In Whiteoak

Whiteoak is an extension of Java that adds structural typing. Syntactically, their approach is very similar to Scala’s–explicit, definition-side declaration of structural types.

The syntax looks something like:

public class YourLibrary {
  // they introduce a 'struct' keyword for 'structural'
  struct Closeable {
    void close();
  }
  public static void doClose(Closeable closeable) {
    // do stuff
    closeable.close()
  }
}

So, at compile-time, it looks very much like using interfaces.

However, just like Scala, at runtime it has to jump through some hoops to satisfy the JVM and accept non-Closeable arguments to the doClose method.

To do this, Whiteoak uses the same approach as Scala–structurally typed arguments become java.lang.Objects in the class file. However, unlike Scala, Whiteoak generates cached adaptor classes at runtime.

So your code at runtime basically becomes:

// Runtime version
public class YourLibrary {
  // Closeable gets an interface
  interface ICloseable {
    void close();
  }
  // doClose takes an Object but, like Scala, any argument has been
  // compile-time checked to structurally have a close method
  public static void doClose(Object closeable) {
    ICloseable c = Whiteoak.make(closeable, ICloseable.class);
    c.close();
  }
}

// Whiteoak.make looks at closeable, and ifs its SomeClass, uses
// runtime bytecode generation to make a class like:
public class GeneratedSomeClass {
  private SomeClass contents;
  public SomeClass(Object contents) {
    this.contents = (SomeClass) contents;
  }
  public void close() {
    contents.close();
  }
}

You’ll end up with a separate GeneratedXxx adaptor class for each type you pass in to doClose. However, like Scala caching for reflection, Whiteoak uses caching to avoid re-generating the class on each make call.

Between the two, I don’t consider Scala’s cached-reflection vs. Whiteoak’s cached-adaptors to be that large of a difference. The paper Compiling structural types on the JVM goes into more detail and also benchmarks the two approaches.

However, essentially, they both treat structural types as a definition-side concern and consider it doClose’s responsibility to take a java.lang.Object and know how to do the right thing with it to get close called.

In Heron

Heron is an interesting language that takes a caller-side approach to structural typing. It is not actually a JVM language, but his caller-side approach is something I like, so I thought I’d include it.

The author of Heron also wrote a very good article, Explicit Structural Typing, that covers these same structural typing ideas and terminology better than I do.

So, Heron implements explicit caller-side structural typing. You can see the explicit syntax in its unit test, or, in our example, it looks like:

 // define Closeable as a regular interface
 // define YourLibrary.doClose as a regular method taking Closeable
 var s = new SomeClass()
 // compiles because `as Closeable` suffix
 YourLibrary.doClose(s as Closeable)

The as Closeable directive ensures s structurally complies with Closeable and then lets the call happen.

At least I think it does the structural check at compile time. He mentions a runtime check also occurring and then what I assume to be a Whiteoak-like adaptor object being made at runtime as well.

I’m a little fuzzy on the details as I just came across the language, but the key thing is that Heron moves structural typing to be something you as a caller decide you want to use. The declaration-side, the doClose implementation, is none the wiser.

Implicit Caller-Side

In my look-ma-I’m-a-language-designer opinion, I like Heron’s approach, but I think Scala should do one better and support implicit caller-side structural typing. As in you don’t need the as Closeable, the compiler just notices this should happen and makes it so.

With this approach, you can write library/API code and be blithely unaware of whether your callers are passing in real-conforming or structurally-conforming arguments.

So, it’d look like:

object YourLibrary {
  // regular trait/interface
  trait Closeable {
    def close(): Unit
  }
  def doClose(closeable: Closeable) = {
    // other nifty stuff
    closeable.close()
  }
}

So far, this is all straight, “non-structural” Scala code. But then, when the compiler notices the caller passing in a SomeClass argument that is not actually a Closeable, do one of two things:

Generate, at compile-time, a adaptor class that implements Closeable. E.g. something like:
```
class SomeClassAsCloseable(val c: Closeable) extends Closeable {
  def close() = c.close()
}
```
And automatically transform the caller’s call into:
```
val s = new SomeClass()
YourLibrary.doClose(new SomeClassAsCloseable(s))
```
Points:
- Pro: Everything is plain Java at runtime–doClose still takes a regular Closeable interface and there is no reflection/bytecode generation
- Pro: Conversion semantics are similar to Scala’s views/implicit conversions, which are used extensively
- Pro: Doable now–doesn’t rely on new JDK features (see option 2)
- Con: Object identity is broken–if doClose does any identity comparison of its argument, it will do so against the SomeClassAsCloseable adaptor instance instead of SomeClass itself. (I don’t consider this a huge deal given how much proxies are used in Java and implicit views in Scala.)
- Con: Generates an extra adaptor class for each caller-side type (like Whiteoak, except generation is at compile-time, so there is no runtime hit)
- Con: Generates an extra adaptor instance (new SomeClassAsCloseable) for each Closeable call (though perhaps this could be cached somewhere, e.g. on SomeClass.asCloseable if SomeClass was a class we controlled)
Use Interface Injection

This is a JDK7 feature, but the idea is that there will be a way to, at runtime, dynamically add Closeable to the list of interfaces that SomeClass implements. This is like reaching into the SomeClass class declaration line and saying “oh, yeah, you meant to add implements Closeable, let me do that for you”.

I think this is the best option for JVM-based structural typing, it just sucks that it is not available yet.

Points:
- Pro: Object identity is not broken–there is no proxy/adaptor instance hiding the real SomeClass instance in the background
- Con: Relies on a JDK7 feature that is at least 6-12 months away from release. Even then, it is doubtful Scala would use such a cutting edge feature and limit its target-able runtimes.

Concerns About Implicit Conversion

A few articles on structural typing have mentioned structural typing in and of itself is potentially a bad thing–the assertion is that a named interface entails a documented protocol across the entire set of methods, not just a grab bag of disparate methods that can be called willy nilly.

For example, let’s say SomeClass.close() was actually part of SomeClass implementing this other interface IResource. And part of IResource’s contract is that clients must call open() before calling close() or else bad things happen. And so SomeClass is implemented with this contract in mind.

But now you pass SomeClass to doClose, and the compiler magically turns it into a ICloseable for you. However, ICloseable has no documented “call open() first” contract, and so now the doClose method will start violating SomeClass.close’s semantics without knowing any better.

This is not a bad point. And, perhaps by making structural types an explicit/definition-side concern, Scala and Whiteoak were purposefully setting out to say library/API designers need to explicitly note that they are okay with getting a “grab bag of methods”.

Certainly making structural typing an implicit, caller-side implementation as I’m proposing will increase the chances of semantics being unintentionally violated.

However, foregoing the “lack of documented protocol” concern is how Google’s Go implements structural typing, so it will be interesting to see if that plays out well and if “willy nilly” structural typing gains either popularity or notoriety.

Wrapping Up

I ended up talking more about how other languages implement structural typing more than I intended to. Well, besides the fact that I avoided the big one, Google’s Go, which I haven’t looked in to enough yet.

My main assertion is that Scala’s structural typing seems like it would integrate better with the JVM if it used caller-side/compile-time adaptor hacks. Basically in the same vein of how Scala 2.8’s default/named arguments also use caller-side/compile-time hacks. And, as an added bonus, this would mean structural typing could be used anywhere that takes existing regular traits/interfaces instead of only those picked to accept structural types.

Of course, declaration-side structural typing still gets the job done and I’ll definitely use it, assuming I control the library/API implementation and foresee the needed flexibility.

Changing My Style

2010-01-15T00:00:00-08:00

Changing My Style

Lately I’ve been reconsidering my approach with regard to statics.

Basically, less of them.

DI With Manual Wiring

Yeah, I know I’m late to the game here, what with DI taking over the Java world, what, 10 years ago.

I’ve always liked the class-design side of DI. I noticed early on that DI-style projects were much easier to integrate with than others. Pre-DI, projects would typically look at their own proprietary configuration files and then take off running, and not let you easily change things.

Post-DI, integration was much easier, even though I would still manually wire together our DI-enabled dependencies.

Which brings me to the crux of my issue with standard DI: auto-wiring bugs me.

In three ways:

Spring auto-wiring still involves XML configuration files that are easily hundreds of lines long.

This is confusing because the service objects being wired together are usually the ones most likely to be driven by application-level configuration parameters, environment checks, etc. And XML is pretty much the most static place you can put stuff. No ifs, whiles, logic, abstractions, etc.

Supposedly Java-based configuration for Spring is available, but I’ve yet to see a project actually use it. I’m not sure why.
Leaving auto-wiring to a framework foregoes static typing of your service object dependencies.

Spring’s XML is especially bad at this, being just a grab bag of fun that you get to wait until runtime to see what happens with it.

But even Guice, which asserts to “embrace Java’s type safe nature”, can really only ensure that you bind the right type of implementation to an interface.

Which is fine, but what they cannot check is whether you’ve added the binding at all in the first place. E.g. you’re going to have to wait until runtime to make sure all of your @Inject constructors just magically work.

Contrast this with manual wiring where, if you’re missing a constructor parameter, you’ll know it immediately at compile time.
Manual wiring shouldn’t be that hard.

Lex Spoon says it very well, that DI propaganda picks on XxxFactory as why you need auto-wiring when really the XxxFactory is an anti-pattern in and of itself and just needs a dose of good implementation and abstraction.

(Note I’m working on this–slowly. Nothing awesome yet.)

Joist Example

Anyway, when building Joist, I wasn’t as anti-static as I am becoming, so I’d have code that looks like:

public class SomeBusinessLogic {
  public void doSomeBusinessLogic(final Integer fooId) {
    // UoW is a static that reaches out and starts a transaction
    UoW.go(new Block() {
      public void go() {
        // Foo.queries is another static that reaches out for a FoodQueries instance
        final Foo foo = Foo.queries.findById(fooId);
        // do stuff with foo
      }
    });
  }
}

I think I would write this now as:

public class SomeBusinessLogic {
  private final Repository repo;

  public SomeBusinessLogic(final Repository repo) {
    this.repo = repo;
  }

  public void doSomeBusinessLogic(final Integer fooId) {
    repo.go(new Block() {
      public void go() {
        final Foo foo = repo.getFooQueries().findById(fooId);
        // do stuff with foo
      }
    });
  }
}

The odd thing is that I don’t know how useful this would actually be.

Part of my historical anti-DI stance is that some semantics, like the transactional semantics of a database-backed unit of work, just cannot be mocked/stubbed out very effectively.

E.g. with the real unit of work, if you get an instance of Foo, change some properties, but then an exception happens, those changes are lost.

However, most any mock/stub repository is going to hand you an instance of Foo, let you change some properties, and when an exception happens, leave Foo just as it is. It’s a mock/stub–it’s not smart enough to actually track/rollback object changes.

So, my opinion with Joist was “why bother?” and so I typically have just stuck with integration tests for anything that touches a unit of work/database.

And I still subscribe to this view, e.g. I don’t see myself mocking out getFooQueries any time soon.

But what I find odd is that my style has changed such that now even looking at the statics makes me uncomfortable.

Registries Example

I’m also moving away from a static-based Registry, to an interface-based one.

I still like Fowler’s pattern of the Registry being the one singleton in the application. It matches the Spring/Guice semantics of having one application context or application module that is tucked away in a static/thread local/servlet filter somewhere.

So, even though my previous Registries were the only singleton, I still exposed their resources via static getter methods, e.g.:

public class Registry {
  public static ResourceA getResourceA() { ... }
  public static ResourceB getResourceB() { ... }
}

public class Client {
  public void doStuffWith() {
    Registry.getResourceB().doStuff();
  }
}

But now, yeah, the static Registry.getResourceB() call hurts and I’m changing to something like:

public interface Registry {
  ResourceA getResourceA();
  ResourceB getResourceB();
}

public class RegistryInstance implements Registry {
  public static Registry get() { ... }
}

public class Client {
  private final Registry registry;

  // Ideally use this constructor when you've got a registry
  // on hand already
  public Client(final Registry registry) {
    this.registry = registry;
  }

  // Only use the default constructor if you don't control
  // class instantation, e.g. a servlet or domain object
  public Client() {
    this(RegistryInstance.get());
  }

  public void doStuffWith() {
    registry.getResourceA().doStuff();
  }
}

Such that now Registry can be mocked/stubbed out.

Which, yeah, is obvious in this day and age.

But, I still like the Registry as a pure-Java/typed version of your Spring application context or Guice client module. I get to strongly declare the dependencies my application has.

I’ll add the caveat that I haven’t used this new approach in a huge system yet. I don’t intend on the Registry context being passed around through layer after layer. Hopefully good design, or a few strategic RegistryInstance.get() calls, will avoid that.

And I’m not too worried about the occasional RegistryInstance.get() call, especially if used in a default constructor that then defers to a mockable constructor. Spring apps have do the same thing now and then, reach out to a thread-local/etc. application context.

Inner-Class Dependency Interfaces

One approach I want to play more with is using a GWT MVP-style dependency declaration. E.g. instead of service components being in an application-wide Registry interface, or a huge list of constructor arguments, I think an inner-interface would be interesting:

public class SomeBusinessLogic {
  public interface Deps {
    Repository getRepository()
  }

  private final Deps deps;

  public SomeBusinessLogic(Deps deps) {
    this.deps = deps;
  }
}

// off in your Registry
public interface Registry extends SomeBusinessLogic, ... {
}

What I like about this is that each class gets its own declaration of the dependencies it requires. For very common dependencies, you could use inheritance, e.g.:

public class SomeBusinessLogic {
  public interface Deps extends CommonAppDeps {
  }
}

But, without some structural typing tricks, your Registry interface is going to have an explosion of extends XxxLogic, YyyLogic, etc.

Which, ironically, verbosity is one of my complaints about GWT MVP’s use of inner-interfaces as well.

So, perhaps it is not such a great idea.

Thanks

Also, I wanted to thank to my coworkers at Bizo for influencing my style lately. It’s fun to still be learning.

Sprunge And Dropbox

2009-12-13T00:00:00-08:00

Sprunge And Dropbox

Just a quick post on Sprunge and Dropbox.

Sprunge Rocks

If you haven’t used it yet, sprunge.us rocks.

It’s a CLI-friendly paste bin.

So, say you have some log file/snippet/whatever, off on your headless server, and you’d like your coworkers to take a look at it. Assuming you don’t have sensitive information in it, Sprunge makes this trivial:

curl -F 'sprunge=@somefile.txt' sprunge.us

This uses curl to do an HTTP POST to http://sprunge.us with a multi-part form containing sprunge=<the contents of somefile.txt>.

In the response, Sprunge will give you a unique URL that you can then send to your coworkers for them to check out (e.g. something like http://sprunge.us/IdhX).

Note if you don’t want all of somefile.txt, you can also use stdin, e.g.:

cat somefile.txt | grep ERROR | curl -F 'sprunge=&lt;-' sprunge.us

Being CLI-friendly is Sprunge’s main act–it doesn’t have much else, e.g. no syntax highlighting, commenting, whatever. But for what I’ve used it for, sharing snippets of files, it works just great.

Speaking of which…

Dropbox CLI Upload

I can’t give Dropbox too much crap, because I only have a free account, but I wanted to get a file from a headless server into their system today and finally gave up.

To their credit, they have a Linux download, but it involves running a proprietary daemon plus an open source Nautilus extension.

Which I’m sure is exactly what you want for 2-way sync, normal Dropbox awesomeness, but it really sucks when all I want to do is drop a backup file up there and be done with it.

So, riffing on Sprunge, I’d like to be able to do:

curl -F 'data=@somefile.bin' -F 'name=myfolder/somefile.bin' -u me:password https://dropbox.com

This would use basic auth to identify me, but that’s fine given the connection is over HTTPS anyway.

This command may not be something users could type off the top of their head, but it’d be easy to script for automating uploads/backups/etc.

So, for now I’ll continue with a manual scp download to my laptop and then use a browser to upload the file back into Dropbox. It’s nothing too important/frequent, so it’ll be fine for now.

Running ScalaTest Spec Tests from Eclipse

2009-09-10T00:00:00-07:00

Running ScalaTest Spec Tests from Eclipse

ScalaTest is pretty cool. I’ve been playing with the “spec” way of writing tests–for the most part, I have nothing against traditional JUnit 3 testXxx methods, other than having string-based test names is pretty darn cool from a readability perspective.

The big con, however, is that ScalaTest doesn’t have its own Eclipse plugin, so if you move away from the JUnit 3 testXxx methods, you don’t get the nice Alt-Shift-X + T test-running capabilities directly within Eclipse.

I started fiddling with ways of tricking Eclipse into running spec-type ScalaTests and came up with a workable approach.

A Sample Test

So, here’s a sample spec-based test that we’d like to run with Eclipse:

import org.junit.runner.RunWith
import org.scalatest.Spec
import org.scalatest.matchers.MustMatchers

@RunWith(classOf[JUnit4Runner])
class ZazTest extends Spec with MustMatchers {
  describe("something") {
    it("should do something fancy") {
      println("fancy")
    }
    it ("should do something plain") {
      println("plain")
    }
    it ("should also fail") {
      println("fail")
      1 must equal (2)
    }
  }
}

Note the "should do something fancy" test names that JUnit really isn’t going to understand (because they are not methods, they’re anonymous inner classes ScalaTest keeps track of in an internal data structure).

How To Get Eclipse To Run This Test

The key thing I’ve added above is a RunWith annotation that uses a JUnit4Runner I wrote. When you hit Alt-Shift-X + T in Eclipse, even though ZazTest doesn’t extend TestCase or have any @Test annotations, the Eclipse JUnit 4 runner seems the RunWith annotation and hands over control to it.

The JUnit4Runner then just has to translate a JUnit run into something the Spec suite can handle.

This turned out to be not that bad:

import org.junit.runner.{Description => JuDescription}
import org.junit.runner.{Runner => JuRunner}
import org.junit.runner.notification.{Failure => JuFailure}
import org.junit.runner.notification.{RunNotifier => JuRunNotifer}
import org.junit.runners.{Suite => JuSuite}
import org.scalatest.{Filter => StFilter}
import org.scalatest.{Reporter => StReporter}
import org.scalatest.{Stopper => StStopper}
import org.scalatest.{Suite => StSuite}
import org.scalatest.{Tracker => StTracker}
import org.scalatest.events._

class JUnit4Runner(val testClass: Class[_]) extends JuSuite(testClass, new java.util.ArrayList[JuRunner]()) {
  val suite = testClass.newInstance.asInstanceOf[StSuite]
  suite.testNames.foreach((testName) => getChildren.add(new TestAdapter(this, testName)))
}

class TestAdapter(runner: JUnit4Runner, testName: String) extends JuRunner {
  override def run(notifier: JuRunNotifer): Unit = {
    val reporter = new ReporterAdapter(this, notifier)
    val stopper = new StopperAdapter
    val filter = new StFilter(None, Set())
    val tracker = new StTracker()
    runner.suite.run(Some(testName), reporter, stopper, filter, Map(), None, tracker)
  }
  override def getDescription() = JuDescription.createTestDescription(runner.testClass, testName)
}

class ReporterAdapter(test: TestAdapter, notifier: JuRunNotifer) extends StReporter {
  override def apply(event: Event): Unit = {
    event match {
      case e: TestStarting => notifier.fireTestStarted(test.getDescription)
      case e: TestSucceeded => notifier.fireTestFinished(test.getDescription)
      case e: TestFailed => notifier.fireTestFailure(new JuFailure(test.getDescription, e.throwable.get))
      case e: InfoProvided => // ignore
      case e => println(e)
    }
  }
}

class StopperAdapter extends StStopper {
  override def apply = false
}

It basically just translates ScalaTest Events into JUnit RunNotifier events.

The Results

Here’s a screenshot:

What’s really cool is that, in typical JUnit fashion, no existing Run Configuration needs to be setup. E.g. I don’t have to manually create a run configuration for each spec-based ScalaTest–just hitting Alt-Shift-X + T will make a new JUnit run configuration and fire off the tests.

The Downside

The Eclipse JUnit UI still assumes “something should do something fancy” is a method name, so if you double click on it, it will fail to find it and just take you to the ZazTest class. So it’s not as easy to jump right to failures.

Bonus

Turns out you can right click and run individual it tests too. I have no idea how that is working–and it doesn’t seem to be just a UI trick, because the console output from the other tests doesn’t show up either. Weird…but cool.

Anyway, I haven’t decided if I’ll completely jump ship on traditional TestCase-extending tests for Scala projects. There is a warm familiarity that I like about it. But if I do start writing more spec-based ScalaTests, this RunWith hack will be very handy.

Update

Turns out this feature already exists in ScalaTest trunk and should be in the next release as org.scalatest.junit.JUnitRunner.

Port 80 to Port 8080

2009-08-23T00:00:00-07:00

Serving Port 80 from 8080

Several times lately I’ve wanted to run a Jetty instance on port 8080 but have it available via port 80.

On Unix boxes, this usually involves running as root, or at least starting as root and dropping down to a lower-privileged user.

Given I wanted to quickly start/stop Jetty test instances from within Eclipse, I really wanted to keep running Jetty on 8080 but have it show up on 80.

What ended up being easiest for my Ubuntu 9.04 box was two firewall rules:

/etc/network/if-up.d/port80to8080:

#!/bin/sh
[ "$IFACE" != "lo" ] || exit 0;
iptables -t nat -A PREROUTING --src 0/0 --dest 127.0.0.1 -p tcp --dport http -j REDIRECT --to-ports 8080
iptables -t nat -A OUTPUT     --src 0/0 --dest 127.0.0.1 -p tcp --dport http -j REDIRECT --to-ports 8080

/etc/network/if-down.d/port80to8080:

#!/bin/sh
[ "$IFACE" ! "lo" ] || exit 0;
iptables -t nat -D PREROUTING --src 0/0 --dest 127.0.0.1 -p tcp --dport http -j REDIRECT --to-ports 8080
iptables -t nat -D OUTPUT     --src 0/0 --dest 127.0.0.1 -p tcp --dport http -j REDIRECT --to-ports 8080

Make sure to chmod 744 and chown root:root both files.

These iptables rules catch all incoming (PREROUTING, others hitting your box) and outgoing (OUTPUT, you hitting your box) requests going to 127.0.0.1:80 and shunt it over to 8080.

I’m not enough of a sysadmin to know the pros/cons of using this approach in production, but for my dev box it works great.

Bindgen 2.0 Released

2009-07-21T00:00:00-07:00

Bindgen 2.0 Released

My hobby project bindgen just got a new release: 2.0.

bindgen provides expression language-like capabilities, but with type-safe method calls instead of opaque strings like OGNL.

Stateless Bindings

The biggest change is that bindings can now be stateless.

Previously, a binding could only be bound to 1 instance at a time, making them not safe for use across multiple threads. You could reuse them within a thread, with a set(instance)-based idiom like:

FooBinding fb = new FooBinding();
StringBinding nb = fb.name(); // could be more complex, e.g. fb.bar().name()

Foo foo = new Foo("foo");
fb.set(foo); // binds fb to the foo instance
nb.get(); // returns "foo"

But the gap between fb.set and nb.get() meant another thread could step in and interleave a set behind your back.

Now there are getWithRoot and setWithRoot methods that are stateless and so thread-safe:

FooBinding fb = new FooBinding();
StringBinding nb = fb.name();

Foo foo = new Foo("foo");
nb.getWithRoot(foo); // returns "foo"

This means you can instantiate a binding just once and reuse it across many instances/threads.

Joist is starting to use these stateless bindings for its validation rules. The iterative nature (e.g. foo.employer().name()) of bindgen is more flexible than Joist’s previous approach.

Validation with Objects Instead Of Annotations

2009-07-14T00:00:00-07:00

Validation With Objects Instead Of Annotations

Intro

Annotations are really popular these days for marking up validation rules.

I’m forcing myself to go through a Seam tutorial, and their example is fairly representative:

public class FooDomainObject {
    @NotNull @Length(max=100)
    public String getTitle() {
        return title;
    }
}

I cringe every time I see this–annotations are not inherently bad, but I see the annotation-hammer as having replaced the XML-hammer is the Java world. Specifying validation rules as annotations has its strength, but also its weaknesses, which I think are not always evaluated.

I’ve had success with a pure-OO approach I’ll describe here.

But first let’s look at the annotations approach.

The Pros of Annotations

You get to type-safely add rules on an attribute-by-attribute basis.

This is of course the huge win over XML–you don’t have to retype an attribute name in an XML file and brave typos due to repetition that is not compile-checked.
Very clean, succinct declarations.

The Cons of Annotations

Annotations are static–you have no way of adding/removes rules as needed.

One app I worked on had non-trivial validation rules–they were closer to business constraints than low-level “not null” checks. Which was good because it kept the data sane and caught bugs before the Unit of Work was committed. But, real life being what it is, we needed to occasionally turn them off. Especially if we had legacy data that we knew wouldn’t conform to the new business rules.

Obviously you want disabling rules to be a very one-off thing–I’d be worried if it become habitual. But it is handy when needed.
Annotations cannot cross multiple attributes–often times rules want to bind across multiple parameters (e.g. stop/end for date ranges).
Annotations seem harder to customize–most frameworks seem to have boilerplate not null/column length rules, but the real power of validation is when you start adding business-specific rules. It is not incredibly clear to me whether the annotation-based validation frameworks allow easy addition of your own custom annotations.

A Java Alternative

I’ve had success with each domain object having its own list of Rule objects. Rules can be added/removed as needed, and, being just POJOs themselves, are easy to create your own, business-specific rules.

For type-safety, this approach leverages bindgen. Instead of bindgen, it can also work by passing OGNL expressions to the rules (instead of bindgen’s Binding objects), but then you give up type-safety.

So, an example of a domain object would be:

public class FooDomainObject extends BaseClassWithAddRulesEtc {
  public FooDomainObject() {
      this.addExtraRules();
  }

  private void addExtraRules() {
      FooDomainObjectBinding b = new FooDomainObjectBinding(this);
      this.addRule(new NotNullRule(b.title()));
      this.addRule(new SaneDateRule(b.start(), b.stop()));
  }

  // ... title, start, stop getters &amp; setters ...

  // ... in the base class:
  public ValidationErrors validate() {
      ValidationErrors errors = new ValidationErrors();
      for (Rule rule : this.getRules()) {
          rule.validate(errors, this);
      }
      return errors;
  }
}

This first alternative has a few trade-offs:

All rules are within the addExtraRules method instead of alongside their getter/setter.
It is more verbose, having to repeat b.title() in the addRule clause. But this only gets really annoying if you need a private static reference to a rule for later removal.
It is simpler from an implementation perspective–just iterating over rules and calling validate. Annotations usually involve non-trivial lookup/storage/etc. that means delegating to a heavier-weight framework to handle.

Turning off rules requires promoting rules to a static field, as in this 2nd example:

public class FooDomainObject {

    private static FooDomainObjectBinding b = new FooDomainObjectBinding();
    private static Rule titleNotNull = new NotNullRule(b.title());
    private static Rule saneDateRule = new SaneDateRule(b.start(), b.end());

    public FooDomainObject() {
        this.addExtraRules();
    }

    private void addExtraRules() {
        this.addRule(FooDomainObject.titleNotNull);
        this.addRule(FooDomainObject.saneDateRule);
    }

    public void disableTitleRule() {
        this.removeRule(FooDomainObject.titleNotNull);
    }

    // ... title, start, stop getters &amp; setters ...
}

// ... sometime later ...
fooDomainObject.disableTitleRule();

A variation of this theme would be to kill the addExtraRules and use a list utility in the declarations:

public class FooDomainObject {

    private static FooDomainObjectBinding b = new FooDomainObjectBinding();
    private static DefaultRules rules = new DefaultRules();
    private static Rule titleNotNull = rules.ref(new NotNullRule(b.title()));
    private static Rule saneDateRule = rules.ref(new SaneDateRule(b.start(), b.end()));

    public FooDomainObject() {
        FooDomainObject.rules.copyTo(this);
    }

    public void disableTitleRule() {
        this.removeRule(FooDomainObject.titleNotNull);
    }

    // ... title, start, stop getters &amp; setters ...
}

// ... sometime later ...
fooDomainObject.disableTitleRule();

This:

Adds another static variable (rules)
Makes the rule declaration longer as we pass the rule reference through the ref method to keep track of it

But, nicely:

Removes the addExtraRules and rules being referenced in multiple places

A Scala Alternative

And, actually, since two-way binding is not required, Scala’s call-by-name functionality would work here:

class FooDomainObject {
  addRule(new NotNullRule(title))

  // ... title ...
}

class NotNullRule[T](value: => AnyRef) implements Rule[T] {
  def validate(T instance) = {
    if (value == null) {
      // ... add error ...
    }
  }
}

However, this has one major trade-off:

Passing title as call-by-name only lets us get the value–both annotations and bindgen also allow access to the name of the property for inclusion in error messages (e.g. “title is required”–with call-by-name, you don’t actually know it’s called “title”).

I think having the attribute name is required, so we’d have to pass another string parameter:
```
class FooDomainObject extends BaseClassWithAddRulesEtc {
  addRule(new NotNullRule("title", title))
}
```

But, even then, that’s pretty slick and lightweight. If scala’s call-by-name had something like “set-by-name” to make it two-way, and perhaps throw in a getName() for good measure, it would easily trump the need for bindgen-like hacks.

Wrapping Up

I’ve been coming around on annotations. But I do like to be contrary and just highlight that they are not the only solution for specifying business rules against domain objects. Having had the success with it in the past, I’m currently partial to staying with object-based approaches to validation rules.

Scala Per-Instance Singletons

2009-07-13T00:00:00-07:00

Scala Per-Instance Singletons

I was reading about Lift and came across a funky scala syntax:

class Foo {
  object bar {
    val name = "bob"
  }
}

This:

Declares a Foo.bar field
Declares a bar inner class
Adds a Foo.bar() method that lazy-instantiates a single instance of the bar inner class for each Foo instance

Looking at the decompiled code, it makes more sense:

import java.rmi.RemoteException;
import scala.ScalaObject;

public class Foo implements ScalaObject {
    private bar. bar$module;

    public Foo() {
    }

    public final bar. bar() {
        class bar. implements ScalaObject {
            private final String name = "bob";
            public bar.() {
                super();
            }
            public String name() {
                return name;
            }
            public int $tag() throws RemoteException {
                return scala.ScalaObject.class.$tag(this);
            }
        }
        if(bar$module == null)
            bar$module = new bar.();
        return bar$module;
    }

    public int $tag() throws RemoteException {
        return scala.ScalaObject.class.$tag(this);
    }
}

My one curiosity is the lack of synchronization in the lazy initialization. I don’t know about the official Scala docs, but Lift insinuated an “inner object” declaration was a singleton, not a singleton-unless-you-have-lots-of-threads.

If you use top-level object declarations, it seems to make more sense:

object Bar {
  def zaz() = {
    println("hi")
  }
}

As this is decompiled to:

public final class Bar {
  public static final void zaz() {
    Bar..MODULE$.zaz();
  }

  public static final int $tag() throws RemoteException {
    return Bar..MODULE$.$tag();
  }
}

public final class Bar$ implements ScalaObject {
  public static final Bar$ MODULE$;

  static {
    new Bar$();
  }

  public Bar$() {
    MODULE$ = this;
  }

  public void zaz() {
    Predef..MODULE$.println("hi");
  }

  public int $tag() throws RemoteException {
    return ScalaObject.class.$tag(this);
  }
}

This uses the Bar$ static initializer to ensure there is just one instance of Bar$. Which works great.

“Inner” object declarations not being true singletons is probably not a big deal, it was just something I was curious about.

Achieving Durability

2009-06-24T00:00:00-07:00

Achieving Durability

Introduction

At one of my last gigs, building a claims system for an employee benefits 3rd-party administrator, nightly batch processes were a way of life. Yeah, batch processes aren’t sexy, but when you need to mail out thousands of checks every morning, you don’t generate the PDFs from within the user’s rich client Air application.

The durability of these processes was important, and we achieved it by simply leveraging our existing database.

Durability was important because if something happened (which it always does), things should just work. Power/network/whatever went out? Just restart the process. A vendor sent data that we’ve never seen before? The process continues and just tries the funky data again tomorrow.

Previously, these types of events would cause mini-catastrophes that required immediate attention from a developer. Developers would have to hand-edit the file to only retry the “bad” transactions, figure out where a process died and jury rig it to start from there, and just generally do a lot of manual leg-work and hand-holding for the system.

Instead of constantly fighting fires, the goal was to expect failures, handle them gracefully, and continue on to the next task, either immediately if the error was recoverable or, at worst, after a system restart. This would free up resources from day-to-day fire-fighting and let devs focus on just fixing bugs, not fixing bugs while also finessing the system back into a good state.

Of course, it is unlikely you’ll have the time/desire to make the entire system fault tolerant to the Nth degree, but some basics will still take you a long way, in my experience.

Atomicity

One fundamental concept to durability is atomicity–if you want to continue where you left off before, you can’t redo previous work.

If your tasks are idempotent, you’re in luck. Being idempotent means you can “retry” a task as many times as you want, and the task is smart enough to not cause funky behavior (like double-/triple-processing). For example, it’s a transaction with a unique id that, if you find the id already in your system, you know not to enter it again. If your tasks are idempotent, you can just retry everything and what was already done will not cause duplicates.

However, if your tasks are not idempotent, you’ll have to explicitly mark tasks as pending and then as done.

Marking tasks as done is pretty easy with in-memory lists/etc.–but its neither atomic nor durable. Your process can’t be:

Make an ArrayList of tasks
Do task A
Remove task A from the list
Repeat until list is empty

There are two bad scenarios here:

Failure happens between 2 and 3–you’ve done a task but not yet marked it done.
Failure happens after N tasks–on restart, the ArrayList will have those first N items in it again.

The key to scenario 1) is atomicity–you can’t have a two step “do A” then “mark A done”, because if the box goes down in between those two, you’re going to redo “A” when you come back up.

The key to scenario 2) is to make your lookup of tasks take into account those that are already done.

Embrace ACID

The easiest way I’ve found to achieve durability is to realize you have an awesomely-durable resource at your disposal and you should leverage/abuse it as much as possible: your relational database server.

The key is to perform the business logic of the task and mark the task as done within the same transaction.

This means embedding in-progress data in your primary database instead of the JVM process (see the examples for details). A con is that if your database is already your bottleneck, even this small extra load may not be welcome. However, in the enterprise apps I’ve worked on, this was not the case. Also, a pro is that the in-progress data will be easily available for dashboards to report against.

So now scenario 1) is solved. Your database does all of the hard work ensuring that both task + marking either happen or not happen.

Solving scenario 2) is fairly problem specific, so I’ll defer to the examples, particularly the DocumentCursor.line attribute.

Examples

Two examples of adding durability into a system are:

Sending emails
Processing 3rd party data files.

Both can run into problems that you want to have handled nicely.

Sending Email

The first time I wrote email processing for the client’s app, it felt dirty–here within a nice Unit Of Work, doing some business logic, was an ugly Transport.send dropping an email onto the wire. Who knew what that would do if it failed. For example:

The email goes out because the Transport.send succeeds, but the transaction fails to commit–we’ve told the user about some action we thought we performed but didn’t actually get committed.
The Transport.send fails because our mail server is being dumb, but then the entire Unit Of Work fails and we don’t get any work done for the day until the mail server is back up.

There ended up being an obvious solution–a partner firm was storing their generated email in the database for CRM purposes (knowing what you’ve sent users), but I realized this was also the perfect way to solve the Transport.send problem–decouple generation of the email content within the business process from the actual sending of the email content out onto the network.

So, now:

A business process has 1 Unit Of Work that: does business logic and saves a Email object to the database–both either succeed or fail atomically.
An infrastructure process polls the email table and, after seeing newly-committed emails, drops them onto the wire. If errors occur, it tries again after 5 minutes. If it succeeds, it updates the row’s “sent” column.

Now email server funkiness will not disrupt the business process from its core work of performing business logic and generating emails. And business process funkiness will not result in “leaked” emails.

Note that we still have a window of opportunity for failure in the infrastructure process–again between the Transport.send and the UoW.commit, but it’s much smaller window given we’re only updating the sent column and not performing the complex business logic that lead to the creation of the email (and could have triggered non-trivial validation rules that would have to all pass before committing). This is where, if you wanted to go to the Nth degree, you’d implement some sort of API with your mail server to see if the current message id had already been sent.

Processing Data Files

Processing nightly batch files from one of the client’s vendors was another big win for durability. The vendor has a history of sending new and interesting transactions on a semi-regular basis. Not enough to be really annoying, but enough to burn a day screwing around with recovery every few months or so.

The original approach would retry entire files, and attempted to leverage an almost-idempotent transaction id. However, there was a heuristic involved that was not always accurate.

So, when we were changing how the system handled files anyway, I refactored the process to be durable:

Upon finding a file, a Document is saved to the database, and then a DocumentCursor with cursor.line=0 is stored as well.
An atomic parser then finds all open cursors in the database, and starts reading over their documents. It skips to line x if line != 0, so if a file is 80% done, it jumps right to the last 20%.
Each line is processed in its own transaction–if the business logic succeeds, the cursor’s line is ticked within the same transaction.
If a line’s transaction fails due to faulty parsing/business rules, the DocumentCursor is given a new FailedLine child row that stores that line’s number. This will cause the cursor to stay open, and the FailedLine will be retried on the next process run (e.g. tomorrow). The idea is to keep retrying every morning until the line succeeds. If a fix is required, the line will be automatically retried and should work the morning after the fix is released to production.

Also, the cursor logic can work against multiple types of documents–it was later used to handle another vendor’s incoming files with non-idempotent lines, so the durability was again necessary to avoid double processing in failure scenarios.

Keep Things Simple: One Datasource

The thing that made all of this doable was keeping business data and temporary in-progress data in the same database.

At first, I hesitated to do this, and was initially considering jury rigging some sort of two-phase commit with the primary database and a separate embedded/temporary database for the in-progress data. But, frankly, it’s so much simpler to avoid JTA and just use 1 transaction that, empirically, the one-datasource approach has won me over.

Having easy benefits like this with a single ACID data source makes me curious about how people handle similar scenarios with DHTs. I love the sexiness of scaling to Amazon-size as much as the next guy, but doing recovery scenarios in application code on top of a DHT seems complex–wouldn’t it devolve into manual two-phase commit? I’m not sure. Intra-source resolution (e.g. “merge carts”) makes sense, but it is inter-source resolution that I haven’t puzzled through yet (e.g. “book order reduced in inventory + book removed from cart”).

I favor starting with a RDBMS for your first few versions and only switching to DHTs when it becomes painfully obvious you need it. Yes, this is going to involve a massive refactoring of your code to deal with the completely different semantics of a DHT, but I think that is worth the simpler development you’ll get up-front. And, who knows, you may never need the DHT.

Testing For Failures

I don’t trust myself to get failure scenarios correct the first time, so I also developed a way to test the most likely points of failure. A different approach was required to solve two pain points of traditional approaches, such as setting up bad data or using mock objects:

Causing business logic to purposefully fail was difficult because our domain model had lots of validation rules to keep invalid data from getting into the database. Making invalid vendor files was easy, but setting up bad data within the database required ugly hacks to turn off validation rules or do manual INSERTs/etc.
Mock objects can only fail when going across API boundaries, e.g. into the email API. Several of the durability scenarios require testing what happens within an API boundary–e.g. you’re in the middle of a method in the CursorProcessor class and the power goes out.

My solution was a class, TestBreaker, that we made explicit calls to from specific vulnerability points in the production code. The TestBreakers calls did nothing in production, and in test would throw an exception if explicitly enabled by a unit test.

So, the CursorProcessor had several of these TestBreakers declared as constants:

public static final TestBreaker BREAK_AFTER_CURSOR = new TestBreaker();
public static final TestBreaker BREAK_INSIDE_LINE_RETRY = new TestBreaker();
public static final TestBreaker BREAK_AFTER_LINE_ATTEMPT = new TestBreaker();
public static final TestBreaker BREAK_INSIDE_LINE_ATTEMPT = new TestBreaker();

Then at vulnerable points in the code path, we’d put an explicit call:

// some important code that could break
CursorProcessor.BREAK_AFTER_CURSOR.ifSetFor(cursorId);

In production, this is a no-op. But in test, it will throw an exception if we’re on a certain cursor. This allows us to test the scenario of one cursor completely blowing up, but verifying that the process continues on to the next cursor.

A JUnit test can then explicitly trigger the breakage:

public void testOneCursorFailingOutsideLineContinuesOnToTheNext() {
    // data setup
    CursorProcessor.BREAK_AFTER_CURSOR.setFor(2);
    // run process
    // assertions
}

Showing my bias, I also love that BREAK_AFTER_CURSOR is a static constant, because just I did a Ctrl-Shift-G on the constant in Eclipse and immediately saw which one test out of thousands was referencing it to trigger than failure condition. I’m not an IoC expert, but I anticipate you would lose this capability with dependency injection.

Conclusion

I’ve shown several examples of leveraging your RDBMS to achieve business process durability. The approach has worked very well for me and I anticipate using it again in the future.

I’m also interested in other approaches, e.g. when you can’t leverage a single data source. I have done some googling on the topic, but I haven’t found much yet. If you have pointers to different ways of solving this sort of problem, I’d appreciate links in the comments.

Dynamic Keywords

2009-05-12T00:00:00-07:00

Dynamic Keywords

One of the things I love about boo are its macros that allow you to rewrite the AST at compile time.

This makes a lot of sense. All of malleability that people loves in dynamic languages like Ruby and Groovy, screwing with classes at runtime, etc., to me, should be done at compile time.

Typically, meta-programming in dynamic languages is only performed at load time anyway, when the interpreter first loads a file…it is not like after being deployed for 2 weeks, the Employee object suddenly gets another attribute added to it. At least I hope not.

Historically it has not been possible to plug into the compiler of type-safe languages, so it was easier to go with dynamic languages that let you screw with their types. I’ve seen Scala making some progress towards type-safe compiler plugins, but they seem non-trivial to write. Though, granted, I have no real experience other than glancing at them and thinking “wow, looks hard.”

Anyway, back to boo, what I find intriguing is if a language was macros all the way down…i.e. even basic constructs like class, method, and if were not baked into the syntax, but just macros that ship by default and that you could override/add to as needed.

I think the result would end up looking something like io, albeit with the magic happening at compile-time instead of runtime.

I’ve been typing out a syntax:

class Foo extends(Object) implements(Bar)
    field name

    method bar param(p1, String) param(p2, String)
        ...
    end
end

Where class is a shipped macro. extends and implements are…additive-macros? I dunno, either options baked into the class macro itself, or, ideally, layered onto the class macro. So, conceptually, you could add your own extensions, e.g. class Foo mixin(Bar) or what not.

The field name and method bar lines are a little jarring at first–in C-based languages, the field-ness/method-ness is taken for granted by being baked into the syntax, so you don’t have to explicitly say ”I’m doing a field now”, ”I’m doing a method now”.

What I don’t have an intelligent answer for is how to differentiate between regular runtime method calls and AST-mucking compile-time macro calls.

Maybe something silly like prefixes, e.g. $class Foo or @class Foo. A little too Perl for my liking. I also thought of suffixes, e.g. class: Foo, field: name, which seems better.

There is a risk of ending up too fancy–a mailing list discussion recently made the comment that Java hits a sweet spot of being simple enough to just glance at and understand, without having to know all of the concise DSL-enabling syntax tricks of Ruby/Groovy.

Nonetheless, if done right, I think macros all the way down would be very cool.

The IBM JDK is Awesome

2009-04-29T00:00:00-07:00

The IBM JDK is Awesome

Insofar as its J9 JRE supports adding methods to classes at runtime. For me, this is a real boon for productivity.

(Edit: To clarify, I’m talking about editing source code while debugging and having changes applied by “hot swapping” classes in the running JVM without having to restart. Not the Ruby-style meta-programming of modifying classes at runtime.)

I don’t understand why Sun has not fixed this in their JREs, see bug 4910812, to bring Java development that much closer to the Smalltalk “always-running” ideal I’ve heard Smalltalkers wax poetic about.

If you haven’t voted for 4910812, please go do so. It has only 379 votes, which seems surprisingly low for the number of developers whose productivity would be positively effected by it being implemented. I remember seeing a “vote 4910812” meme go around awhile ago, but it must not have caught on.

Compared to the IBM JDK, I generally prefer the Sun JDK because it:

Seams less finicky (which is very subjective, I know)
Ships with the source code for its Java class library (which IBM’s JDK does not)–not that I read Java class library source code all day, but I flinch every time the “unattached source” view pops up in Eclipse
Is faster than the J9 JRE in the one micro benchmark I ran–while recording stats for bindgen, I was confused about why it was suddenly so slow, but it turned out I had switched my workspace preferences to the IBM JDK. Switching back to the Sun JDK restored the performance numbers to their previous values.

But I can deal with these in my development environment to get the awesomeness of the J9 JRE adding methods without restarting.

I’ve tried other JDKs, like BEA/Oracle’s JRockit, Apache’s Harmony, but none of them do hot method adding like IBM’s J9. I was surprised because I’ve always heard good things about JRockit, and Harmony has some sort of access to J9, but neither have pulled it off yet.

I added small entry about the IBM JDK to Joist’s Eclipse Tips page if you’re interested in how to get it/set it up, though it is pretty easy.

One of these days I’ll play with ZeroTurnaround, but having the JRE support it natively just seems cleaner.

Ivy is Useful

2009-04-23T00:00:00-07:00

Ivy is Useful

After being burned by Maven, I’ve shunned any sort of dependency management solution that is not just checking jars into the SCM.

However, I finally ran into a “parent-with-sub-project” type of arrangement in Joist, and so needed a way to locally publish SNAPSHOT/in-progress jars for the subsequent builds to find them.

After hacking around with my own Ant-based home directory jar cache, I decided to kick Ivy’s tires, and I’ve been quite pleased.

Here’s a few things I’ve learned:

IvyDE rocks, especially being able to recognize other open Eclipse projects and put them on the classpath instead of the cached SNAPSHOT jars, so now you can just hit save and not have to worry about updating jars.

You have to enable this in Java Build Path, Libraries, ivy.xml, Advanced, check Resolve dependencies in workspace.
IvyDE is still immature–the ivy.xml has to resolve of its dependencies perfectly or else you are kind of screwed. It’s best to get you ivy.xml, ivysettings.xml working with Ant first, then try Eclipse and IvyDE.

Opening/closing the Eclipse project seems like the best way to get IvyDE to “try again”.

I use a small variation of the Ivy documentation’s bootstrapping logic to auto-install Ivy (and JSch) into ~/.ivy2 so that Ant users do not need to download it by hand

<project name="ivybootstrap" xmlns:ivy="antlib:org.apache.ivy.ant">
  <!--
  The "ivy.bootstrap" target ensures ivy and JSCH are downloaded and installed
  in the user's $HOME/.ivy2 directory so we can implicitly taskdef them into
  this ant context without messing with the $ANT_HOME/lib directory or
  otherwise having the user explicitly go download ivy.
  -->

  <property name="ivy.jar.version" value="2.0.0"/>
  <property name="ivy.jar.name" value="ivy-${ivy.jar.version}.jar"/>
  <property name="ivy.home" value="${user.home}/.ivy2"/>
  <available property="ivy.installed" file="${ivy.home}/${ivy.jar.name}"/>

  <property name="jsch.jar.version" value="0.1.29"/>
  <property name="jsch.jar.name" value="jsch-${jsch.jar.version}.jar"/>
  <available property="jsch.installed" file="${ivy.home}/${jsch.jar.name}"/>

  <target name="ivy.install" unless="ivy.installed">
    <mkdir dir="${ivy.home}"/>
    <get src="http://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.jar.version}/${ivy.jar.name}" dest="${ivy.home}/${ivy.jar.name}"/>
  </target>

  <target name="jsch.install" unless="jsch.installed">
    <get src="http://repo1.maven.org/maven2/jsch/jsch/${jsch.jar.version}/${jsch.jar.name}" dest="${ivy.home}/${jsch.jar.name}"/>
  </target>

  <target name="ivy.bootstrap" depends="ivy.install,jsch.install" unless="ivy.bootstrapped">
    <taskdef resource="org/apache/ivy/ant/antlib.xml" uri="antlib:org.apache.ivy.ant" classpath="${ivy.home}/${ivy.jar.name};${ivy.home}/${jsch.jar.name}"/>
    <property name="ivy.bootstrapped" value="true"/> <!-- Avoid re-bootstrapping because it causes classloader issues. -->
  </target>
</project>

The default settings gave me a fit trying to get SNAPSHOTs to work–Ivy is pretty insistent about caching as much as it possibly can.

Which is cool, but it grew annoying when it would not check the local repo, ~/.ivy2/local, for a newly-published SNAPSHOT just because a SNAPSHOT already existed in the cache, ~/.ivy2/cache.

I ended up using a local-snapshot resolver to bust through:

<ivysettings>
  <settings defaultResolver="default"/>
  <include url="${ivy.default.settings.dir}/ivysettings-public.xml"/>
  <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
  <resolvers>
    <!-- Copy/paste from ivysettings-local.xml with with changingPattern to bust the cache for snapshots. -->
    <filesystem name="local-snapshot" changingPattern=".*SNAPSHOT">
      <ivy pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" />
      <artifact pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
    </filesystem>

    <!-- Repeating the changingPattern incantation here is very important. -->
    <chain name="default" changingPattern=".*SNAPSHOT">
      <resolver ref="local-snapshot"/>
      <resolver ref="public"/>
    </chain>
  </resolvers>
</ivysettings>

Update: I previously had checkmodified=true set on both localhost-snapshot and chain resolvers, however, I don’t believe this is required.

Overall I’ve found Ivy pleasant and look forward to future releases, especially of IvyDE.

Old School Bell Trick

2009-02-19T00:00:00-08:00

Old School Bell Trick

I’m running test cases from the console a lot lately. Besides missing Eclipse, my productivity has dropped as I’ll task switch to something else while the tests run, and I typically only notice the tests have completed after my other supposedly-parallel task hits an interrupt.

To help with this, I’m using an old bell script I had laying around. I came across it awhile ago, and it is pretty simple, but I thought it might be worth rehashing the trick for others finding themselves on the command line lately.

It looks like:

#!/bin/sh
echo ^G

Where ^G is not two literal characters ^ and G, but a single control character BEL. How you enter BEL depends on your editor–in vim, you do Ctrl-V Ctrl-G in insert mode.

If you chmod u+x bell and then just run bell from the command line, you should hear a “ding” system bell.

Now when running tests, I do:

grails test-app ; bell

Switch away, and then I can come back immediately when I hear the “ding”. The pre-emptive task switch makes me feel more productive anyway.

Grails Stacktraces

2009-02-16T00:00:00-08:00

Grails Stacktraces

One of the many joys of working in Grails is the stack traces.

The first is 590 lines. The second is 597 lines. However, the second cheats and includes 59 lines of “caused by” stack traces. From a purity standpoint, the first is all just one stack, so is the current winner.

The solution to each?

Clean and restart.

In that regard, Grails exceptions are nicer than Spring exceptions–Spring exceptions don’t go away after a clean/restart.

[253826] mortbay.log Nested in org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.NullPointerException: Cannot invoke method count() on null object:
java.lang.NullPointerException: Cannot invoke method count() on null object
    at org.codehaus.groovy.runtime.NullObject.invokeMethod(NullObject.java:77)
    at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:743)
    at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:720)
    at org.codehaus.groovy.runtime.callsite.NullCallSite.call(NullCallSite.java:17)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at BootStrap$_populateBootstrapData_closure490.doCall(BootStrap.groovy:788)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at org.codehaus.groovy.runtime.DefaultGroovyMethods.callClosureForMapEntry(DefaultGroovyMethods.java:1911)
    at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1184)
    at org.codehaus.groovy.runtime.dgm$88.invoke(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:270)
    at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at BootStrap.populateBootstrapData(BootStrap.groovy:786)
    at BootStrap.this$2$populateBootstrapData(BootStrap.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:146)
    at BootStrap$_closure1.doCall(BootStrap.groovy:9)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at org.codehaus.groovy.grails.commons.DefaultGrailsBootstrapClass.callInit(DefaultGrailsBootstrapClass.java:43)
    at org.codehaus.groovy.grails.web.context.GrailsConfigUtils.executeGrailsBootstraps(GrailsConfigUtils.java:64)
    at org.codehaus.groovy.grails.web.context.GrailsContextLoader.createWebApplicationContext(GrailsContextLoader.java:69)
    at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
    at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
    at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
    at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
    at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
    at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
    at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
    at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
    at org.mortbay.jetty.Server.doStart(Server.java:222)
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
    at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at org.codehaus.groovy.grails.web.container.JettyServer.startServer(JettyServer.groovy:146)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.groovy.grails.web.container.JettyServer.start(JettyServer.groovy:106)
    at grails.web.container.EmbeddableServer$start.call(Unknown Source)
    at _GrailsRun_groovy$_run_closure6_closure12.doCall(_GrailsRun_groovy:145)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at _GrailsRun_groovy$_run_closure6_closure12.doCall(_GrailsRun_groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at groovy.lang.Closure$call.call(Unknown Source)
    at _GrailsSettings_groovy$_run_closure10.doCall(_GrailsSettings_groovy:268)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at _GrailsRun_groovy$_run_closure6.doCall(_GrailsRun_groovy:140)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:72)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at _GrailsRun_groovy.runInline(_GrailsRun_groovy:117)
    at _GrailsRun_groovy.this$4$runInline(_GrailsRun_groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at _GrailsRun_groovy$_run_closure1.doCall(_GrailsRun_groovy:63)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:292)
    at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy:152)
    at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.gant.GantBinding.withTargetEvent(GantBinding.groovy:90)
    at org.codehaus.gant.GantBinding.this$4$withTargetEvent(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:718)
    at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:158)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy:152)
    at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:162)
    at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:146)
    at _GrailsRun_groovy$_run_closure8_closure14.doCall(_GrailsRun_groovy:235)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at _GrailsRun_groovy$_run_closure8_closure14.doCall(_GrailsRun_groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at _GrailsPackage_groovy$_run_closure7.doCall(_GrailsPackage_groovy:259)
    at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at _GrailsRun_groovy$_run_closure8.doCall(_GrailsRun_groovy:224)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:292)
    at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy:152)
    at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.gant.GantBinding.withTargetEvent(GantBinding.groovy:90)
    at org.codehaus.gant.GantBinding.this$4$withTargetEvent(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:718)
    at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:158)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy:152)
    at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:146)
    at RunApp$_run_closure1.doCall(RunApp.groovy:35)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:292)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy:152)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at org.codehaus.gant.GantBinding.withTargetEvent(GantBinding.groovy:90)
    at org.codehaus.gant.GantBinding.this$4$withTargetEvent(GantBinding.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:718)
    at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:158)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy:152)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:292)
    at groovy.lang.Closure$call$0.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at gant.Gant.withBuildListeners(Gant.groovy:344)
    at gant.Gant.this$2$withBuildListeners(Gant.groovy)
    at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at gant.Gant.dispatch(Gant.groovy:334)
    at gant.Gant.this$2$dispatch(Gant.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:720)
    at gant.Gant.invokeMethod(Gant.groovy)
    at groovy.lang.GroovyObject$invokeMethod.callCurrent(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at gant.Gant.processTargets(Gant.groovy:495)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at gant.Gant.processTargets(Gant.groovy:480)
    at org.codehaus.groovy.grails.cli.GrailsScriptRunner.callPluginOrGrailsScript(GrailsScriptRunner.java:397)
    at org.codehaus.groovy.grails.cli.GrailsScriptRunner.executeCommand(GrailsScriptRunner.java:270)
    at org.codehaus.groovy.grails.cli.GrailsScriptRunner.main(GrailsScriptRunner.java:106)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.grails.cli.support.GrailsStarter.rootLoader(GrailsStarter.java:157)
    at org.codehaus.groovy.grails.cli.support.GrailsStarter.main(GrailsStarter.java:182)

[17] mortbay.log Failed startup of context org.mortbay.jetty.webapp.WebAppContext@38859d{/proxibid,C:\svn\proxibid\juggernaut/web-app}
org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.NullPointerException
    at org.codehaus.groovy.grails.web.context.GrailsContextLoader.createWebApplicationContext(GrailsContextLoader.java:74)
    at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
    at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
    at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
    at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
    at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
    at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
    at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
    at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
    at org.mortbay.jetty.Server.doStart(Server.java:222)
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
    at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at org.codehaus.groovy.grails.web.container.JettyServer.startServer(JettyServer.groovy:146)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.groovy.grails.web.container.JettyServer.start(JettyServer.groovy:106)
    at grails.web.container.EmbeddableServer$start.call(Unknown Source)
    at RunApp$_run_closure6_closure12.doCall(RunApp:145)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at RunApp$_run_closure6_closure12.doCall(RunApp)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at groovy.lang.Closure$call.call(Unknown Source)
    at _GrailsSettings_groovy$_run_closure10.doCall(_GrailsSettings_groovy:268)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at RunApp$_run_closure6.doCall(RunApp:140)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:72)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at RunApp.runInline(RunApp:117)
    at RunApp.this$4$runInline(RunApp)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at RunApp$_run_closure1.doCall(RunApp:63)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:292)
    at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy:152)
    at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.gant.GantBinding.withTargetEvent(GantBinding.groovy:90)
    at org.codehaus.gant.GantBinding.this$4$withTargetEvent(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:718)
    at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:158)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy:152)
    at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:162)
    at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:146)
    at RunApp$_run_closure8_closure14.doCall(RunApp:235)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at RunApp$_run_closure8_closure14.doCall(RunApp)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at _GrailsPackage_groovy$_run_closure7.doCall(_GrailsPackage_groovy:259)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at RunApp$_run_closure8.doCall(RunApp:224)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:292)
    at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy:152)
    at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.gant.GantBinding.withTargetEvent(GantBinding.groovy:90)
    at org.codehaus.gant.GantBinding.this$4$withTargetEvent(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:718)
    at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:158)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy:152)
    at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy)
    at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Script.invokeMethod(Script.java:87)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:146)
    at RunApp$_run_closure1.doCall(RunApp.groovy:35)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:292)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:142)
    at org.codehaus.gant.GantMetaClass.invokeMethod(GantMetaClass.java:127)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:39)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy:152)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8_closure9.doCall(GantBinding.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at org.codehaus.gant.GantBinding.withTargetEvent(GantBinding.groovy:90)
    at org.codehaus.gant.GantBinding.this$4$withTargetEvent(GantBinding.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1009)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:718)
    at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
    at groovy.lang.MetaClassImpl.invokeMethodOnGroovyObject(MetaClassImpl.java:1119)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1023)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:158)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy:152)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at org.codehaus.gant.GantBinding$_initializeGantBinding_closure4_closure8.doCall(GantBinding.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:292)
    at groovy.lang.Closure$call$0.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
    at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.Closure.call(Closure.java:279)
    at groovy.lang.Closure.call(Closure.java:274)
    at groovy.lang.Closure$call.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
    at gant.Gant.withBuildListeners(Gant.groovy:344)
    at gant.Gant.this$2$withBuildListeners(Gant.groovy)
    at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
    at gant.Gant.dispatch(Gant.groovy:334)
    at gant.Gant.this$2$dispatch(Gant.groovy)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
    at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:720)
    at gant.Gant.invokeMethod(Gant.groovy)
    at groovy.lang.GroovyObject$invokeMethod.callCurrent(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at gant.Gant.processTargets(Gant.groovy:495)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
    at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
    at gant.Gant.processTargets(Gant.groovy:480)
    at org.codehaus.groovy.grails.cli.GrailsScriptRunner.callPluginOrGrailsScript(GrailsScriptRunner.java:397)
    at org.codehaus.groovy.grails.cli.GrailsScriptRunner.executeCommand(GrailsScriptRunner.java:270)
    at org.codehaus.groovy.grails.cli.GrailsScriptRunner.main(GrailsScriptRunner.java:106)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.groovy.grails.cli.support.GrailsStarter.rootLoader(GrailsStarter.java:157)
    at org.codehaus.groovy.grails.cli.support.GrailsStarter.main(GrailsStarter.java:182)
Caused by: org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.NullPointerException
    at grails.web.container.EmbeddableServer$start.call(Unknown Source)
    at RunApp$_run_closure6_closure12.doCall(RunApp:145)
    at RunApp$_run_closure6_closure12.doCall(RunApp)
    at _GrailsSettings_groovy$_run_closure10.doCall(_GrailsSettings_groovy:268)
    at RunApp$_run_closure6.doCall(RunApp:140)
    at RunApp.runInline(RunApp:117)
    at RunApp.this$4$runInline(RunApp)
    at RunApp$_run_closure1.doCall(RunApp:63)
    at RunApp$_run_closure8_closure14.doCall(RunApp:235)
    at RunApp$_run_closure8_closure14.doCall(RunApp)
    at _GrailsPackage_groovy$_run_closure7.doCall(_GrailsPackage_groovy:259)
    at RunApp$_run_closure8.doCall(RunApp:224)
    at RunApp$_run_closure1.doCall(RunApp.groovy:35)
    at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
    at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
    at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
    at gant.Gant.withBuildListeners(Gant.groovy:344)
    at gant.Gant.this$2$withBuildListeners(Gant.groovy)
    at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
    at gant.Gant.dispatch(Gant.groovy:334)
    at gant.Gant.this$2$dispatch(Gant.groovy)
    at gant.Gant.invokeMethod(Gant.groovy)
    at gant.Gant.processTargets(Gant.groovy:495)
    at gant.Gant.processTargets(Gant.groovy:480)
Caused by: java.lang.NullPointerException
    at BootStrap$_populateBootstrapData_closure508.doCall(BootStrap.groovy:26)
    at BootStrap.populateBootstrapData(BootStrap.groovy:21)
    at BootStrap$_closure1.doCall(BootStrap.groovy:11)
    ... 24 more
[21] mortbay.log Nested in org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.NullPointerException:
java.lang.NullPointerException
    at BootStrap$_populateBootstrapData_closure508.doCall(BootStrap.groovy:26)
    at BootStrap.populateBootstrapData(BootStrap.groovy:21)
    at BootStrap$_closure1.doCall(BootStrap.groovy:11)
    at grails.web.container.EmbeddableServer$start.call(Unknown Source)
    at RunApp$_run_closure6_closure12.doCall(RunApp:145)
    at RunApp$_run_closure6_closure12.doCall(RunApp)
    at _GrailsSettings_groovy$_run_closure10.doCall(_GrailsSettings_groovy:268)
    at RunApp$_run_closure6.doCall(RunApp:140)
    at RunApp.runInline(RunApp:117)
    at RunApp.this$4$runInline(RunApp)
    at RunApp$_run_closure1.doCall(RunApp:63)
    at RunApp$_run_closure8_closure14.doCall(RunApp:235)
    at RunApp$_run_closure8_closure14.doCall(RunApp)
    at _GrailsPackage_groovy$_run_closure7.doCall(_GrailsPackage_groovy:259)
    at RunApp$_run_closure8.doCall(RunApp:224)
    at RunApp$_run_closure1.doCall(RunApp.groovy:35)
    at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
    at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
    at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
    at gant.Gant.withBuildListeners(Gant.groovy:344)
    at gant.Gant.this$2$withBuildListeners(Gant.groovy)
    at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
    at gant.Gant.dispatch(Gant.groovy:334)
    at gant.Gant.this$2$dispatch(Gant.groovy)
    at gant.Gant.invokeMethod(Gant.groovy)
    at gant.Gant.processTargets(Gant.groovy:495)
    at gant.Gant.processTargets(Gant.groovy:480)

Boojay is Promising

2009-02-06T00:00:00-08:00

Boojay is Promising

Rodrigo B. de Oliveira has a new post up about his progress getting boo running in Eclipse and compiling to the JVM. This is very cool stuff.

Boo has both a wrist-friendly syntax and macro meta-programming abilities, but in a type-safe language without all the “gee, what does this code do at runtime again?” ambiguities of dynamic languages like Groovy and Ruby.

Okay, yeah, boo can’t do method_missing, but I don’t want that anyway. Closures, type inference, and macros? That’s all the magic I want and need.

If you watch the video in his post, it even shows a dual view of the “regular” macro/type inferred source code that you actually type, then you can press a shortcut and see a read-only view of the “processed” source code after it has been expanded by macros and had the types filled in. I.e. you can easily see exactly what the code you write is going to end up as after the magic is applied.

Try doing that in the dynamic language of your choice.

I tried to get Rodrigo’s example working on my Windows box, and it seems to be really close, but I cannot get the Mono Eclipse plugin to find my local Mono runtime, so nothing is compiling right now. But I’m not too worried–it’s not ready to go just yet, but the progress is very impressive.

Boo has also impressed me with its longevity–back in the early days, it seemed like a very cool .NET hobby language that would probably fade after a few releases. IIRC, it even had an edge on C# 1.0 for awhile. Then Microsoft blew everyone away with the C# 2.0 and 3.0 releases, but, contrary to Java, boo is steadily catching up.

In my opinion, boojay is currently the best “Java++” contender. I can’t wait for a few more releases to go by to see where it goes.

JavaFX Decompiled

2009-01-18T00:00:00-08:00

JavaFX Decompiled

While lamenting the lack of BGGA closures in Java, I came across a poll that had some interesting JavaFX comments from a guy named Bryan:

JavaFX Script is Java++ ... as general purpose as Java itself ... type inference ... closures ... The primary language on the JVM in the future will be JavaFX Script. New language features will go there. Java will not accept new features.

Okay, my interest was piqued. Besides JavaFX being a UI toolkit, turns out JavaFX Script is a new programming language as well. Would Sun really choose an entirely different language to evolve Java? They’ve done sillier things, I suppose, so, maybe?

Looking through some tutorials, JavaFX seems like it might actually work–it even has a crazy bind keyword for data binding. Given my bindgen hobby project, I was very interested to see how they implemented first-class data binding.

Tutorials only go so far though, so I downloaded the JavaFX SDK, made sure I still had the very handy Jad decompiler around, and thought I’d see what was really going on.

After a few tests, I ended up with foo.fx:

var num = 1;
var x = bind f(num);

println("num={num}, x={x}");

num = 3;
println("num={num}, x={x}");

function f(arg:Integer) {
    return arg + 1;
}

Running javafxc foo.fx to compile it and then javafx foo to run it produces this output:

num=1, x=2
num=3, x=4

Okay, cool, the f(num) function is being lazily bound to x, such that x changes with num.

How’d they do that?

Run jad foo.class and we get:

import com.sun.javafx.runtime.*;
import com.sun.javafx.runtime.location.*;
import com.sun.javafx.runtime.sequence.Sequence;
import javafx.lang.Builtins;

public class foo implements Intf, FXObject {
    public static final IntVariable $num = IntVariable.make();
    public static final IntVariable $x = IntVariable.make();

    public static Object javafx$run$(Sequence sequence) {
        $num.setAsInt(1);
        $x.bind(IntVariable.make(false, new IntBindingExpression() {
            private IntLocation arg$0;
            { arg$0 = foo.$num; }
            protected Location[] getStaticDependents() {
                return (new Location[] { arg$0 });
            }
            public int computeValue() {
                return foo.f(arg$0.getAsInt());
            }
        }, new Location[0]));
        Builtins.println(String.format("num=%s, x=%s", new Object[] {
            Integer.valueOf($num.getAsInt()), Integer.valueOf($x.getAsInt())
        }));
        $num.setAsInt(3);
        Builtins.println(String.format("num=%s, x=%s", new Object[] {
            Integer.valueOf($num.getAsInt()), Integer.valueOf($x.getAsInt())
        }));
        return null;
    }

    public static int f(int i) {
        return i + 1;
    }

    public void initialize$() {
        addTriggers$(this);
        userInit$(this);
        postInit$(this);
        InitHelper.finish(new AbstractVariable[0]);
    }

    public static void addTriggers$(Intf intf) {
    }

    public foo() {
        this(false);
        initialize$();
    }

    public foo(boolean flag) {
    }

    public static void userInit$(Intf intf) {
    }

    public static void postInit$(Intf intf) {
    }

    public static void main(String args[]) throws Throwable {
        Entry.start(foo, args);
    }
}

A lot of syntactic sugar is going on here.

The biggest surprise is that variables in JavaFX are not variables in Java, but instead are wrapper objects, e.g. IntVariable.

This allows the binding to work, where x is not set to a value, but instead set to an anonymous inner class that holds the reference to num for late-binding x.

Coincidentally, this is similar to bindgen’s approach–it also uses anonymous inner classes that are initialized with references to late-bind the evaluation.

What is also surprising is all of the addTriggers, postInit, userInit, etc. in the output.

I’m not sure what to make of this. This is where I start doubting JavaFX Script as the next general purpose language.

This is a bit hypocritical of me–I pine for the “good” magic of extension methods, local variable type inference, and BGGA closures, but I start to cringe and label it “bad” magic when int is now an IntVariable and my class has a bunch of cruft it in. It seems like meta-level semantics that I was not expecting.

I trust these meta-level semantics are perfect for leveraging JavaFX Script in the JavaFX UI framework, but to me it disqualifies JavaFX as a “Java++” contender.

It seems like all of the “Java++” contenders (JavaFX, Groovy, and Scala) add their own meta-level semantics on top of Java. They need the meta-level to do the dynamic, trait, etc., cool features, but, to me, it just adds complexity and a leaky abstraction that I’d rather not deal with.

Enterprise software is hard enough and bad enough as it is–I can’t imagine the average programmer also having to deal with, say, Scala’s case classes, or traits, or whatever other nifty tricks the current “Java++” contenders layer on top of Java.

The simplicity of Java is a real virtue. I assert that any language that adds its own “meta-level semantics” on top of Java is not going to replace it.

My current rule of thumb: if you can decompile a “Java++” contender’s code into the regular Java syntax, and have it look pretty darn close to what you’d type out by hand, then you’ve found your true “Java++” language.

War-less Development with Jetty

2009-01-10T00:00:00-08:00

War-less Development with Jetty

Update: see the jtty project for a single jar based on this approach that contains both the Jetty dependencies and a generic bootstrap class.

Reviewing my posts, most of them are negative rants, so I figured I should contribute something positive every now and then.

One of my favorite hacks for Java web development is using Jetty for a war-less development environment to get automatic updating of classes/JSPs while debugging your app. Although limited by the usual JVM limitation of no hot reloading class declaration changes, I’ve nonetheless found this approach to be quick and useful.

Perhaps lots of people use this type of approach already, but I haven’t come across it much.

The idea is to be able to start Jetty as your server against your web project and not have to go through a war step–instead, Jetty will pick up the web.xml, JSPs, etc. directly from your source folder, like an exploded war deployment.

This assumes you have a war-like directory structure of:

yourapp
  - WebContent
    - ...content...
    - WEB-INF
      - web.xml

If for whatever reason your project’s source tree doesn’t match this, or needs several build steps to generate/massage a web.xml file, then YMMV.

Instead of a standard jetty script, I typically create a Jetty wrapper class directly in the project (either src/main or src/bootstrap) that resembles:

public class Jetty {
    private static final Server SERVER = new Server();

    public static void main(String[] args) {
        String webapp = "./WebContent";
        if (args.length > 0) {
            webapp = args[0];
        }

        WebAppContext app = new WebAppContext();
        app.setContextPath("/yourapp");
        app.setWar(webapp);
        // Avoid the taglib configuration because its a PITA if you don't have a net connection
        app.setConfigurationClasses(new String[] { WebInfConfiguration.class.getName(), WebXmlConfiguration.class.getName() });
        app.setParentLoaderPriority(true);

        // We explicitly use the SocketConnector because the SelectChannelConnector locks files
        Connector connector = new SocketConnector();
        connector.setPort(Integer.parseInt(System.getProperty("jetty.port", "8080")));
        connector.setMaxIdleTime(60000);

        Jetty.SERVER.setConnectors(new Connector[] { connector });
        Jetty.SERVER.setHandlers(new Handler[] { app });
        Jetty.SERVER.setAttribute("org.mortbay.jetty.Request.maxFormContentSize", 0);
        Jetty.SERVER.setStopAtShutdown(true);

        try {
            Jetty.SERVER.start();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

And run this Java class from Eclipse with a Jetty.launch target. You’ll need jetty-6.X.jar and jetty-util-6.X.jar on your classpath–either in lib/main or a lib/bootstrap as you won’t need the Jetty jars ending up in your production war.

Jetty will start up, see your WebContent/WEB-INF/web.xml, and fire up your servlet classes.

Now the interesting part is how it finds the servlet classes–typically there is the WEB-INF/lib, WEB-INF/classes, etc., which works great for production, but you’re not going to have those without going through a war step.

But since Eclipse (or IDEA or whatever) is running the Jetty class as a Java Application, it will put all of your project’s classes and libraries on the application loader classpath, much like it would if it were running your JUnit tests.

So, we’re cheating a bit, as Jetty will get your classes from the same application classloader it finds its own classes on instead of the usual WebappClassloader, but in practice I’ve found this is not a big deal.

Plus, it allows hot code reloading and editing of JSP files (if you have to use them) and seeing the changes automatically in your app without a war/restart delay.

Now if only Sun would fix hot code replacement to not blow up when you change classes. I know nothing about JVM internals, so I’ll trust them that this is hard, but, please, pretty please, even if enabled with a debug-only, hurts-perf-25%, never-use-this-in-production flag?

Also, if you need JNDI resources, you have a few alternatives. One app I worked on did not rely on the container for anything (it used its own c3p0 pool), so this was no problem. Another app did want the DataSource in JNDI, so we wrote a FakeJndiFactory that returned a FakeContext–it’s kind of stupid, FakeContext has a 10-15 methods in it, but only lookup ever seems to be called, so we left most of FakeContext’s methods as no-op and had lookup use a static HashMap. Then the project-specific Jetty class just did:

	System.setProperty("java.naming.factory.initial", FakeJndiFactory.class.getName());
	FakeJndiFactory.properties.put("java:comp/env/jdbc/yourapp", FakeDataSource.getDataSource());

Where FakeDataSource was a c3p0-backed data source. If you need more container resources than a DataSource, you’ll have to invent your own ways to mount them in Jetty or else just stay in the container.

The ability to customize the Jetty wrapper class as needed for your project is one of the strengths of this approach, I think. For example, it wouldn’t make much sense for me to make a github project out of this, because I think everyone is best off copy/pasting the 20 or so lines of code and just customizing them as needed to their project.

As alternatives to this war-less Jetty approach, I have seen a few cool reloading hacks like Tapestry 5 live class reloading and JavaRebel’s ZeroTurnaround. They both seem a bit tricky, though I haven’t investigated them as much as I should.

So far, this low tech approach has worked very well on our projects. I hope others like it as well.

Let me know if you have other cool, avoid-server-restart tips.

NamedQuery Proposal

2009-01-06T00:00:00-08:00

NamedQuery Proposal

Recently I ranted about EJB3 @NamedQuery annotations as being a bad use of annotations.

Turns out I was mistaken about the lack of pros–startup-time validation of queries seems like an admirable goal.

However, I would propose a different implementation: instead of the “name” part of the query being in an non-referrable annotation, the annotation should be used solely as a marker on an otherwise pure Java construct. For example:

@Sql
private static final String FIND_FOO = "select * from foo ...";

public List&lt;Foo&gt; findFoo() {
    Query q = em.createQuery(FIND_FOO);
    q.setParameter(...);
    return q.getResultList();
}

This would alleviate my concerns about type-safety and SQL encapsulation, but still allow the EntityManager to find all of the annotated queries on startup for validation.

Until my proposal makes it into EJB4 (haha), I also came across this comment, which seems like an acceptable, though verbose, compromise with the current annotation.

Moving to GitHub Pages

2008-12-20T00:00:00-08:00

Moving to GitHub Pages

WordPress sucks for including code examples. And bulleted lists. And authoring in Opera. So, I’m going with a GitHub page based on:

http://github.com/mojombo/mojombo.github.com/tree/master

It’s cool stuff. No ability to comment, but I don’t get a lot of those anyway. Just email me instead.

NamedQuery Considered Stupid

2008-12-19T00:00:00-08:00

NamedQuery Considered Stupid

I was recently exposed to JPA’s NamedQuery annotation. I cannot imagine a more useless way to store your queries.

(Well…okay, it’s not XML, but still…)

A few examples from Google show the basic syntax:

@Entity
@NamedQuery(
    name="findAllEmployeesByFirstName",
    queryString="SELECT OBJECT(e) FROM Employee e WHERE e.firstName = :firstName")
public class Employee {
}

Then somewhere else, you can do:

Query queryEmployeesByFirstName = em.createNamedQuery("findAllEmployeesByFirstName");
queryEmployeeByFirstName.setParameter("firstName", "John");
Collection employees = queryEmployessByFirstName.getResultList();

(I’m using the first google hit for “JPA @NamedQuery” for the examples.)

I’m confused about the benefits of this annotation-based approach.

If pulling queries out of methods is a must, I would opt for a static final String. This would get you:

Compile time enforcement of the findAllEmployeesByFirstName variable
Ctrl-Shift-G find references in Eclipse
Ability to add a private scope to limit scope of the string

All of these, to me, are huge pros.

Instead, with the annotation, it’s not compile-type checked, you can’t easily find its references, and the “somewhere else” that calls createNamedQuery could be anywhere in your codebase that has access to the EntityManager. Chaos.

The only benefit I can guess about this approach is that you’d get to reuse the findAllEmployeesByFirstName in multiple places without retyping the SQL query. But I fail to see how this is even worth accomplishing–my personal preference is to isolate the query in its own method and then just have multiple people call the method:

public Collection findAllEmployeesByFirstName(String firstName) {
    Query queryEmployeesByFirstName = em.createQuery(
        "SELECT OBJECT(e) FROM Employee e WHERE e.firstName = :firstName");
    queryEmployeeByFirstName.setParameter("firstName", "John");
    return queryEmployessByFirstName.getResultList();
}

And there you go, reuse and encapsulation all in one go, and all Plain Old Java.

But, alas, JPA and NamedQueries are a standard, and so countless Java programmers will think they’re following best practice by just doing what the standards/examples/books say they should instead of stopping to think critically about it.

(Sun, if you’re reading this, can you please work on something more constructive than JPA…like catching Java up to C#? I don’t even need LINQ…just lambdas and static extension methods, that’s all I ask.)

To me this is just yet another example of annotations being abused as a non-XML configuration panacea where pure Java constructs would work just fine.

Update: Turns out I’m uneducated, named queries can be on-startup verified against the database–cool, but that’s still wrong.

WEP sucks

2008-11-26T00:00:00-08:00

WEP sucks

All due to my own stupidity, but WEP led to several hours of frustration today connecting various devices to a Qwest M1000/W1000 modem/gateway:

64-bit hex keys make it all too easy to transpose digits–I would have noticed a transposed passwrod a lot sooner.
While typing in the WEP key, I mistakenly thought this constituted a “shared key” and selected as such from the Authorization Type menu. Turns out, no, the correct Authorization Type is “Open System”. “Open System” even though I’m using a key? Hm. Okay.

That had me stuck for quite awhile until I hit the “flip random settings until it works” stage.

Especially so because I was configuring a PhotoVu that requires 2 reboots for every settings change. 1st reboot is with a CAT5 plugged into the router to change the settings via its web admin interface, 2nd reboot is without the CAT5 to kick it into wireless mode and see what happens. When it doesn’t work, repeat. The PhotoVu is slick, but a “test wireless connection” button would be very, very helpful.

More Evil Than Spring

2008-11-21T00:00:00-08:00

More Evil Than Spring

As if Spring does not give us enough interfaces: Qi4j.

And one of its core principles: “Classes are dead, long live interfaces”.

Not this again.

Perhaps the author can, as I would hope Spring’s authors can as well, build supremely elegant systems with their tools.

But for the rest of us, it means yet more codebases with tens and tens of interfaces, all of them having only 1 implementation, all in the name of future flexibility/injection/proxy/something magic.

You never know when our Employee class is going to need to mixin some Claim functionality, so we better just support it now. After we go 1.0 and are in production, we will only be allowed to re-organize mixins, not, you know, just change the model and code as appropriate.

Rather than throwing a bunch of interfaces around up front, I propose we wait until the reuse/proxy/whatever scenario actually happens, and then we’ll deal with it. And when it doesn’t 90% of the time, we all win.

That being said, Qi4j looks technically spiffy. And I’m sure the author makes very judicious use of interfaces. I just don’t look forward to working on any Qi4j codebase that isn’t written by him.

Draconian Overlord

todomvc in Tessell

todomvc in Tessell

Demo and Code

Project Layout

Models

Views

Presenters

Testing

Comparison with JS Frameworks

Templates

No Selectors

Disclaimers

Sane AJAX Testing in Selenium

Sane AJAX Testing in Selenium

Reintroduce “page loading”

Post-Action Waiting

Page Objects

Disclaimer

Why No One Uses Scala's Structural Typing

Why No One Uses Scala’s Structural Typing

A GWT Developer's Reaction to Dart

A GWT Developer’s Reaction to Dart

Typing and Tools

A Better DevMode

A Better GWT

Disclaimers

Modern Code Generation Talk

Modern Code Generation Talk

Command Query Responsibility Segregation with S3 and JSON

Command Query Responsibility Segregation with S3 and JSON

Prior Approach: Cached JPA Calls

Potential “Big Data” Approaches

Realization: MySQL is Fine, Fix the Cache

A Few Wrinkles: Real-Time Reads and Writes

Scalatra Servlet Example

Background Writes

tl;dr We Implemented Command Query Responsibility Segregation

Framework-less Dependency Injection

Framework-less Dependency Injection

Overview

Example

Potential Approaches

AppRegistry Approach

Pros/Cons

Other Alternatives

Conclusion

Preferred Build Setup

Preferred Build Setup

Requirements

Ant vs. Buildr

Aether Possibilities

Example

ivy.xml

ivysettings.xml

.classpath

buildfile

That’s It

Why I'm a Static Typing Bigot

Why I’m a Static Typing Bigot

What I Like About Static Typing

What I Don’t Like About Static Typing

Other Notes

Over Emphasis

GWT Handler Registrations

GWT Handler Registrations

Is Calling removeHandler() Required?

What To Think About

Be Proactive

Doubting GMail-style Loading Indicators

Doubting GMail-style Loading Indicators

Joist Tip–Fast Database Resets

Joist Tip–Fast Database Resets

Abusing Transactions for Resetting Test Data

Domain-Level Resetting Test Data

Database-Level Resetting Test Data

Postgres Implementation

MySQL Implementation

Time Savings

Limited Applicability

`ivy.xml`

`ivysettings.xml`

`.classpath`

`buildfile`

Is Calling `removeHandler()` Required?

`ivysettings.xml`

`ivy.xml`

`build.xml`

`n+1` Selects

`sourcegen`

Getting `gwt-mpv-apt`

`HasXxx` vs. `IsXxx`