Staying Flexible: Develop in Another Environment

I've been doing a little work on a Firefox Extension lately, and I've gotta say, it's stretching me in very different ways compared to the development work that I usually do. That's true of any environment that's new to you.

In any environment where you do a lot of development, you reach a point where everything is either pretty clear, or at least pretty familiar. It's true that I've never written a line of Struts code, but having done work in several other Java web development environment, I'm pretty sure that I could pick up Struts with a minimum of confusion.

The same isn't true of building a firefox extension -- I don't have a broad knowledge base to fall back on. It just took me about an hour to get a shortcut key added to a sidebar, even with a working example, and I'm still not entirely sure how working bit of XUL differs from the original bit of XUL that wasn't, for reasons unknown, working.

While it's a little frustrating not knowing what I'm doing, and wishing the documentation were better, at the same time, I'm inclined to believe that doing some work in another environment is good for me, increases my flexibility, and my sense for the available options.

PURE + AJAX + REST + JSON Web Framework

I am imagining a web framework that delivered static HTML which made data requests to the server using AJAX to REST services that returned JSON, which were mapped into the HTML using PURE.

I'm curious to see what working in that kind of structure would be like. Seems very tightly compartmentalized, quite possibly in a good way.

In particular, I'm not totally sold on the idea that interleaving application data with HTML on the server-side is the right approach - sending down a clean, cacheable template of HTML (possibly still generated on the server-side to put components together and so forth), and then sending down a really thin data representation and having the client interleave the two seems appealing, and I haven't yet worked with a web framework that goes in that direction.

Apache Geronimo, Still Interesting, Still Troubling

I tried Apache Geronimo a little bit in the 1.0 era, mostly just to see what all the talk was about. It looked like it had some interesting concepts, but had a lot of rough edges, and for the most part, I get along with simple web containers like Tomcat, so I stopped playing with it.

I recently had the need to fire up an integration test with a web container and messaging queue, so I thought I'd try Apache Geronimo again, see if it was the right tool for the job. So, Wednesday morning, I took a quick peek at Cargo's integration for Geronimo, and decided it was unsuitable, then spent the remainder of the day with the Geronimo plugin. There were a few minor documentation warts, nothing serious, but enough to delay me 'til mid-morning on Thursday while I sorted it all out.

By Thursday end-of-day, I had a Maven configuration that would start up Geronimo before the integration tests and tear it down afterwards. That seemed to work fine, but deploying our applications to Geronimo didn't.

I took the first part of Friday to re-verify that Tomcat 6.X and ActiveMQ could, independently of Geronimo, deploy and functionally test our modules, and, yes, they could. The rest of Friday was spent trying to make Geronimo do the same, either geronimo-jetty6-javaee5, geronimo-tomcat6-javaee5 or a custom assembly. Every configuration we tried had some subtle inability to either deploy or startup several of our modules.

Now, I can't blame Geronimo outright -- I don't know what the problem is, there could be some issues with our WARs that don't show up in our usual deployments, or some problem with one of the many modules that Geronimo includes, but ultimately, if it takes more than a day to deploy a few WARs in an application server, I'm starting to be a little concerned.

Geronimo has some interesting ideas, but I end up feeling like it still has too many rough edges for me. Maybe I'll try again with 3.X?