Maven Versioning

Managing version numbers in Maven has always been an extreme hassle. Especially when it comes time to upgrade components.

I don't know why I've never found it before, but the Maven Versions Plugin can deal with much of that for you. Check it out!

Type Coercion failed no more

We recently upgrade from Flex 3.2 to Flex 3.5, and ran into a slew of mysterious type coercion errors.

Type Coercion failed: cannot convert Object@... to com.mycompany.myapp.MyDto

Executive summary: if you have a loadable module that gets loaded, unloaded, reloaded, and you use RemoteClass for annotating DTO's for BlazeDS or LDS, then you're going to have some Type Coercion issues after the reload. In the preinitialize method of your module, you need to manually register your classes using registerClassAlias.

A bit of context about our application. First we load a generalized shell of a console, which can then loads within it one of many Modules that runs different applications. Depending on what the user does, different modules get loaded and unloaded at run-time.

Our module makes heavy use of BlazeDS for communication with the back-end Java server. The objects we were getting the type conversion errors on were always our DTO objects, which were marked with the RemoteClass metadata tag for serializing to/from the server with BlazeDS. And the error always seemed to happen during de-serialization.

Things always worked fine the first time the module was loaded. But if it got unloaded and re-loaded, then the Type Coercion errors would start happening.

Googling about the problem usually led us down the path of people having problems with multi-version applications, and the solutions were usually to put the definitions of your remote classes into the main .swf. We don't have a multi-version application (we load, unload, reload the same .swf), and we can't modify the main .swf (it's owned by another team. Anyways, it runs lots of apps and can't reasonably pull in our app specific classes).

So I got to thinking about the problem. We knew that when the module gets reloaded, it gets loaded into a new ApplicationDomain. For whatever reason, when messages get returned from the server back to the client, our best guess was that it was still building objects using the classes from the ApplicationDomain from the first load. The profile confirmed that the old classes were still loaded, and weren't being garbage collected, in spite of our best efforts.

RemoteClass was a bit mystical and magical, but StackOverflow has deeper magic. Discovering that all RemoteClass does is invoke registerClassAlias for you, it was reasonable to think that it wasn't working properly on the subsequent loads.

So a quick trial using registerClassAlias instead of RemoteClass, and the Type Coercion errors go away. Voila!

Collatz

After seeing the xkcd on the Collatz Conjecture, I had to write an example in Scala.

def collatz(n:BigInt):Stream[BigInt] =
if (n == 1) {
   Stream(1);
} else {
   def next(n:BigInt):BigInt = if ((n % 2) == 0) (n / 2) else (n * 3 + 1);
   Stream.cons(n, collatz(next(n)));
}

That was a fun little diversion!

A little less noise, please.

If you work in big corporate America, like I somehow find myself these days, then the server hosting your Git depot has a really annoying /etc/issue file, which you see every time you clone/push/pull/fetch. In my case, it's 20+ lines of noise.

Finally found the magic to suppress the issue. Put the following lines in your ~/ssh/config file.

Host git-depot-server
LogLevel ERROR

Enjoy :-)

IDEA + git, without the passwords

Git is my new favorite in source control. IntelliJ IDEA has long been my favorite IDE.

A nuisance lately has been IDEA prompting me for my SSH key password every time I Commit and Push. Since forever, Ubuntu has added my key to ssh-agent every time I login, giving me both good security and password-less pushing from the command line.

I finally found the config tweak to push from IntelliJ without the prompt.

Settings-->Version Control-->VCSs-->Git
SSH Executable: Native

By using the native SSH client, you take advantage of native key management, like ssh-agent.

Agreement

Yes! I mean No! I mean I Agree!

in reference to:

"Any statics whatsoever Implementation inheritance (subclassing) Primitives Unnecessary boilerplate"
- noop - Project Hosting on Google Code (view on Google Sidewiki)

Mouse broke in Fedora 9? Here's a fix!

Last Friday, I was greeted by the unfortunately behaviour that my mouse stopped working. I checked my yum logs, and the culprit looked to be some recent updates to Xorg.

Looks like I guessed correctly. Someone was nice enough to post details about the problem, and how to fix it.

Thank you twilightomni!