Tembrel's Tome

Deploying Restlet components in Elastic Beanstalk

2012-01-23T20:15:00.000-05:00

I spent some time finding a way to deploy a Restlet component in ElasticBeanstalk without giving up the option of deploying it as a standard Java executable for local development and testing. People have expressed interest in seeing the approach, but I don't have the time to create a full-fledged framework, so I've extracted the following template instead (links to code embedded in the prose). Just copy to your own environment, changing package and class names as you see fit, add your Guice Modules, define your Restlet applications and resources, and you should be able to run the resulting component both standalone and (by bundling everything in a WAR) via Elastic Beanstalk. I make no claims that this code is correct, that it is safe to use, or even that it will compile. You have to read it, compile it, and judge for yourself.

The code depends on Restlet, Guice, and Rocoto. I've included commented-out code that uses the Restlet-Guice extension, which is in incubator status in the Restlet codebase.

The Main class is a GuiceServletContextListener and it has a main method. When you run com.example.server.Main from the command line, the GuiceServletContextListener methods are ignored. When you deploy a WAR that contains the associated web.xml file, the main routine is never called. You can inject the current DeploymentMode into your classes if you want to change behavior depending whether you're running standalone or in Elastic Beanstalk (i.e., as a servlet).

The MainComponent class is where your Restlet component logic goes. Its lifecycle is managed by the MainService class, which is where you can manage other services with lifecycles. (If you use JClouds BlobStores, for example, you can ensure that a singleton BlobStoreContext is closed when the MainService is stopped. Another example: a LifecycleService for the Hazelcast data grid) There is some trickiness to handling shutdown in various cases; make sure you nest try-finally clauses so that every one of your services gets a chance to shut down even if the previous shutdown attempt throws an exception or error.

The MainServletModule and MainServlet classes deal with the details of embedding the component in a servlet (which is necessary in order to use Elastic Beanstalk).

AwsCredentialsModule is an example of how you can inject AWS credentials from either of two sources: system properties defined on the command line (or via Ant invocation) and system properties defined by an Elastic Beanstalk configuration.

The flow of control when running standalone is that the main routine creates an instance of Main with the STANDALONE deployment mode, creates the injector, gets the singleton MainService, and starts it, which causes (in a different thread), the MainComponent to be started.

The flow of control when running as a servlet is that a default instance of Main is created (due to the web.xml directive) and gets the SERVLET deployment mode. Its contextInitialized call creates the injector, which injects the MainService and starts it, causing (in a different thread), the MainComponent to be started.

Files:

web.xml - web application descriptor
Main - has main() routine for standalone; is context listener for servlet mode
MainComponent - the Restlet component we want to be able to deploy in both modes
MainService - manages lifecycle of MainComponent and (optionally) other services
MainServletModule - included in module list in Main; configures Restlet-Servlet bridge
MainServlet - injects MainComponent and returns it as the component it wraps
DeploymentMode - enum with two values: STANDALONE and SERVLET
AwsCredentialsModule - example of passing AWS credentials for binding with @Named

Overriding common bindings with test bindings in Jukito

2011-12-06T10:44:00.001-05:00

This post is about how to get common bindings for Jukito tests without having to write too much boilerplate. (Obviously not a general interest post!)

A recent conversation on the Jukito newsgroup discusses various proposals for reducing the amount of boilerplate involved in setting up common bindings for tests that have a common superclass. I've noticed that the underlying assumption to these proposals is that bindings in modules are inheritable in the same way that methods are, but that's not generally the case. You can override methods by defining a new version in a subclass, but to override the bindings in a module, you need to use Modules.override, which doesn't work via inheritance.

I've written a template to illustrate how to override with test bindings; it uses Jukito 1.1 as is:

http://pastebin.com/BLQnMEqx

The key is to declare a static method in a common test superclass that returns a single module, which is easy to do with Modules.combine. Then in the concrete test class, use

Modules.override(commonBindings).with(testBindings)

This strikes what I think is the right balance between compactness and clarity: You have one place in the concrete test class that says what the basic bindings are (commonBindings) and what test bindings are being used to override for the purposes of this test (testBindings). There's no hunting around through the inheritance hierarchy for modules with the right characteristics.

Because the Modules.combine/override approach is so simple, the case for adding special Jukito support (based on inheritance alone, annotations alone, or on a combination of inheritance and annotations) for auto-installing commonly-used modules becomes much weaker. Jukito is already pretty magical; it doesn't need to add mystery to its magic.

Java Standards Annoyances

2011-07-20T15:56:00.001-04:00

The Java Standards Annoyances session at OSCON 2011 looks like fun. I wish I could be there.

If I were there, after first expressing congratulations mixed with condolences to Ben Evans and the London Java Community on the election to the EC, I'd probably say that the most important part of building standards is knowing when and what not to standardize. The PMO measures success quantitatively, in terms of numbers of JSR stage transitions, but the inevitable result has been that a lot of the JSRs that made it to final release are junk that should never have been accepted in the first place. The EC actually did one useful thing during my time as a member: It rejected the PFD of a (well-intentioned) JSR that was not ready for prime time.

So talk of "streamlining" the process makes me nervous. I wouldn't want to make it easier to introduce garbage, and I don't trust the EC to be a responsible gatekeeper, nor do I trust the JCP as a whole to provide high-quality feedback during public review; there's too much noise, and it's too easy for a spec lead to ignore substantial criticism.

There are good JSRs. Naturally I think the JSRs on whose EGs I have served are good ones, the most recent being JSR 334 ("Coin"). But I think the enthusiasm and energy of the community should be directed more at building great libraries and frameworks than at getting them accepted as standards.

Resigned from EC

2010-12-07T11:38:00.000-05:00

Today I resigned from the SE/EE Executive Committee of the Java Community Process. I lasted about a year before giving up hope that the ECs would ever do anything meaningful.

The last straw for me was Oracle's failure to address the ambiguous licensing terms in JSRs 336 and 337 (the Java SE7/8 umbrella JSRs) before the EC had to vote on them. At first I abstained, but I was so dismayed by Oracle's silence that I changed my vote to No, joining the Apache Software Foundation and Google.

Several of the other EC members expressed their own disappointment while voting Yes. I'm reasonably certain that the bulk of the Yes votes were due to contractual obligations rather than strongly-held principles. It's not that I'm shocked, shocked that votes can be bought, but it finally made it clear to me that my vote was worthless.

Add to that Oracle's expressed intent to proceed with the SE7/8 JSRs whatever the outcome of the vote, and one can only conclude that the SE/EE EC is never going to be more than a rubber stamp for Oracle. (The belligerent tone with which this message was delivered does not come across in the public minutes, but it was loud and clear over my phone connection.)

That's not to say that I'm against the technical aspects of the JSRs. In fact, I'm a member of the Expert Group for JSR 334 ("Project Coin") and I'm participating in discussions about some of the library-related work on JSR 335 ("Project Lambda"). I think these are both good projects that will ultimately be beneficial to the Java language and libraries.

But here's a funny thing: To my own surprise, I'm coming to believe something heretical, that it actually is not all that crucial for Java to move forward, at least not to the constituency I felt that I represented on the EC, the tens of thousands of Java developers who don't work for a big company with an Oracle contract.

The big boys want big apparent forward motion because it means more stuff to sell, more contracts and control. As a result, we are whipped to a frenzy with messages (both subliminal and explicit) that Java is falling behind, losing mind-share, being lapped by C#, anything to sell the idea that more is desperately needed, when in fact most folks could make do with a lot less.

So while I think things like Project Coin and Project Lambda are worth working on, the Java ecosystem is already so amazingly rich that the absence of these features (and of all the other good things planned for SE7 and SE8) in practice doesn't get in the way of real progress for developers like me, who just want to put together maintainable, type-safe programs, taking advantage of field-tested readily-available libraries and frameworks.

It's nice to be back in the real world, writing Java code. Here's a partial list of what I'm using, besides Java:

Ant
Freemarker
Guava
Guice
Hazelcast
iText
Ivy
Jackson
JavaScript
JClouds
Joda Time
jQuery
JUnit
Mockito
Restlet
Rhino
SnakeYAML
YUI Compressor

Vote for Bob Lee and prove Doug Lea wrong!

2010-10-26T09:00:00.002-04:00

In explaining why he is not seeking another term on the JCP SE/EE Executive Committee, Doug Lea encourages us to prove him wrong about the growing irrelevance of the Java Community Process.

The best hope for proving Doug wrong lies with folks who have experience working on JSRs that weren't simply rubber stamps — and Bob Lee is the best of those folks. Bob is running for one of two open seats on the SE/EE EC against Azul, Eclipse, Google, and three others, and (if you're a member of the JCP) I urge you to vote for him.

Bob is running as an individual, which means that his votes will not be tied to the commercial and legal interests of a large corporation, but will instead reflect his personal expertise and judgment about the best interests of the Java community.

There's no denying that the JCP has been moribund for too long, and that Oracle's ham-handed moves have made the prospect of a true revitalization far less likely than anyone expected a year or so ago. But it's worth a shot, and I don't know anyone better equipped to help make that shot than Bob Lee. (Except Doug Lea, of course, but that's water under the bridge.)

Doug Lea in New York Times article

2010-08-30T10:40:00.001-04:00

Doug Lea, my colleague and co-author, is quoted in a New York Times article about the Oracle-Google patent infringement lawsuit.

Moderating Chinese comments

2010-07-13T09:14:00.000-04:00

I've been rejecting comments in Chinese whenever I can't be sure that the comment isn't spam, i.e., always. Google Translate renders them as unobjectionable but content-free, but so far none of them seem to have come from an actual person who read my post.

If you can read my blog posts and you'd like to comment in Chinese, please include an English translation.

Google Collections is dead, long live Guava!

2010-06-14T14:21:00.000-04:00

Kevin Bourrillion wants to get the word out: Google Collections is dead, long live Guava! Guava is a proper superset of Google Collections, so the passing of the latter is cause to rejoice, not mourn.

I've only scratched the surface of Guava in my own work on Seat Yourself, but I can tell already that it makes large parts of our "common" code unnecessary. Being able to replace your own code with a well-tested open source library is a wonderful thing, like getting someone else to mow the lawn for free.

In what feels to me like a dark time, as big companies privately negotiate the fate of Java and the JCP, Google's ongoing and generous investment in and championing of open Java-related technologies (Guava, GWT, GAE/J, Android, to name a few) is a welcome bright spot. Without their work ... well, I'd still be a Java developer, but I'd probably be looking for a way out.

That I'm still enthusiastic about coding in Java, in spite of the murky politics, is largely due to my friends at Google, which should tell you something.

The Minstrel Boy

2010-05-24T22:46:00.004-04:00

The Minstrel Boy, a piece I wrote nearly 25 years ago during graduate work in Computer Science at Cornell (with a minor in Music Composition), received its first public performance yesterday at the Unitarian-Universalist Congregation at Shelter Rock. I had shown the score to the music director there, Stephen Michael Smith, who has a track record of fostering new works and composers, and to my surprise and pleasure, he very quickly arranged for a group of singers—Leslie Craigie, Farah Chandu, Leslie Pirchinello, Chee Shun Tan, and Brace Negron—to perform it as part of the regular Sunday service. (Pianists Evan Solomon and Akira Eguchi assisted during rehearsals.)

The piece is a setting for SSATB (with solo sections) of Thomas Moore's poem of the same name. It's normally sung to the tune of "The Moreen", and I used that melody heavily in my setting. The composition teacher under whose supervision I wrote it, Steven Stucky, was not, I think, entirely on board with my wholesale appropriation of these existing materials—he might reasonably have felt that I should be producing my own music instead of rehashing others', at least on his watch—but I persisted anyway.

This was the second world premiere of my work in as many months: In April, TracyLynn Conner performed a song I wrote for her, as part of a American Cancer Society benefit concert.

Both of these events were big thrills for me. If you don't count my music for theater, arrangements, orchestrations, or works for personal occasions, the last time I had a world premiere was in ... 1984.

Concurrently initialized singletons in Guice

2009-11-27T10:25:00.030-05:00

William Pietri asked whether it would be possible to take advantage of concurrency and Guice's knowledge of dependencies to provide interdependent (and expensive to create) singleton services in parallel.

For example, say that service A depends on services B and C and that B and C don't know about each other (and so could be constructed concurrently). Obviously, you could explicitly construct B and C in separate tasks running in a thread pool, then construct A once B and C exist.

class A {
    A(B b, C c) { /* ... use b and c ... */ }
}

class B {
    B() { /* ... takes a long time ... */ }
}

class C {
    C() { /* ... takes a long time ... */ }
}

class Services {
    A a; B b; C c;
    void init() throws InterruptedException {
        final CountDownLatch ready = new CountDownLatch(2);
        Executor pool = Executors.newCachedThreadPool();
        pool.execute(new Runnable() {
            public void run() { b = new B(); ready.countDown(); }
        })
        pool.execute(new Runnable() {
            public void run() { c = new C(); ready.countDown(); }
        })
        ready.await();
        a = new A(b, c);
        // Now publish a, b, and c safely -- not shown.
    }
}

But it's a pain to have to orchestrate this yourself. You have to know the dependencies intimately and write a lot of tricky code. If the dependencies change, the code has to be completely rethought. Wouldn't it be nice if Guice could do this for you automatically without giving up on the opportunities for concurrency? Well, it turns out that it can.

The idea is to use a variant of singleton scope that runs the providers of all bindings for that scope in separate threads. Naturally some of these providers block in their own thread while their dependencies finish in other threads, but those services that can be constructed in parallel will be.

Here's what the Guice version looks like:

@ConcurrentSingleton
class A {
    @Inject A(B b, C c) { /* ... use b and c ... */ }
}

@ConcurrentSingleton
class B {
    @Inject B() { /* ... takes a long time ... */ }
}

@ConcurrentSingleton
class C {
    @Inject C() { /* ... takes a long time ... */ }
}

No special initialization code needed, just inject A, B, and C wherever they are needed. (Note that if you have circular dependencies, this probably won't work. So don't have circular dependencies.)

ConcurrentSingleton is just a scope annotation. The actual scope implementation is ConcurrentSingletonScope. I have a fleshed-out version of the A, B, C example, ConcurrentSingletonExample, that is slightly different from the code above; it uses Providers for B and C so that A can do some work before getting B and C in the constructor.

You aren't forced to do all the expensive work in the constructor. You could also inject a start method with injected parameters to provide needed dependencies.

In the same thread that provoked the ConcurrentSingleton response, Jesse Wilson suggested the use of the experimental lifecycle facility in Guava. This could prove useful in the current context if, for example, you have singleton services that take a while to stop and could benefit from being stopped in parallel.

Update 2009-11-30
I added a call to pool.shutdown() in the scope implementation to make sure the pool threads don't prevent the JVM from exiting. It might not be necessary, but I don't think it hurts.

Update 2010-7-3
Added explicit notice that the sources are in the public domain.

The Emperor's New Clothes

2009-10-26T00:49:00.005-04:00

I posted Ray Mason's video of The Emperor's New Clothes, a Theatre Three Children's Theatre production of a show that Jeff Sanzel and I wrote together, on my Facebook profile and my YouTube channel, broken up into scene length segments.

See the links section in the right-hand column -- you'll want to look at the YouTube version unless you're my Facebook friend, and even then you might prefer to watch the YouTube playlist, something for which there is no analogue in Facebook ... is there?

I haven't bothered to post to MySpace this time around.

Joshua Rosenblum's site

2009-09-11T10:10:00.004-04:00

Josh Rosenblum has a website worth checking out:

http://rosenblummusic.com

The site was designed and implemented by Josh's 13-year-old son, Julian.

And don't be afraid to go ahead and buy those albums! :-)

Dependency injection in Restlet 2.0 with Guice

2009-05-12T16:55:00.006-04:00

I'm very excited about Restlet 2.0, which is in testing now and scheduled for release at the end of 2009. Among other things, the newly refactored Resource API encourages more readable code through the use of a small number of annotations. Here's a very simple server-side resource:


public class DefaultResource extends ServerResource {
    @Get public String represent() {
        return "Default resource, try /hello/resource or /hello/handler";
    }
}

ServerResource has a no-arg constructor, so you don't need to pass Context, Request, and Response objects to super().

Nice as this is, I still want to inject my resources using Guice, so I've updated the Restlet-Guice classes from my previous post to support both the new ServerResources and the old Handlers. It incorporates the enhancement mentioned in the updates: You can override methods to use different providers for Application, Context, Request, and Response, although for most purposes the default providers should suffice.

Still no fancy packaging, just a zip archive of source that you can compile against Restlet 2.0 and Guice 1.0 (it would probably work with Guice 2, but I haven't tried).

Update 2009-Dec-11

I've been working on a Guice extension for Restlet as an incubator project that uses the ideas in this posting. My goal is to make this extension independent of Guice at the interface level, so that people can provide implementations for different DI frameworks, of which Guice is only the first.

Musical numbers from my shows

2008-12-15T15:52:00.013-05:00

After years of vague promises to cast members to provide a record of the shows that Jeff Sanzel and I have written together for Theatre Three children's theatre productions, I finally got up my courage to edit together the tapes I'd made into more or less coherent individual musical numbers. I've been posting them to YouTube, Facebook, and MySpace as I finish them.

The tapes were made by setting up a camera (or two) before each performance, pointing it towards the stage, turning it on, and leaving it there unattended. In some cases I also recorded a separate audio track with a decent stereo mic. There are several problems with this approach:

The camera is stationary, so any zooming or panning has to be applied after the fact. This makes for blurry closeups.

The autofocus is often confused by stage lighting changes.

Each performance is slightly different, so synching lip movements can be tricky. I got it wrong in several instances.

The mic in the camera is not as good as the separate stereo mic, and the sound quality varies depending on where the camera is placed. So only The Fairy Princess has good sound.

But I hope the end results are entertaining, if only for the performers who took part in the productions.

Eventually I'd like to create a video or sequence of videos covering an entire show, for watching in a YouTube playlist, for example. I made studio recordings of Hansel and Gretel and The Fairy Princess (and I hope to do so for The Elves and the Shoemaker), so it is possible that I could use that material for the soundtrack.

New CD: "Colloquy"

2008-09-25T09:34:00.004-04:00

I am once more proud to announce the release of a CD that I produced: Colloquy, an album of music by Gary William Friedman. And once more, I am several weeks late in my announcement. Maybe I planned it that way. Yeah, that's it.

I wrote the liner notes for this album, and I won't repeat them here, so go get a copy and read them. Or don't read them, just listen to the music -- I don't mind.

Update:

There's also a video about the making of one of the pieces on the album.

New CD: "Before Love Has Gone"

2008-07-24T17:06:00.006-04:00

I'm proud to announce the release, one month ago, of a new album from Stevie Holland, Before Love Has Gone, that I co-produced with Todd Barkan and Gary William Friedman. (The actual release date was June 24, but I kept forgetting to blog about it and decided to wait out the full month.)

Go get it and listen to it. The whole album is great, but if you're really stingy and can only spring for one tune, I recommend "Lazy Afternoon". It's phenomenal.

Update:

There's also an EPK for the album.

Resource dependency injection in Restlet via Guice

2008-07-24T15:56:00.015-04:00

(See a more recent posting on this subject.)

I have a body of code that already benefits from Guice dependency injection, and I want to migrate it from a servlet-based architecture to Restlet without losing those benefits. I've had some success, and I figured I'd report on it.

I don't mean that I wanted to use Guice to wire up an object graph of Restlets (Components, VirtualHosts, Applications, etc.). It's straightforward enough to use the builder-like API of Restlet, and such code is nicely confined in a few places where it doesn't bother the meat of the application, its resources.

What I do want is to have those resources created by Guice, so that they can be constructed with dependencies injected into them. With the Finder approach, resource constructors get a Context, a Request, and a Response, but that's it. I suppose I could find a way to stash an Injector in one of these so that resources could look up the dependencies they need, but I wanted something more direct. I came up with the following scheme, which seems to be working pretty well:

I use a custom Finder that knows how to look up a Handler/Resource by class or Guice key -- instances of these custom Finders are provided by a FinderFactory:


public interface FinderFactory {
    Finder finderFor(Key<? extends Handler> key);
    Finder finderFor(Class<? extends Handler> cls);
}

The class RestletGuice has static methods named createInjector that parallel those of the Guice class. The difference is that it adds bindings for Context, Request, Response, and FinderFactory. In my Guiced version of the FirstStepsApplication from restlet.org, the following lines create an Injector with some bindings and then look up the FinderFactory that will produce Finders that will be able to make use of those bindings. (These bindings are not necessarily good practice; they just demonstrate the technique.)


    Injector injector = RestletGuice.createInjector(new AbstractModule() {
        public void configure() {
            bind(Handler.class)
                .annotatedWith(HelloWorld.class)
                .to(HelloWorldResource.class);
            bindConstant()
                .annotatedWith(named(HelloWorldResource.HELLO_MSG))
                .to("Hello, Restlet-Guice!");
        }
    });
    FinderFactory factory = injector.getInstance(FinderFactory.class);

HelloWorldResource is slightly changed. It has a private final field, msg, that is used to generate the text representation. The msg field is initialized via an injected value.


    @Inject public HelloWorldResource(@Named(HELLO_MSG) String msg,
                                      Request request,
                                      Response response,
                                      Context context) {
        super(context, request, response);
        this.msg = msg;
        getVariants().add(new Variant(MediaType.TEXT_PLAIN));
    }
    static final String HELLO_MSG = "hello.message";

This all comes together in the Application class when attaching a Finder for the default routing.


    Finder finder = factory.finderFor(Key.get(Handler.class, HelloWorld.class));
    Router router = new Router(getContext());
    router.attachDefault(finder);
    return router;

I read this as "Route any request for this application to whatever resource is bound to @HelloWorld-annotated Handlers, injecting that resource's dependencies," which was exactly what I wanted.

For those who don't want to have to call a special RestletGuice method, there is a public class FinderFactoryModule extending AbstractModule that can be used with Guice.createInjector(...) to get the same effect.

FinderFactoryModule also implements FinderFactory, so you can construct an instance in your Restlet wiring code and use it right away. You can then use the FinderFactoryModule to create an injector explicitly.

As a special convenience, if you don't use a FinderFactoryModule to create an injector, one will be created implicitly the first time one of its Finders is used to find a target Handler/Resource. This encourages a style where each Application gets its own implicit Injector by creating a local FinderFactoryModule and using it to create Finders.

That's basically it. It works with plain Guice 1.0 and Restlet 1.1 (since it uses Handler as the base type for all Resources). I haven't had time to package it nicely, but you can follow the links below for the actual code.

Sources:
FinderFactory.java
FinderFactoryModule.java
RestletGuice.java

Example:
FirstStepsApplication.java
HelloWorld.java
HelloWorldResource.java
Main.java

Update (August 2008)

Chris Lee discovered that Context.getCurrent() doesn't work reliably as of 1.1m5; the workaround is to use Application.getCurrent().getContext(). A more comprehensive fix, that I hope to post soon, would involve letting subclasses of FinderFactoryModule override the methods that create the Providers for Request, Response, and Context.

Update (2009-Feb-3)

Leigh Klotz has a workaround for using Guice Finders with WadlApplication. And I still haven't had time to package any of this more nicely. (Feb 7: Jérôme Louvel took Leigh's suggestion and checked it in on the Restlet trunk.)

Concert at Kosciuszko Hall

2008-04-22T10:12:00.005-04:00

I attended a lovely concert at Kosciuszko Hall in Manhattan on Monday night. Cellist Mairi Dorman-Phaneuf and composer-pianist Joshua Rosenblum performed works by Schumann, Brahms, de Falla, Prokofieff, Rosenblum, Bolling, and others, assisted by soprano Joanne Lessner, bassist Bill Ellison, drummer Bruce Doctor, and special guest Julia Murney.

Mairi's particular interest (she referred to it as an obsession) is in performing songs with the cello taking the voice part, and she made a compelling case for her obsession in the songs of Schumann, Brahms, and de Falla. I particularly liked Brahms' Wie Melodien.

The concert included the world premiere of Josh Rosenblum's setting for soprano, cello, piano, and contrabass of T. S. Eliot's poem, The Love Song of J. Alfred Prufrock. I liked it a lot, and I hope to make a recording of it soon so it can be shared with others.

I was very pleased to see that the three CDs on sale in the lobby were all produced (or co-produced) by me! Not surprising, of course, because they all feature Josh Rosenblum's music:

There is another Peierls-produced Rosenblum album, Impetuosities, but it wasn't on sale at the concert.

Another world premiere of Josh's music can be heard at the upcoming performance of the dance company, The Chase Brock Experience. Chase Brock commissioned a ballet from Josh, and I produced a recording of the piece for use during the performance. It's called ... are you ready? ... Cut to the Chase.

Magic in the City

2008-02-02T16:51:00.001-05:00

If you're looking to hire a magician for a New York City area children's birthday party, Jazzo the Great comes highly recommended:

The Red and the Green

2008-01-16T15:05:00.001-05:00

So wine tastes better with an expensive price tag. And I thought I just had good taste.

Wilma-a-a-a-a

2007-11-29T19:16:00.000-05:00

There are two kinds of people: those who quote the Red Dwarf going-to-bed-with-Wilma-Flintstone line in their signatures, and those who have gotten over it.

Yes, it's funny. But not that funny.

Concurrency issues in Restlet

2007-11-05T15:18:00.000-05:00

Issue #368 in the Restlet issue tracker was originally focused on the Guard class. Since then, I've taken a look at the rest of the org.restlet package and found that the fields of most classes are accessed without appropriate synchronization. [Update 2008-Feb-6: All of these have been fixed as of Restlet 1.1 M1.]

Most of these problems would disappear if the fields could be final, but that would mean taking away setter-injectability.

There is hope, however: Methods that are used only for setter injection (and not, for example, used to reconfigure an instance dynamically), should be documented as setter-injection-only, meaning they must not be called after the instance has been (safely) published. Fields set by such methods get their values before publication, and those values never change; such fields are effectively immutable. I don't know of any standard documentation conventions for this, but the important thing is to decide for each non-final, non-volatile field whether it is truly mutable or only setter-injected before publication.

I have a long-standing gripe about the Spring documentation that it doesn't state, at least not in terms that I recognize, under what conditions beans are safely published. The vanilla use cases (standard ApplicationContext implementations) are almost certainly fine, but if you have any doubts about whether your dependency injection framework can guarantee safe publication, then you should either guard your setter-injected fields with a lock or make them volatile. I have a personal preference for using volatile in this case, but most of my Java Concurrency in Practice co-authors have the opposite preference.

Even if you're fairly confident about your DI framework's guarantees, it is never wrong to guard field access or make a field volatile, only potentially wasteful. For a framework like Restlet that should be usable in any DI context, I think it would be prudent to assume the worst of that context.

But is setter injection really necessary? Most of the injected fields are of distinct types, so constructor injection in Spring would be straightforward. Getting rid of setter injection entirely would allow most, if not all, fields to be final, which would greatly reduce the risk of concurrency problems in Restlet.

Babel

2007-10-13T16:19:00.000-04:00

Jeffrey Sanzel writes (referring to this posting):

Here are the words I understood on your blog:

blog
Tim
Peierls (to an extent)
A (in context)
of (in context)
There
All

Basic rules for @ThreadSafe classes

2007-10-09T16:27:00.000-04:00

Some rules for classes to be annotated with @ThreadSafe:

All non-final, non-volatile fields (and final references to non-thread-safe state) must be annotated with @GuardedBy(x), where x is usually this, meaning that all access to the field -- reads and writes -- is performed within a synchronized (this) block or synchronized method. [This is probably the hardest rule for people to accept; it's not intuitive that reads must be performed with a lock held. See amplification below.]

If two fields annotated with @GuardedBy participate in the same class invariant, they must be annotated with the same argument to @GuardedBy. [This is trivially satisfied if you only use @GuardedBy("this").]

All compound actions with atomic semantics (e.g., check-then-act and read-modify-write sequences) must be performed completely within a synchronized block or method. [This is what many people incorrectly think is the only reason to use synchronized.]

Do not make calls to code whose synchronization properties you don't know or control from inside a synchronized block or method; prefer open calls (calls made with no locks held). [This is a strategy for deadlock avoidance.]

Prefer final fields. For collection fields, prefer thread-safe collections. (But don't bother using a thread-safe collection if the field needs to be @GuardedBy for some other reason.)

Prefer final atomic variables to volatiles. Volatile fields cannot be modified atomically without a synchronized block.

There need be no special relationship between x and y in "@GuardedBy(x) Type y;" as long as all access to y is made while holding x's lock.

Don't be too clever: even if your clever reasoning is correct right now, it will be harder in the future for others (and you) to understand and maintain the code that relies on that reasoning.

Amplification

Brian Goetz suggests that I make this point more strongly: Not only do you need to declare such fields @GuardedBy(lock), you have to acquire lock every time you access the field in any way.

Concurrency discussion in Restlet community

2007-10-09T09:24:00.000-04:00

I started a thread on concurrency issues in the Restlet framework, and it led to a several people saying nice things about Java Concurrency in Practice.

Jérôme Louvel's responsiveness to these issues is gratifying. A far cry from the huffiness I provoked when I had the temerity to question the concurrency guarantees in Spring!

Java Concurrency in Practice news

2007-09-16T13:52:00.000-04:00

I'm told that Java Concurrency in Practice is going into its fifth printing!

Custom Matcher and MethodInterceptor for DWR-Guice

2007-09-16T12:59:00.000-04:00

I wanted a way to intercept calls to public methods of a remoted interface so I could replace my use of bindFilter with bindInterceptor, as described in an earlier posting.

At first I thought I could just use the static methods in Matchers:


bindInterceptor(
  only(MyService.class), 
  any(), 
  myInterceptor
);

This doesn't intercept anything, because MyService is an interface. What I needed was to intercept calls to a method of a subclass of MyService for which there exists a method of the same name and argument types in MyService.


bindInterceptor(
  subclassesOf(MyService.class), 
  declaredBy(MyService.class),
  myInterceptor
);

The subclassesOf matcher is already provided in com.google.inject.matcher.Matchers, but I had to roll my own declaredBy method matcher. Here's the heart of the implementation (cls is a final Class<?> field, initialized from the argument to declaredBy):


public boolean matches(Method method) {
  try {
    // Matches if the method is from a subclass 
    // of the given class (or the class itself) 
    // and the given class declares a method
    // with the same name and parameter types. 
    if (cls.isAssignableFrom(
             method.getDeclaringClass())) {
      // Return value of getDeclaredMethod 
      // is ignored. It throws an exception 
      // if the method is not found.
      cls.getDeclaredMethod(
        method.getName(), 
        method.getParameterTypes());
      return true;
    }
    // fall through
  } catch (NoSuchMethodException e) {
    // fall through
  } catch (SecurityException e) {
    // fall through
  }
  return false;
}

This still didn't work quite right; the implementation of one method called another public method of the interface, and that call was intercepted even though it wasn't a remote call. To mimic AjaxFilter, I want to able to intercept only the outermost call. I wrote a MethodInterceptor-decorator:


public class OutermostCallInterceptor 
    implements MethodInterceptor {
  /**
   * Decorates a MethodInterceptor so that only the 
   * outermost invocation using that interceptor will 
   * be intercepted and nested invocations willbe 
   * ignored.
   */ 
  public static MethodInterceptor outermostCall(
      MethodInterceptor interceptor) {
    return new OutermostCallInterceptor(interceptor);
  }

  /** Ensure underlying interceptor is injected. */
  @Inject void injectInterceptor(Injector injector) {
    injector.injectMembers(interceptor);
  }

  public Object invoke(MethodInvocation invocation) 
      throws Throwable {
    int savedCount = count.get();
    count.set(savedCount + 1);
    try {
        if (count.get() > 1) 
          return invocation.proceed();
        else 
          return interceptor.invoke(invocation);
    } finally {
      count.set(savedCount);
    }
  }

  private OutermostCallInterceptor(
      MethodInterceptor interceptor) {
    this.interceptor = interceptor;
  }

  private final MethodInterceptor interceptor;

  private final ThreadLocal count = 
    new ThreadLocal() {
      @Override protected Integer initialValue() {
        return 0;
      }
    };
}

So now my binding looks like this:


bindInterceptor(
  subclassesOf(MyService.class), 
  declaredBy(MyService.class),
  outermostCall(myInterceptor)
);

and myInterceptor is injected. It's not as compact as using bindFilter, but I can apply multiple interceptors without having to resort to FluentConfigurator. The use of subclassesOf is probably redundant, since declaredBy checks that the method is from a subclass of MyService, but I think it helps to clarify what's going on.

Replacing AjaxFilter with MethodInterceptor

2007-09-15T23:41:00.000-04:00

I wrote the previous posting without referring to DWR-Guice integration but in practice I extended org.directwebremoting.guice.AbstractDwrModule, not com.google.inject.AbstractModule.

For DWR-Guice users, the nice thing about injectable method interceptors is that you can use them to replace most uses of AjaxFilter, which is a good thing because the AjaxFilter support in the DWR-Guice stuff is weak (mea culpa).

I had to write some support utilities to get the right effect, but now I can do something like this:

bindInterceptor(
 subclassesOf(VulnerableService.class), // class matcher
 declaredBy(VulnerableService.class),   // method matcher
 // prevent nested interception
 outermostCall(new AuthenticationInterceptor()),
 outermostCall(new AuthorizationInterceptor())
);

and AuthenticationInterceptor is injected, so that it can look like
this:

class AuthenticationInterceptor 
    implements MethodInterceptor {
 @Inject Provider<RequestParameters> reqParmsProvider;
 @Inject Provider<AuthenticationService> authSvcProvider;
 public Object invoke(MethodInvocation invocation) 
     throws Throwable {
   RequestParameters reqParms = reqParmsProvider.get();
   AuthenticationService authSvc = authSvcProvider.get();
   if (authSvc.authenticate(reqParms))
     return invocation.proceed();
   else
     throw new AuthenticationException(reqParms);
 }
}

The subclassesOf matcher is part of Guice. The declaredBy matcher and the outermostCall interceptor decorator are custom implementations that I'll describe in a later posting.

Injecting method interceptors in Guice 1.0

2007-09-14T23:57:00.001-04:00

Guice 1.1 will probably have injected method interceptors, but until then those of us who need this kind of thing will have to roll our own.

[Update 2009-1-3] Guice 2 has (or will have, depending on how you view its release status) a requestInjection facility.

The way I've been doing it is similar to the way Stuart McCulloch suggested, but more automatic: I extend AbstractModule by

adding a registerForInjection method that takes a varargs array of objects that should be injected and
overriding bindInterceptor to call registerForInjection(interceptors) before calling the superclass implementation.

The implementation of registerForInjection adds the elements of the array argument to a set of objects to be injected. There is a private method, injectRegisteredObjects, marked with @Inject; all it does is call Injector.injectMembers on every element of this set.

To ensure that injectRegisteredObjects is called, I bind the module class to the module instance. Since I want to be able to do this for every instance of the module, I bind with a unique annotation instance each time. The private method ensureSelfInjection does this binding once only for each module instance, so I can safely call it in registerForInjection.

Here's the code:

/**

 * An extension of AbstractModule that provides
* support for member injection of instances
* constructed at bind-time; in particular,
* itself and MethodInterceptors.
*/
public abstract class ExtendedModule extends AbstractModule {

 /**
  * Overridden version of bindInterceptor that,
  * in addition to the standard behavior,
  * arranges for field and method injection of
  * each MethodInterceptor in {@code interceptors}.
  */
 @Override public void bindInterceptor(Matcher<? super Class<?>> classMatcher,
                                       Matcher<? super Method> methodMatcher,
                                       MethodInterceptor... interceptors) {
   registerForInjection(interceptors);
   super.bindInterceptor(classMatcher, methodMatcher, interceptors);
 }

 /**
  * Arranges for this module and each of the given
  * objects (if any) to be field and method injected
  * when the Injector is created. It is safe to call
  * this method more than once, and it is safe
  * to call it more than once on the same object(s).
  */
 protected <T> void registerForInjection(T... objects) {
   ensureSelfInjection();
   if (objects != null) {
     for (T object : objects) {
       if (object != null) toBeInjected.add(object);
     }
   }
 }

 @Inject private void injectRegisteredObjects(Injector injector) {
   for (Object injectee : toBeInjected) {
     injector.injectMembers(injectee);
   }
 }

 private void ensureSelfInjection() {
   if (!selfInjectionInitialized) {
     bind(ExtendedModule.class)
       .annotatedWith(getUniqueAnnotation())
       .toInstance(this);
     selfInjectionInitialized = true;
   }
 }

 private final Set<Object> toBeInjected = new HashSet<Object>();
  
 private boolean selfInjectionInitialized = false;  

 /**
  * Hack to ensure unique Keys for binding different
  * instances of ExtendedModule. The prefix is chosen
  * to reduce the chances of a conflict with some other
  * use of @Named. A better solution would be to invent
  * an Annotation for just this purpose.
  */
 private static Annotation getUniqueAnnotation() {
   return named("ExtendedModule-" + count.incrementAndGet());
 }

 private static final AtomicInteger count = new AtomicInteger();
}

There's a follow-up posting on DWR-Guice applications.

Children's show opening

2007-07-06T20:20:00.000-04:00

The Fairy Princess, a children's show that Jeffrey E. Sanzel and I wrote, opened today at Theatre Three in Port Jefferson. It runs Fridays and Saturdays at 11am throughout July.

Fifth of July

2007-07-05T07:21:00.001-04:00

It would have been more appropriate to post this yesterday, I suppose:

Michele Oliver blogged about the song "This is America", on which Ilene and I can be heard as part of the backing chorus near the end of the song. It was recorded in 2001, partly in response to the 9/11 attacks.

A Guice utility for binding to legacy classes

2007-04-12T17:53:00.000-04:00

You're going along, happily Guicing your world, when you run into a snag. There's a class Legacy that you'd like to be able to bind things to, but you can't edit the source to add the @Inject annotations. It looks like this:


public class Legacy implements SomeInterface {
 public Legacy(LegacyDependency dep, String str) {
   ...
 }
 public void initialize(LegacyConfig cfg) {
   ...
 }
 ...
}

And you wish it looked like this:


public class Legacy implements SomeInterface {
 @Inject public Legacy(LegacyDependency dep,
                       @MyAnnotation String str) {
   ...
 }
 @Inject public void initialize(LegacyConfig cfg) {
   ...
 }
 ...
}

You're used to Guice by now, so right away you think, "No problem, I'll use a Provider!"


public class LegacyProvider
     implements Provider<Legacy> {

 public Legacy get() {
   Legacy result = new Legacy(dep, str);
   result.initialize(cfg);
   return result;
 }

 @Inject LegacyDependency dep;
 @Inject @MyAnnotation String str;
 @Inject LegacyConfig cfg;
}

...

 protected void configure() {
   bind(SomeInterface.class)
     .toProvider(LegacyProvider.class)
     .in(WEB_APPLICATION_SCOPE);
 }

So you've written a Provider<Legacy>, and it works. But now you have this extra class to maintain. It's not complicated, in fact it's quite trivial. It seems like something you shouldn't have had to write. You'd rather write something like this:


 bind(SomeInterface.class)
   .toProvider(

     fromConstructor(Legacy.class,
       Key.get(LegacyDependency.class),
       Key.get(String.class, MyAnnotation.class))

     .injecting("initialize",
       Key.get(LegacyConfig.class))

     )

   .in(WEB_APPLICATION_SCOPE);

If this looks like something you want, check out my implementation in the DWR-Guice integration sources. The javadocs are there, too, but they aren't complete. It doesn't have anything to do with DWR, but it seems like a nice convenience to provide.

There are also several flavors of factory-method-based providers, so you don't have to write a special provider just to call a factory method.

I wrote it because even though I've been able to jettison a lot of baggage as I migrate from Spring to Guice, there are still Spring things I want to keep using, like JavaMailSender. I don't want to have to write provider implementations for each one.

Guice support in DWR

2007-04-05T08:55:00.001-04:00

Guice is the hot new dependency injection framework from Bob Lee and others at Google. DWR is a system for remoting Java server-side objects as JavaScript client-side objects in a way that is natural on both the client and server sides.

I'd been using DWR with Spring to wire together all the components of the Seat Yourself on-line ticket sales web application for almost a year and I was pretty happy with the combination. Then a few weeks ago, just as I was considering how to make the webapp more easily configurable, to support rapid administration and self-configuration of many customers, Josh Bloch suggested I take a look at Guice, and I suddenly realized just how fragile and unmaintainable was all that XML I had written for DWR and Spring.

Of course I could use Guice without integrating it with DWR, but one of the things that had always bothered me about DWR (and many other tools, not just DWR) was that everything -- remoted objects, data transfer objects, extension classes -- has to be concrete and public, with a public parameterless constructor, and everything works through setter injection, which makes things difficult. I want to work in terms of interfaces, with implementation classes that have final fields for injected state.

Guice looked like a way to have it all: easy remoting with type-safe (pure Java) configuration. I wrote a Guice integration package for DWR, and Joe Walker signed me on as a DWR contributor so I can help maintain it as part of the DWR distribution. The package Javadoc describes how to use it along with a simple example.

I'm still in the early stages of applying it to the Seat Yourself web sales application, but already the power of Guice has made things simpler. Each customer (where a customer is ticket-selling entity, like a theater) is associated with a domain where all their data -- seat charts, performance information, pricing information, patrons and their reservations, and holds on seats -- is maintained. When a user visits the web store to buy tickets, the link contains a domain name, e.g., "t3" for Theatre Three. Before Guice support, I had devised a complicated system using reflection and proxying to route the user request to the appropriate service object. It was so involved that I had trouble explaining it to my partners, both smart people. Not being able to explain something is a bad code smell.

With Guice-injected remoted objects, I can define a new scope, domain scope, where the details of providing the appropriate domain-specific service object are neatly encapsulated and managed by Guice. All I have to do is write something like this in my binding code:


bindRemotedAs("Tix", WebstoreService.class) // interface
  .to(WebstoreServiceImpl.class)            // impl
  .in(DomainScopes.DOMAIN);                 // scope

where the interface looks like this:


public interface WebstoreService {
  PerformanceAvailability getPerformanceAvailability();
  ...
}

Only the methods of WebstoreService are exposed to the world, even though the implementation class might have other public methods. With the Guice support, I don't need to specify which methods to expose. As usual with DWR, on the JavaScript side I can write things like:


Tix.getPerformanceAvailability({
  callback : function(availability) {
    notifyPerformanceAvailabilityReceived(availability)
  },
  exceptionHandler : ...
});

Because Guice has Spring integration, I can migrate my existing Spring-based code smoothly. Because it has JNDI integration, I can rewrite the code that manages the domain-specific configuration to use whatever LDAP back-end I like, instead of having to maintain an assortment of XML files and registry settings. We've already had problems with syntax errors in the XML configuration files, so this will save us a lot of heartache.

Guice also has support for AOP Alliance method interceptors, which means that on most of the occasions when I would feel most tempted to use AspectJ, I can stick to pure Java. Not that I have anything against AspectJ, but it's a different language and one more thing to worry about. I want to save it for the occasions when I really need it (as was the case for another submodule of our project).

Blurb in Yale Alumni Magazine

2007-01-10T22:24:00.001-05:00

The class notes section of the current issue of the Yale Alumni Magazine includes some notes I submitted in the fall.

Tim Peierls (JE) (tim@peierls.net) writes that 2006 was exceptionally busy, with his hand in a wide range of diverse ventures: "I helped produce fellow JEer Josh Rosenblum's musical show, Bush is Bad; the title says it all. I co-wrote a book, Java Concurrency in Practice (Addison-Wesley). If the title makes sense to you, then you need the book; if not, then ... not. I co-produced (with Gary William Friedman) an album by jazz vocalist Stevie Holland, More Than Words Can Say. And I developed an online ticket sales application that went into production in November. See www.SeatYourself.biz for details."

Rescued from Nokia

2006-12-07T16:18:00.000-05:00

I had been unable/unwilling to download the many photos I had accumulated on my old Nokia phone. Today, however, I put the Treo head-to-head (well, head-to-side) with the Nokia, and I transferred them all over IR to the Treo, then down to the PC, then up to my public gallery with Picasa.

For example, this was my phone's background for a long time:

The full album:

Rescued from Nokia

Grinch opening

2006-12-04T07:14:00.000-05:00

I posted about opening night at the new Grinch musical on the BoxPop site.

[update 2007-Sep-15]

That link might be down for good, so here's what I posted:

The new Broadway production of How the Grinch Stole Christmas opened on November 8, my birthday. My friend Josh Rosenblum is the musical director for the show. As a birthday present he got my family in on opening night, including passes to the opening night party across the street at Madame Tussaud’s wax museum.

The show runs about 75 minutes, with no intermission. It was mostly not my cup of tea, but both of my kids were riveted and said they would like to see it again. In addition to providing music direction, Josh wrote some of the incidental music and did the vocal arrangements; there were several lovely moments of multipart singing, which is what I go for. There was also one very funny line that I’m told was an ad lib during rehearsals; I won’t give it away, but I’ll mention that it happens just before Cindy Lou Who’s big number.

The party at Madame Tussaud’s was huge. I had never been to a wax museum before, so I had what I gather is the usual reaction of mistaking wax figures for real people and vice versa. I would have liked to stay longer, but we discovered that Tessa, our oldest, is afraid of wax figures, so we had to hustle through quickly and miss a lot.

Inspired by Natto blog

2006-09-02T11:56:00.000-04:00

I created this blog because it seemed like the easiest way to post a comment on The Natto Project.