Fixing Hessian Flex 3.2.0 References

If you're using Hessian Flex 3.2.0 and you'd like to fix the problem with references, the following one-line fix seems to do the job for me:

$ svn diff
Index: src/main/flex/hessian/io/Hessian2Input.as
===================================================================
--- src/main/flex/hessian/io/Hessian2Input.as (revision 1172)
+++ src/main/flex/hessian/io/Hessian2Input.as (working copy)
@@ -129,9 +129,10 @@
     public override function init(di:IDataInput):void
     {
       _di = di;
       _buffer = new ByteArray();
       _offset = 0;
       _length = 0;
+      _refs = null;
     }

Basically, HessianOperation hangs on to a Hessian2Input class between invocations, and calls init() to clear out the state before using the class for another invocation. The init() doesn't currently clear the reference cache. By setting _refs to null, you clear the cache and Hessian2Input will simply instantiate a new array in its place if and when it needs to do so.

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.

Flex Builder 3 on Eclipse 3.5 (Gallileo) on OS X?

I spent a little time this morning trying to get FlexBuilder 3 up and running in Eclipse 3.5 (Gallileo). A little experimentation and reading implied that getting it up in the Cocoa version of Eclipse wasn't going to happen.

I then tried a few more times with Eclipse 3.5 carbon, and still wasn't able to get it working. So if you've managed to get FlexBuilder 3.X up and running on Eclipse 3.5 on OS X, I'd be happy to hear more.

Caucho's OSGi Pains

Earlier this month, I commented on Atlassian's OSGi experiences, and how it seemed that most of these experiences recount the pain of getting up-close-and-personal with OSGi. I've just noticed that Caucho has a similar tale of woe; they considered using OSGi within their application server and eventually rejected it, at least for the time being.

Now, you could of course argue that this a way for Caucho to explain the lack of OSGi support within their application server. I'm not trying to position their tale in any way. I don't have enough OSGi experience to agree or disagree with the points they raise, I'm just trying to synthesize from the experiences of others, and that seems to come down to this:

If you read detailed adventures of people's experiences with OSGi, it seems to come with a fair amount of pain, so keep that in mind when you're looking at OSGi for your own purposes.