Monday, June 29, 2009

Dependency Trap - Hessian, Spring, Tapestry

A project I'm doing some work with is using Hessian, Spring and Tapestry, and we've just discovered that we're deep in a dependency trap, as follows:

  1. Hessian, a binary remote-invocation protocol written by Caucho, avoids cycles and reduces bandwidth by only serializing objects once per request by using object references. Unfortunately, hessian-flex 3.2.0 and below have a problem with references such that they have a tendency to point to the wrong object. (See: my initial report of a bug in references, confirmation of references bug).
  2. There's a new version of hessian-flex, hessian-flex-4.0.0, which solves this reference problem, but it's only compatible with hessian-3.2.1 and above. (See: hessian-flex-4.0 posted)
  3. Hessian-3.2.1 and above do not work with the Spring Framework's remoting framework in Spring 2.5.6; there's been some motion to resolve this in Spring 3.X, but that may not be complete. Further, hessian-3.2.1 itself has a bug. (See: summary of the current state, spring-framework bug for supporting later hessian versions, hessian null-pointer bug)
  4. Tapestry-spring, which integrates the spring framework's context into Tapestry's IoC, apparently doesn't play well with Spring 3.x. (See: T5.1/Spring/Antlr issue, another issue I posted myself, but which isn't yet in the list archives).
So, we can:
  1. Continue with the dependencies we have, which leave us with broken hessian references.
  2. Upgrade to a newer hessian-flex, which requires a newer spring framework, possibly one that isn't even made yet, and which isn't compatible with Tapestry.
  3. Fix hessian-flex-3.2.0 ourselves to avoid the reference issue.
  4. Write our own hessian remoting (or patch existing) for springframework 2.5.6 to export services using hessian-3.2.1.
  5. Fix tapestry-spring to work with Spring 3.x.
  6. Abandon hessian in favor of Spring-BlazeDS.
  7. Other equally painful choices, probably.
It's always nice to have choices.

2 comments:

Unknown said...

The Tapestry-Spring integration code is not complex; perhaps you could fork it to account for Spring 3 changes?

Geoffrey Wiseman said...

Yes, Option 5 above. I suspect it's not a big deal, if the other bits were sufficiently resolved. If that were the only problem rather than the final nail in the coffin, I'd probably just dive into that. ;)